* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: Borislav Petkov @ 2018-05-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39bde8c5-4dfb-c1b9-02a4-ba467539ea24@codeaurora.org>
On Wed, May 16, 2018 at 11:38:16AM -0400, Tyler Baicar wrote:
> I haven't seen a deadlock from that, but it looks possible. What if
> the ghes_proc() call in ghes_probe() is moved before the second switch
> statement? That way it is before the NMI/IRQ/poll is setup. At quick
> glance I think that should avoid the deadlock and still provide the
> functionality that call was added for. I can test that out if you all
> agree.
Makes sense but please audit it properly before doing the change. That
code is full of landmines and could use a proper scrubbing first.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: Borislav Petkov @ 2018-05-17 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c871e15-689c-226d-760d-dd92614de2e9@arm.com>
On Wed, May 16, 2018 at 03:51:14PM +0100, James Morse wrote:
> The first two overload existing architectural behavior, the third improves all
> this with a third standard option. Its the standard story!
:-)
> I thought this was safe because its just ghes_copy_tofrom_phys()s access to the
> fixmap slots that needs mutual exclusion.
>
> Polled and all the IRQ flavours are kept apart by the spin_lock_irqsave(), and
> the NMIs have their own fixmap entry. (This is fine until there is more than
> once source of NMI)
For example:
ghes_probe()
switch (generic->notify.type) {
...
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
}
...
ghes_proc();
ghes_read_estatus();
spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
memcpy...
-> NMI
ghes_notify_nmi();
ghes_read_estatus();
..
if (in_nmi) {
raw_spin_lock(&ghes_ioremap_lock_nmi);
...
<- NMI
ghes->estatus from above, before the NMI fired, has gotten some nice
scribbling over. AFAICT.
Now, I don't know whether this can happen with the ARM facilities but if
they're NMI-like, I don't see why not.
Which means, that this code is not really reentrant and if should be
fixed to be callable from different contexts, then it should use private
buffers and be careful about locking.
Oh, and that
if (in_nmi)
lock()
else
lock_irqsave()
pattern is really yucky. And it is an explosion waiting to happen.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-17 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOtvUMdVNX_vBRofpc5rNiVL-a1NvWMDyWSOaXKYPkm57wkR_A@mail.gmail.com>
Hi Gilad,
On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> However, even with your clock patch, the signature checking fails for me,
>> on both R-Car H3 ES1.0 and ES2.0.
>> Does this need changes to the ARM Trusted Firmware, to allow Linux to
>> access the public SCEG module?
>
> Well, this is actually something different. If you look you will
> notice that my patch was part of a 3 part patch series,
> the first of which disabled this test.
Sorry, I had completely forgotten about the first patch from the series.
With that applied, it continues:
ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version
0x00000000, Driver version 4.0
ccree e6601000.crypto: Cache params previous: 0x00000777
ccree e6601000.crypto: Cache params current: 0x00000000
(expect: 0x00000000)
alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)
alg: No test for authenc(xcbc(aes),cbc(aes))
(authenc-xcbc-aes-cbc-aes-ccree)
alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes)))
(authenc-xcbc-aes-rfc3686-ctr-aes-ccree)
ccree e6601000.crypto: ARM ccree device initialized
Is HW version 0x00000000 expected?
> If you take all the 3 patches, it will work.
is there an easy way to test proper operation?
I enabled CONFIG_CRYPT_TEST, and did insmod tcrypt.ko, but I mostly see
"Failed to load transform" messages.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V6 10/12] ARM: dts: ipq8074: Add peripheral nodes
From: kbuild test robot @ 2018-05-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526475004-10341-11-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.17-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sricharan-R/ARM-dts-ipq-updates-to-enable-a-few-peripherals/20180517-155124
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Sricharan-R/ARM-dts-ipq-updates-to-enable-a-few-peripherals/20180517-155124 HEAD 1e054800261138fd8f0f8f93340f5781ff622233 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/arm64/boot/dts/qcom/ipq8074-hk01.dtb: ERROR (duplicate_label): /soc/pinctrl at 1000000/serial4_pinmux: Duplicate label 'serial_4_pins' on /soc/pinctrl at 1000000/serial4_pinmux and /soc/pinctrl at 1000000/serial4-pinmux
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38151 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/78988781/attachment-0001.gz>
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Pintu Kumar @ 2018-05-17 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLiZJrDveOHWwvJQ+JLg+j6FOk74oQBKaEq0oqY6w0ko=A@mail.gmail.com>
On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>
Hi,
I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
However I still dont know how to set the cpumask for one of the GPIO Bank.
>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144
But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.
Thanks
> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module....
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.ping@gmail.com>
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root at 10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root at 10:~# cat /proc/interrupts | grep 21
> >> > > > > 47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity: (null)
> >> > > > > [ 0.000000] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > > > When I try to set smp_affinity for mmc0, then it works.
> >> > > > > # cat /proc/interrupts | grep mmc
> >> > > > > 295: 55 0 GPCV2 22 Edge mmc0
> >> > > > > 296: 0 0 GPCV2 23 Edge mmc1
> >> > > > > 297: 52 0 GPCV2 24 Edge mmc2
> >> > > > >
> >> > > > > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
> >> > > > > root at 10:~#
> >> > > > >
> >> > > > >
> >> > > > > So, I wanted to know what are the conditions for which
> >> > > > > setting
> >> > > > > smp_affinity for an IRQ will work ?
> >> > > > >
> >> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> >> > > > > IRQ ?
> >> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> >> > > >
> >> > > > IRQ affinity is only supported where interrupts are _directly_
> >> > > > wired to
> >> > > > the GIC. It's the GIC which does the interrupt steering to the
> >> > > > CPU
> >> > > > cores.
> >> > > >
> >> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> >> > > > have no
> >> > > > ability to be directed independently to other CPUs - the only
> >> > > > possible
> >> > > > way to change the mapping is to move _all_ interrupts on that
> >> > > > controller,
> >> > > > and any downstream chained interrupts at GIC level.
> >> > > >
> >> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> >> > > > is no way
> >> > > > for the interrupt controller itself to change the affinity of
> >> > > > the input
> >> > > > interrupt.
> >> > >
> >> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> >> > > mapping
> >> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> >> > > thus be
> >> > > handled by forwarding the request to the GIC by
> >> > > irq_chip_set_affinity_parent().
> >> > >
> >> > > As this is handled correctly in the upstream kernel since the
> >> > > first
> >> > > commit introducing support for the GPCv2, it seems the issue is
> >> > > only
> >> > > present in some downstream kernel.
> >> > >
> >> >
> >> > OK. Thanks so much for your reply.
> >> >
> >> > I saw some of the drivers using irq_set_affinity_hint() to force
> >> > the
> >> > IRQ affinity to a particular CPU.
> >> > This is the sample:
> >> > {
> >> > cpumask_clear(mask);
> >> > cpumask_set_cpu(cpu, mask);
> >> > irq_set_affinity_hint(irq, mask);
> >> > }
> >> >
> >> > Whether this logic will work for a particular GPIO pin ?
> >> >
>
> >> >
> >> > > Regards,
> >> > > Lucas
^ permalink raw reply
* [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-17 13:22 UTC (permalink / raw)
To: linux-arm-kernel
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus 0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff])
pci 0000:02:00.0: reg 0x10: [mem 0x8011e000000-0x8011effffff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e000000
efifb: framebuffer at 0x1e000000, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..ea68d5c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_bus_region region;
+ struct resource res;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,14 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ region.start = base;
+ region.end = base + size - 1;
+ res.start = 0;
+ res.flags = IORESOURCE_MEM;
+ pcibios_bus_to_resource(dev->bus, &res, ®ion);
+ if (res.start)
+ base = res.start;
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-17 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVM55S7+PdnKusX-qkTxioc=0kQ6EGSbwv+kbLk5RCUYw@mail.gmail.com>
On Thu, May 17, 2018 at 12:16 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>>> > Add bindings for CryptoCell instance in the SoC.
>>>> >
>>>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > @@ -528,6 +528,14 @@
>>>> > status = "disabled";
>>>> > };
>>>> >
>>>> > + arm_cc630p: crypto at e6601000 {
>>>> > + compatible = "arm,cryptocell-630p-ree";
>>>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>>>> > + #interrupt-cells = <2>;
>>>>
>>>> I believe the #interrupt-cells property is not needed.
>>>>
>>>> > + reg = <0x0 0xe6601000 0 0x1000>;
>>>> > + clocks = <&cpg CPG_MOD 229>;
>
> Missing "power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;", as
> the Secure Engine is part of the CPG/MSSR clock domain (see below [*]).
And missing "resets = <&cpg 229>;", as the module is tied to the CPG/MSSR
reset controller.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Eric Anholt @ 2018-05-17 13:17 UTC (permalink / raw)
To: linux-arm-kernel
The a53 and a7 counters seem to match up, so we advertise a7 so that
arm32 can probe.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/bcm2837.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi
index 7704bb029605..1f5e5c782835 100644
--- a/arch/arm/boot/dts/bcm2837.dtsi
+++ b/arch/arm/boot/dts/bcm2837.dtsi
@@ -17,6 +17,12 @@
};
};
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,cortex-a7-pmu";
+ interrupt-parent = <&local_intc>;
+ interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&local_intc>;
--
2.17.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517090438.pqggltzkcdhzktsp@verge.net.au>
On Thu, May 17, 2018 at 12:04 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> >> Hi Gilad,
>> >>
>> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> >> > Add bindings for CryptoCell instance in the SoC.
>> >> >
>> >> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>> >>
>> >> Thanks for your patch!
>> >>
>> >> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > @@ -528,6 +528,14 @@
>> >> > status = "disabled";
>> >> > };
>> >> >
>> >> > + arm_cc630p: crypto at e6601000 {
>> >> > + compatible = "arm,cryptocell-630p-ree";
>> >> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> >> > + #interrupt-cells = <2>;
>> >>
>> >> I believe the #interrupt-cells property is not needed.
>> >>
>> >> > + reg = <0x0 0xe6601000 0 0x1000>;
>> >> > + clocks = <&cpg CPG_MOD 229>;
>> >> > + };
>> >>
>> >> The rest looks good, but I cannot verify the register block.
>> >>
>> >> > +
>> >> > i2c3: i2c at e66d0000 {
>> >> > #address-cells = <1>;
>> >> > #size-cells = <0>;
>> >
>> > Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> I think its fine if it does not yet work.
> But not if its causes things that previously worked to stop working.
Based on the further discussion with Geert my recommendation is to
drop my patch for now,
take Geert CR clock patch and I will follow up next week with a v2
that fixes the clock
handing as discussed with Geert.
Many thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH v2 02/40] iommu/sva: Bind process address spaces to devices
From: Jonathan Cameron @ 2018-05-17 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-3-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:03 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Add bind() and unbind() operations to the IOMMU API. Bind() returns a
> PASID that drivers can program in hardware, to let their devices access an
> mm. This patch only adds skeletons for the device driver API, most of the
> implementation is still missing.
>
> IOMMU groups with more than one device aren't supported for SVA at the
> moment. There may be P2P traffic between devices within a group, which
> cannot be seen by an IOMMU (note that supporting PASID doesn't add any
> form of isolation with regard to P2P). Supporting groups would require
> calling bind() for all bound processes every time a device is added to a
> group, to perform sanity checks (e.g. ensure that new devices support
> PASIDs at least as big as those already allocated in the group).
Is it worth adding an explicit comment on this reasoning (or a minimal subset
of it) at the check for the number of devices in the group?
It's well laid out here, but might not be so obvious if someone is reading
the code in the future.
>It also
> means making sure that reserved ranges (IOMMU_RESV_*) of all devices are
> carved out of processes. This is already tricky with single devices, but
> becomes very difficult with groups. Since SVA-capable devices are expected
> to be cleanly isolated, and since we don't have any way to test groups or
> hot-plug, we only allow singular groups for now.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Otherwise, looks good to me.
>
> ---
> v1->v2: remove iommu_sva_bind/unbind_group
> ---
> drivers/iommu/iommu-sva.c | 27 +++++++++++++
> drivers/iommu/iommu.c | 83 +++++++++++++++++++++++++++++++++++++++
> include/linux/iommu.h | 37 +++++++++++++++++
> 3 files changed, 147 insertions(+)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 8b4afb7c63ae..8d98f9c09864 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -93,6 +93,8 @@ int iommu_sva_device_shutdown(struct device *dev)
> if (!domain)
> return -ENODEV;
>
> + __iommu_sva_unbind_dev_all(dev);
> +
> mutex_lock(&dev->iommu_param->lock);
> param = dev->iommu_param->sva_param;
> dev->iommu_param->sva_param = NULL;
> @@ -108,3 +110,28 @@ int iommu_sva_device_shutdown(struct device *dev)
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown);
> +
> +int __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags, void *drvdata)
> +{
> + return -ENOSYS; /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_bind_device);
> +
> +int __iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENOSYS; /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
> +
> +/**
> + * __iommu_sva_unbind_dev_all() - Detach all address spaces from this device
> + * @dev: the device
> + *
> + * When detaching @device from a domain, IOMMU drivers should use this helper.
> + */
> +void __iommu_sva_unbind_dev_all(struct device *dev)
> +{
> + /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_unbind_dev_all);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9e28d88c8074..bd2819deae5b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2261,3 +2261,86 @@ int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids);
> +
> +/**
> + * iommu_sva_bind_device() - Bind a process address space to a device
> + * @dev: the device
> + * @mm: the mm to bind, caller must hold a reference to it
> + * @pasid: valid address where the PASID will be stored
> + * @flags: bond properties
> + * @drvdata: private data passed to the mm exit handler
> + *
> + * Create a bond between device and task, allowing the device to access the mm
> + * using the returned PASID. If unbind() isn't called first, a subsequent bind()
> + * for the same device and mm fails with -EEXIST.
> + *
> + * iommu_sva_device_init() must be called first, to initialize the required SVA
> + * features. @flags is a subset of these features.
> + *
> + * The caller must pin down using get_user_pages*() all mappings shared with the
> + * device. mlock() isn't sufficient, as it doesn't prevent minor page faults
> + * (e.g. copy-on-write).
> + *
> + * On success, 0 is returned and @pasid contains a valid ID. Otherwise, an error
> + * is returned.
> + */
> +int iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + int ret = -EINVAL;
> + struct iommu_group *group;
> +
> + if (!pasid)
> + return -EINVAL;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return -ENODEV;
> +
> + /* Ensure device count and domain don't change while we're binding */
> + mutex_lock(&group->mutex);
> + if (iommu_group_device_count(group) != 1)
> + goto out_unlock;
> +
> + ret = __iommu_sva_bind_device(dev, mm, pasid, flags, drvdata);
> +
> +out_unlock:
> + mutex_unlock(&group->mutex);
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
> +
> +/**
> + * iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device
> + * @dev: the device
> + * @pasid: the pasid returned by bind()
> + *
> + * Remove bond between device and address space identified by @pasid. Users
> + * should not call unbind() if the corresponding mm exited (as the PASID might
> + * have been reallocated for another process).
> + *
> + * The device must not be issuing any more transaction for this PASID. All
> + * outstanding page requests for this PASID must have been flushed to the IOMMU.
> + *
> + * Returns 0 on success, or an error value
> + */
> +int iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + int ret = -EINVAL;
> + struct iommu_group *group;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return -ENODEV;
> +
> + mutex_lock(&group->mutex);
> + ret = __iommu_sva_unbind_device(dev, pasid);
> + mutex_unlock(&group->mutex);
> +
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 2efe7738bedb..da59c20c4f12 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -613,6 +613,10 @@ void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode);
>
> +extern int iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags, void *drvdata);
> +extern int iommu_sva_unbind_device(struct device *dev, int pasid);
> +
> #else /* CONFIG_IOMMU_API */
>
> struct iommu_ops {};
> @@ -932,12 +936,29 @@ static inline int iommu_sva_invalidate(struct iommu_domain *domain,
> return -EINVAL;
> }
>
> +static inline int iommu_sva_bind_device(struct device *dev,
> + struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENODEV;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #ifdef CONFIG_IOMMU_SVA
> extern int iommu_sva_device_init(struct device *dev, unsigned long features,
> unsigned int max_pasid);
> extern int iommu_sva_device_shutdown(struct device *dev);
> +extern int __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags,
> + void *drvdata);
> +extern int __iommu_sva_unbind_device(struct device *dev, int pasid);
> +extern void __iommu_sva_unbind_dev_all(struct device *dev);
> #else /* CONFIG_IOMMU_SVA */
> static inline int iommu_sva_device_init(struct device *dev,
> unsigned long features,
> @@ -950,6 +971,22 @@ static inline int iommu_sva_device_shutdown(struct device *dev)
> {
> return -ENODEV;
> }
> +
> +static inline int __iommu_sva_bind_device(struct device *dev,
> + struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int __iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENODEV;
> +}
> +
> +static inline void __iommu_sva_unbind_dev_all(struct device *dev)
> +{
> +}
> #endif /* CONFIG_IOMMU_SVA */
>
> #endif /* __LINUX_IOMMU_H */
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVM55S7+PdnKusX-qkTxioc=0kQ6EGSbwv+kbLk5RCUYw@mail.gmail.com>
On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>>> > Add bindings for CryptoCell instance in the SoC.
>>>> >
>>>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > @@ -528,6 +528,14 @@
>>>> > status = "disabled";
>>>> > };
>>>> >
>>>> > + arm_cc630p: crypto at e6601000 {
>>>> > + compatible = "arm,cryptocell-630p-ree";
>>>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>>>> > + #interrupt-cells = <2>;
>>>>
>>>> I believe the #interrupt-cells property is not needed.
>>>>
>>>> > + reg = <0x0 0xe6601000 0 0x1000>;
>>>> > + clocks = <&cpg CPG_MOD 229>;
>
> Missing "power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;", as
> the Secure Engine is part of the CPG/MSSR clock domain (see below [*]).
Thank you. I didn't get this information from Renesas :-)
>
>>>> > + };
>>>>
>>>> The rest looks good, but I cannot verify the register block.
>>>>
>>>> > +
>>>> > i2c3: i2c at e66d0000 {
>>>> > #address-cells = <1>;
>>>> > #size-cells = <0>;
>>>
>>> Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
> does not distinguish between the absence of the clock property, and an
> actual error in getting the clock, and never considers any error a failure
> (incl. -PROBE_DEFER).
>
> As of_clk_get() returns -ENOENT for both a missing clock property and a
> missing clock, you should use (devm_)clk_get() instead, and distinguish
> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>
Thank you, this is very valuable. I will do as you suggested.
> Hence in the absence of the clock patch, the driver accesses the crypto
> engine while its module clock is turned off, leading to:
>
> ccree e6601000.crypto: Invalid CC signature: SIGNATURE=0x00000000
> != expected=0xDCC63000
>
> You must be lucky, though, usually you get an imprecise external abort
> later, crashing the whole system ;-)
>
> So I think this patch should be dropped for now.
>
> However, even with your clock patch, the signature checking fails for me,
> on both R-Car H3 ES1.0 and ES2.0.
> Does this need changes to the ARM Trusted Firmware, to allow Linux to
> access the public SCEG module?
Well, this is actually something different. If you look you will
notice that my patch was part of a 3 part patch series,
the first of which disabled this test.
If you take all the 3 patches, it will work.
To make things more interesting, I have since sending the patch
learned WHY the test does not work, so disabling
it is not needed - to make a long story short, I was reading the wrong
register that just happens to have the right value
in our FPGA based tests systems but does not in the real silicon
implementations.
But you are right - if the clock is not enabled and you are try to
read from the register the system does freeze.
I will send a fixed v2. based on your patch enabling the CR clock.
>
> [*] More on the subject of clock control:
> At least for Renesas SoCs, where the module is part of a clock domain, and
> can be controlled automatically by Runtime PM, you could drop the explicit
> clock control, and use Runtime PM instead
> (pm_runtime_{enable,get_sync,put,disable}()). That would allow the driver
> to work on systems with any kind of PM Domains, too.
> Depending on the other platforms that include a CryptoCell and their
> (non)reliance on PM Domains, you may have to keep the explicit clock
> handling, in addition to Runtime PM.
>
> To decrease power consumption, I suggest to move the clock and/or Runtime
> PM handling to the routines that actually use the hardware, instead of
> powering the module in the probe routine.
>
This is very interesting and I will give it a try.
Thanks again!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [GIT PULL 3/3] DaVinci defconfig updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/defconfig
for you to fetch changes up to e081c754ad4b8665364fcfb07b8bec5289f23dd8:
ARM: davinci_all_defconfig: enable support for remoteproc drivers (2018-04-23 20:24:23 +0530)
----------------------------------------------------------------
Enable DA8XX remoteproc driver support in davinci_all_defconfig
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: davinci_all_defconfig: enable support for remoteproc drivers
arch/arm/configs/davinci_all_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 2/3] DaVinci device-tree updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/dt
for you to fetch changes up to fe9d2a40d995dc1da042a4fcd7813239d063554d:
ARM: dts: da850-evm: add WP and CD to MMC (2018-05-16 16:36:51 +0530)
----------------------------------------------------------------
DaVinci device-tree updates for v4.18
* DA850 EVM gains USB support, SD card write-protect, card detect
and some clean-up
* Support for gpio-ranges makes using gpios from DT much easier
* Lego EV3 clean-up
----------------------------------------------------------------
Adam Ford (3):
ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1
ARM: dts: da850-evm: use phandles to extend nodes
ARM: dts: da850-evm: add WP and CD to MMC
David Lechner (2):
ARM: dts: da850: use gpio-ranges
ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
arch/arm/boot/dts/da850-evm.dts | 298 +++++++++++++++++++----------------
arch/arm/boot/dts/da850-lego-ev3.dts | 83 +---------
arch/arm/boot/dts/da850.dtsi | 154 ++++++++++++++++++
3 files changed, 319 insertions(+), 216 deletions(-)
^ permalink raw reply
* [GIT PULL 1/3] DaVinci SoC updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/soc
for you to fetch changes up to ccfadbb759bed3cc40336e2c486e619e3bf8590b:
Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc (2018-05-02 15:04:15 +0530)
----------------------------------------------------------------
DaVinci SoC support updates for v4.18
Mainly contains patches to move NAND chipselect to platform data
(currently platform device id is being used). These patches have
been acked by NAND maintainer and because of the driver dependency
an immutable branch has been provided to Boris.
The other patch is to remove an unnecessary postcore_initcall() on
DM644x which is needed for common clock framework conversion.
----------------------------------------------------------------
Bartosz Golaszewski (12):
mtd: rawnand: davinci: store the core chipselect number in platform data
ARM: davinci: da830-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: da850-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm355-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm355-leopard: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm365-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm644x-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: mityomapl138: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm646x-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: neuros-osd2: specify the chipselect in davinci_nand_pdata
mtd: rawnand: davinci: stop using pdev->id as chipselect
ARM: davinci: aemif: stop using pdev->id as nand chipselect
Sekhar Nori (2):
ARM: davinci: dm644x: remove unnecessary postcore_initcall()
Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc
arch/arm/mach-davinci/aemif.c | 8 ++++----
arch/arm/mach-davinci/board-da830-evm.c | 1 +
arch/arm/mach-davinci/board-da850-evm.c | 1 +
arch/arm/mach-davinci/board-dm355-evm.c | 1 +
arch/arm/mach-davinci/board-dm355-leopard.c | 1 +
arch/arm/mach-davinci/board-dm365-evm.c | 1 +
arch/arm/mach-davinci/board-dm644x-evm.c | 3 +++
arch/arm/mach-davinci/board-dm646x-evm.c | 1 +
arch/arm/mach-davinci/board-mityomapl138.c | 1 +
arch/arm/mach-davinci/board-neuros-osd2.c | 3 +++
arch/arm/mach-davinci/board-sffsdr.c | 2 ++
arch/arm/mach-davinci/davinci.h | 1 +
arch/arm/mach-davinci/dm644x.c | 13 +++----------
drivers/mtd/nand/raw/davinci_nand.c | 6 +++---
include/linux/platform_data/mtd-davinci.h | 10 ++++++++++
15 files changed, 36 insertions(+), 17 deletions(-)
^ permalink raw reply
* [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-17 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74ae2347-464c-ddc1-3cb9-f928692e792f@arm.com>
On 5/17/2018 6:17 AM, Robin Murphy wrote:
>> +??? }
>> +
>
> Is this not pretty much just pcibios_bus_to_resource()?
>
Agreed, let me convert the code to use pcibios_bus_to_resource() API.
I wasn't aware of its existence.
> Robin.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Olivier MOYSAN @ 2018-05-17 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180417111733.GG8973@sirena.org.uk>
Hello Takashi,
On 04/17/2018 01:17 PM, Mark Brown wrote:
> On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>
>> I guess the blocking patch in this patchset is the patch "add IEC958
>> channel status control helper". This patch has been reviewed several
>> times, but did not get a ack so far.
>> If you think these helpers will not be merged, I will reintegrate the
>> corresponding code in stm driver.
>> Please let me know, if I need to prepare a v2 without helpers, or if we
>> can go further in the review of iec helpers patch ?
>
> I don't mind either way but you're right here, I'm waiting for Takashi
> to review the first patch. I'd probably be OK with it just integrated
> into the driver if we have to go that way though.
>
Kind reminder.
Would you have some comments on this patchset ?
Thanks
olivier
^ permalink raw reply
* [GIT PULL] ARM: mvebu: arm for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-17 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for arm for mvebu for v4.18.
As I feared, there were (trivial) merge issues due to the defconfig
update in linux-next. The best place to solve them is in your tree, so
as soon as you will pull this, I will remove from my mvebu/for-next
branch.
Gregory
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-arm-4.18-1
for you to fetch changes up to 95fbfe2f63d0838fed56d2f93604f205719bc51c:
ARM: multi_v7_defconfig: Add Marvell NAND controller support (2018-05-16 19:38:34 +0200)
----------------------------------------------------------------
mvebu arm for 4.18 (part 1)
Updating multi_v7_defconfig and adding marvell NAND controller
support.
----------------------------------------------------------------
Gregory CLEMENT (2):
ARM: multi_v7_defconfig: Update with current configuration
ARM: multi_v7_defconfig: Add Marvell NAND controller support
arch/arm/configs/multi_v7_defconfig | 369 +++++++++++++++---------------------
1 file changed, 153 insertions(+), 216 deletions(-)
^ permalink raw reply
* [PATCH 1/3] crypto: ccree: drop signature register check
From: Gilad Ben-Yossef @ 2018-05-17 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387370-17142-2-git-send-email-gilad@benyossef.com>
Herbert,
On Tue, May 15, 2018 at 3:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> We were using the content of the signature register as a sanity
> check for the hardware functioning but it turns out not all
> implementers use the same values so the check is giving false
> negative on certain SoCs and so we drop it.
>
Please drop this patch. I have found a better fix and will send a v2 soon.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
From: Jia He @ 2018-05-17 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <698b0355-d430-86b8-cd09-83c6d9e566f8@arm.com>
Hi Suzuki
On 5/17/2018 4:17 PM, Suzuki K Poulose Wrote:
>
> Hi Jia,
>
> On 17/05/18 07:11, Jia He wrote:
>> I ever met a panic under memory pressure tests(start 20 guests and run
>> memhog in the host).
>
> Please avoid using "I" in the commit description and preferably stick to
> an objective description.
Thanks for the pointing
>
>>
>> The root cause might be what I fixed at [1]. But from arm kvm points of
>> view, it would be better we caught the exception earlier and clearer.
>>
>> If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the
>> wrong(more or less) page range. Hence it caused the "BUG: Bad page
>> state"
>
> I don't see why we should ever panic with a "positive" size value. Anyways,
> the unmap requests must be in units of pages. So this check might be useful.
>
>
good question,
After further digging, maybe we need to harden the break condition as below?
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 7f6a944..dac9b2e 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -217,7 +217,7 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
put_page(virt_to_page(pte));
}
- } while (pte++, addr += PAGE_SIZE, addr != end);
+ } while (pte++, addr += PAGE_SIZE, addr < end);
basically verified in my armv8a server
--
Cheers,
Jia
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
>>
>> [1] https://lkml.org/lkml/2018/5/3/1042
>>
>> Signed-off-by: jia.he at hxt-semitech.com
>> ---
>> ? virt/kvm/arm/mmu.c | 2 ++
>> ? 1 file changed, 2 insertions(+)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index 7f6a944..8dac311 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm,
>> phys_addr_t start, u64 size)
>> ????? phys_addr_t next;
>> ? ????? assert_spin_locked(&kvm->mmu_lock);
>> +??? WARN_ON(size & ~PAGE_MASK);
>> +
>> ????? pgd = kvm->arch.pgd + stage2_pgd_index(addr);
>> ????? do {
>> ????????? /*
>>
>
>
^ permalink raw reply related
* [PATCH RT] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
From: Sebastian Andrzej Siewior @ 2018-05-17 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
code disables BH and expects that it is not preemptible. On -RT the
task remains preemptible but remains the same CPU. This may corrupt the
content of the SIMD registers if the task is preempted during
saving/restoring those registers.
Add a locallock around next to the local_bh_disable(). This fulfill the
requirement that the code is not invoked again in different context on
the same CPU while it remains preemptible.
The preempt_disable() + local_bh_enable() combo in kernel_neon_begin()
is not working on -RT. We don't use NEON in kernel mode on RT right now
but this still should be addressed.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
arch/arm64/kernel/fpsimd.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index e7226c4c7493..3a5cd1908874 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -38,6 +38,7 @@
#include <linux/signal.h>
#include <linux/slab.h>
#include <linux/sysctl.h>
+#include <linux/locallock.h>
#include <asm/fpsimd.h>
#include <asm/cputype.h>
@@ -235,7 +236,7 @@ static void sve_user_enable(void)
* whether TIF_SVE is clear or set, since these are not vector length
* dependent.
*/
-
+static DEFINE_LOCAL_IRQ_LOCK(fpsimd_lock);
/*
* Update current's FPSIMD/SVE registers from thread_struct.
*
@@ -594,6 +595,7 @@ int sve_set_vector_length(struct task_struct *task,
* non-SVE thread.
*/
if (task == current) {
+ local_lock(fpsimd_lock);
local_bh_disable();
task_fpsimd_save();
@@ -604,8 +606,10 @@ int sve_set_vector_length(struct task_struct *task,
if (test_and_clear_tsk_thread_flag(task, TIF_SVE))
sve_to_fpsimd(task);
- if (task == current)
+ if (task == current) {
+ local_unlock(fpsimd_lock);
local_bh_enable();
+ }
/*
* Force reallocation of task SVE state to the correct size
@@ -838,6 +842,7 @@ asmlinkage void do_sve_acc(unsigned int esr, struct pt_regs *regs)
sve_alloc(current);
local_bh_disable();
+ local_lock(fpsimd_lock);
task_fpsimd_save();
fpsimd_to_sve(current);
@@ -849,6 +854,7 @@ asmlinkage void do_sve_acc(unsigned int esr, struct pt_regs *regs)
if (test_and_set_thread_flag(TIF_SVE))
WARN_ON(1); /* SVE access shouldn't have trapped */
+ local_unlock(fpsimd_lock);
local_bh_enable();
}
@@ -926,6 +932,7 @@ void fpsimd_flush_thread(void)
return;
local_bh_disable();
+ local_lock(fpsimd_lock);
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
@@ -967,6 +974,7 @@ void fpsimd_flush_thread(void)
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ local_unlock(fpsimd_lock);
local_bh_enable();
}
@@ -980,7 +988,9 @@ void fpsimd_preserve_current_state(void)
return;
local_bh_disable();
+ local_lock(fpsimd_lock);
task_fpsimd_save();
+ local_unlock(fpsimd_lock);
local_bh_enable();
}
@@ -1022,12 +1032,14 @@ void fpsimd_restore_current_state(void)
return;
local_bh_disable();
+ local_lock(fpsimd_lock);
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
task_fpsimd_load();
fpsimd_bind_to_cpu();
}
+ local_unlock(fpsimd_lock);
local_bh_enable();
}
@@ -1042,6 +1054,7 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
return;
local_bh_disable();
+ local_lock(fpsimd_lock);
current->thread.fpsimd_state.user_fpsimd = *state;
if (system_supports_sve() && test_thread_flag(TIF_SVE))
@@ -1052,6 +1065,7 @@ void fpsimd_update_current_state(struct user_fpsimd_state const *state)
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE))
fpsimd_bind_to_cpu();
+ local_unlock(fpsimd_lock);
local_bh_enable();
}
@@ -1116,6 +1130,7 @@ void kernel_neon_begin(void)
BUG_ON(!may_use_simd());
local_bh_disable();
+ local_lock(fpsimd_lock);
__this_cpu_write(kernel_neon_busy, true);
@@ -1128,6 +1143,7 @@ void kernel_neon_begin(void)
/* Invalidate any task state remaining in the fpsimd regs: */
fpsimd_flush_cpu_state();
+ local_unlock(fpsimd_lock);
preempt_disable();
local_bh_enable();
--
2.17.0
^ permalink raw reply related
* [bug report] ARM: sun9i: smp: Add is_a83t field
From: Dan Carpenter @ 2018-05-17 12:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello Myl?ne Josserand,
The patch 1631090e34f5: "ARM: sun9i: smp: Add is_a83t field" from May
4, 2018, leads to the following static checker warning:
arch/arm/mach-sunxi/mc_smp.c:804 sunxi_mc_smp_init()
error: buffer overflow 'sunxi_mc_smp_data' 2 <= 2 (assuming for loop doesn't break)
arch/arm/mach-sunxi/mc_smp.c
789 /*
790 * We can't actually use the enable-method magic in the kernel.
791 * Our loopback / trampoline code uses the CPU suspend framework,
792 * which requires the identity mapping be available. It would not
793 * yet be available if we used the .init_cpus or .prepare_cpus
794 * callbacks in smp_operations, which we would use if we were to
795 * use CPU_METHOD_OF_DECLARE
796 */
797 for (i = 0; i < ARRAY_SIZE(sunxi_mc_smp_data); i++) {
798 ret = of_property_match_string(node, "enable-method",
799 sunxi_mc_smp_data[i].enable_method);
800 if (!ret)
801 break;
802 }
803
804 is_a83t = sunxi_mc_smp_data[i].is_a83t;
^^^^^^^^^^^^^^^^^^^^
Potentially one past the end.
805
806 of_node_put(node);
807 if (ret)
808 return -ENODEV;
^^^^^^^^^^^^^^
This is where we return if we don't hit a break.
809
regards,
dan carpenter
^ permalink raw reply
* [PATCH V2 8/8] dt-bindings: stm32: add compatible for syscon
From: Rob Herring @ 2018-05-17 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2b4cd1845b949a7bf9c42a17a5358a2@SFHDAG5NODE3.st.com>
On Tue, May 15, 2018 at 11:19 AM, Christophe ROULLIER
<christophe.roullier@st.com> wrote:
> Hi Rob,
Please don't top post to lists.
>
> I do not understand, so let me explain our status:
>
> We have syscfg IP Harware in our SOC.
Add a compatible string that uniquely identifies what the block is. So
something like "st,stm32f746-syscfg".
> But we do not have SoC specific driver to manage syscfg, we are using a generic driver "syscon".
That does not matter. We're talking about the binding. Design
decisions in the OS should not define the binding. It doesn't matter
that the OS currently doesn't use the compatible string.
> So can you tell me what you wish to describe this part in our SOC bindings ?
>
> Thanks for your help.
>
> Christophe.
>
> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: lundi 7 mai 2018 18:36
> To: Christophe ROULLIER <christophe.roullier@st.com>
> Cc: mark.rutland at arm.com; mcoquelin.stm32 at gmail.com; Alexandre TORGUE <alexandre.torgue@st.com>; Peppe CAVALLARO <peppe.cavallaro@st.com>; devicetree at vger.kernel.org; andrew at lunn.ch; linux-arm-kernel at lists.infradead.org; netdev at vger.kernel.org
> Subject: Re: [PATCH V2 8/8] dt-bindings: stm32: add compatible for syscon
>
> On Wed, May 02, 2018 at 04:18:43PM +0200, Christophe Roullier wrote:
>> This patch describes syscon DT bindings.
>>
>> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
>> ---
>> Documentation/devicetree/bindings/arm/stm32.txt | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/stm32.txt
>> b/Documentation/devicetree/bindings/arm/stm32.txt
>> index 6808ed9..06e3834 100644
>> --- a/Documentation/devicetree/bindings/arm/stm32.txt
>> +++ b/Documentation/devicetree/bindings/arm/stm32.txt
>> @@ -8,3 +8,7 @@ using one of the following compatible strings:
>> st,stm32f746
>> st,stm32h743
>> st,stm32mp157
>> +
>> +Required nodes:
>> +- syscon: the soc bus node must have a system controller node
>> +pointing to the
>> + global control registers, with the compatible string "syscon";
>
> You misunderstood my prior comment. 'syscon' alone is not valid. You need SoC specific compatible string for it and 'stm32' is not SoC specific. IOW, the compatible property for a syscon should imply every single register field in the block.
>
> Rob
^ permalink raw reply
* Product Inquiry
From: ABDULLAH @ 2018-05-17 12:28 UTC (permalink / raw)
To: linux-arm-kernel
Dear Sir,
Good wishes.
We would greatly appreciate receiving any information, brochures
and the current prices lists of your productsfor our customer
here in Dubai,UAE.
Looking forward to receiving the materials from you.
Thanks & Regards
ABDULLAH Ghada
Marketing & Procurement
Mobile No.: 00971 52 341 7951
Wintech Industries LLC
PO Box: 283249,
15th B Street,Al Quoz indl.Area #04
Dubai.UAE
Tel.No. : 0097143410033
Fax No.: 0097143410500
Email: sales.wintechindustriesllc at consultant.com
sales.wintechindustriesllc at netcourrier.com
P please consider the environment and only print this email if
you really need to.Thank you.
^ permalink raw reply
* [PATCH net-next v3 00/10] net: mvpp2: phylink conversion
From: Gregory CLEMENT @ 2018-05-17 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517082939.14598-1-antoine.tenart@bootlin.com>
Hi Antoine,
On jeu., mai 17 2018, Antoine Tenart <antoine.tenart@bootlin.com> wrote:
> Hi Dave, Russell,
>
> This series convert the Marvell PPv2 driver to phylink (models the MAC
> to PHY link).
>
> One important point is the PPv2 driver supports two probe modes: device
> tree and ACPI. This series only brings phylink support for the device
> tree mode, as the ACPI one will need further work. Still, the driver
> should be working as before when using ACPI. This split should be
> temporary, and was discussed with Marcin (in Cc.) who added ACPI support
> to the driver.
>
> Also as the SFP cages on both DB boards can be considered as non-wired.
> We thus chose not to describe those SFP cages and we use fixed-link.
>
> The rest of the series uses phylink to add support for 1000BaseX and
> 2500BaseX modes in the PPv2 driver. To do this, two patches are needed
> in the common PHY framework (patches 3 and 4). The last 4 patches modify
> the device tree to use the new PPv2 functionalities.
>
> The series has been tested for the device tree mode on the 7040-db,
> 8040-db and 8040-mcbin boards, to ensure all the interface where working
> as expected.
>
> @Dave: patches 7 to 10 should go through the mvebu tree (Gregory in
> Cc.) to avoid any conflict with the other mvebu dt patches taken during
> this cycle.
Patches 7 to 10 have been applied on mvebu/dt64.
Thanks,
Gregory
>
> The series is based on today's net-next.
>
> Thanks!
> Antoine
>
> Since v2:
> - Removed the SFP description from the DB boards, as their SFP cages
> are wired properly. We now use fixed-link.
> - Because of this rework, split the series in two, so that the SFP
> part is reviewed separately.
> - Small fixes in the phylink patch.
> - Rebased on the latest net-next branch.
>
> Since v1:
> - Chose a different approach to the SFP changes, as the previous ones
> weren't valid and reworked both BD boards device trees.
> - Misc fixes.
> - Added Kishon's acked-by on one patch.
> - Rebaed on latest net-next branch.
>
> Antoine Tenart (9):
> net: mvpp2: align the ethtool ops definition
> net: mvpp2: phylink support
> phy: add 2.5G SGMII mode to the phy_mode enum
> phy: cp110-comphy: 2.5G SGMII mode
> net: mvpp2: 1000baseX support
> net: mvpp2: 2500baseX support
> arm64: dts: marvell: mcbin: enable the fourth network interface
> arm64: dts: marvell: 8040-db: describe the 10G interfaces as
> fixed-link
> arm64: dts: marvell: 7040-db: describe the 10G interface as fixed-link
>
> Russell King (1):
> arm64: dts: marvell: mcbin: add 10G SFP support
>
> .../arm64/boot/dts/marvell/armada-7040-db.dts | 5 +
> .../arm64/boot/dts/marvell/armada-8040-db.dts | 10 +
> .../boot/dts/marvell/armada-8040-mcbin.dts | 70 ++
> drivers/net/ethernet/marvell/Kconfig | 1 +
> drivers/net/ethernet/marvell/mvpp2.c | 931 +++++++++++-------
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +-
> include/linux/phy/phy.h | 1 +
> 7 files changed, 680 insertions(+), 355 deletions(-)
>
> --
> 2.17.0
>
--
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
^ permalink raw reply
* [PATCH v2 3/3] ARM: multi_v7_defconfig: enable STM32 RTC
From: Amelie Delaunay @ 2018-05-17 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526558828-24456-1-git-send-email-amelie.delaunay@st.com>
Enable the STM32 Real Time Clock (RTC) driver, implemented on STM32MP1 SoC.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 89167cd..8e02f86 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -863,6 +863,7 @@ CONFIG_RTC_DRV_SUN6I=y
CONFIG_RTC_DRV_SUNXI=y
CONFIG_RTC_DRV_MV=y
CONFIG_RTC_DRV_TEGRA=y
+CONFIG_RTC_DRV_STM32=y
CONFIG_RTC_DRV_CPCAP=m
CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox