* [PATCH] arm64: kpti: Fix the interaction between ASID switching and software PAN
From: James Morse @ 2018-01-12 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112123043.43535-1-catalin.marinas@arm.com>
Hi Catalin,
On 12/01/18 12:30, Catalin Marinas wrote:
> With ARM64_SW_TTBR0_PAN enabled, the exception entry code checks the
> active ASID to decide whether user access was enabled (non-zero ASID)
> when the exception was taken. On return from exception, if user access
> was previously disabled, it re-instates TTBR0_EL1 from the per-thread
> saved value (updated in switch_mm() or efi_set_pgd()).
>
> Commit 7655abb95386 ("arm64: mm: Move ASID from TTBR0 to TTBR1") makes a
> TTBR0_EL1 + ASID switching non-atomic. Subsequently, commit 27a921e75711
> ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN") changes the
> __uaccess_ttbr0_disable() function and asm macro to first write the
> reserved TTBR0_EL1 followed by the ASID=0 update in TTBR1_EL1. If an
> exception occurs between these two, the exception return code will
> re-instate a valid TTBR0_EL1. Similar scenario can happen in
> cpu_switch_mm() between setting the reserved TTBR0_EL1 and the ASID
> update in cpu_do_switch_mm().
>
> This patch reverts the entry.S check for ASID == 0 to TTBR0_EL1 and
> disables the interrupts around the TTBR0_EL1 and ASID switching code in
> __uaccess_ttbr0_disable(). It also ensures that, when returning from the
> EFI runtime services, efi_set_pgd() doesn't leave a non-zero ASID in
> TTBR1_EL1.
>
> As a safety measure, __uaccess_ttbr0_enable() always masks out any
> existing non-zero ASID TTBR1_EL1 before writing in the new ASID.
>
> Fixes: 27a921e75711 ("arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN")
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
I saw sporadic assert-failures and translation faults running hackbench in a
loop on Seattle with software PAN. I think this explains (and fixes) it.
Tested-by: James Morse <james.morse@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
^ permalink raw reply
* [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
From: David Lechner @ 2018-01-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fc8bd35-0416-216d-8e1e-53a0ec6e8790@ti.com>
On 01/12/2018 03:21 AM, Sekhar Nori wrote:
> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>> This adds a new driver for mach-davinci PLL clocks. This is porting the
>> code from arch/arm/mach-davinci/clock.c to the common clock framework.
>> Additionally, it adds device tree support for these clocks.
>>
>> The ifeq ($(CONFIG_COMMON_CLK), y) in the Makefile is needed to prevent
>> compile errors until the clock code in arch/arm/mach-davinci is removed.
>>
>> Note: although there are similar clocks for TI Keystone we are not able
>> to share the code for a few reasons. The keystone clocks are device tree
>> only and use legacy one-node-per-clock bindings. Also the register
>> layouts are a bit different, which would add even more if/else mess
>> to the keystone clocks. And the keystone PLL driver doesn't support
>> setting clock rates.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> +
>> +#define PLLM_MASK 0x1f
>> +#define PREDIV_RATIO_MASK 0x1f
>
> May be use the mode modern GENMASK()?
I haven't seen that one before. Thanks.
...
>> +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw,
>> + unsigned long parent_rate)
>> +{
>> + struct davinci_pll_clk *pll = to_davinci_pll_clk(hw);
>> + unsigned long rate = parent_rate;
>> + u32 prediv, mult, postdiv;
>> +
>> + prediv = readl(pll->base + PREDIV) & PREDIV_RATIO_MASK;
>> + mult = readl(pll->base + PLLM) & PLLM_MASK;
>> + postdiv = readl(pll->base + POSTDIV) & POSTDIV_RATIO_MASK;
>
> Shouldn't we check if the pre and post dividers are enabled before using
> them?
Indeed.
>
>> +
>> + rate /= prediv + 1;
>> + rate *= mult + 1;
>> + rate /= postdiv + 1;
>> +
>> + return rate;
>> +}
>> +
...
>
> PLL output on DA850 must never be below 300MHz or above 600MHz (see
> datasheet table "Allowed PLL Operating Conditions"). Does this take care
> of that? Thats one of the main reasons I recall I went with some
> specific values of prediv, pllm and post div in
> arch/arm/mach-davinci/da850.c
Apparently, I missed this requirement. It looks like I am going to have to
rework things so that there is some coordination between the PLL and the
PLLDIV clocks in order to get the < 300MHz operating points.
...
>> +
>> + divider->reg = base + OSCDIV;
>> + divider->width = OSCDIV_RATIO_WIDTH;
>
> can you write OD1EN of OSCDIV here? I guess the reset default is 1 so
> you didnt need to do that. But not doing exposes us to settings that
> bootloader left us in.
>
It looks like I am going to have to make a custom implementation for parts
of this clock anyway, so I will probably just make new enable/disable
callbacks that set both OSCDIV_OD1EN and CKEN_OBSCLK.
>> +
>> + clk = clk_register_composite(NULL, name, parent_names, num_parents,
>> + &mux->hw, &clk_mux_ops,
>> + ÷r->hw, &clk_divider_ops,
>> + &gate->hw, &clk_gate_ops, 0);
>> + if (IS_ERR(clk)) {
>> + kfree(divider);
>> + kfree(gate);
>> + kfree(mux);
>> + }
>> +
>> + return clk;
>> +}
>> +
>> +struct clk *
>> +davinci_pll_divclk_register(const struct davinci_pll_divclk_info *info,
>> + void __iomem *base)
>> +{
>> + const struct clk_ops *divider_ops = &clk_divider_ops;
>
> setting the sysclk divider requires GOSTAT handling apart from setting
> the divider value. So I think .set_rate ops above wont work. Other ops
> can be used, I guess. So we need a private structure here.
>
> Can you port over davinci_set_sysclk_rate() too? I understand you cannot
> test it due to lack of cpufreq support in DT, but I can help testing there.
>
> Or leave .set_rate NULL and it can be added later.
Yes, I noticed that I missed this after I submitted this series. And I
will have to rework things to coordinate with the PLL as mentioned above.
FYI, I do have cpufreq-dt working, although the LEGO EV3 has a fixed 1.2V
regulator, so I am limited in what I can test. Basically, I can only switch
between 300MHz and 375MHz according to the datasheets. The chip is technically
the 456MHz version. What would happen if I ran it faster or slower with the
wrong voltage?
...
>> +
>> + child = of_get_child_by_name(node, "auxclk");
>> + if (child && of_device_is_available(child)) {
>> + char child_name[MAX_NAME_SIZE];
>> +
>> + snprintf(child_name, MAX_NAME_SIZE, "%s_aux_clk", name);
>> +
>> + clk = davinci_pll_aux_clk_register(child_name, parent_name, base);
>> + if (IS_ERR(clk))
>> + pr_warn("%s: failed to register %s (%ld)\n", __func__,
>> + child_name, PTR_ERR(clk));
>> + else
>> + of_clk_add_provider(child, of_clk_src_simple_get, clk);
>> + }
>
> davinci_pll_obs_clk_register() should also be handled here?
I omitted it because no one is using it (same reason I left it out of the
device tree bindings). We can certainly add it, though.
^ permalink raw reply
* [PATCH v2 0/3] ARM: mvebu: dts: updates to enable EDAC
From: Gregory CLEMENT @ 2018-01-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2460bc23c4d4ff2adbd05821e86aea9@svr-chch-ex1.atlnz.lc>
Hi Chris,
On jeu., janv. 11 2018, Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
> On 11/01/18 22:14, Gregory CLEMENT wrote:
>> Hi Chris,
>>
>> On jeu., janv. 11 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>>
>>> I've split this off from my earlier series[1] this is just the dts changes that
>>> will enable support for the EDAC series when it lands.
>>>
>>> The Armada 38x as well as the 98dx3236 and similar switch chips with integrated
>>> CPUs use the same SDRAM controller block as the Armada XP. The key difference
>>> is the width of the DDR interface.
>>>
>>> [1] - https://marc.info/?l=linux-kernel&m=151545124505964&w=2
>>
>> The series is looks good now. For patch 1 I still wait for that
>> the "marvell,,ecc-enable" property was accepted before merging it.
>>
>> So I can either wait for that it was accepted before applying the series,
>> or just applying patch 2 and 3 for now, as you want.
>
> I'm happy either way. If it's easier for you to keep the 3 patches
> together that's fine by me.
So I will apply all of them in the same time.
Thanks,
Gregory
>
>>
>> Thanks,
>>
>> Gregory
>>
>>
>>>
>>> Changes in v2:
>>> - update commit message
>>> - add labels to dts
>>>
>>> Chris Packham (3):
>>> ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
>>> ARM: dts: armada-xp: add label to sdram-controller node
>>> ARM: dts: mvebu: add sdram controller node to Armada-38x
>>>
>>> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
>>> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
>>> arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
>>> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
>>> 4 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> --
>>> 2.15.1
>>>
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Sudeep Holla @ 2018-01-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112131508.GC19999@ulmo>
On 12/01/18 13:15, Thierry Reding wrote:
> On Fri, Jan 12, 2018 at 01:58:28PM +0100, Thierry Reding wrote:
>> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>>
>>>
>>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>>
>>>>
>>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>
>>>>> After moving the SoC device initialization to an early initcall in
>>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>>> for the device is enabled in the kernel configuration.
>>>>>
>>>>> This causes an additional SoC device to appear on platforms that already
>>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>>> causes various scripts and programs to fail because they don't know how
>>>>> to parse that data.
>>>>>
>>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>>> that already prevents the code from doing anything nonsensical on non-
>>>>> STB platforms.
>>>>>
>>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>>> ---
>>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>>> static int __init brcmstb_soc_device_init(void)
>>>>> {
>>>>> struct soc_device_attribute *soc_dev_attr;
>>>>> + struct device_node *sun_top_ctrl;
>>>>> struct soc_device *soc_dev;
>>>>>
>>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>>> + if (!sun_top_ctrl)
>>>>> + return -ENODEV;
>>>>> +
>>>>
>>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>>
>>>
>>> Further, I still the error messags on my Juno with this patch applied. I
>>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>>
>> I'm not sure I understand. There's no way we can prevent the early
>> initcall from running. The point here is to prevent it from running code
>> that shouldn't be run on a platform.
>>
>> That said, perhaps an even better thing would be to return 0 in order to
>> avoid marking this as failure, since it really isn't an error if this
>> happens.
>
> Oh, I see the errors you mentioned now. They're in the biuctrl code,
> which I hadn't noticed before since they don't cause any weird behaviour
> other than the error messages in the boot log. Let me fix that up while
> I'm on it.
Sorry for missing context. I posted a patch[1] to fix the error messages
I mentioned, but Florian directed me to his patch instead and hence the
above question was for him as your patch was addressing a different issue.
--
Regards,
Sudeep
[1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
^ permalink raw reply
* [PATCH] soc: brcmstb: Only register SoC device on STB platforms
From: Sudeep Holla @ 2018-01-12 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112125828.GB19999@ulmo>
On 12/01/18 12:58, Thierry Reding wrote:
> On Fri, Jan 12, 2018 at 12:12:11PM +0000, Sudeep Holla wrote:
>>
>>
>> On 12/01/18 11:39, Sudeep Holla wrote:
>>>
>>>
>>> On 09/01/18 14:54, Thierry Reding wrote:
>>>> From: Thierry Reding <treding@nvidia.com>
>>>>
>>>> After moving the SoC device initialization to an early initcall in
>>>> commit f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall"),
>>>> the Broadcom STB SoC device is registered on all platforms if support
>>>> for the device is enabled in the kernel configuration.
>>>>
>>>> This causes an additional SoC device to appear on platforms that already
>>>> register a native one. In case of Tegra the STB SoC device is registered
>>>> as soc0 (with totally meaningless content in the sysfs attributes) and
>>>> causes various scripts and programs to fail because they don't know how
>>>> to parse that data.
>>>>
>>>> To fix this, duplicate the check from brcmstb_soc_device_early_init()
>>>> that already prevents the code from doing anything nonsensical on non-
>>>> STB platforms.
>>>>
>>>> Fixes: f780429adfbc ("soc: brcmstb: biuctrl: Move to early_initcall")
>>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>>> ---
>>>> drivers/soc/bcm/brcmstb/common.c | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/drivers/soc/bcm/brcmstb/common.c b/drivers/soc/bcm/brcmstb/common.c
>>>> index 781ada62d0a3..4fe1cb73b39a 100644
>>>> --- a/drivers/soc/bcm/brcmstb/common.c
>>>> +++ b/drivers/soc/bcm/brcmstb/common.c
>>>> @@ -89,8 +89,13 @@ early_initcall(brcmstb_soc_device_early_init);
>>>> static int __init brcmstb_soc_device_init(void)
>>>> {
>>>> struct soc_device_attribute *soc_dev_attr;
>>>> + struct device_node *sun_top_ctrl;
>>>> struct soc_device *soc_dev;
>>>>
>>>> + sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
>>>> + if (!sun_top_ctrl)
>>>> + return -ENODEV;
>>>> +
>>>
>>> missing of_node_put(sun_top_ctrl) ? or am I missing to see that elsewhere ?
>>>
>>
>> Further, I still the error messags on my Juno with this patch applied. I
>> fail to see how this patch prevents brcmstb_biuctrl_init which is
>> early_initcall in drivers/soc/bcm/brcmstb/biuctrl.c getting called ?
>
> I'm not sure I understand. There's no way we can prevent the early
> initcall from running. The point here is to prevent it from running code
> that shouldn't be run on a platform.
>
Sorry for missing the context, I was referring [1]
--
Regards,
Sudeep
[1] [1] https://marc.info/?l=linux-kernel&m=151568158127806&w=2
^ permalink raw reply
* [PATCH v2] dt-bindings: display: stm32: add pixel clock mandatory property
From: Philippe Cornu @ 2018-01-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Add the DPI/RGB input pixel clock in mandatory properties
because it really offers a better preciseness for timing
computations.
Note: Fix also the DSI panel example where "ref" & "pclk"
clocks were swapped.
Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
---
Changes in v2: put new clock in last position (Rob Herring)
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
index 029252253ad4..942b7237ae87 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
+++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
@@ -29,6 +29,7 @@ Mandatory properties specific to STM32 DSI:
- compatible: "st,stm32-dsi".
- clock-names:
- phy pll reference clock string name, must be "ref".
+ - DPI/RGB input pixel clock string name, must be "px_clk".
- resets: see [5].
- reset-names: see [5].
@@ -97,8 +98,9 @@ Example 2: DSI panel
#size-cells = <0>;
compatible = "st,stm32-dsi";
reg = <0x40016c00 0x800>;
- clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>;
- clock-names = "ref", "pclk";
+ clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>,
+ <&rcc 1 CLK_LCD>;
+ clock-names = "pclk", "ref", "px_clk";
resets = <&rcc STM32F4_APB2_RESET(DSI)>;
reset-names = "apb";
--
2.15.1
^ permalink raw reply related
* [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
From: Adam Ford @ 2018-01-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01fbde0e-36a0-2b19-e385-e63bc4a3ae4a@lechnology.com>
On Fri, Jan 12, 2018 at 9:25 AM, David Lechner <david@lechnology.com> wrote:
> On 01/12/2018 03:21 AM, Sekhar Nori wrote:
>>
>> On Monday 08 January 2018 07:47 AM, David Lechner wrote:
>>>
>>> This adds a new driver for mach-davinci PLL clocks. This is porting the
>>> code from arch/arm/mach-davinci/clock.c to the common clock framework.
>>> Additionally, it adds device tree support for these clocks.
>>>
>>> The ifeq ($(CONFIG_COMMON_CLK), y) in the Makefile is needed to prevent
>>> compile errors until the clock code in arch/arm/mach-davinci is removed.
>>>
>>> Note: although there are similar clocks for TI Keystone we are not able
>>> to share the code for a few reasons. The keystone clocks are device tree
>>> only and use legacy one-node-per-clock bindings. Also the register
>>> layouts are a bit different, which would add even more if/else mess
>>> to the keystone clocks. And the keystone PLL driver doesn't support
>>> setting clock rates.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>
>
>>> +
>>> +#define PLLM_MASK 0x1f
>>> +#define PREDIV_RATIO_MASK 0x1f
>>
>>
>> May be use the mode modern GENMASK()?
>
>
> I haven't seen that one before. Thanks.
>
> ...
>
>>> +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw,
>>> + unsigned long parent_rate)
>>> +{
>>> + struct davinci_pll_clk *pll = to_davinci_pll_clk(hw);
>>> + unsigned long rate = parent_rate;
>>> + u32 prediv, mult, postdiv;
>>> +
>>> + prediv = readl(pll->base + PREDIV) & PREDIV_RATIO_MASK;
>>> + mult = readl(pll->base + PLLM) & PLLM_MASK;
>>> + postdiv = readl(pll->base + POSTDIV) & POSTDIV_RATIO_MASK;
>>
>>
>> Shouldn't we check if the pre and post dividers are enabled before using
>> them?
>
>
> Indeed.
>
>>
>>> +
>>> + rate /= prediv + 1;
>>> + rate *= mult + 1;
>>> + rate /= postdiv + 1;
>>> +
>>> + return rate;
>>> +}
>>> +
>
>
> ...
>
>>
>> PLL output on DA850 must never be below 300MHz or above 600MHz (see
>> datasheet table "Allowed PLL Operating Conditions"). Does this take care
>> of that? Thats one of the main reasons I recall I went with some
>> specific values of prediv, pllm and post div in
>> arch/arm/mach-davinci/da850.c
>
>
> Apparently, I missed this requirement. It looks like I am going to have to
> rework things so that there is some coordination between the PLL and the
> PLLDIV clocks in order to get the < 300MHz operating points.
>
> ...
>
>>> +
>>> + divider->reg = base + OSCDIV;
>>> + divider->width = OSCDIV_RATIO_WIDTH;
>>
>>
>> can you write OD1EN of OSCDIV here? I guess the reset default is 1 so
>> you didnt need to do that. But not doing exposes us to settings that
>> bootloader left us in.
>>
>
> It looks like I am going to have to make a custom implementation for parts
> of this clock anyway, so I will probably just make new enable/disable
> callbacks that set both OSCDIV_OD1EN and CKEN_OBSCLK.
>
>
>>> +
>>> + clk = clk_register_composite(NULL, name, parent_names,
>>> num_parents,
>>> + &mux->hw, &clk_mux_ops,
>>> + ÷r->hw, &clk_divider_ops,
>>> + &gate->hw, &clk_gate_ops, 0);
>>> + if (IS_ERR(clk)) {
>>> + kfree(divider);
>>> + kfree(gate);
>>> + kfree(mux);
>>> + }
>>> +
>>> + return clk;
>>> +}
>>> +
>>> +struct clk *
>>> +davinci_pll_divclk_register(const struct davinci_pll_divclk_info *info,
>>> + void __iomem *base)
>>> +{
>>> + const struct clk_ops *divider_ops = &clk_divider_ops;
>>
>>
>> setting the sysclk divider requires GOSTAT handling apart from setting
>> the divider value. So I think .set_rate ops above wont work. Other ops
>> can be used, I guess. So we need a private structure here.
>>
>> Can you port over davinci_set_sysclk_rate() too? I understand you cannot
>> test it due to lack of cpufreq support in DT, but I can help testing
>> there.
>>
>> Or leave .set_rate NULL and it can be added later.
>
>
> Yes, I noticed that I missed this after I submitted this series. And I
> will have to rework things to coordinate with the PLL as mentioned above.
>
> FYI, I do have cpufreq-dt working, although the LEGO EV3 has a fixed 1.2V
> regulator, so I am limited in what I can test. Basically, I can only switch
I can test the cpufreq-dt. Are there additional patches or are they
part of the same git repo I have been testing?
The DA850 I have may not run all the way to highest speed, but I'll
see what I can find. I think I had a few at one point, but I don't
think it was part of Logic PD's standard product lineup.
adam
> between 300MHz and 375MHz according to the datasheets. The chip is
> technically
> the 456MHz version. What would happen if I ran it faster or slower with the
> wrong voltage?
>
> ...
>
>>> +
>>> + child = of_get_child_by_name(node, "auxclk");
>>> + if (child && of_device_is_available(child)) {
>>> + char child_name[MAX_NAME_SIZE];
>>> +
>>> + snprintf(child_name, MAX_NAME_SIZE, "%s_aux_clk", name);
>>> +
>>> + clk = davinci_pll_aux_clk_register(child_name,
>>> parent_name, base);
>>> + if (IS_ERR(clk))
>>> + pr_warn("%s: failed to register %s (%ld)\n",
>>> __func__,
>>> + child_name, PTR_ERR(clk));
>>> + else
>>> + of_clk_add_provider(child, of_clk_src_simple_get,
>>> clk);
>>> + }
>>
>>
>> davinci_pll_obs_clk_register() should also be handled here?
>
>
> I omitted it because no one is using it (same reason I left it out of the
> device tree bindings). We can certainly add it, though.
>
>
^ permalink raw reply
* [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
From: Johan Hovold @ 2018-01-12 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <90F9A8E4-035A-4A9E-8AAB-757491D63E69@goldelico.com>
On Tue, Jan 09, 2018 at 12:55:11PM +0100, H. Nikolaus Schaller wrote:
> Hi Johan,
>
> > Am 22.12.2017 um 15:40 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > Hi Johan,
> >
> >> Am 22.12.2017 um 13:44 schrieb Johan Hovold <johan@kernel.org>:
> >>
> >> On Fri, Dec 01, 2017 at 08:49:36AM +0100, H. Nikolaus Schaller wrote:
> >>> Add driver for Wi2Wi W2SG0004/84 GPS module connected to some SoC UART.
> >>>
> >>> It uses serdev API hooks to monitor and forward the UART traffic to /dev/ttyGPSn
> >>> and turn on/off the module. It also detects if the module is turned on (sends data)
> >>> but should be off, e.g. if it was already turned on during boot or power-on-reset.
> >>>
> >>> Additionally, rfkill block/unblock can be used to control an external LNA
> >>> (and power down the module if not needed).
> >>>
> >>> The driver concept is based on code developed by Neil Brown <neilb@suse.de>
> >>> but simplified and adapted to use the new serdev API introduced in v4.11.
> >>
> >> I'm sorry (and I know this discussion has been going on for a long
> >> time),but this still feels like too much of a hack.
>
> Happy new year ... Happy new attempt...
Same to you.
> Let's restart this discussion and focus on the main roadblock (others
> are minor details which can be sorted out later).
>
> If it feels like a hack, the key issue seems to me to be the choice of
> the API to present the GPS data to user space. Right?
Or even more fundamentally, does this belong in the kernel at all?
Given that we'd still depend on gpsd and other, proprietary, daemons to
actually parse and use (also for control) the plethora of GPS protocols
available, it may even be best to just keep it all in user space.
The next user may want to keep the GPS powered also when the port is
closed; this all seems like policy that should remain in user space.
Now, if we'd ever have a proper GPS framework that handled everything in
kernel space (i.e. no more gpsd) then we would be able to write kernel
drivers that also take care of PM. But perhaps that's unlikely to ever
be realised given the state of things (proprietary protocols, numerous
quirky implementations, etc).
Also it seems at least part of your specific problem is that you have
failed to wire up the WAKEUP pin of the W2SG0004/84 properly, which then
forces you to look at the data stream to determine the power state of
the chip. Judging from a quick look at the GTA04 schematics it seems
you've even connected the WAKEUP output to the 1V8_OUT output?!
The kernel is probably not the place to be working around issues like
that, even if serdev at least allows for such hacks to be fairly
isolated in drivers (unlike some of the earlier proposals touching core
code).
> I see three reasonable options how this presentation can be done:
>
> 1. char device
> 2. tty device
> 3. some new gps interface API (similar to network, bluetooth interfaces)
> 4. no driver and use the UART tty directly
>
> Pros and cons:
> 4. no driver and use UART directly
> + a non-solution seems to be attractive
> - must turn on/off chip by gpio hacks from user-space
I'm not sure that would amount to more of hack then doing it in the
kernel would.
> - can not guarantee (!) to power off the chip if the last user-space
> process using it is killed (which is essential for power-management of
> a handheld, battery operated device)
That depends on how you implement things (extending gpsd, wrapper
script, pty daemon, ...).
> I would clearly prefer 3 over 2 over 1 over 4.
>
> So do you see a chance that the kernel core team provides something useable
> (not perfect) for variant 3 in reasonable time (let's say 3-6 months)?
No, I'm afraid not. At least not if we're talking about a framework
that would replace gpsd.
> If not, I want to suggest to accept the second-best choice 2. for now and we
> will update the driver as soon as 3. appears. IMHO it would be a good test case
> for a new subsystem.
Getting the interface right from the start is quite important, as
otherwise we may end up having to support a superseded one for a long
time.
Johan
^ permalink raw reply
* [PATCH v5 06/20] firmware: arm_scmi: add initial support for performance protocol
From: Sudeep Holla @ 2018-01-12 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALW4P+L-YJRNZ_qv1SohM7vCWekBf+KKZos7FuZE0Tu1Yh8i-g@mail.gmail.com>
On 12/01/18 14:55, Alexey Klimov wrote:
> On Tue, Jan 2, 2018 at 2:42 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> The performance protocol is intended for the performance management of
>> group(s) of device(s) that run in the same performance domain. It
>> includes even the CPUs. A performance domain is defined by a set of
>> devices that always have to run at the same performance level.
>> For example, a set of CPUs that share a voltage domain, and have a
>> common frequency control, is said to be in the same performance domain.
>>
>> The commands in this protocol provide functionality to describe the
>> protocol version, describe various attribute flags, set and get the
>> performance level of a domain. It also supports discovery of the list
>> of performance levels supported by a performance domain, and the
>> properties of each performance level.
>>
>> This patch adds basic support for the performance protocol.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/firmware/arm_scmi/Makefile | 2 +-
>> drivers/firmware/arm_scmi/common.h | 1 +
>> drivers/firmware/arm_scmi/perf.c | 527 +++++++++++++++++++++++++++++++++++++
>> include/linux/scmi_protocol.h | 34 +++
>> 4 files changed, 563 insertions(+), 1 deletion(-)
>
> [...]
>
[..]
>> +
>> +static int scmi_perf_limits_notify_enable(const struct scmi_handle *handle,
>> + u32 domain, bool enable)
>> +{
>> + return __scmi_perf_notify_enable(handle, PERF_NOTIFY_LIMITS,
>> + domain, enable);
>> +}
>> +
>> +static int scmi_perf_level_notify_enable(const struct scmi_handle *handle,
>> + u32 domain, bool enable)
>> +{
>> + return __scmi_perf_notify_enable(handle, PERF_NOTIFY_LEVEL,
>> + domain, enable);
>> +}
>> +
>
> Do you have any support to correctly handle notifications without
> errors/warnings?
Good catch.
> It looks like this two functions are accessible to some user through
> perf_ops. But are you sure that notifications will be correctly
> handled by transport, mailbox framework and scmi protocol?
>
Indeed, it slipeed through the cracks. I have some rudimentary notifier
support with I have not put it as part of this series due to lack of
firmware to test.
> The reason I ask is that it looks like it's better to return
> -EOPNOTSUPP or -ENODEV, maybe -EINVAL here.
I agree, will change it.
> When you add notifications support you can allow these operations when
> it's safe to do it.
>
Yes, sounds like that's good plan.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2 3/7] PCI: aardvark: set host and device to the same MAX payload size
From: Thomas Petazzoni @ 2018-01-12 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112144024.GB113206@bhelgaas-glaptop.roam.corp.google.com>
Hello Bjorn,
Thanks again for this discussion!
On Fri, 12 Jan 2018 08:40:24 -0600, Bjorn Helgaas wrote:
> Sorry, I didn't mean that commit would fix your problem. It's just an
> example of another case where generic code incorrectly assumed a Root
> Port would always be present.
OK, understood.
> > I.e, there is no Root Port. Therefore, I don't see how the kernel
> > can know what is the maximum allowed payload size of the PCIe
> > controller, nor how to adjust the payload size to use. Same for the L0s
> > configuration.
>
> The Device Control MPS field defaults to 128 bytes. Generic software
> can only change that default if it knows that every element that might
> receive a packet from the device can handle it. In this case, we have
> no information about what the invisible Root Port can handle, so I
> would argue that we cannot change MPS.
>
> In the lspci above, MPS is set to 256 bytes. If that was done by
> firmware, it might be safe because it knows things about the Root Port
> that Linux doesn't. But I don't think the Linux PCI core could set it
> to 256.
So you're suspecting that the firmware/bootloader has configured the
MPS on the E1000E device to 256 bytes ?
Isn't it dangerous for the kernel to rely on the firmware/bootloader
configuration ? Indeed, the firmware/bootloader might have configured
MPS to X bytes on the endpoint, but when the kernel boots and
initializes the PCIe controller, its sets the PCIe controller MPS to Y
bytes, with Y > X.
> ASPM L0s is similar. We should only enable L0s if we can tell that
> both ends of the link support it. If there's no Root Port, we don't
> have any ASPM capability information for the upstream end of the link,
> so we shouldn't enable ASPM at all.
Well, even without the Root Port, we are able to use the endpoint
configuration space to figure out whether it supports L0s, and adjust
the root complex configuration accordingly. This is what our patch is
doing for MPS, and which could be done similarly for L0s, no?
>
> > This is why we need those changes, one to update the PCIe controller
> > MPS according to the Maximum Payload Size acceptable by the endpoint,
> > and one to disable L0s entirely to avoid issues with non-L0s compliant
> > devices.
>
> The generic core code should perform minimal, guaranteed-to-work
> configuration using the least information and fewest assumptions
> possible. That may not lead to optimal performance, but it should at
> least be functional. This should work even if there is no Root Port.
>
> Once we have that figured out, then we can worry about whether we can
> or should do platform-specific tweaks to improve performance, e.g.,
> increase MPS if we know Root Port capabilities implicitly.
>
> I had the impression that these patches were required for correct
> functionality, not just to improve performance. But maybe I
> misunderstood?
I don't myself have the device that wasn't working, and that this patch
got to work, so I can't double check myself. However, indeed, I was
told that without this fix, some devices would not work.
One question: is it valid/working to have the root complex configured
with MPS = 128 bytes but the endpoint configured with MPS = 256 or 512
bytes ? Or should the MPS value be strictly equal on both sides ?
Depending on your answer, there are two options:
- It is a valid situation to have a root complex MPS lower than the
endpoint MPS. In this case, we could for now simply unconditionally
set the MPS to 128 bytes in the root complex, as a fix to get all
devices working. And then separately, work on improving performance
by increasing the MPS according to the endpoint capabilities.
- It is not valid for the root complex MPS to be different than the
endpoint MPS. In this case, then I don't see how we can do things
differently than the proposed patch: we have to see what the
endpoint MPS is, and adjust the root complex MPS accordingly.
Indeed, the bootloader/firmware might have changed the endpoint MPS
so that it is no longer the default of 128 bytes.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
From: David Lechner @ 2018-01-12 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xK44_zv27xe5yxL8Efey=VC-nypK6hY6VWqsoLqnKe04g@mail.gmail.com>
On 01/12/2018 09:30 AM, Adam Ford wrote:
> On Fri, Jan 12, 2018 at 9:25 AM, David Lechner <david@lechnology.com> wrote:
>>
>> Yes, I noticed that I missed this after I submitted this series. And I
>> will have to rework things to coordinate with the PLL as mentioned above.
>>
>> FYI, I do have cpufreq-dt working, although the LEGO EV3 has a fixed 1.2V
>> regulator, so I am limited in what I can test. Basically, I can only switch
>
> I can test the cpufreq-dt. Are there additional patches or are they
> part of the same git repo I have been testing?
>
> The DA850 I have may not run all the way to highest speed, but I'll
> see what I can find. I think I had a few at one point, but I don't
> think it was part of Logic PD's standard product lineup.
>
There are some extra patches I have not submitted yet. However, based on the
other comments here, I don't have things implemented correctly, so you probably
want to wait to test until I get that straightened out anyway.
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2018-01-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-1-miquel.raynal@free-electrons.com>
On Tue, 9 Jan 2018 11:36:30 +0100
Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Hi,
>
> After the addition of the NAND framework ->exec_op() interface (see [1]
> for the series preparing it and [2] for the last version of the
> core-side implementation of ->exec_op() itself), this series replaces
> the current Marvell NAND controller driver pxa3xx_nand.c with a rework
> called marvell_nand.c.
>
> Aside the fact that it drops the big state machine, improves the overall
> speed and implements raw accesses, it is the first driver-side
> implementation of the ->exec_op() interface and may be used as reference
> for latter reworks of the same type.
>
> One may find more detail about why a completely new driver is needed in
> the commit log of:
>
> "mtd: nand: add reworked Marvell NAND controller driver"
>
> Device tree NAND node definition for all platforms referring to the
> Marvell driver using the new bindings have already been accepted by the
> MVEBU DT maintainers and will be merged after the driver. They are more
> hierarchical and fit the real organization of the hardware, by having
> NAND partitions that are part of NAND chip nodes, themselves part of the
> NAND controller node.
>
> These changes have been tested on:
> - PXA3xx platform with a CM-X300 board (2kiB page NAND, 1b/512B
> strength, Hamming ECC engine) [32 bits]
> - Armada 385 DB AP (4kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
> - Armada 398 DB (4kiB page NAND, 8b/512B, BCH ECC engine using a layout
> with a last chunk different than the others) [32 bits]
> - Armada 7040 DB and Armada 8040 DB (4kiB page NAND, 4b/512B, BCH ECC
> engine) [64 bits]
> - Triax dvb-tc board (2kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
>
> This version is known not to be stable yet with a Zylonite based setup but
> otherwise looks good for Marvell EBU platforms.
>
> For people who would like to test it easily, a branch ready to be tested
> is available at [3]. It is based on nand/next and has all the changes
> brought by the previously mentionned series as well as this one.
>
> Thank you,
> Miqu?l
>
>
> [1] https://www.spinics.net/lists/arm-kernel/msg619633.html
> [2] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077965.html
> [3] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
>
>
> Changes since v2:
> - Added a patch to create the nand-rb property in the Documentation
> - Rewording in the Documentation according to Rob's comments
> - Moved from marvell,rb to nand-rb property in the code
> - Disociated using this driver with Marvell EBU platforms than using
> it with PXA ones
> - Fixed the handling of 16-bit buses
> - Fixed SPDX comment style
> - Reorganized registers offsets/bit fields definitions as requested
> - Moved to Kernel doc
> - Changed the logic in ->select_chip() to use a prepared value of NDCR
> only instead of recalculating it
> - Fixed the presence of the SPARE_EN bit, reworked a bit the
> hmg_do_read/write() helpers
> - Fixed the OOB layouts that were unusable (all spare data first, then
> all ECC bytes)
> - Additional check on mtd->writesize when using NFCv1 (all sizes not
> supported)
> - Various typos/rewording
>
> Changes since v1:
> - Rewording
> - Fixed BCH ->read/write_page() hooks for 2kiB pages NAND chips
> - Removed license text, used SPDX tag instead
> - Removed read_page_data()
> - Enhanced the DT bindings document with the label property and the
> deprecated bindings.
> - Simplified the read_chunk() helper (OOB always read).
> - Simplified the ->bch_read_page() hook by removing the addition raw
> read to get ECC bytes.
> - Fixed the ->correct() function that did not check for bitflips in
> ECC bytes in erased pages.
>
>
> Miquel Raynal (7):
> dt-bindings: mtd: document new nand-rb property
> dt-bindings: mtd: add Marvell NAND controller documentation
> mtd: nand: add reworked Marvell NAND controller driver
> mtd: nand: use reworked NAND controller driver with Marvell EBU SoCs
Applied patches 1 to 4.
Can you please send a patch to add a new entry in MAINTAINERS for this
driver?
Thanks,
Boris
> mtd: nand: use Marvell reworked NAND controller driver with all
> platforms
> dt-bindings: mtd: remove pxa3xx NAND controller documentation
> mtd: nand: remove useless fields from pxa3xx NAND platform data
>
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +
> Documentation/devicetree/bindings/mtd/nand.txt | 1 +
> .../devicetree/bindings/mtd/pxa3xx-nand.txt | 50 -
> arch/arm/configs/cm_x300_defconfig | 2 +-
> arch/arm/configs/mvebu_v7_defconfig | 2 +-
> arch/arm/configs/pxa3xx_defconfig | 3 +-
> arch/arm/configs/pxa_defconfig | 2 +-
> arch/arm/configs/raumfeld_defconfig | 2 +-
> arch/arm/mach-mmp/ttc_dkb.c | 4 +-
> arch/arm/mach-pxa/cm-x300.c | 8 +-
> arch/arm/mach-pxa/colibri-pxa3xx.c | 8 +-
> arch/arm/mach-pxa/colibri.h | 2 +-
> arch/arm/mach-pxa/littleton.c | 10 +-
> arch/arm/mach-pxa/mxm8x10.c | 10 +-
> arch/arm/mach-pxa/raumfeld.c | 6 +-
> arch/arm/mach-pxa/zylonite.c | 10 +-
> arch/arm64/configs/defconfig | 2 +-
> drivers/mtd/nand/Kconfig | 18 +-
> drivers/mtd/nand/Makefile | 2 +-
> drivers/mtd/nand/marvell_nand.c | 2896 ++++++++++++++++++++
> drivers/mtd/nand/pxa3xx_nand.c | 2104 --------------
> include/linux/platform_data/mtd-nand-pxa3xx.h | 43 +-
> 22 files changed, 3072 insertions(+), 2236 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
> delete mode 100644 Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
> create mode 100644 drivers/mtd/nand/marvell_nand.c
> delete mode 100644 drivers/mtd/nand/pxa3xx_nand.c
>
^ permalink raw reply
* [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds
From: Catalin Marinas @ 2018-01-12 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <904afc66-7936-d430-f056-6aa6e64ca0a9@suse.com>
On Tue, Jan 09, 2018 at 03:07:28PM +0100, Matthias Brugger wrote:
> On 01/08/2018 07:53 PM, Catalin Marinas wrote:
> > On Mon, Jan 08, 2018 at 05:32:25PM +0000, Will Deacon wrote:
> >> Jayachandran C (1):
> >> arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs
> >>
> >> Marc Zyngier (3):
> >> arm64: Move post_ttbr_update_workaround to C code
> >> arm64: KVM: Use per-CPU vector when BP hardening is enabled
> >> arm64: KVM: Make PSCI_VERSION a fast path
> >>
> >> Shanker Donthineni (1):
> >> arm64: Implement branch predictor hardening for Falkor
> >>
> >> Will Deacon (8):
> >> arm64: use RET instruction for exiting the trampoline
> >> arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry
> >> arm64: Take into account ID_AA64PFR0_EL1.CSV3
> >> arm64: cpufeature: Pass capability structure to ->enable callback
> >> drivers/firmware: Expose psci_get_version through psci_ops structure
> >> arm64: Add skeleton to harden the branch predictor against aliasing
> >> attacks
> >> arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75
> >> arm64: Implement branch predictor hardening for affected Cortex-A CPUs
> >
> > I'm queuing these into the arm64 for-next/core (after some overnight
> > testing). Any additional fixes should be done on top.
>
> I see these patches are not yet pushed to:
> git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>
> Did you hit any problems in the overnight tests?
Yes, I did, but they were not related to these patches but rather the
original kpti. See:
https://marc.info/?l=linux-arm-kernel&m=151576029908809
They are pushed now.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: dts: marvell: armada-80x0: Fix pinctrl compatible string
From: Gregory CLEMENT @ 2018-01-12 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180112100002.3967-1-gregory.clement@free-electrons.com>
Hi,
On ven., janv. 12 2018, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> When replacing the cpm by cp0 and cps by cp1 [1] not only the label and
> the alias were replaced but also the compatible string which was wrong.
>
> Due to this the pinctrl driver was no more probed.
>
> This patch fix it by reverting this change for the pinctrl compatible
> string on Armada 8K.
>
> [1]: "arm64: dts: marvell: replace cpm by cp0, cps by cp1"
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/dt64 with the reviewed-by flag from Thomas Petazzoni. I
do it right now because I hope being able to make a late pull request
with it in order to have the dtbs in the right state from the beginning
of the 4.16-rc1.
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> index 0d36b0fa7153..e9c84a1d3c4d 100644
> --- a/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-80x0.dtsi
> @@ -108,13 +108,13 @@
>
> &cp0_syscon0 {
> cp0_pinctrl: pinctrl {
> - compatible = "marvell,armada-8k-cp0-pinctrl";
> + compatible = "marvell,armada-8k-cpm-pinctrl";
> };
> };
>
> &cp1_syscon0 {
> cp1_pinctrl: pinctrl {
> - compatible = "marvell,armada-8k-cp1-pinctrl";
> + compatible = "marvell,armada-8k-cps-pinctrl";
>
> nand_pins: nand-pins {
> marvell,pins =
> --
> 2.15.1
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks
From: Sekhar Nori @ 2018-01-12 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01fbde0e-36a0-2b19-e385-e63bc4a3ae4a@lechnology.com>
On Friday 12 January 2018 08:55 PM, David Lechner wrote:
>>
>> PLL output on DA850 must never be below 300MHz or above 600MHz (see
>> datasheet table "Allowed PLL Operating Conditions"). Does this take care
>> of that? Thats one of the main reasons I recall I went with some
>> specific values of prediv, pllm and post div in
>> arch/arm/mach-davinci/da850.c
>
> Apparently, I missed this requirement. It looks like I am going to have to
> rework things so that there is some coordination between the PLL and the
> PLLDIV clocks in order to get the < 300MHz operating points.
Just to make sure we are on the same page. The datasheet
constraint is 600 >= PLLOUT >= 300. PLLOUT is output of POSTDIV.
The operating points are defined in terms of ARM frequency (and
voltage). The OPPs defined in kernel today are here:
https://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git/tree/arch/arm/mach-davinci/da850.c#n1092
Thanks,
Sekhar
^ permalink raw reply
* [PATCH][next] hwrng: exynos: check for -ve error return from readl_poll_timeout
From: Colin King @ 2018-01-12 16:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently, the return from readl_poll_timeout is being assigned to
a u32 and this is being checked for a -ve return which is always
false since a u32 cannot be less than zero. Fix this by changing
val to an int so that error returns can be correctly detected.
Detected by CoverityScan, CID#1463776 ("Logically dead code")
Fixes: 6cd225cc5d8a ("hwrng: exynos - add Samsung Exynos True RNG driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/char/hw_random/exynos-trng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 34d6f51ecbee..f4643e3ec346 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -55,7 +55,7 @@ static int exynos_trng_do_read(struct hwrng *rng, void *data, size_t max,
bool wait)
{
struct exynos_trng_dev *trng;
- u32 val;
+ int val;
max = min_t(size_t, max, (EXYNOS_TRNG_FIFO_LEN * 4));
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries
From: Nicolas Ferre @ 2018-01-12 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb6b3cbe8e48faee7e88eca0649e42cbde91ffa6.1515503733.git.nicolas.ferre@microchip.com>
On 09/01/2018 at 14:46, Nicolas Ferre wrote:
> These two image capture interface drivers are now handled
> by Wenyou Yang.
> I benefit from this change to update the two entries by correcting the
> binding documentation link for ISC and moving the ISI to the new
> MICROCHIP / ATMEL location.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> Hi,
>
> Patch against next-20180109.
> Note that I didn't find it useful to have several patches for these changes.
> Tell me if you feel differently.
>
> I would like to have the Ack from Ludovic and Wenyou obviously. I don't know if
> Songjun can answer as he's not with Microchip anymore.
Update on this patch:
Boris took the second patch of the series through NAND/MTD tree so this
one can go alone upstream through the linux-media tree.
I also have the 2 required Ack.
So, do you want me to re-send this one independently or should we wait
for 4.16-rc1?
Best regards,
Nicolas
> MAINTAINERS | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a7d10a2bb980..65c4b59b582f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2353,13 +2353,6 @@ L: linux-i2c at vger.kernel.org
> S: Supported
> F: drivers/i2c/busses/i2c-at91.c
>
> -ATMEL ISI DRIVER
> -M: Ludovic Desroches <ludovic.desroches@microchip.com>
> -L: linux-media at vger.kernel.org
> -S: Supported
> -F: drivers/media/platform/atmel/atmel-isi.c
> -F: include/media/atmel-isi.h
> -
> ATMEL LCDFB DRIVER
> M: Nicolas Ferre <nicolas.ferre@microchip.com>
> L: linux-fbdev at vger.kernel.org
> @@ -9102,12 +9095,20 @@ S: Maintained
> F: drivers/crypto/atmel-ecc.*
>
> MICROCHIP / ATMEL ISC DRIVER
> -M: Songjun Wu <songjun.wu@microchip.com>
> +M: Wenyou Yang <wenyou.yang@microchip.com>
> L: linux-media at vger.kernel.org
> S: Supported
> F: drivers/media/platform/atmel/atmel-isc.c
> F: drivers/media/platform/atmel/atmel-isc-regs.h
> -F: devicetree/bindings/media/atmel-isc.txt
> +F: Documentation/devicetree/bindings/media/atmel-isc.txt
> +
> +MICROCHIP / ATMEL ISI DRIVER
> +M: Wenyou Yang <wenyou.yang@microchip.com>
> +L: linux-media at vger.kernel.org
> +S: Supported
> +F: drivers/media/platform/atmel/atmel-isi.c
> +F: include/media/atmel-isi.h
> +F: Documentation/devicetree/bindings/media/atmel-isi.txt
>
> MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
> M: Woojung Huh <Woojung.Huh@microchip.com>
>
--
Nicolas Ferre
^ permalink raw reply
* EDAC driver for ARMv8 L1/L2 cache
From: Thor Thayer @ 2018-01-12 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR04MB20788AC2E71A3CFFC37B85BB9A100@VI1PR04MB2078.eurprd04.prod.outlook.com>
On 01/09/2018 03:51 PM, York Sun wrote:
> On 01/09/2018 01:43 PM, Borislav Petkov wrote:
>> Adding some more people to CC.
>>
>> On Tue, Jan 09, 2018 at 08:48:43PM +0000, York Sun wrote:
>>> Borislav,
>>>
>>> Are you aware of any existing (or in development) EDAC driver for ARMv8
>>> L1/L2 cache? I am thinking to write one if not available yet.
>>
>> no I'm not but I see two EDAC drivers for ARM64: thunderx and xgene.
>>
>> Please synchronize with their authors and ARM people what would be the
>> best thing to do and try extracting shared functionality from them
>> into a common compilation unit instead of duplicating it. I don't want
>> separate drivers per functional unit.
>>
>
> Thanks for the pointer. Thunderx and xgene's drivers have different
> implementation on the hardware. I found one patch closer to what I
> expect, https://patchwork.kernel.org/patch/7513231/. I don't see
> activities after 2015. I will reach out to the author.
>
> York
>
Hi York,
I'll be adding EDAC support for our Stratix10 (Quad ARM Cortex A-53) at
some point but I'm not sure when it is scheduled - probably in the next
few months. I'll be going through the same process of comparing our
architecture to others. Below are links to the Stratix10.
https://www.altera.com/products/soc/portfolio/stratix-10-soc/overview.html
https://www.altera.com/products/soc/portfolio/stratix-10-soc/support.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" 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 v15 1/4] drivers: jtag: Add JTAG core driver
From: Oleksandr Shamray @ 2018-01-12 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13433849-cb7d-e2c0-4ce9-d91a6012d7d7@gmail.com>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli at gmail.com]
> Sent: 26 ??????? 2017 ?. 1:09
> To: Oleksandr Shamray <oleksandrs@mellanox.com>;
> gregkh at linuxfoundation.org; arnd at arndb.de
> Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; openbmc at lists.ozlabs.org; joel at jms.id.au;
> jiri at resnulli.us; tklauser at distanz.ch; linux-serial at vger.kernel.org; Vadim
> Pasternak <vadimp@mellanox.com>; system-sw-low-level <system-sw-low-
> level at mellanox.com>; robh+dt at kernel.org; openocd-devel-
> owner at lists.sourceforge.net; linux-api at vger.kernel.org;
> davem at davemloft.net; mchehab at kernel.org; Jiri Pirko
> <jiri@mellanox.com>
> Subject: Re: [patch v15 1/4] drivers: jtag: Add JTAG core driver
>
>
[snip]
> > +
> > + case JTAG_IOCXFER:
> > + if (copy_from_user(&xfer, (void *)arg,
> > + sizeof(struct jtag_xfer)))
> > + return -EFAULT;
> > +
> > + if (xfer.length >= JTAG_MAX_XFER_DATA_LEN)
> > + return -EINVAL;
> > +
> > + if (xfer.type > JTAG_SDR_XFER)
> > + return -EINVAL;
> > +
> > + if (xfer.direction > JTAG_WRITE_XFER)
> > + return -EINVAL;
> > +
> > + if (xfer.endstate > JTAG_STATE_PAUSEDR)
> > + return -EINVAL;
> > +
> > + data_size = DIV_ROUND_UP(xfer.length, BITS_PER_BYTE);
> > + xfer_data = memdup_user(u64_to_user_ptr(xfer.tdio),
> data_size);
> > +
> > + if (!xfer_data)
> > + return -EFAULT;
> > +
> > + if (jtag->ops->xfer) {
> > + err = jtag->ops->xfer(jtag, &xfer, xfer_data);
> > + } else {
> > + kfree(xfer_data);
> > + return -EOPNOTSUPP;
> > + }
>
> Why don't you move all of the code here into a function which will make the
> error handling consistent? Also, checking whether the jtag adapter
Greg KH <gregkh@linuxfoundation.org> Say to move all of this insight ioctl
> implements ops->xfer should probably be done before you do the
> memdup_user().
Yes
> > + if (err) {
> > + kfree(xfer_data);
> > + return -EFAULT;
> > + }
> > +
> > + if (jtag->ops->mode_set)
> > + err = jtag->ops->mode_set(jtag, value);
> > + else
> > + err = -EOPNOTSUPP;
> > + break;
>
> Same here, this can be checked before get_user().
>
Yes
> > + if (jtag->opened) {
> > + mutex_unlock(&jtag->open_lock);
> > + return -EINVAL;
>
> -EBUSY maybe?
>
Yes
> > +
> > + jtag = kzalloc(sizeof(*jtag) + round_up(priv_size,
> ARCH_DMA_MINALIGN),
> > + GFP_KERNEL);
> > + if (!jtag)
> > + return NULL;
>
> If you set ARCH_DMA_MINALIGN to 1 when not defined, what is this
> achieving that kmalloc() is not already doing?
>
Removed ARCH_DMA_MINALIGN
> > +
> > + jtag->ops = ops;
> > + return jtag;
> > +}
> > +EXPORT_SYMBOL_GPL(jtag_alloc);
> > +
> > +void jtag_free(struct jtag *jtag)
> > +{
> > + kfree(jtag);
> > +}
> > +EXPORT_SYMBOL_GPL(jtag_free);
> > +
> > +int jtag_register(struct jtag *jtag)
> > +{
> > + char *name;
> > + int err;
> > + int id;
> > +
> > + id = ida_simple_get(&jtag_ida, 0, 0, GFP_KERNEL);
> > + if (id < 0)
> > + return id;
> > +
> > + jtag->id = id;
> > +
> > + name = kzalloc(MAX_JTAG_NAME_LEN, GFP_KERNEL);
> > + if (!name) {
> > + err = -ENOMEM;
> > + goto err_jtag_alloc;
> > + }
>
> Can't you use jtag->miscdev.dev here to simplify the allocation error
> handling?
>
How, what you mean?
> > +#ifndef ARCH_DMA_MINALIGN
> > +#define ARCH_DMA_MINALIGN 1
> > +#endif
>
> Why?
>
Not used now, Deleted
> > +#endif /* __JTAG_H */
> > diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h new
> > file mode 100644 index 0000000..cda2520
> > --- /dev/null
> > +++ b/include/uapi/linux/jtag.h
>
> [snip]
>
> > +struct jtag_xfer {
> > + __u8 type;
> > + __u8 direction;
>
> Can these two be an enum referring to what you defined earlier?
>
Greg KH <gregkh@linuxfoundation.org> say:
"All structures that cross the user/kernel boundry have to use the __ type variables.
No "unsigned char", it has to be "__u8", no "unsigned short", it has to be "__u16", and so on.
Also, watch out for your enumerated types, what's the packing end up looking like on these structures? Have you verified it works with a 64bit kernel and 32bit userspace all correctly?"
So I use __u8 type instead of enum to avoid errors while crossing 64bit kernel and 32bit userspace.
> > + __u8 endstate;
> > + __u32 length;
> > + __u64 tdio;
> > +};
> --
> Florian
Thaks.
^ permalink raw reply
* EDAC driver for ARMv8 L1/L2 cache
From: York Sun @ 2018-01-12 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc8d7450-3f58-95c2-42c2-d16b2f7a76e4@linux.intel.com>
On 01/12/2018 08:35 AM, Thor Thayer wrote:
> On 01/09/2018 03:51 PM, York Sun wrote:
>> On 01/09/2018 01:43 PM, Borislav Petkov wrote:
>>> Adding some more people to CC.
>>>
>>> On Tue, Jan 09, 2018 at 08:48:43PM +0000, York Sun wrote:
>>>> Borislav,
>>>>
>>>> Are you aware of any existing (or in development) EDAC driver for ARMv8
>>>> L1/L2 cache? I am thinking to write one if not available yet.
>>>
>>> no I'm not but I see two EDAC drivers for ARM64: thunderx and xgene.
>>>
>>> Please synchronize with their authors and ARM people what would be the
>>> best thing to do and try extracting shared functionality from them
>>> into a common compilation unit instead of duplicating it. I don't want
>>> separate drivers per functional unit.
>>>
>>
>> Thanks for the pointer. Thunderx and xgene's drivers have different
>> implementation on the hardware. I found one patch closer to what I
>> expect, https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F7513231%2F&data=02%7C01%7Cyork.sun%40nxp.com%7C29cd81c44431418e2a6308d559da7d3b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636513717317947616&sdata=flIZL8mxGc4VWbTpl5nPjkRXaB8uNjcc382HcXO08qE%3D&reserved=0. I don't see
>> activities after 2015. I will reach out to the author.
>>
>> York
>>
>
> Hi York,
>
> I'll be adding EDAC support for our Stratix10 (Quad ARM Cortex A-53) at
> some point but I'm not sure when it is scheduled - probably in the next
> few months. I'll be going through the same process of comparing our
> architecture to others. Below are links to the Stratix10.
>
I see Stratix10 has A53 core. I am concerned on reading the
CPUMERRSR_EL1 and L2MERRSR_EL1. The are IMPLEMENTATION DEFINED
registers. They may not be available on all SoCs, or all time. The
CPUMERRSR_EL1 needs to be read on each core, the L2MERRSR_EL1 needs to
be read on each cluster. I am not sure how to handle them in EDAC driver
yet. I am hoping Mark Rutland can shed some light as he commented on
similar patches [1][2] before.
York
[1] https://patchwork.kernel.org/patch/7460391/
[2] https://patchwork.kernel.org/patch/7513231/
^ permalink raw reply
* [PATCH v2 0/2] kasan: a few cleanups
From: Andrey Konovalov @ 2018-01-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
Clean up usage of KASAN_SHADOW_SCALE_SHIFT and fix prototype author email
address.
Changes in v2:
- fix comments as well.
Andrey Konovalov (2):
kasan: fix prototype author email address
kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
arch/arm64/include/asm/kasan.h | 17 ++++++++++-------
arch/arm64/include/asm/memory.h | 3 ++-
arch/arm64/mm/kasan_init.c | 3 ++-
arch/x86/include/asm/kasan.h | 12 ++++++++----
include/linux/kasan.h | 2 --
mm/kasan/kasan.c | 2 +-
mm/kasan/report.c | 2 +-
7 files changed, 24 insertions(+), 17 deletions(-)
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply
* [PATCH v2 1/2] kasan: fix prototype author email address
From: Andrey Konovalov @ 2018-01-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1515775666.git.andreyknvl@google.com>
Use the new one.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/kasan/kasan.c | 2 +-
mm/kasan/report.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 405bba487df5..cb4065f31f7f 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -5,7 +5,7 @@
* Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
*
* Some code borrowed from https://github.com/xairy/kasan-prototype by
- * Andrey Konovalov <adech.fo@gmail.com>
+ * Andrey Konovalov <andreyknvl@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 410c8235e671..eee796a005ac 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -5,7 +5,7 @@
* Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
*
* Some code borrowed from https://github.com/xairy/kasan-prototype by
- * Andrey Konovalov <adech.fo@gmail.com>
+ * Andrey Konovalov <andreyknvl@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply related
* [PATCH v2 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Andrey Konovalov @ 2018-01-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1515775666.git.andreyknvl@google.com>
Right now the fact that KASAN uses a single shadow byte for 8 bytes of
memory is scattered all over the code.
This change defines KASAN_SHADOW_SCALE_SHIFT early in asm include files
and makes use of this constant where necessary.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/kasan.h | 17 ++++++++++-------
arch/arm64/include/asm/memory.h | 3 ++-
arch/arm64/mm/kasan_init.c | 3 ++-
arch/x86/include/asm/kasan.h | 12 ++++++++----
include/linux/kasan.h | 2 --
5 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index e266f80e45b7..b1591f4cbbdb 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -12,7 +12,8 @@
/*
* KASAN_SHADOW_START: beginning of the kernel virtual addresses.
- * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
+ * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/N of kernel virtual addresses,
+ * where N = (1 << KASAN_SHADOW_SCALE_SHIFT).
*/
#define KASAN_SHADOW_START (VA_START)
#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
@@ -20,14 +21,16 @@
/*
* This value is used to map an address to the corresponding shadow
* address by the following formula:
- * shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
+ * shadow_addr = (address >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET
*
- * (1 << 61) shadow addresses - [KASAN_SHADOW_OFFSET,KASAN_SHADOW_END]
- * cover all 64-bits of virtual addresses. So KASAN_SHADOW_OFFSET
- * should satisfy the following equation:
- * KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
+ * (1 << (64 - KASAN_SHADOW_SCALE_SHIFT)) shadow addresses that lie in range
+ * [KASAN_SHADOW_OFFSET, KASAN_SHADOW_END) cover all 64-bits of virtual
+ * addresses. So KASAN_SHADOW_OFFSET should satisfy the following equation:
+ * KASAN_SHADOW_OFFSET = KASAN_SHADOW_END -
+ * (1ULL << (64 - KASAN_SHADOW_SCALE_SHIFT))
*/
-#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
+#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
+ (64 - KASAN_SHADOW_SCALE_SHIFT)))
void kasan_init(void);
void kasan_copy_shadow(pgd_t *pgdir);
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d4bae7d6e0d8..50fa96a49792 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -85,7 +85,8 @@
* stack size when KASAN is in use.
*/
#ifdef CONFIG_KASAN
-#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - 3))
+#define KASAN_SHADOW_SCALE_SHIFT 3
+#define KASAN_SHADOW_SIZE (UL(1) << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
#define KASAN_THREAD_SHIFT 1
#else
#define KASAN_SHADOW_SIZE (0)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index acba49fb5aac..6e02e6fb4c7b 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -135,7 +135,8 @@ static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
/* The early shadow maps everything to a single page of zeroes */
asmlinkage void __init kasan_early_init(void)
{
- BUILD_BUG_ON(KASAN_SHADOW_OFFSET != KASAN_SHADOW_END - (1UL << 61));
+ BUILD_BUG_ON(KASAN_SHADOW_OFFSET !=
+ KASAN_SHADOW_END - (1UL << (64 - KASAN_SHADOW_SCALE_SHIFT)));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_START, PGDIR_SIZE));
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, NUMA_NO_NODE,
diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
index b577dd0916aa..13e70da38bed 100644
--- a/arch/x86/include/asm/kasan.h
+++ b/arch/x86/include/asm/kasan.h
@@ -4,6 +4,7 @@
#include <linux/const.h>
#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#define KASAN_SHADOW_SCALE_SHIFT 3
/*
* Compiler uses shadow offset assuming that addresses start
@@ -12,12 +13,15 @@
* 'kernel address space start' >> KASAN_SHADOW_SCALE_SHIFT
*/
#define KASAN_SHADOW_START (KASAN_SHADOW_OFFSET + \
- ((-1UL << __VIRTUAL_MASK_SHIFT) >> 3))
+ ((-1UL << __VIRTUAL_MASK_SHIFT) >> \
+ KASAN_SHADOW_SCALE_SHIFT))
/*
- * 47 bits for kernel address -> (47 - 3) bits for shadow
- * 56 bits for kernel address -> (56 - 3) bits for shadow
+ * 47 bits for kernel address -> (47 - KASAN_SHADOW_SCALE_SHIFT) bits for shadow
+ * 56 bits for kernel address -> (56 - KASAN_SHADOW_SCALE_SHIFT) bits for shadow
*/
-#define KASAN_SHADOW_END (KASAN_SHADOW_START + (1ULL << (__VIRTUAL_MASK_SHIFT - 3)))
+#define KASAN_SHADOW_END (KASAN_SHADOW_START + \
+ (1ULL << (__VIRTUAL_MASK_SHIFT - \
+ KASAN_SHADOW_SCALE_SHIFT)))
#ifndef __ASSEMBLY__
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index e3eb834c9a35..e9eaa964473a 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -11,8 +11,6 @@ struct task_struct;
#ifdef CONFIG_KASAN
-#define KASAN_SHADOW_SCALE_SHIFT 3
-
#include <asm/kasan.h>
#include <asm/pgtable.h>
--
2.16.0.rc1.238.g530d649a79-goog
^ permalink raw reply related
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Andrey Konovalov @ 2018-01-12 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8f1d954-64fe-1e9c-d8ba-94e880de2501@virtuozzo.com>
On Thu, Jan 11, 2018 at 10:59 PM, Andrey Ryabinin
<aryabinin@virtuozzo.com> wrote:
>
>
> On 01/11/2018 06:29 PM, Andrey Konovalov wrote:
>
>> diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
>> index e266f80e45b7..811643fe7640 100644
>> --- a/arch/arm64/include/asm/kasan.h
>> +++ b/arch/arm64/include/asm/kasan.h
>> @@ -27,7 +27,8 @@
>> * should satisfy the following equation:
>> * KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
>
> Care to update comments as well?
Sure, done in v2.
>
>> */
>> -#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
>> +#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
>> + (64 - KASAN_SHADOW_SCALE_SHIFT)))
>>
>> void kasan_init(void);
>> void kasan_copy_shadow(pgd_t *pgdir);
^ permalink raw reply
* [patch v16 0/4] JTAG driver introduction
From: Oleksandr Shamray @ 2018-01-12 16:54 UTC (permalink / raw)
To: linux-arm-kernel
When a need raise up to use JTAG interface for system's devices
programming or CPU debugging, usually the user layer
application implements jtag protocol by bit-bang or using a
proprietary connection to vendor hardware.
This method can be slow and not generic.
We propose to implement general JTAG interface and infrastructure
to communicate with user layer application. In such way, we can
have the standard JTAG interface core part and separation from
specific HW implementation.
This allow new capability to debug the CPU or program system's
device via BMC without additional devices nor cost.
This patch purpose is to add JTAG master core infrastructure by
defining new JTAG class and provide generic JTAG interface
to allow hardware specific drivers to connect this interface.
This will enable all JTAG drivers to use the common interface
part and will have separate for hardware implementation.
The JTAG (Joint Test Action Group) core driver provides minimal generic
JTAG interface, which can be used by hardware specific JTAG master
controllers. By providing common interface for the JTAG controllers,
user space device programing is hardware independent.
Modern SoC which in use for embedded system' equipped with
internal JTAG master interface.
This interface is used for programming and debugging system's
hardware components, like CPLD, FPGA, CPU, voltage and
industrial controllers.
Firmware for such devices can be upgraded through JTAG interface during
Runtime. The JTAG standard support for multiple devices programming,
is in case their lines are daisy-chained together.
For example, systems which equipped with host CPU, BMC SoC or/and
number of programmable devices are capable to connect a pin and
select system components dynamically for programming and debugging,
This is using by the BMC which is equipped with internal SoC master
controller.
For example:
BMC JTAG master --> pin selected to CPLDs chain for programming (filed
upgrade, production)
BMC JTAG master --> pin selected to voltage monitors for programming
(field upgrade, production)
BMC JTAG master --> pin selected to host CPU (on-site debugging
and developers debugging)
For example, we can have application in user space which using calls
to JTAG driver executes CPLD programming directly from SVF file
The JTAG standard (IEEE 1149.1) defines the next connector pins:
- TDI (Test Data In);
- TDO (Test Data Out);
- TCK (Test Clock);
- TMS (Test Mode Select);
- TRST (Test Reset) (Optional);
The SoC equipped with JTAG master controller, performs
device programming on command or vector level. For example
a file in a standard SVF (Serial Vector Format) that contains
boundary scan vectors, can be used by sending each vector
to the JTAG interface and the JTAG controller will execute
the programming.
Initial version provides the system calls set for:
- SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
- SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
- RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
number of clocks.
SoC which are not equipped with JTAG master interface, can be built
on top of JTAG core driver infrastructure, by applying bit-banging of
TDI, TDO, TCK and TMS pins within the hardware specific driver.
Linus Torvalds (1):
Linux 4.15-rc6
Oleksandr Shamray (3):
drivers: jtag: Add JTAG core driver
drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master
driver
Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx
families JTAG master driver
.../devicetree/bindings/jtag/aspeed-jtag.txt | 22 +
Documentation/ioctl/ioctl-number.txt | 2 +
MAINTAINERS | 10 +
Makefile | 2 +-
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/jtag/Kconfig | 30 +
drivers/jtag/Makefile | 2 +
drivers/jtag/jtag-aspeed.c | 786 ++++++++++++++++++++
drivers/jtag/jtag.c | 283 +++++++
include/linux/jtag.h | 41 +
include/uapi/linux/jtag.h | 104 +++
12 files changed, 1284 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
create mode 100644 drivers/jtag/Kconfig
create mode 100644 drivers/jtag/Makefile
create mode 100644 drivers/jtag/jtag-aspeed.c
create mode 100644 drivers/jtag/jtag.c
create mode 100644 include/linux/jtag.h
create mode 100644 include/uapi/linux/jtag.h
^ 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