* Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Stephen Boyd @ 2019-09-06 5:26 UTC (permalink / raw)
To: Jack Pham, Jorge Ramirez
Cc: mark.rutland, robh, kishon, gregkh, linux-usb, khasim.mohammed,
linux-kernel, Bjorn Andersson, devicetree, linux-arm-msm,
andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <20190905175802.GA19599@jackp-linux.qualcomm.com>
Quoting Jack Pham (2019-09-05 10:58:02)
> Hi Jorge, Bjorn,
>
> On Thu, Sep 05, 2019 at 09:18:57AM +0200, Jorge Ramirez wrote:
> > On 9/4/19 01:34, Bjorn Andersson wrote:
> > > On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
> > >> that would need an of_regulator_get() sort of API that can get the
> > >> regulator out of there? Or to make the connector into a struct device
> > >> that can get the regulator out per some generic connector driver and
> > >> then pass it through to the USB controller when it asks for it. Maybe
> > >> try to prototype that out?
> > >>
> > >
> > > The examples given in the DT bindings describes the connector as a child
> > > of a PMIC, with of_graph somehow tying it to the various inputs. But in
> > > these examples vbus is handled by implicitly inside the MFD, where
> > > extcon is informed about the plug event they toggle vbus as well.
> > >
> > > In our case we have a extcon-usb-gpio to detect mode, which per Jorge's
> > > proposal will trickle down to the PHY and become a regulator calls on
> > > either some external regulator or more typically one of the chargers in
> > > the system.
>
> Interesting you mention extcon-usb-gpio. I thought extcon at least from
> bindings perspective is passé now. Maybe this is what you need (just
> landed in usb-next):
>
> usb: common: add USB GPIO based connection detection driver
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=4602f3bff2669012c1147eecfe74c121765f5c56
>
> dt-bindings: usb: add binding for USB GPIO based connection detection driver
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=f651c73e71f53f65e9846677d79d8e120452b59f
>
> Fortunately this new driver might check the right boxes for you:
> - usb connector binding
> - ID detect GPIO
> - vbus-supply regulator
>
> With that, I think you can also keep the connector subnode out of the
> SSPHY node well, and similarly get rid of the vbus toggle handling from
> the PHY driver.
>
> The big thing missing now is that this driver replaces extcon
> completely, so we'll need handling in dwc3/dwc3-qcom to retrieve the
> role switch state to know when host mode is entered. I saw this a while
> back but don't think it got picked up:
>
> https://patchwork.kernel.org/patch/10909981/
>
Yes this looks like the approach that should be taken. One question
though, is this a micro-b connector or a type-c connector on the board?
I thought it was a type-c, so then this USB gpio based connection driver
isn't an exact fit?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Jianxin Pan @ 2019-09-06 5:59 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Hanjie Lin, Victor Wan, Neil Armstrong, Kevin Hilman,
linux-kernel, Qiufang Dai, Rob Herring, Jian Hu, Xingyu Chen,
Tao Zeng, Carlo Caione, linux-amlogic, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <CAFBinCBSmW4y-Dz7EkJMV8HOU4k6Z0G-K6T77XnVrHyubaSsdg@mail.gmail.com>
Hi Martin,
Thanks for the review, we really appreciate your time.
Please see my comments below.
On 2019/9/6 4:15, Martin Blumenstingl wrote:
> Hi Jianxin,
>
> (it's great to see that you and your team are upstreaming this early)
>
> On Thu, Sep 5, 2019 at 9:08 AM Jianxin Pan <jianxin.pan@amlogic.com> wrote:
> [...]
>> + memory@0 {
>> + device_type = "memory";
>> + reg = <0x0 0x0 0x0 0x8000000>;
>> + /*linux,usable-memory = <0x0 0x0 0x0 0x8000000>;*/
> why do we need that comment here (I don't understand it - why doesn't
> the "reg" property cover this)?
> I replaced "linux,usable-memory" with reg, but forgot to remove this comment line.
I will remove this line in the next version. Thank you.
>> + };
>> +};
>> +
>> +&uart_AO_B {
>> + status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
>> new file mode 100644
>> index 00000000..4d476ac
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
>> @@ -0,0 +1,122 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +/ {
>> + compatible = "amlogic,a1";
>> +
>> + interrupt-parent = <&gic>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + cpus {
>> + #address-cells = <0x2>;
>> + #size-cells = <0x0>;
> only now I notice that all our other .dtsi also use hex values
> (instead of decimal as just a few lines above) here
> do you know if there is a particular reason for this?
>
I just copied from the previous series, and didn't notice the difference before.> [...]
>> + uart_AO_B: serial@fe002000 {
>> + compatible = "amlogic,meson-gx-uart",
>> + "amlogic,meson-ao-uart";
>> + reg = <0x0 0xfe002000 0x0 0x18>;
> the indentation of the "reg" property is off here
OK, I will fix it.
>
> also I'm a bit surprised to see no busses (like aobus, cbus, periphs, ...) here
> aren't there any busses defined in the A1 SoC implementation or are
> were you planning to add them later?
>Unlike previous series,there is no Cortex-M3 AO CPU in A1, and there is no AO/EE power domain.
Most of the registers are on the apb_32b bus. aobus, cbus and periphs are not used in A1.
>
> Martin
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] perf/hw_breakpoint: Fix arch_hw_breakpoint use-before-initialization
From: Mark-PK Tsai @ 2019-09-06 6:01 UTC (permalink / raw)
To: peterz, mingo, acme, alexander.shishkin, jolsa, namhyung,
matthias.bgg
Cc: Alix Wu, YJ Chiang, linux-kernel, linux-mediatek,
linux-arm-kernel, Mark-PK Tsai
If we disable the compiler's auto-initialization feature
(-fplugin-arg-structleak_plugin-byref or -ftrivial-auto-var-init=pattern)
is disabled, arch_hw_breakpoint may be used before initialization after
the change 9a4903dde2c86.
(perf/hw_breakpoint: Split attribute parse and commit)
On our arm platform, the struct step_ctrl in arch_hw_breakpoint, which
used to be zero-initialized by kzalloc, may be used in
arch_install_hw_breakpoint without initialization.
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Cc: YJ Chiang <yj.chiang@mediatek.com>
Cc: Alix Wu <alix.wu@mediatek.com>
---
kernel/events/hw_breakpoint.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index c5cd852fe86b..8fb842394924 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -413,7 +413,7 @@ static int hw_breakpoint_parse(struct perf_event *bp,
int register_perf_hw_breakpoint(struct perf_event *bp)
{
- struct arch_hw_breakpoint hw;
+ struct arch_hw_breakpoint hw = {0};
int err;
err = reserve_bp_slot(bp);
@@ -461,7 +461,7 @@ int
modify_user_hw_breakpoint_check(struct perf_event *bp, struct perf_event_attr *attr,
bool check)
{
- struct arch_hw_breakpoint hw;
+ struct arch_hw_breakpoint hw = {0};
int err;
err = hw_breakpoint_parse(bp, attr, &hw);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/5] Add ast2600 gpio support
From: Rashmica Gupta @ 2019-09-06 6:25 UTC (permalink / raw)
To: linus.walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Rob Herring, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
v3: Different ordering of patches, using ngpio property to distinguish between
the two ast2600 gpio controllers, fixed typos of 3.6V.
v2: More verbose commit messages, using DIV_ROUND_UP().
Rashmica Gupta (5):
dt-bindings: gpio: aspeed: Update documentation with ast2600
controllers
gpio/aspeed: Fix incorrect number of banks
gpio/aspeed: Setup irqchip dynamically
gpios: Use ngpio property from device tree if available
gpio: Add in ast2600 details to Aspeed driver
drivers/gpio/gpio-aspeed.c | 52 ++++++++++++-------
.../devicetree/bindings/gpio/gpio-aspeed.txt | 7 ++-
2 files changed, 39 insertions(+), 20 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: gpio: aspeed: Update documentation with ast2600 controllers
From: Rashmica Gupta @ 2019-09-06 6:25 UTC (permalink / raw)
To: linus.walleij
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Rob Herring, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
The ast2600 is a new generation of SoC from ASPEED. Similarly to the
ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins.
Additionally, it has a GPIO controller for 36 1.8V GPIO pins. We use
the ngpio property to differentiate between these controllers.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
index 7e9b586770b0..b2033fc3a71a 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
@@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
-------------------------------------------
Required properties:
-- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
+- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
+ or "aspeed,ast2600-gpio".
- #gpio-cells : Should be two
- First cell is the GPIO line number
@@ -17,7 +18,9 @@ Required properties:
Optional properties:
-- clocks : A phandle to the clock to use for debounce timings
+- clocks : A phandle to the clock to use for debounce timings
+- ngpios : Number of GPIOs controlled by this controller. Should be set
+ when there are multiple GPIO controllers on a SoC (ast2600).
The gpio and interrupt properties are further described in their respective
bindings documentation:
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/5] gpio/aspeed: Fix incorrect number of banks
From: Rashmica Gupta @ 2019-09-06 6:26 UTC (permalink / raw)
To: linus.walleij
Cc: moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
The current calculation for the number of GPIO banks is only correct if
the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
currently say there are 0 banks, which is incorrect).
Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/gpio/gpio-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 9defe25d4721..b83e23aecd18 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->chip.base = -1;
/* Allocate a cache of the output registers */
- banks = gpio->config->nr_gpios >> 5;
+ banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/5] gpio/aspeed: Setup irqchip dynamically
From: Rashmica Gupta @ 2019-09-06 6:26 UTC (permalink / raw)
To: linus.walleij
Cc: moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
This is in preparation for adding ast2600 support. The ast2600 SoC
requires two instances of the GPIO driver as it has two GPIO
controllers. Each instance needs it's own irqchip.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index b83e23aecd18..16c6eaf70857 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -52,6 +52,7 @@ struct aspeed_gpio_config {
*/
struct aspeed_gpio {
struct gpio_chip chip;
+ struct irq_chip irqc;
spinlock_t lock;
void __iomem *base;
int irq;
@@ -681,14 +682,6 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(ic, desc);
}
-static struct irq_chip aspeed_gpio_irqchip = {
- .name = "aspeed-gpio",
- .irq_ack = aspeed_gpio_irq_ack,
- .irq_mask = aspeed_gpio_irq_mask,
- .irq_unmask = aspeed_gpio_irq_unmask,
- .irq_set_type = aspeed_gpio_set_type,
-};
-
static void set_irq_valid_mask(struct aspeed_gpio *gpio)
{
const struct aspeed_bank_props *props = gpio->config->props;
@@ -1192,7 +1185,12 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->irq = rc;
girq = &gpio->chip.irq;
- girq->chip = &aspeed_gpio_irqchip;
+ girq->chip = &gpio->irqc;
+ girq->chip->name = dev_name(&pdev->dev);
+ girq->chip->irq_ack = aspeed_gpio_irq_ack;
+ girq->chip->irq_mask = aspeed_gpio_irq_mask;
+ girq->chip->irq_unmask = aspeed_gpio_irq_unmask;
+ girq->chip->irq_set_type = aspeed_gpio_set_type;
girq->parent_handler = aspeed_gpio_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(&pdev->dev, 1,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/5] gpios: Use ngpio property from device tree if available
From: Rashmica Gupta @ 2019-09-06 6:27 UTC (permalink / raw)
To: linus.walleij
Cc: moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
Use the ngpio property from the device tree if it exists. If it doesn't
then fallback to the hardcoded value in the config.
This is in preparation for adding ast2600 support. The ast2600 SoC has
two GPIO controllers and so requires two instances of the GPIO driver.
We use the ngpio property to different between them as they have
different numbers of GPIOs.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 16c6eaf70857..c3d5ecba343b 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -694,7 +694,7 @@ static void set_irq_valid_mask(struct aspeed_gpio *gpio)
for_each_clear_bit(offset, &input, 32) {
unsigned int i = props->bank * 32 + offset;
- if (i >= gpio->config->nr_gpios)
+ if (i >= gpio->chip.ngpio)
break;
clear_bit(i, gpio->chip.irq.valid_mask);
@@ -1007,10 +1007,10 @@ int aspeed_gpio_copro_grab_gpio(struct gpio_desc *desc,
unsigned long flags;
if (!gpio->cf_copro_bankmap)
- gpio->cf_copro_bankmap = kzalloc(gpio->config->nr_gpios >> 3, GFP_KERNEL);
+ gpio->cf_copro_bankmap = kzalloc(gpio->chip.ngpio >> 3, GFP_KERNEL);
if (!gpio->cf_copro_bankmap)
return -ENOMEM;
- if (offset < 0 || offset > gpio->config->nr_gpios)
+ if (offset < 0 || offset > gpio->chip.ngpio)
return -EINVAL;
bindex = offset >> 3;
@@ -1055,7 +1055,7 @@ int aspeed_gpio_copro_release_gpio(struct gpio_desc *desc)
if (!gpio->cf_copro_bankmap)
return -ENXIO;
- if (offset < 0 || offset > gpio->config->nr_gpios)
+ if (offset < 0 || offset > gpio->chip.ngpio)
return -EINVAL;
bindex = offset >> 3;
@@ -1119,7 +1119,8 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
{
const struct of_device_id *gpio_id;
struct aspeed_gpio *gpio;
- int rc, i, banks;
+ int rc, i, banks, err;
+ u32 ngpio;
gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
if (!gpio)
@@ -1145,7 +1146,10 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->config = gpio_id->data;
gpio->chip.parent = &pdev->dev;
- gpio->chip.ngpio = gpio->config->nr_gpios;
+ err = of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpio);
+ gpio->chip.ngpio = (u16) ngpio;
+ if (err)
+ gpio->chip.ngpio = gpio->config->nr_gpios;
gpio->chip.direction_input = aspeed_gpio_dir_in;
gpio->chip.direction_output = aspeed_gpio_dir_out;
gpio->chip.get_direction = aspeed_gpio_get_direction;
@@ -1158,7 +1162,7 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->chip.base = -1;
/* Allocate a cache of the output registers */
- banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
+ banks = DIV_ROUND_UP(gpio->chip.ngpio, 32);
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-06 6:28 UTC (permalink / raw)
To: Gerald Schaefer
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20190905190629.523bdb87@thinkpad>
On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
> On Thu, 5 Sep 2019 14:48:14 +0530
> Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>>> [...]
>>>> +
>>>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>> +static void pud_clear_tests(pud_t *pudp)
>>>> +{
>>>> + memset(pudp, RANDOM_NZVALUE, sizeof(pud_t));
>>>> + pud_clear(pudp);
>>>> + WARN_ON(!pud_none(READ_ONCE(*pudp)));
>>>> +}
>>>
>>> For pgd/p4d/pud_clear(), we only clear if the page table level is present
>>> and not folded. The memset() here overwrites the table type bits, so
>>> pud_clear() will not clear anything on s390 and the pud_none() check will
>>> fail.
>>> Would it be possible to OR a (larger) random value into the table, so that
>>> the lower 12 bits would be preserved?
>>
>> So the suggestion is instead of doing memset() on entry with RANDOM_NZVALUE,
>> it should OR a large random value preserving lower 12 bits. Hmm, this should
>> still do the trick for other platforms, they just need non zero value. So on
>> s390, the lower 12 bits on the page table entry already has valid value while
>> entering this function which would make sure that pud_clear() really does
>> clear the entry ?
>
> Yes, in theory the table entry on s390 would have the type set in the last
> 4 bits, so preserving those would be enough. If it does not conflict with
> others, I would still suggest preserving all 12 bits since those would contain
> arch-specific flags in general, just to be sure. For s390, the pte/pmd tests
> would also work with the memset, but for consistency I think the same logic
> should be used in all pxd_clear_tests.
Makes sense but..
There is a small challenge with this. Modifying individual bits on a given
page table entry from generic code like this test case is bit tricky. That
is because there are not enough helpers to create entries with an absolute
value. This would have been easier if all the platforms provided functions
like __pxx() which is not the case now. Otherwise something like this should
have worked.
pud_t pud = READ_ONCE(*pudp);
pud = __pud(pud_val(pud) | RANDOM_VALUE (keeping lower 12 bits 0))
WRITE_ONCE(*pudp, pud);
But __pud() will fail to build in many platforms.
The other alternative will be to make sure memset() happens on all other
bits except the lower 12 bits which will depend on endianness. If s390
has a fixed endianness, we can still use either of them which will hold
good for others as well.
memset(pudp, RANDOM_NZVALUE, sizeof(pud_t) - 3);
OR
memset(pudp + 3, RANDOM_NZVALUE, sizeof(pud_t) - 3);
>
> However, there is another issue on s390 which will make this only work
> for pud_clear_tests(), and not for the p4d/pgd_tests. The problem is that
> mm_alloc() will only give you a 3-level page table initially on s390.
> This means that pudp == p4dp == pgdp, and so the p4d/pgd_tests will
> both see the pud level (of course this also affects other tests).
Got it.
>
> Not sure yet how to fix this, i.e. how to initialize/update the page table
> to 5 levels. We can handle 5 level page tables, and it would be good if
> all levels could be tested, but using mm_alloc() to establish the page
> tables might not work on s390. One option could be to provide an arch-hook
> or weak function to allocate/initialize the mm.
Sure, got it. Though I plan to do add some arch specific tests or init sequence
like the above later on but for now the idea is to get the smallest possible set
of test cases which builds and runs on all platforms without requiring any arch
specific hooks or special casing (#ifdef) to be agreed upon broadly and accepted.
Do you think this is absolutely necessary on s390 for the very first set of test
cases or we can add this later on as an improvement ?
>
> IIUC, the (dummy) mm is really only needed to provide an mm->pgd as starting
> point, right?
Right.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/4] DaVinci defconfig updates for v5.4
From: Peter Ujfalusi @ 2019-09-06 6:31 UTC (permalink / raw)
To: Arnd Bergmann, Sekhar Nori
Cc: Bartosz Golaszewski, ARM-SoC Maintainers, Linux ARM Mailing List
In-Reply-To: <CAK8P3a0NGVHhWBtXwbB7aZMA-hsGn-jwJDYUS1WgLoux6j-hBA@mail.gmail.com>
On 04/09/2019 17.51, Arnd Bergmann wrote:
> On Wed, Aug 28, 2019 at 5:18 PM Sekhar Nori <nsekhar@ti.com> wrote:
>>
>> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>>
>> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v5.4/defconfig
>>
>> for you to fetch changes up to e869e44f2d82b9b4d35d58ceaeeadb0242bc634c:
>>
>> ARM: davinci_all_defconfig: enable GPIO backlight (2019-08-08 14:33:45 +0530)
>>
>> ----------------------------------------------------------------
>> Contains davinci_all_defconfig refresh using savedefconfig and a
>> patch to enable GPIO backlight.
>>
>> ----------------------------------------------------------------
>> Bartosz Golaszewski (2):
>> ARM: davinci: refresh davinci_all_defconfig
>> ARM: davinci_all_defconfig: enable GPIO backlight
>
> I'm generally not a fan of these 'refresh defconfig' patches when they
> silently change options that may or may not be needed.
>
> Some lines are just moved around but these ones
> are completely removed:
>
> -# CONFIG_IOSCHED_DEADLINE is not set
> -# CONFIG_IOSCHED_CFQ is not set
> -CONFIG_PREEMPT=y
> -CONFIG_SND_SOC_TLV320AIC3X=m
> -CONFIG_SND_SOC_DAVINCI_MCASP=m
> -CONFIG_LEDS_TRIGGERS=y
> -CONFIG_TI_EDMA=y
EDMA is kind of needed on daVinci, no?
aic3x and McASP can be good if you want audio support on the boards...
> -# CONFIG_ARM_UNWIND is not set
>
> I think most of these are ok, but I don't see any explanation
> about why you turn off CONFIG_PREEMPT.
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 5/5] gpio: Add in ast2600 details to Aspeed driver
From: Rashmica Gupta @ 2019-09-06 6:37 UTC (permalink / raw)
To: linus.walleij
Cc: moderated list:ARM/ASPEED MACHINE SUPPORT,
open list:GPIO SUBSYSTEM, Andrew Jeffery, open list,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
moderated list:ARM/ASPEED MACHINE SUPPORT
The ast2600 is a new generation of SoC from ASPEED. Similarly to the
ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins.
Additionally, it has a GPIO controller for 1.8V GPIO pins.
As the register names for both controllers are the same and the 36 1.8V
GPIOs and the first 36 of the 3.3V GPIOs are all bidirectional, we can
use the same configuration struct and use the ngpio property to
differentiate between the two sets of GPIOs.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index effcfaaf8c0c..22d482072632 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct irq_chip *ic = irq_desc_get_chip(desc);
struct aspeed_gpio *data = gpiochip_get_data(gc);
- unsigned int i, p, girq;
+ unsigned int i, p, girq, banks;
unsigned long reg;
+ struct aspeed_gpio *gpio = gpiochip_get_data(gc);
chained_irq_enter(ic, desc);
- for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
+ banks = DIV_ROUND_UP(gpio->chip.ngpio, 32);
+ for (i = 0; i < banks; i++) {
const struct aspeed_gpio_bank *bank = &aspeed_gpio_banks[i];
reg = ioread32(bank_reg(data, bank, reg_irq_status));
@@ -1134,9 +1136,25 @@ static const struct aspeed_gpio_config ast2500_config =
/* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
{ .nr_gpios = 232, .props = ast2500_bank_props, };
+static const struct aspeed_bank_props ast2600_bank_props[] = {
+ /* input output */
+ {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
+ {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
+ { },
+};
+
+static const struct aspeed_gpio_config ast2600_config =
+ /*
+ * ast2600 has two controllers one with 208 GPIOs and one with 36 GPIOs.
+ * We expect ngpio being set in the device tree and this is a fallback
+ * option.
+ */
+ { .nr_gpios = 208, .props = ast2600_bank_props, };
+
static const struct of_device_id aspeed_gpio_of_table[] = {
{ .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config, },
{ .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config, },
+ { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config, },
{}
};
MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH 1/2] nvmem: imx: scu: support hole region check
From: Peng Fan @ 2019-09-06 6:57 UTC (permalink / raw)
To: Peng Fan, srinivas.kandagatla@linaro.org, shawnguo@kernel.org,
s.hauer@pengutronix.de
Cc: Aisheng Dong, linux-kernel@vger.kernel.org, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566356496-30493-1-git-send-email-peng.fan@nxp.com>
> Subject: [PATCH 1/2] nvmem: imx: scu: support hole region check
Ping..
Thanks,
Peng.
>
> From: Peng Fan <peng.fan@nxp.com>
>
> Introduce HOLE/ECC_REGION flag and in_hole helper to ease the check of
> hole region. The ECC_REGION is also introduced here which is preparing for
> programming support. ECC_REGION could only be programmed once, so need
> take care.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/nvmem/imx-ocotp-scu.c | 42
> +++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index d9dc482ecb2f..2f339d7432e6 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -18,9 +18,20 @@ enum ocotp_devtype {
> IMX8QXP,
> };
>
> +#define ECC_REGION BIT(0)
> +#define HOLE_REGION BIT(1)
> +
> +struct ocotp_region {
> + u32 start;
> + u32 end;
> + u32 flag;
> +};
> +
> struct ocotp_devtype_data {
> int devtype;
> int nregs;
> + u32 num_region;
> + struct ocotp_region region[];
> };
>
> struct ocotp_priv {
> @@ -37,8 +48,31 @@ struct imx_sc_msg_misc_fuse_read { static struct
> ocotp_devtype_data imx8qxp_data = {
> .devtype = IMX8QXP,
> .nregs = 800,
> + .num_region = 3,
> + .region = {
> + {0x10, 0x10f, ECC_REGION},
> + {0x110, 0x21F, HOLE_REGION},
> + {0x220, 0x31F, ECC_REGION},
> + },
> };
>
> +static bool in_hole(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & HOLE_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> u32 *val)
> {
> @@ -85,11 +119,9 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
> buf = p;
>
> for (i = index; i < (index + count); i++) {
> - if (priv->data->devtype == IMX8QXP) {
> - if ((i > 271) && (i < 544)) {
> - *buf++ = 0;
> - continue;
> - }
> + if (in_hole(context, i)) {
> + *buf++ = 0;
> + continue;
> }
>
> ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
> --
> 2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/2] nvmem: imx: scu: support write
From: Peng Fan @ 2019-09-06 6:57 UTC (permalink / raw)
To: Peng Fan, srinivas.kandagatla@linaro.org, shawnguo@kernel.org,
s.hauer@pengutronix.de
Cc: Aisheng Dong, linux-kernel@vger.kernel.org, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1566356496-30493-2-git-send-email-peng.fan@nxp.com>
> Subject: [PATCH 2/2] nvmem: imx: scu: support write
Ping..
Thanks,
Peng.
>
> From: Peng Fan <peng.fan@nxp.com>
>
> The fuse programming from non-secure world is blocked, so we could only use
> Arm Trusted Firmware SIP call to let ATF program fuse.
>
> Because there is ECC region that could only be programmed once, so add a
> heler in_ecc to check the ecc region.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>
> The ATF patch will soon be posted to ATF community.
>
> drivers/nvmem/imx-ocotp-scu.c | 73
> ++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
> index 2f339d7432e6..0f064f2e74a8 100644
> --- a/drivers/nvmem/imx-ocotp-scu.c
> +++ b/drivers/nvmem/imx-ocotp-scu.c
> @@ -7,6 +7,7 @@
> * Peng Fan <peng.fan@nxp.com>
> */
>
> +#include <linux/arm-smccc.h>
> #include <linux/firmware/imx/sci.h>
> #include <linux/module.h>
> #include <linux/nvmem-provider.h>
> @@ -14,6 +15,9 @@
> #include <linux/platform_device.h>
> #include <linux/slab.h>
>
> +#define IMX_SIP_OTP 0xC200000A
> +#define IMX_SIP_OTP_WRITE 0x2
> +
> enum ocotp_devtype {
> IMX8QXP,
> };
> @@ -45,6 +49,8 @@ struct imx_sc_msg_misc_fuse_read {
> u32 word;
> } __packed;
>
> +static DEFINE_MUTEX(scu_ocotp_mutex);
> +
> static struct ocotp_devtype_data imx8qxp_data = {
> .devtype = IMX8QXP,
> .nregs = 800,
> @@ -73,6 +79,23 @@ static bool in_hole(void *context, u32 index)
> return false;
> }
>
> +static bool in_ecc(void *context, u32 index) {
> + struct ocotp_priv *priv = context;
> + const struct ocotp_devtype_data *data = priv->data;
> + int i;
> +
> + for (i = 0; i < data->num_region; i++) {
> + if (data->region[i].flag & ECC_REGION) {
> + if ((index >= data->region[i].start) &&
> + (index <= data->region[i].end))
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> u32 *val)
> {
> @@ -116,6 +139,8 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
> if (!p)
> return -ENOMEM;
>
> + mutex_lock(&scu_ocotp_mutex);
> +
> buf = p;
>
> for (i = index; i < (index + count); i++) { @@ -126,6 +151,7 @@ static int
> imx_scu_ocotp_read(void *context, unsigned int offset,
>
> ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, i, buf);
> if (ret) {
> + mutex_unlock(&scu_ocotp_mutex);
> kfree(p);
> return ret;
> }
> @@ -134,18 +160,63 @@ static int imx_scu_ocotp_read(void *context,
> unsigned int offset,
>
> memcpy(val, (u8 *)p + offset % 4, bytes);
>
> + mutex_unlock(&scu_ocotp_mutex);
> +
> kfree(p);
>
> return 0;
> }
>
> +static int imx_scu_ocotp_write(void *context, unsigned int offset,
> + void *val, size_t bytes)
> +{
> + struct ocotp_priv *priv = context;
> + struct arm_smccc_res res;
> + u32 *buf = val;
> + u32 tmp;
> + u32 index;
> + int ret;
> +
> + /* allow only writing one complete OTP word at a time */
> + if ((bytes != 4) || (offset % 4))
> + return -EINVAL;
> +
> + index = offset >> 2;
> +
> + if (in_hole(context, index))
> + return -EINVAL;
> +
> + if (in_ecc(context, index)) {
> + pr_warn("ECC region, only program once\n");
> + mutex_lock(&scu_ocotp_mutex);
> + ret = imx_sc_misc_otp_fuse_read(priv->nvmem_ipc, index, &tmp);
> + mutex_unlock(&scu_ocotp_mutex);
> + if (ret)
> + return ret;
> + if (tmp) {
> + pr_warn("ECC region, already has value: %x\n", tmp);
> + return -EIO;
> + }
> + }
> +
> + mutex_lock(&scu_ocotp_mutex);
> +
> + arm_smccc_smc(IMX_SIP_OTP, IMX_SIP_OTP_WRITE, index, *buf,
> + 0, 0, 0, 0, &res);
> +
> + mutex_unlock(&scu_ocotp_mutex);
> +
> + return res.a0;
> +}
> +
> static struct nvmem_config imx_scu_ocotp_nvmem_config = {
> .name = "imx-scu-ocotp",
> - .read_only = true,
> + .read_only = false,
> .word_size = 4,
> .stride = 1,
> .owner = THIS_MODULE,
> .reg_read = imx_scu_ocotp_read,
> + .reg_write = imx_scu_ocotp_write,
> };
>
> static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> --
> 2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Christian Brauner @ 2019-09-06 7:00 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Peter Zijlstra, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Shuah Khan, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Jiri Olsa, Alexander Shishkin, Ingo Molnar,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, Namhyung Kim, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, linux-api,
Chanho Min, Jeff Layton, Oleg Nesterov, Eric Biederman,
linux-alpha, linux-fsdevel, Andrew Morton, Linus Torvalds,
containers
In-Reply-To: <20190905195618.pwzgvuzadkfpznfz@yavin.dot.cyphar.com>
On Fri, Sep 06, 2019 at 05:56:18AM +1000, Aleksa Sarai wrote:
> On 2019-09-05, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Thu, Sep 05, 2019 at 08:23:03PM +0200, Christian Brauner wrote:
> >
> > > Because every caller of that function right now has that limit set
> > > anyway iirc. So we can either remove it from here and place it back for
> > > the individual callers or leave it in the helper.
> > > Also, I'm really asking, why not? Is it unreasonable to have an upper
> > > bound on the size (for a long time probably) or are you disagreeing with
> > > PAGE_SIZE being used? PAGE_SIZE limit is currently used by sched, perf,
> > > bpf, and clone3 and in a few other places.
> >
> > For a primitive that can be safely used with any size (OK, any within
> > the usual 2Gb limit)? Why push the random policy into the place where
> > it doesn't belong?
> >
> > Seriously, what's the point? If they want to have a large chunk of
> > userland memory zeroed or checked for non-zeroes - why would that
> > be a problem?
>
> Thinking about it some more, there isn't really any r/w amplification --
> so there isn't much to gain by passing giant structs. Though, if we are
> going to permit 2GB buffers, isn't that also an argument to use
> memchr_inv()? :P
I think we should just do a really dumb, easy to understand minimal
thing for now. It could even just be what every caller is doing right
now anyway with the get_user() loop.
The only way to settle memchr_inv() vs all the other clever ways
suggested here is to benchmark it and see if it matters *for the current
users* of this helper. If it does, great we can do it. If it doesn't why
bother having that argument right now?
Once we somehow end up in a possible world where we apparently have
decided it's a great idea to copy 2GB argument structures for a syscall
into or from the kernel we can start optimizing the hell out of this.
Before that and especially with current callers I honestly doubt it
matters whether we use memchr_inv() or while() {get_user()} loops.
Christian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-06 7:03 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, linux-arm-kernel, linux-snps-arc,
Kees Cook, Masahiro Yamada, Mark Brown, Dan Williams,
Vlastimil Babka, Sri Krishna chowdary, Ard Biesheuvel,
Greg Kroah-Hartman, linux-mips, Ralf Baechle, linux-kernel,
Paul Burton, Mike Rapoport, Vineet Gupta, Martin Schwidefsky,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20190905085910.i6dppgnqi4ple22w@box.shutemov.name>
On 09/05/2019 02:29 PM, Kirill A. Shutemov wrote:
> On Thu, Sep 05, 2019 at 01:48:27PM +0530, Anshuman Khandual wrote:
>>>> +#define VADDR_TEST (PGDIR_SIZE + PUD_SIZE + PMD_SIZE + PAGE_SIZE)
>>>
>>> What is special about this address? How do you know if it is not occupied
>>> yet?
>>
>> We are creating the page table from scratch after allocating an mm_struct
>> for a given random virtual address 'VADDR_TEST'. Hence nothing is occupied
>> just yet. There is nothing special about this address, just that it tries
>> to ensure the page table entries are being created with some offset from
>> beginning of respective page table page at all levels ? The idea is to
>> have a more representative form of page table structure for test.
>
> Why P4D_SIZE is missing?
That was an omission even though I was wondering whether it will be
applicable or even make sense on platforms which dont have real P4D.
>
> Are you sure it will not land into kernel address space on any arch?
Can it even cross user virtual address range with just a single span
at each page table level ? TBH I did not think about that possibility.
>
> I think more robust way to deal with this would be using
> get_unmapped_area() instead of fixed address.
Makes sense and probably its better to get a virtual address which
is known to have been checked against all boundary conditions. Will
explore around get_unmapped_area() in this regard.
>
>> This makes sense for runtime cases but there is a problem here.
>>
>> On arm64, pgd_populate() which takes (pud_t *) as last argument instead of
>> (p4d_t *) will fail to build when not wrapped in !__PAGETABLE_P4D_FOLDED
>> on certain configurations.
>>
>> ./arch/arm64/include/asm/pgalloc.h:81:75: note:
>> expected ‘pud_t *’ {aka ‘struct <anonymous> *’}
>> but argument is of type ‘pgd_t *’ {aka ‘struct <anonymous> *’}
>> static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
>> ~~~~~~~^~~~
>> Wondering if this is something to be fixed on arm64 or its more general
>> problem. Will look into this further.
>
> I think you need wrap this into #ifndef __ARCH_HAS_5LEVEL_HACK.
Okay.
>
>>>> + pmd_populate_tests(mm, pmdp, (pgtable_t) page);
>>>
>>> This is not correct for architectures that defines pgtable_t as pte_t
>>> pointer, not struct page pointer.
>>
>> Right, a grep on the source confirms that.
>>
>> These platforms define pgtable_t as struct page *
>>
>> arch/alpha/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/arm/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/arm64/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/csky/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/hexagon/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/ia64/include/asm/page.h: typedef struct page *pgtable_t;
>> arch/ia64/include/asm/page.h: typedef struct page *pgtable_t;
>> arch/m68k/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/microblaze/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/mips/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/nds32/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/nios2/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/openrisc/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/parisc/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/riscv/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/sh/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/sparc/include/asm/page_32.h:typedef struct page *pgtable_t;
>> arch/um/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/unicore32/include/asm/page.h:typedef struct page *pgtable_t;
>> arch/x86/include/asm/pgtable_types.h:typedef struct page *pgtable_t;
>> arch/xtensa/include/asm/page.h:typedef struct page *pgtable_t;
>>
>> These platforms define pgtable_t as pte_t *
>>
>> arch/arc/include/asm/page.h:typedef pte_t * pgtable_t;
>> arch/powerpc/include/asm/mmu.h:typedef pte_t *pgtable_t;
>> arch/s390/include/asm/page.h:typedef pte_t *pgtable_t;
>> arch/sparc/include/asm/page_64.h:typedef pte_t *pgtable_t;
>>
>> Should we need have two pmd_populate_tests() definitions with
>> different arguments (struct page pointer or pte_t pointer) and then
>> call either one after detecting the given platform ?
>
> Use pte_alloc_one() instead of alloc_mapped_page() to allocate the page
> table.
Right, the PTE page table page should come from pte_alloc_one() instead
directly from a struct page. The functions pte_alloc_one() and pte_free()
operate on (struct page or pte_t) pointers depending applicable pgtable_t
definition (in cases where platform defines otherwise). Will fix it.
>
>>>> + pud_populate_tests(mm, pudp, pmdp);
>>>> + p4d_populate_tests(mm, p4dp, pudp);
>>>> + pgd_populate_tests(mm, pgdp, p4dp);
>>>
>>> This is wrong. All p?dp points to the second entry in page table entry.
>>> This is not valid pointer for page table and triggers p?d_bad() on x86.
>>
>> Yeah these are second entries because of the way we create the page table.
>> But I guess its applicable only to the second argument in all these above
>> cases because the first argument can be any valid entry on previous page
>> table level.
>
> Yes:
>
> @@ -397,9 +396,9 @@ static int __init arch_pgtable_tests_init(void)
> pgd_clear_tests(pgdp);
>
> pmd_populate_tests(mm, pmdp, (pgtable_t) page);
> - pud_populate_tests(mm, pudp, pmdp);
> - p4d_populate_tests(mm, p4dp, pudp);
> - pgd_populate_tests(mm, pgdp, p4dp);
> + pud_populate_tests(mm, pudp, saved_pmdp);
> + p4d_populate_tests(mm, p4dp, saved_pudp);
> + pgd_populate_tests(mm, pgdp, saved_p4dp);
Sure.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] bus: ti-sysc: Fix handling of invalid clocks
From: Roger Quadros @ 2019-09-06 7:39 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Nishanth Menon, Tero Kristo, Dave Gerlach, Keerthy, linux-kernel,
Andrew F . Davis, Peter Ujfalusi, Faiz Abbas, Greg Kroah-Hartman,
linux-arm-kernel
In-Reply-To: <20190905215356.8168-1-tony@atomide.com>
On 06/09/2019 00:53, Tony Lindgren wrote:
> We can currently get "Unable to handle kernel paging request at
> virtual address" for invalid clocks with dts node but no driver:
>
> (__clk_get_hw) from [<c0138ebc>] (ti_sysc_find_one_clockdomain+0x18/0x34)
> (ti_sysc_find_one_clockdomain) from [<c0138f0c>] (ti_sysc_clkdm_init+0x34/0xdc)
> (ti_sysc_clkdm_init) from [<c0584660>] (sysc_probe+0xa50/0x10e8)
> (sysc_probe) from [<c065c6ac>] (platform_drv_probe+0x58/0xa8)
>
> Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
> clk_get() with -ENOENT as a proper error. If the clock name is specified
> in device tree we must succeed with clk_get() to continue. For modules with
> no clock names specified in device tree we will just ignore the clocks.
>
> Fixes: 2b2f7def058a ("bus: ti-sysc: Add support for missing clockdomain handling")
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Roger Quadros <rogerq@ti.com>
> ---
> arch/arm/mach-omap2/pdata-quirks.c | 4 ++--
> drivers/bus/ti-sysc.c | 5 +----
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -491,11 +491,11 @@ static int ti_sysc_clkdm_init(struct device *dev,
> struct clk *fck, struct clk *ick,
> struct ti_sysc_cookie *cookie)
> {
> - if (fck)
> + if (!IS_ERR(fck))
> cookie->clkdm = ti_sysc_find_one_clockdomain(fck);
> if (cookie->clkdm)
> return 0;
> - if (ick)
> + if (!IS_ERR(ick))
> cookie->clkdm = ti_sysc_find_one_clockdomain(ick);
> if (cookie->clkdm)
> return 0;
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -280,9 +280,6 @@ static int sysc_get_one_clock(struct sysc *ddata, const char *name)
>
> ddata->clocks[index] = devm_clk_get(ddata->dev, name);
> if (IS_ERR(ddata->clocks[index])) {
> - if (PTR_ERR(ddata->clocks[index]) == -ENOENT)
> - return 0;
> -
> dev_err(ddata->dev, "clock get error for %s: %li\n",
> name, PTR_ERR(ddata->clocks[index]));
>
> @@ -357,7 +354,7 @@ static int sysc_get_clocks(struct sysc *ddata)
> continue;
>
> error = sysc_get_one_clock(ddata, name);
> - if (error && error != -ENOENT)
> + if (error)
> return error;
> }
>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 0/5] net: stmmac: Improvements and fixes for -next
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
Improvements and fixes for recently introduced features. All for -next tree.
More info in commit logs.
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (5):
net: stmmac: selftests: Add missing checks for support of SA
net: stmmac: selftests: Set RX tail pointer in Flow Control test
net: stmmac: dwmac4: Enable RX Jumbo frame support
net: stmmac: selftests: Add Split Header test
net: stmmac: Limit max speeds of XGMAC if asked to
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 3 +-
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 ---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 25 +++++----
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 60 ++++++++++++++++++++++
4 files changed, 78 insertions(+), 16 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 5/5] net: stmmac: Limit max speeds of XGMAC if asked to
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
We may have some SoCs that can't achieve XGMAC max speed. Limit it if
asked to.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 25 +++++++++++++++--------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c3baca9f587b..686b82068142 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -831,15 +831,22 @@ static void stmmac_validate(struct phylink_config *config,
phylink_set(mask, 1000baseT_Full);
phylink_set(mask, 1000baseX_Full);
} else if (priv->plat->has_xgmac) {
- phylink_set(mac_supported, 2500baseT_Full);
- phylink_set(mac_supported, 5000baseT_Full);
- phylink_set(mac_supported, 10000baseSR_Full);
- phylink_set(mac_supported, 10000baseLR_Full);
- phylink_set(mac_supported, 10000baseER_Full);
- phylink_set(mac_supported, 10000baseLRM_Full);
- phylink_set(mac_supported, 10000baseT_Full);
- phylink_set(mac_supported, 10000baseKX4_Full);
- phylink_set(mac_supported, 10000baseKR_Full);
+ if (!max_speed || (max_speed >= 2500)) {
+ phylink_set(mac_supported, 2500baseT_Full);
+ phylink_set(mac_supported, 2500baseX_Full);
+ }
+ if (!max_speed || (max_speed >= 5000)) {
+ phylink_set(mac_supported, 5000baseT_Full);
+ }
+ if (!max_speed || (max_speed >= 10000)) {
+ phylink_set(mac_supported, 10000baseSR_Full);
+ phylink_set(mac_supported, 10000baseLR_Full);
+ phylink_set(mac_supported, 10000baseER_Full);
+ phylink_set(mac_supported, 10000baseLRM_Full);
+ phylink_set(mac_supported, 10000baseT_Full);
+ phylink_set(mac_supported, 10000baseKX4_Full);
+ phylink_set(mac_supported, 10000baseKR_Full);
+ }
}
/* Half-Duplex can only work with single queue */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next 4/5] net: stmmac: selftests: Add Split Header test
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
Add a test to validate that Split Header feature is working correctly.
It works by using the rececently introduced counter that increments each
time a packet with split header is received.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 2943943bec43..c56e89e1ae56 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1603,6 +1603,44 @@ static int stmmac_test_mjumbo(struct stmmac_priv *priv)
return 0;
}
+static int stmmac_test_sph(struct stmmac_priv *priv)
+{
+ unsigned long cnt_end, cnt_start = priv->xstats.rx_split_hdr_pkt_n;
+ struct stmmac_packet_attrs attr = { };
+ int ret;
+
+ if (!priv->sph)
+ return -EOPNOTSUPP;
+
+ /* Check for UDP first */
+ attr.dst = priv->dev->dev_addr;
+ attr.tcp = false;
+
+ ret = __stmmac_test_loopback(priv, &attr);
+ if (ret)
+ return ret;
+
+ cnt_end = priv->xstats.rx_split_hdr_pkt_n;
+ if (cnt_end <= cnt_start)
+ return -EINVAL;
+
+ /* Check for TCP now */
+ cnt_start = cnt_end;
+
+ attr.dst = priv->dev->dev_addr;
+ attr.tcp = true;
+
+ ret = __stmmac_test_loopback(priv, &attr);
+ if (ret)
+ return ret;
+
+ cnt_end = priv->xstats.rx_split_hdr_pkt_n;
+ if (cnt_end <= cnt_start)
+ return -EINVAL;
+
+ return 0;
+}
+
#define STMMAC_LOOPBACK_NONE 0
#define STMMAC_LOOPBACK_MAC 1
#define STMMAC_LOOPBACK_PHY 2
@@ -1724,6 +1762,10 @@ static const struct stmmac_test {
.name = "Multichannel Jumbo ",
.lb = STMMAC_LOOPBACK_PHY,
.fn = stmmac_test_mjumbo,
+ }, {
+ .name = "Split Header ",
+ .lb = STMMAC_LOOPBACK_PHY,
+ .fn = stmmac_test_sph,
},
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next 3/5] net: stmmac: dwmac4: Enable RX Jumbo frame support
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
We are already doing it by default in the TX path so we can also enable
Jumbo Frame support in the RX path independently of MTU value.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 6 ------
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index 2ed11a581d80..03301ffc0391 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -352,7 +352,8 @@ enum power_event {
/* Default operating mode of the MAC */
#define GMAC_CORE_INIT (GMAC_CONFIG_JD | GMAC_CONFIG_PS | \
- GMAC_CONFIG_BE | GMAC_CONFIG_DCRS)
+ GMAC_CONFIG_BE | GMAC_CONFIG_DCRS | \
+ GMAC_CONFIG_JE)
/* To dump the core regs excluding the Address Registers */
#define GMAC_REG_NUM 132
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index fc9954e4a772..596311a80d1c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -25,15 +25,9 @@ static void dwmac4_core_init(struct mac_device_info *hw,
{
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONFIG);
- int mtu = dev->mtu;
value |= GMAC_CORE_INIT;
- if (mtu > 1500)
- value |= GMAC_CONFIG_2K;
- if (mtu > 2000)
- value |= GMAC_CONFIG_JE;
-
if (hw->ps) {
value |= GMAC_CONFIG_TE;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next 2/5] net: stmmac: selftests: Set RX tail pointer in Flow Control test
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
We need to set the RX tail pointer so that RX engine starts working
again after finishing the Flow Control test.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index dce34c081a1e..2943943bec43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -722,8 +722,14 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
for (i = 0; i < rx_cnt; i++) {
struct stmmac_channel *ch = &priv->channel[i];
+ u32 tail;
+ tail = priv->rx_queue[i].dma_rx_phy +
+ (DMA_RX_SIZE * sizeof(struct dma_desc));
+
+ stmmac_set_rx_tail_ptr(priv, priv->ioaddr, tail, i);
stmmac_start_rx(priv, priv->ioaddr, i);
+
local_bh_disable();
napi_reschedule(&ch->rx_napi);
local_bh_enable();
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH net-next 1/5] net: stmmac: selftests: Add missing checks for support of SA
From: Jose Abreu @ 2019-09-06 7:41 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <cover.1567755423.git.joabreu@synopsys.com>
Add checks for support of Source Address Insertion/Replacement before
running the test.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 305d24935cf4..dce34c081a1e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1057,6 +1057,9 @@ static int stmmac_test_desc_sai(struct stmmac_priv *priv)
struct stmmac_packet_attrs attr = { };
int ret;
+ if (!priv->dma_cap.vlins)
+ return -EOPNOTSUPP;
+
attr.remove_sa = true;
attr.sarc = true;
attr.src = src;
@@ -1076,6 +1079,9 @@ static int stmmac_test_desc_sar(struct stmmac_priv *priv)
struct stmmac_packet_attrs attr = { };
int ret;
+ if (!priv->dma_cap.vlins)
+ return -EOPNOTSUPP;
+
attr.sarc = true;
attr.src = src;
attr.dst = priv->dev->dev_addr;
@@ -1094,6 +1100,9 @@ static int stmmac_test_reg_sai(struct stmmac_priv *priv)
struct stmmac_packet_attrs attr = { };
int ret;
+ if (!priv->dma_cap.vlins)
+ return -EOPNOTSUPP;
+
attr.remove_sa = true;
attr.sarc = true;
attr.src = src;
@@ -1114,6 +1123,9 @@ static int stmmac_test_reg_sar(struct stmmac_priv *priv)
struct stmmac_packet_attrs attr = { };
int ret;
+ if (!priv->dma_cap.vlins)
+ return -EOPNOTSUPP;
+
attr.sarc = true;
attr.src = src;
attr.dst = priv->dev->dev_addr;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] bus: ti-sysc: Fix handling of invalid clocks
From: Keerthy @ 2019-09-06 7:49 UTC (permalink / raw)
To: Tony Lindgren, linux-omap
Cc: Nishanth Menon, Tero Kristo, Dave Gerlach, Greg Kroah-Hartman,
linux-kernel, Andrew F . Davis, Peter Ujfalusi, Faiz Abbas,
linux-arm-kernel, Roger Quadros
In-Reply-To: <20190905215356.8168-1-tony@atomide.com>
On 06/09/19 3:23 AM, Tony Lindgren wrote:
> We can currently get "Unable to handle kernel paging request at
> virtual address" for invalid clocks with dts node but no driver:
>
> (__clk_get_hw) from [<c0138ebc>] (ti_sysc_find_one_clockdomain+0x18/0x34)
> (ti_sysc_find_one_clockdomain) from [<c0138f0c>] (ti_sysc_clkdm_init+0x34/0xdc)
> (ti_sysc_clkdm_init) from [<c0584660>] (sysc_probe+0xa50/0x10e8)
> (sysc_probe) from [<c065c6ac>] (platform_drv_probe+0x58/0xa8)
>
> Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
> clk_get() with -ENOENT as a proper error. If the clock name is specified
> in device tree we must succeed with clk_get() to continue. For modules with
> no clock names specified in device tree we will just ignore the clocks.
Tested for DS0 and RTC+DDR modes on AM437x
FWIW
Tested-by: Keerthy <j-keerthy@ti.com>
>
> Fixes: 2b2f7def058a ("bus: ti-sysc: Add support for missing clockdomain handling")
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/pdata-quirks.c | 4 ++--
> drivers/bus/ti-sysc.c | 5 +----
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -491,11 +491,11 @@ static int ti_sysc_clkdm_init(struct device *dev,
> struct clk *fck, struct clk *ick,
> struct ti_sysc_cookie *cookie)
> {
> - if (fck)
> + if (!IS_ERR(fck))
> cookie->clkdm = ti_sysc_find_one_clockdomain(fck);
> if (cookie->clkdm)
> return 0;
> - if (ick)
> + if (!IS_ERR(ick))
> cookie->clkdm = ti_sysc_find_one_clockdomain(ick);
> if (cookie->clkdm)
> return 0;
> diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
> --- a/drivers/bus/ti-sysc.c
> +++ b/drivers/bus/ti-sysc.c
> @@ -280,9 +280,6 @@ static int sysc_get_one_clock(struct sysc *ddata, const char *name)
>
> ddata->clocks[index] = devm_clk_get(ddata->dev, name);
> if (IS_ERR(ddata->clocks[index])) {
> - if (PTR_ERR(ddata->clocks[index]) == -ENOENT)
> - return 0;
> -
> dev_err(ddata->dev, "clock get error for %s: %li\n",
> name, PTR_ERR(ddata->clocks[index]));
>
> @@ -357,7 +354,7 @@ static int sysc_get_clocks(struct sysc *ddata)
> continue;
>
> error = sysc_get_one_clock(ddata, name);
> - if (error && error != -ENOENT)
> + if (error)
> return error;
> }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
From: Christoffer Dall @ 2019-09-06 7:58 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Peter Maydell, Daniel P. Berrangé, Marc Zyngier,
lkml - Kernel Mailing List, Stefan Hajnoczi, kvmarm,
arm-mail-list
In-Reply-To: <27e7edd6-1c4f-c970-3395-ecb4f176f858@gmx.de>
On Thu, Sep 05, 2019 at 03:25:47PM +0200, Heinrich Schuchardt wrote:
> On 9/5/19 11:22 AM, Christoffer Dall wrote:
> > On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
> > > On Thu, 5 Sep 2019 at 09:52, Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Thu, 05 Sep 2019 09:16:54 +0100,
> > > > Peter Maydell <peter.maydell@linaro.org> wrote:
> > > > > This is true, but the problem is that barfing out to userspace
> > > > > makes it harder to debug the guest because it means that
> > > > > the VM is immediately destroyed, whereas AIUI if we
> > > > > inject some kind of exception then (assuming you're set up
> > > > > to do kernel-debug via gdbstub) you can actually examine
> > > > > the offending guest code with a debugger because at least
> > > > > your VM is still around to inspect...
> > > >
> > > > To Christoffer's point, I find the benefit a bit dubious. Yes, you get
> > > > an exception, but the instruction that caused it may be completely
> > > > legal (store with post-increment, for example), leading to an even
> > > > more puzzled developer (that exception should never have been
> > > > delivered the first place).
> > >
> > > Right, but the combination of "host kernel prints a message
> > > about an unsupported load/store insn" and "within-guest debug
> > > dump/stack trace/etc" is much more useful than just having
> > > "host kernel prints message" and "QEMU exits"; and it requires
> > > about 3 lines of code change...
> > >
> > > > I'm far more in favour of dumping the state of the access in the run
> > > > structure (much like we do for a MMIO access) and let userspace do
> > > > something about it (such as dumping information on the console or
> > > > breaking). It could even inject an exception *if* the user has asked
> > > > for it.
> > >
> > > ...whereas this requires agreement on a kernel-userspace API,
> > > larger changes in the kernel, somebody to implement the userspace
> > > side of things, and the user to update both the kernel and QEMU.
> > > It's hard for me to see that the benefit here over the 3-line
> > > approach really outweighs the extra effort needed. In practice
> > > saying "we should do this" is saying "we're going to do nothing",
> > > based on the historical record.
> > >
> >
> > How about something like the following (completely untested, liable for
> > ABI discussions etc. etc., but for illustration purposes).
> >
> > I think it raises the question (and likely many other) of whether we can
> > break the existing 'ABI' and change behavior for missing ISV
> > retrospectively for legacy user space when the issue has occurred?
> >
> > Someone might have written code that reacts to the -ENOSYS, so I've
> > taken the conservative approach for this for the time being.
> >
> >
> > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> > index 8a37c8e89777..19a92c49039c 100644
> > --- a/arch/arm/include/asm/kvm_host.h
> > +++ b/arch/arm/include/asm/kvm_host.h
> > @@ -76,6 +76,14 @@ struct kvm_arch {
> >
> > /* Mandated version of PSCI */
> > u32 psci_version;
> > +
> > + /*
> > + * If we encounter a data abort without valid instruction syndrome
> > + * information, report this to user space. User space can (and
> > + * should) opt in to this feature if KVM_CAP_ARM_NISV_TO_USER is
> > + * supported.
> > + */
> > + bool return_nisv_io_abort_to_user;
> > };
> >
> > #define KVM_NR_MEM_OBJS 40
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index f656169db8c3..019bc560edc1 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -83,6 +83,14 @@ struct kvm_arch {
> >
> > /* Mandated version of PSCI */
> > u32 psci_version;
> > +
> > + /*
> > + * If we encounter a data abort without valid instruction syndrome
> > + * information, report this to user space. User space can (and
> > + * should) opt in to this feature if KVM_CAP_ARM_NISV_TO_USER is
> > + * supported.
> > + */
> > + bool return_nisv_io_abort_to_user;
>
> How about 32bit ARM?
>
What about it? Not sure I understand the comment.
> > };
> >
> > #define KVM_NR_MEM_OBJS 40
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 5e3f12d5359e..a4dd004d0db9 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -235,6 +235,7 @@ struct kvm_hyperv_exit {
> > #define KVM_EXIT_S390_STSI 25
> > #define KVM_EXIT_IOAPIC_EOI 26
> > #define KVM_EXIT_HYPERV 27
> > +#define KVM_EXIT_ARM_NISV 28
> >
> > /* For KVM_EXIT_INTERNAL_ERROR */
> > /* Emulate instruction failed. */
> > @@ -996,6 +997,7 @@ struct kvm_ppc_resize_hpt {
> > #define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
> > #define KVM_CAP_ARM_PTRAUTH_GENERIC 172
> > #define KVM_CAP_PMU_EVENT_FILTER 173
> > +#define KVM_CAP_ARM_NISV_TO_USER 174
> >
> > #ifdef KVM_CAP_IRQ_ROUTING
> >
> > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > index 35a069815baf..2ce94bd9d4a9 100644
> > --- a/virt/kvm/arm/arm.c
> > +++ b/virt/kvm/arm/arm.c
> > @@ -98,6 +98,26 @@ int kvm_arch_check_processor_compat(void)
> > return 0;
> > }
> >
> > +int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > + struct kvm_enable_cap *cap)
>
> This overrides the weak implementation in virt/kvm/kvm_main.c. OK.
>
Yes.
> > +{
> > + int r;
> > +
> > + if (cap->flags)
> > + return -EINVAL;
> > +
> > + switch (cap->cap) {
> > + case KVM_CAP_ARM_NISV_TO_USER:
> > + r = 0;
> > + kvm->arch.return_nisv_io_abort_to_user = true;
> > + break;
> > + default:
> > + r = -EINVAL;
> > + break;
> > + }
> > +
> > + return r;
> > +}
> >
> > /**
> > * kvm_arch_init_vm - initializes a VM data structure
> > @@ -196,6 +216,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > case KVM_CAP_MP_STATE:
> > case KVM_CAP_IMMEDIATE_EXIT:
> > case KVM_CAP_VCPU_EVENTS:
> > + case KVM_CAP_ARM_NISV_TO_USER:
> > r = 1;
> > break;
> > case KVM_CAP_ARM_SET_DEVICE_ADDR:
> > @@ -673,6 +694,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> > ret = kvm_handle_mmio_return(vcpu, vcpu->run);
> > if (ret)
> > return ret;
> > + } else if (run->exit_reason == KVM_EXIT_ARM_NISV) {
> > + kvm_inject_undefined(vcpu);
>
> So QEMU can try to enable the feature via IOCTL. And here you would
> raise the 'undefined instruction' exception which QEMU will have to
> handle in the loop calling KVM either by trying to make sense of the
> instruction or by passing it on to the guest.
>
> Conceptually this looks good to me and meets the requirements of my
> application.
>
> Thanks a lot for your suggestion.
>
I will change the undef to an external abort as I think that's more in
line with the architecture, and document this, test and send out as a
proper patch.
Thanks,
Christoffer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
From: Christoffer Dall @ 2019-09-06 8:00 UTC (permalink / raw)
To: Marc Zyngier
Cc: Peter Maydell, Daniel P. Berrangé, Heinrich Schuchardt,
lkml - Kernel Mailing List, Stefan Hajnoczi, kvmarm,
arm-mail-list
In-Reply-To: <4b6662bd-56e4-3c10-3b65-7c90828a22f9@kernel.org>
On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
> On 05/09/2019 10:22, Christoffer Dall wrote:
> > On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
> >> On Thu, 5 Sep 2019 at 09:52, Marc Zyngier <maz@kernel.org> wrote:
> >>>
> >>> On Thu, 05 Sep 2019 09:16:54 +0100,
> >>> Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>> This is true, but the problem is that barfing out to userspace
> >>>> makes it harder to debug the guest because it means that
> >>>> the VM is immediately destroyed, whereas AIUI if we
> >>>> inject some kind of exception then (assuming you're set up
> >>>> to do kernel-debug via gdbstub) you can actually examine
> >>>> the offending guest code with a debugger because at least
> >>>> your VM is still around to inspect...
> >>>
> >>> To Christoffer's point, I find the benefit a bit dubious. Yes, you get
> >>> an exception, but the instruction that caused it may be completely
> >>> legal (store with post-increment, for example), leading to an even
> >>> more puzzled developer (that exception should never have been
> >>> delivered the first place).
> >>
> >> Right, but the combination of "host kernel prints a message
> >> about an unsupported load/store insn" and "within-guest debug
> >> dump/stack trace/etc" is much more useful than just having
> >> "host kernel prints message" and "QEMU exits"; and it requires
> >> about 3 lines of code change...
> >>
> >>> I'm far more in favour of dumping the state of the access in the run
> >>> structure (much like we do for a MMIO access) and let userspace do
> >>> something about it (such as dumping information on the console or
> >>> breaking). It could even inject an exception *if* the user has asked
> >>> for it.
> >>
> >> ...whereas this requires agreement on a kernel-userspace API,
> >> larger changes in the kernel, somebody to implement the userspace
> >> side of things, and the user to update both the kernel and QEMU.
> >> It's hard for me to see that the benefit here over the 3-line
> >> approach really outweighs the extra effort needed. In practice
> >> saying "we should do this" is saying "we're going to do nothing",
> >> based on the historical record.
> >>
> >
> > How about something like the following (completely untested, liable for
> > ABI discussions etc. etc., but for illustration purposes).
> >
> > I think it raises the question (and likely many other) of whether we can
> > break the existing 'ABI' and change behavior for missing ISV
> > retrospectively for legacy user space when the issue has occurred?
> >
> > Someone might have written code that reacts to the -ENOSYS, so I've
> > taken the conservative approach for this for the time being.
> >
> >
> > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> > index 8a37c8e89777..19a92c49039c 100644
> > --- a/arch/arm/include/asm/kvm_host.h
> > +++ b/arch/arm/include/asm/kvm_host.h
> > @@ -76,6 +76,14 @@ struct kvm_arch {
> >
> > /* Mandated version of PSCI */
> > u32 psci_version;
> > +
> > + /*
> > + * If we encounter a data abort without valid instruction syndrome
> > + * information, report this to user space. User space can (and
> > + * should) opt in to this feature if KVM_CAP_ARM_NISV_TO_USER is
> > + * supported.
> > + */
> > + bool return_nisv_io_abort_to_user;
> > };
> >
> > #define KVM_NR_MEM_OBJS 40
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index f656169db8c3..019bc560edc1 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -83,6 +83,14 @@ struct kvm_arch {
> >
> > /* Mandated version of PSCI */
> > u32 psci_version;
> > +
> > + /*
> > + * If we encounter a data abort without valid instruction syndrome
> > + * information, report this to user space. User space can (and
> > + * should) opt in to this feature if KVM_CAP_ARM_NISV_TO_USER is
> > + * supported.
> > + */
> > + bool return_nisv_io_abort_to_user;
> > };
> >
> > #define KVM_NR_MEM_OBJS 40
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 5e3f12d5359e..a4dd004d0db9 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -235,6 +235,7 @@ struct kvm_hyperv_exit {
> > #define KVM_EXIT_S390_STSI 25
> > #define KVM_EXIT_IOAPIC_EOI 26
> > #define KVM_EXIT_HYPERV 27
> > +#define KVM_EXIT_ARM_NISV 28
> >
> > /* For KVM_EXIT_INTERNAL_ERROR */
> > /* Emulate instruction failed. */
> > @@ -996,6 +997,7 @@ struct kvm_ppc_resize_hpt {
> > #define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
> > #define KVM_CAP_ARM_PTRAUTH_GENERIC 172
> > #define KVM_CAP_PMU_EVENT_FILTER 173
> > +#define KVM_CAP_ARM_NISV_TO_USER 174
> >
> > #ifdef KVM_CAP_IRQ_ROUTING
> >
> > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > index 35a069815baf..2ce94bd9d4a9 100644
> > --- a/virt/kvm/arm/arm.c
> > +++ b/virt/kvm/arm/arm.c
> > @@ -98,6 +98,26 @@ int kvm_arch_check_processor_compat(void)
> > return 0;
> > }
> >
> > +int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> > + struct kvm_enable_cap *cap)
> > +{
> > + int r;
> > +
> > + if (cap->flags)
> > + return -EINVAL;
> > +
> > + switch (cap->cap) {
> > + case KVM_CAP_ARM_NISV_TO_USER:
> > + r = 0;
> > + kvm->arch.return_nisv_io_abort_to_user = true;
> > + break;
> > + default:
> > + r = -EINVAL;
> > + break;
> > + }
> > +
> > + return r;
> > +}
> >
> > /**
> > * kvm_arch_init_vm - initializes a VM data structure
> > @@ -196,6 +216,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > case KVM_CAP_MP_STATE:
> > case KVM_CAP_IMMEDIATE_EXIT:
> > case KVM_CAP_VCPU_EVENTS:
> > + case KVM_CAP_ARM_NISV_TO_USER:
> > r = 1;
> > break;
> > case KVM_CAP_ARM_SET_DEVICE_ADDR:
> > @@ -673,6 +694,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> > ret = kvm_handle_mmio_return(vcpu, vcpu->run);
> > if (ret)
> > return ret;
> > + } else if (run->exit_reason == KVM_EXIT_ARM_NISV) {
> > + kvm_inject_undefined(vcpu);
>
> Just to make sure I understand: Is the expectation here that userspace
> could clear the exit reason if it managed to handle the exit? And
> otherwise we'd inject an UNDEF on reentry?
>
Yes, but I think we should change that to an external abort. I'll test
something and send a proper patch with more clear documentation.
> > }
> >
> > if (run->immediate_exit)
> > diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
> > index 6af5c91337f2..62e6ef47a6de 100644
> > --- a/virt/kvm/arm/mmio.c
> > +++ b/virt/kvm/arm/mmio.c
> > @@ -167,8 +167,15 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
> > if (ret)
> > return ret;
> > } else {
> > - kvm_err("load/store instruction decoding not implemented\n");
> > - return -ENOSYS;
> > + if (vcpu->kvm->arch.return_nisv_io_abort_to_user) {
> > + run->exit_reason = KVM_EXIT_ARM_NISV;
> > + run->mmio.phys_addr = fault_ipa;
>
> We could also record whether that's a read or a write (WnR should still
> be valid). Actually, we could store a sanitized version of the ESR.
>
Ah yes, I'll incorporate that.
> > + vcpu->stat.mmio_exit_user++;
> > + return 0;
> > + } else {
> > + kvm_info("encountered data abort without syndrome info\n");
>
> My only issue with this is that the previous message has been sort of
> documented...
Well, my main gripe with the current code is that the error message is
massively misleading because it explains one possible case, which is
very "kernel part of a KVM VM centric" and is actually not the common
scenario that people encounter.
Let me work on the particular wording of the error message and see if I
can achieve something self-documenting.
Thanks,
Christoffer
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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