* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Rob Herring @ 2016-09-23 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474354900-5618-2-git-send-email-clg@kaod.org>
On Tue, Sep 20, 2016 at 09:01:38AM +0200, C?dric Le Goater wrote:
> From: Alistair Popple <alistair@popple.id.au>
>
> This patch adds a simple device driver to expose the iBT interface on
> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
> commonly used as BMCs (BaseBoard Management Controllers) and this
> driver implements the BMC side of the BT interface.
>
> The BT (Block Transfer) interface is used to perform in-band IPMI
> communication between a host and its BMC. Entire messages are buffered
> before sending a notification to the other end, host or BMC, that
> there is data to be read. Usually, the host emits requests and the BMC
> responses but the specification provides a mean for the BMC to send
> SMS Attention (BMC-to-Host attention or System Management Software
> attention) messages.
>
> For this purpose, the driver introduces a specific ioctl on the
> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
> on the BMC to signal the host of such an event.
>
> The device name defaults to '/dev/ipmi-bt-host'
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> [clg: - checkpatch fixes
> - added a devicetree binding documentation
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
> ]
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> [clg: - checkpatch --strict fixes
> - removed the use of devm_iounmap, devm_kfree in cleanup paths
> - introduced an atomic-t to limit opens to 1
> - introduced a mutex to protect write/read operations]
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>
> ---
>
> Changes since v2:
>
> - fixed checkpatch --strict issues
> - cleanup'ed includes
> - limit to one opener
> - protect write/read operations with a mutex.
> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>
> Changes since v1:
>
> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
> the BMC side of the IPMI BT interface
> - renamed the device to 'ipmi-bt-host'
> - introduced a temporary buffer to copy_{to,from}_user
> - used platform_get_irq()
> - moved the driver under drivers/char/ipmi/ but kept it as a misc
> device
> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>
> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
While similar, this is not the kernel directory structure. Just make
this bindings/ipmi/
With that,
Acked-by: Rob Herring <robh@kernel.org>
> drivers/Makefile | 2 +-
> drivers/char/ipmi/Kconfig | 7 +
> drivers/char/ipmi/Makefile | 1 +
> drivers/char/ipmi/bt-bmc.c | 510 +++++++++++++++++++++
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/bt-bmc.h | 18 +
> 7 files changed, 561 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
> create mode 100644 drivers/char/ipmi/bt-bmc.c
> create mode 100644 include/uapi/linux/bt-bmc.h
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Russell King - ARM Linux @ 2016-09-23 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923181301.GD22965@lunn.ch>
On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote:
> > Since the hardware requires longword alignment for its' DMA transfers,
> > aligning the IP header will require a memcpy, right?
>
> The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
> two padding bits on transmit. ENETx_RACC has the same.
>
> What about your hardware?
The iMX6 FEC also has that ability - as part of my FEC patch stack from
ages ago, I implemented support for it.
"net:fec: implement almost zero-copy receive path"
in my public fec-testing branch.
That patch stack is sadly now totally dead and I've no interest in
reviving it myself. There was some interest from others in taking my
patch stack over, but that went quiet.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923173751.GA1041@n2100.armlinux.org.uk>
Thanks Russell,
On 09/23/2016 10:37 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote:
>> Oddly, it does prevent the vast majority (90%+) of the alignment errors.
>>
>> I believe this is because the compiler is generating an ldm instruction
>> when the ntohl() call is used, but I'm stumped about why these aren't
>> generating faults:
After looking at it, I have to think that the code that reads iph->id
is just hit more frequently than the other code in this routine.
>
> ldm generates alignment faults when the address is not aligned to a
> 32-bit boundary. ldr on ARMv6+ does not.
>
>> I don't think that's the case.
>>
>> # CONFIG_IPV6_GRE is not set
>>
>> Hmm... Instrumenting the kernel, it seems that iphdr **is** aligned on
>> a 4-byte boundary.
>>
>> Does the ldm instruction require 8-byte alignment?
>>
>> There's definitely a compiler-version dependency involved here,
>> since using gcc 4.9 also reduced the number of faults dramatically.
>
> Well, I don't think it's that gcc related:
>
I can only say that I noticed a dramatic drop in the number of faults, and
didn't see the inet_gro_receive reported in /proc/cpu/alignment with gcc 4.9
when trying to identify the issue.
> User: 0
> System: 312855 (ip6_route_input+0x6c/0x1e0)
> Skipped: 0
> Half: 0
> Word: 0
> DWord: 2
> Multi: 312853
>
> c06d8998 <ip6_route_input>:
> c06d89ac: e1a04000 mov r4, r0
> c06d89b0: e1d489b4 ldrh r8, [r4, #148] ; 0x94
> c06d89b8: e594a0a0 ldr sl, [r4, #160] ; 0xa0
> c06d89cc: e08ac008 add ip, sl, r8
> c06d89d4: e28c3018 add r3, ip, #24
> c06d89dc: e28c7008 add r7, ip, #8
> c06d89e4: e893000f ldm r3, {r0, r1, r2, r3}
> c06d89ec: e24be044 sub lr, fp, #68 ; 0x44
> c06d89f4: e24b5054 sub r5, fp, #84 ; 0x54
> c06d89fc: e885000f stm r5, {r0, r1, r2, r3}
> c06d8a04: e897000f ldm r7, {r0, r1, r2, r3}
> c06d8a10: e88e000f stm lr, {r0, r1, r2, r3}
>
> This is from:
>
> struct flowi6 fl6 = {
> .flowi6_iif = l3mdev_fib_oif(skb->dev),
> .daddr = iph->daddr,
> .saddr = iph->saddr,
> .flowlabel = ip6_flowinfo(iph),
> .flowi6_mark = skb->mark,
> .flowi6_proto = iph->nexthdr,
> };
>
> specifically, I suspect, the saddr and daddr initialisations.
>
> There's not much to get away from this - the FEC on iMX requires a
> 16-byte alignment for DMA addresses, which violates the network
> stack's requirement for the ethernet packet to be received with a
> two byte offset. So the IP header (and IPv6 headers) will always
> be mis-aligned in memory, which leads to a huge number of alignment
> faults.
>
> There's not much getting away from this - the problem is not in the
> networking stack, but the FEC hardware/network driver. See:
>
> struct fec_enet_private *fep = netdev_priv(ndev);
> int off;
>
> off = ((unsigned long)skb->data) & fep->rx_align;
> if (off)
> skb_reserve(skb, fep->rx_align + 1 - off);
>
> bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev, skb->data, FEC_ENET_RX_FRSIZE - fep->rx_align, DMA_FROM_DEVICE));
>
> in fec_enet_new_rxbdp().
>
So the question is: should we just live with this and acknowledge a
performance penalty of bad alignment or do something about it?
I'm not sure the cost (or the details) of Eric's proposed fix of allocating
and copying the header to another skb.
The original report was of bad network performance, but I haven't
been able to see an impact doing some simple tests using wget
and SSH.
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Arnd Bergmann @ 2016-09-23 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB263894265429130B91E7880C8DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Friday, September 23, 2016 10:58 AM
> > > Really, though, the firmware call thing is an incredibly niche use-case.
> > > Beyond development, the only real benefit of starting an AArch32 kernel
> > > in Hyp is that you can run AArch32 KVM guests, which you can do equally
> > > well (if not better) under an AArch64 kernel.
> >
> > This was my question earlier in the thread, apparently Alison has
> > another use case in mind, but I don't yet know what that is. If
> > that use case is important enough, we could do it this way.
> >
> > The only use case I can think of at the moment is boot testing
> > on kernelci.org, which could be used to check whether all the drivers
> > work in 32-bit environments.
>
> The reason we want aarch32 kernel support is for specific customers that
> have requirements for legacy 32-bit kernel drivers that function on ARMv7
> but for some reason are very problematic to port to a 64-bit kernel. So,
> the way to ease the 64-bit transition is allow them to run an aarch32 kernel
> and their driver on an ARMv8 SoC. I don't think we specifically care
> whether the kernel starts at EL2 or EL1.
Thanks for the explanation. Unfortunately I don't think that helps
get this approach upstream, in particular I wouldn't want to add
a platform specific hack just to help a third party not have to fix
their out-of-tree drivers to be 64-bit clean.
If your customer already has a chunk of downstream patches large
enough to be problematic to rebuild for 64-bit, they should be able
to also pick up these two patches, but of course what we really
want is to get drivers upstream and fixed (presumably this would
be an even larger task than just fixing them, so I don't set my
hopes too high here).
I'm still not opposed to making *all* 64-bit platforms available
to 32-bit kernels for testing purposes though, and that would solve
the customer problem too, as would the approach of encapsulating
the kernel in hypervisor stub that implements the PSCI calls
and using MACH_VIRT with the respective layerscape drivers enabled.
Arnd
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Andrew Lunn @ 2016-09-23 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0fe7a310-2d2f-4fca-d698-85d66122d91c@nelint.com>
> Since the hardware requires longword alignment for its' DMA transfers,
> aligning the IP header will require a memcpy, right?
The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts
two padding bits on transmit. ENETx_RACC has the same.
What about your hardware?
Andrew
^ permalink raw reply
* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Mark Rutland @ 2016-09-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473960166-30155-2-git-send-email-okaya@codeaurora.org>
On Thu, Sep 15, 2016 at 01:22:37PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> index fd5618b..47bfb5a 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
> the channel nodes appear on their own, not under a management node.
>
> Required properties:
> -- compatible: must contain "qcom,hidma-1.0"
> +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
> +for MSI capable HW.
> - reg: Addresses for the transfer and event channel
> - interrupts: Should contain the event interrupt
> - desc-count: Number of asynchronous requests this channel can handle
> - iommus: required a iommu node
>
> +Optional properties for MSI:
> +- msi-parent: pointer to the MSI controller object with the DeviceID in use.
The format of msi-cells depends on the particular msi-controller, so no
need to mention DeviceID here.
Please refer to
Documentation/devicetree/bindings/interrupt-controller/msi.txt
> +Example:
> + msi_parent: <&msi0 0x80024>
This doesn't match (s/_/-/).
> +msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
> +is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
> +instance 1.
I don't think you need any of this text, so long as you refer to the
generic MSI binding document, as above.
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Rob Herring @ 2016-09-23 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-3-git-send-email-ayaka@soulik.info>
On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> supported by the simple panel driver.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> new file mode 100644
> index 0000000..dd22685
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> @@ -0,0 +1,7 @@
> +Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "chunghwa,claa070wp03xg"
What about VCC, VLED, LED_EN (PWM), LVBIT, LVFMT, DITHER signals?
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
^ permalink raw reply
* [PATCH v8 2/2] ARM: dts: add TOPEET itop elite based board
From: Rob Herring @ 2016-09-23 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474300103-26659-3-git-send-email-ayaka@soulik.info>
On Mon, Sep 19, 2016 at 11:48:23PM +0800, Randy Li wrote:
> The TOPEET itop exynos 4412 have three versions base board. The
> Elite version is the cheap one without too much peripheral devices
> on it.
>
> Currently supported are serial console, wired networking(USB),
> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
> enabled.
>
> The FIMC is not used for camera currently, I enabled it just for a
> colorspace convertor.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> .../bindings/arm/samsung/samsung-boards.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 +++++++++++++++++++++
> 3 files changed, 244 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] arm: dts: imx7: Update #pwm-cells for PWM polarity control
From: Rob Herring @ 2016-09-23 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919142347.11342-2-bhuvanchandra.dv@toradex.com>
On Mon, Sep 19, 2016 at 07:53:45PM +0530, Bhuvanchandra DV wrote:
> Update #pwm-cells to 3 in order to support PWM signal polarity control.
>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> ---
> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +++---
> arch/arm/boot/dts/imx7s.dtsi | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
The driver will still work with old DTs, right? If so,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx31: fix clock control module interrupts description
From: Rob Herring @ 2016-09-23 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474250074-11430-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:54:34AM +0300, Vladimir Zapolskiy wrote:
> The type of AVIC interrupt controller found on i.MX31 is one-cell,
> namely 31 for CCM DVFS and 53 for CCM, however for clock control
> module its interrupts are specified as 3-cells, fix it.
>
> Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> Documentation/devicetree/bindings/clock/imx31-clock.txt | 2 +-
> arch/arm/boot/dts/imx31.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] mtd: s3c2410: add device tree support
From: Rob Herring @ 2016-09-23 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474125760-28168-1-git-send-email-sergio.prado@e-labworks.com>
On Sat, Sep 17, 2016 at 12:22:40PM -0300, Sergio Prado wrote:
> Tested on FriendlyARM Mini2440
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/mtd/samsung-s3c2410.txt | 70 +++++++++++
> drivers/mtd/nand/s3c2410.c | 129 ++++++++++++++++++++-
> include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> 3 files changed, 195 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> new file mode 100644
> index 000000000000..1c39f6cf483b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> @@ -0,0 +1,70 @@
> +* Samsung S3C2410 and compatible NAND flash controller
> +
> +Required properties:
> +- compatible : The possible values are:
> + "samsung,s3c2410-nand"
> + "samsung,s3c2412-nand"
> + "samsung,s3c2440-nand"
> + "samsung,s3c6400-nand"
> +- reg : register's location and length.
> +- #address-cells, #size-cells : see nand.txt
> +- clocks : phandle to the nand controller clock
> +- clock-names : must contain "nand"
> +
> +Optional properties:
> +- samsung,tacls : time for active CLE/ALE to nWE/nOE
> +- samsung,twrph0 : active time for nWE/nOE
> +- samsung,twrph1 : time for release CLE/ALE from nWE/nOE inactive
> +- samsung,ignore_unset_ecc : boolean to ignore error when we have
Use '-', not '_'.
> + 0xff,0xff,0xff read ECC, on the
> + assumption that it is an un-eccd page
> +
> +Optional children nodes:
> +Children nodes representing the available nand chips.
s/Children/Child/
> +
> +Optional children properties:
> +- nand-ecc-mode : see nand.txt
> +- nand-on-flash-bbt : see nand.txt
> +
> +Each children device node may optionally contain a 'partitions' sub-node,
s/children/child/
> +which further contains sub-nodes describing the flash partition mapping.
> +See partition.txt for more detail.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Russell King - ARM Linux @ 2016-09-23 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ee28ee0-cf0c-bdab-1271-f17755365c13@nelint.com>
On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote:
> Oddly, it does prevent the vast majority (90%+) of the alignment errors.
>
> I believe this is because the compiler is generating an ldm instruction
> when the ntohl() call is used, but I'm stumped about why these aren't
> generating faults:
ldm generates alignment faults when the address is not aligned to a
32-bit boundary. ldr on ARMv6+ does not.
> I don't think that's the case.
>
> # CONFIG_IPV6_GRE is not set
>
> Hmm... Instrumenting the kernel, it seems that iphdr **is** aligned on
> a 4-byte boundary.
>
> Does the ldm instruction require 8-byte alignment?
>
> There's definitely a compiler-version dependency involved here,
> since using gcc 4.9 also reduced the number of faults dramatically.
Well, I don't think it's that gcc related:
User: 0
System: 312855 (ip6_route_input+0x6c/0x1e0)
Skipped: 0
Half: 0
Word: 0
DWord: 2
Multi: 312853
c06d8998 <ip6_route_input>:
c06d89ac: e1a04000 mov r4, r0
c06d89b0: e1d489b4 ldrh r8, [r4, #148] ; 0x94
c06d89b8: e594a0a0 ldr sl, [r4, #160] ; 0xa0
c06d89cc: e08ac008 add ip, sl, r8
c06d89d4: e28c3018 add r3, ip, #24
c06d89dc: e28c7008 add r7, ip, #8
c06d89e4: e893000f ldm r3, {r0, r1, r2, r3}
c06d89ec: e24be044 sub lr, fp, #68 ; 0x44
c06d89f4: e24b5054 sub r5, fp, #84 ; 0x54
c06d89fc: e885000f stm r5, {r0, r1, r2, r3}
c06d8a04: e897000f ldm r7, {r0, r1, r2, r3}
c06d8a10: e88e000f stm lr, {r0, r1, r2, r3}
This is from:
struct flowi6 fl6 = {
.flowi6_iif = l3mdev_fib_oif(skb->dev),
.daddr = iph->daddr,
.saddr = iph->saddr,
.flowlabel = ip6_flowinfo(iph),
.flowi6_mark = skb->mark,
.flowi6_proto = iph->nexthdr,
};
specifically, I suspect, the saddr and daddr initialisations.
There's not much to get away from this - the FEC on iMX requires a
16-byte alignment for DMA addresses, which violates the network
stack's requirement for the ethernet packet to be received with a
two byte offset. So the IP header (and IPv6 headers) will always
be mis-aligned in memory, which leads to a huge number of alignment
faults.
There's not much getting away from this - the problem is not in the
networking stack, but the FEC hardware/network driver. See:
struct fec_enet_private *fep = netdev_priv(ndev);
int off;
off = ((unsigned long)skb->data) & fep->rx_align;
if (off)
skb_reserve(skb, fep->rx_align + 1 - off);
bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev, skb->data, FEC_ENET_RX_FRSIZE - fep->rx_align, DMA_FROM_DEVICE));
in fec_enet_new_rxbdp().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5ee28ee0-cf0c-bdab-1271-f17755365c13@nelint.com>
Hi Eric,
On 09/23/2016 10:19 AM, Eric Nelson wrote:
> Thanks Eric,
>
> On 09/23/2016 09:54 AM, Eric Dumazet wrote:
>> On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson <eric@nelint.com> wrote:
>>>
>>> Hello all,
>>>
>>> We're seeing alignment issues from the ethernet stack on an i.MX6UL board:
>>>
>>>
>
> <snip>
>
>>>
>>> - id = ntohl(*(__be32 *)&iph->id);
>>> - flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
>>> - id >>= 16;
>>> + id = ntohs(*(__be16 *)&iph->id);
>>> + frag = ntohs(*(__be16 *)&iph->frag_off);
>>> + flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (frag &
>>> ~IP_DF));
>>>
>>> for (p = *head; p; p = p->next) {
>>> struct iphdr *iph2;
>>>
>>
>> This solves nothing, because a few lines after you'll have yet another
>> unaligned access :
>>
>
> Oddly, it does prevent the vast majority (90%+) of the alignment errors.
>
> I believe this is because the compiler is generating an ldm instruction
> when the ntohl() call is used, but I'm stumped about why these aren't
> generating faults:
>
>> ((__force u32)iph->saddr ^ (__force u32)iph2->saddr) |
>> ((__force u32)iph->daddr ^ (__force u32)iph2->daddr)) {
>>
>> So you might have one less problematic access, out of hundreds of them
>> all over the places.
>>
>> Really the problem is that whole stack depends on the assumption that
>> IP headers are aligned on arches that care
>> (ie where NET_IP_ALIGN == 2)
>>
>> If your build does have NET_IP_ALIGN = 2 and you get a fault here, it
>> might be because of a buggy driver.
>>
>
> NET_IP_ALIGN is set to 2.
>
>> The other known case is some GRE encapsulations that break the
>> assumption, and this is discussed somewhere else.
>>
> I don't think that's the case.
>
> # CONFIG_IPV6_GRE is not set
>
> Hmm... Instrumenting the kernel, it seems that iphdr **is** aligned on
> a 4-byte boundary.
>
No. That was wrong.
The iphdr is aligned at offsets of 14 from the ethernet frame, which itself
is longword aligned.
I mistakenly tested before the call to skb_gro_header_slow(), when
iph was NULL.
After putting a test in the right place, I'm seeing an address of
888a364e for the first un-aligned packet.
Since the hardware requires longword alignment for its' DMA transfers,
aligning the IP header will require a memcpy, right?
You hinted at a solution in this post:
http://www.spinics.net/lists/netdev/msg213166.html
Are you aware of another driver doing this that could be used as
a reference?
Please advise,
Eric
^ permalink raw reply
* [RFC PATCH 2/8] thread_info: allow custom in-task thread_info
From: Mark Rutland @ 2016-09-23 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrV6G2DU1d7qr=ADas7nk5a77=J6X7ezKxw2_kzdmJGDXg@mail.gmail.com>
On Thu, Sep 22, 2016 at 03:23:59PM -0700, Andy Lutomirski wrote:
> On Sep 21, 2016 12:28 AM, "Mark Rutland" <mark.rutland@arm.com> wrote:
> > Given all that, can we make the generic thread_info::flags an unsigned
> > long, matching what the thread flag helpers implicitly assume?
>
> Yes. Want to send the patch or should I?
I've sent a patch out to LKML [1], though if that doesn't look right I'm
more than happy for you to send a correct one. ;)
Thanks,
Mark.
[1] http://lkml.kernel.org/r/1474651447-30447-1-git-send-email-mark.rutland at arm.com
^ permalink raw reply
* [PATCH V3 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-09-23 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923153910.GA23150@rob-hp-laptop>
On 9/23/2016 11:39 AM, Rob Herring wrote:
>> Required properties:
>> > -- compatible: must contain "qcom,hidma-1.0"
>> > +- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
>> > +for MSI capable HW.
> Do you have an SoC part number yet? If so, please use that instead.
>
Unfortunately, I have the same problem like "qcom, hidma-1.0". The SoC name is not settled
yet and same IP gets used in multiple SoCs. Each IP reports its own version number. This is
one of the reasons why I sticked to versioning instead of SoC name.
--
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
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANn89iLb+QJu+MYh859oAAjcLCsKRpBbzVf43yOdq+HJVtZDpQ@mail.gmail.com>
Thanks Eric,
On 09/23/2016 09:54 AM, Eric Dumazet wrote:
> On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson <eric@nelint.com> wrote:
>>
>> Hello all,
>>
>> We're seeing alignment issues from the ethernet stack on an i.MX6UL board:
>>
>>
<snip>
>>
>> - id = ntohl(*(__be32 *)&iph->id);
>> - flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
>> - id >>= 16;
>> + id = ntohs(*(__be16 *)&iph->id);
>> + frag = ntohs(*(__be16 *)&iph->frag_off);
>> + flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (frag &
>> ~IP_DF));
>>
>> for (p = *head; p; p = p->next) {
>> struct iphdr *iph2;
>>
>
> This solves nothing, because a few lines after you'll have yet another
> unaligned access :
>
Oddly, it does prevent the vast majority (90%+) of the alignment errors.
I believe this is because the compiler is generating an ldm instruction
when the ntohl() call is used, but I'm stumped about why these aren't
generating faults:
> ((__force u32)iph->saddr ^ (__force u32)iph2->saddr) |
> ((__force u32)iph->daddr ^ (__force u32)iph2->daddr)) {
>
> So you might have one less problematic access, out of hundreds of them
> all over the places.
>
> Really the problem is that whole stack depends on the assumption that
> IP headers are aligned on arches that care
> (ie where NET_IP_ALIGN == 2)
>
> If your build does have NET_IP_ALIGN = 2 and you get a fault here, it
> might be because of a buggy driver.
>
NET_IP_ALIGN is set to 2.
> The other known case is some GRE encapsulations that break the
> assumption, and this is discussed somewhere else.
>
I don't think that's the case.
# CONFIG_IPV6_GRE is not set
Hmm... Instrumenting the kernel, it seems that iphdr **is** aligned on
a 4-byte boundary.
Does the ldm instruction require 8-byte alignment?
There's definitely a compiler-version dependency involved here,
since using gcc 4.9 also reduced the number of faults dramatically.
^ permalink raw reply
* [PATCH] ARM/dt: Respect #address-cells when parsing CPUs
From: Sudeep Holla @ 2016-09-23 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31c4684aa8ef7ef210cc74da5f1b02ff2882a099.1474645829.git.robin.murphy@arm.com>
On 23/09/16 16:51, Robin Murphy wrote:
> Whilst MPIDR values themselves are only 32 bits, it is still perfectly
> valid for a DT to have #address-cells > 1 in the CPUs node, resulting in
> the "reg" property having leading zero cell(s). In that situation, the
> big-endian nature of the data conspires with the current behaviour of
> just parsing the first cell to cause the kernel to think all CPUs have
> ID 0, and become resoundingly unhappy as a consequence.
>
> Take #address-cells into account when parsing CPUs so as to be correct
> under any circumstances.
>
Lorenzo had a patch [1] to address this a while ago. I assume all the
other patches in the series have been merged hopefully which fixes the
device trees.
--
Regards,
Sudeep
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/169093.html
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/169083.html
^ permalink raw reply
* [PATCHv2] arm64: fix dump_backtrace/unwind_frame with NULL tsk
From: Mark Rutland @ 2016-09-23 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In some places, dump_backtrace() is called with a NULL tsk parameter,
e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
core code. The expectation is that this is treated as if current were
passed instead of NULL. Similar is true of unwind_frame().
Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't
take this into account. In dump_backtrace() it compares tsk against
current *before* we check if tsk is NULL, and in unwind_frame() we never
set tsk if it is NULL.
Due to this, we won't initialise irq_stack_ptr in either function. In
dump_backtrace() this results in calling dump_mem() for memory
immediately above the IRQ stack range, rather than for the relevant
range on the task stack. In unwind_frame we'll reject unwinding frames
on the IRQ stack.
In either case this results in incomplete or misleading backtrace
information, but is not otherwise problematic. The initial percpu areas
(including the IRQ stacks) are allocated in the linear map, and dump_mem
uses __get_user(), so we shouldn't access anything with side-effects,
and will handle holes safely.
This patch fixes the issue by having both functions handle the NULL tsk
case before doing anything else with tsk.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Fixes: a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust")
Acked-by: James Morse <james.morse@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yang Shi <yang.shi@linaro.org>
---
arch/arm64/kernel/stacktrace.c | 5 ++++-
arch/arm64/kernel/traps.c | 10 +++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
Since v1 [1]:
* Fix up unwind_frame(), too.
James, I've assumed that your ack still applies. Please shout if that is not
the case!
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/458913.html
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d9751a4..d34fd72 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -43,6 +43,9 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
unsigned long fp = frame->fp;
unsigned long irq_stack_ptr;
+ if (!tsk)
+ tsk = current;
+
/*
* Switching between stacks is valid when tracing current and in
* non-preemptible context.
@@ -67,7 +70,7 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- if (tsk && tsk->ret_stack &&
+ if (tsk->ret_stack &&
(frame->pc == (unsigned long)return_to_handler)) {
/*
* This is a case where function graph tracer has
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1584e8a..8b7e596 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -142,6 +142,11 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
unsigned long irq_stack_ptr;
int skip;
+ pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
+
+ if (!tsk)
+ tsk = current;
+
/*
* Switching between stacks is valid when tracing current and in
* non-preemptible context.
@@ -151,11 +156,6 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
else
irq_stack_ptr = 0;
- pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
-
- if (!tsk)
- tsk = current;
-
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_stack_pointer;
--
1.9.1
^ permalink raw reply related
* Alignment issues with freescale FEC driver
From: Eric Dumazet @ 2016-09-23 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <02afb707-65de-5101-a79b-355929c4e00b@nelint.com>
On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson <eric@nelint.com> wrote:
>
> Hello all,
>
> We're seeing alignment issues from the ethernet stack on an i.MX6UL board:
>
> root at mx6ul:~# cat /proc/cpu/alignment
> User: 0
> System: 470010 (inet_gro_receive+0x104/0x278)
>
> This seems to be related to the ip header alignment, and there
> was much discussion in mailing list threads [1] and [2].
>
> In particular, Russell referred to a patch here, but I haven't been
> able to find it:
> https://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002844.html
>
> Eric Dumazet also suggested a path toward fixing it, but I don't quite
> understand the suggestion:
> http://www.spinics.net/lists/netdev/msg213166.htm
>
> The immediate problem is addressed by just reading the id and frag_offs
> fields in the iphdr structure as shown in this patch:
>
> commit 98810abc911b1286a7e4a2ebdfbad66f12fae19d
> Author: Eric Nelson <eric@nelint.com>
> Date: Fri Sep 23 08:26:03 2016 -0700
>
> net: ipv4: af_inet: don't read multiple 16-bit iphdr fields as a 32-bit
> value
>
> Change-Id: Idc7122c22c13ca078be31907d30ab1c3148ba807
> Signed-off-by: Eric Nelson <eric@nelint.com>
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 0cc98b1..c17ef6e 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1301,6 +1301,7 @@ static struct sk_buff **inet_gro_receive(struct
> sk_buff **head,
> unsigned int hlen;
> unsigned int off;
> unsigned int id;
> + unsigned int frag;
> int flush = 1;
> int proto;
>
> @@ -1326,9 +1327,9 @@ static struct sk_buff **inet_gro_receive(struct
> sk_buff **head,
> if (unlikely(ip_fast_csum((u8 *)iph, 5)))
> goto out_unlock;
>
> - id = ntohl(*(__be32 *)&iph->id);
> - flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
> - id >>= 16;
> + id = ntohs(*(__be16 *)&iph->id);
> + frag = ntohs(*(__be16 *)&iph->frag_off);
> + flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (frag &
> ~IP_DF));
>
> for (p = *head; p; p = p->next) {
> struct iphdr *iph2;
>
This solves nothing, because a few lines after you'll have yet another
unaligned access :
((__force u32)iph->saddr ^ (__force u32)iph2->saddr) |
((__force u32)iph->daddr ^ (__force u32)iph2->daddr)) {
So you might have one less problematic access, out of hundreds of them
all over the places.
Really the problem is that whole stack depends on the assumption that
IP headers are aligned on arches that care
(ie where NET_IP_ALIGN == 2)
If your build does have NET_IP_ALIGN = 2 and you get a fault here, it
might be because of a buggy driver.
The other known case is some GRE encapsulations that break the
assumption, and this is discussed somewhere else.
^ permalink raw reply
* Alignment issues with freescale FEC driver
From: Eric Nelson @ 2016-09-23 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <troy.kisky@boundarydevices.com>
Hello all,
We're seeing alignment issues from the ethernet stack on an i.MX6UL board:
root at mx6ul:~# cat /proc/cpu/alignment
User: 0
System: 470010 (inet_gro_receive+0x104/0x278)
This seems to be related to the ip header alignment, and there
was much discussion in mailing list threads [1] and [2].
In particular, Russell referred to a patch here, but I haven't been
able to find it:
https://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002844.html
Eric Dumazet also suggested a path toward fixing it, but I don't quite
understand the suggestion:
http://www.spinics.net/lists/netdev/msg213166.htm
The immediate problem is addressed by just reading the id and frag_offs
fields in the iphdr structure as shown in this patch:
commit 98810abc911b1286a7e4a2ebdfbad66f12fae19d
Author: Eric Nelson <eric@nelint.com>
Date: Fri Sep 23 08:26:03 2016 -0700
net: ipv4: af_inet: don't read multiple 16-bit iphdr fields as a 32-bit
value
Change-Id: Idc7122c22c13ca078be31907d30ab1c3148ba807
Signed-off-by: Eric Nelson <eric@nelint.com>
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 0cc98b1..c17ef6e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1301,6 +1301,7 @@ static struct sk_buff **inet_gro_receive(struct
sk_buff **head,
unsigned int hlen;
unsigned int off;
unsigned int id;
+ unsigned int frag;
int flush = 1;
int proto;
@@ -1326,9 +1327,9 @@ static struct sk_buff **inet_gro_receive(struct
sk_buff **head,
if (unlikely(ip_fast_csum((u8 *)iph, 5)))
goto out_unlock;
- id = ntohl(*(__be32 *)&iph->id);
- flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id & ~IP_DF));
- id >>= 16;
+ id = ntohs(*(__be16 *)&iph->id);
+ frag = ntohs(*(__be16 *)&iph->frag_off);
+ flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (frag &
~IP_DF));
for (p = *head; p; p = p->next) {
struct iphdr *iph2;
The reading of both fields in one "ntohl" seems obfuscated at best and
certainly worthy of a comment about the optimization but I understand
from other notes that the fundamental problem is that the IP header should
be aligned on a 4-byte boundary and that's not possible without a memcpy.
I'd like to hear suggestions about how we can address this.
Regards,
Eric
[1] - http://www.spinics.net/lists/netdev/msg213114.html
[2] -
https://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002828.html
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: Add timer erratum property for LS2080A and LS1043A
From: Will Deacon @ 2016-09-23 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-2-git-send-email-oss@buserror.net>
On Thu, Sep 22, 2016 at 03:35:16AM -0500, Scott Wood wrote:
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 1 +
> 2 files changed, 2 insertions(+)
This patch conflicts with mainline, but I've queued the other three
patches in the series in the arm64 tree.
Please send the updated .dts changes via arm-soc.
Will
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Dave Gerlach @ 2016-09-23 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923051947.GC17336@vireshk-i7>
On 09/23/2016 12:19 AM, Viresh Kumar wrote:
> On 21-09-16, 14:34, Dave Gerlach wrote:
>> Viresh,
>> On 09/07/2016 10:39 PM, Viresh Kumar wrote:
>>> On 07-09-16, 10:04, Dave Gerlach wrote:
>>>>>> +static const struct of_device_id ti_cpufreq_of_match[] = {
>>>>>> + { .compatible = "operating-points-v2-ti-am3352-cpu",
>>>>>> + .data = &am3x_soc_data, },
>>>>>> + { .compatible = "operating-points-v2-ti-am4372-cpu",
>>>>>> + .data = &am4x_soc_data, },
>>>>>> + { .compatible = "operating-points-v2-ti-dra7-cpu",
>>>>>> + .data = &dra7_soc_data },
>>>>>
>>>>> You should be using your SoC compatible strings here. OPP compatible
>>>>> property isn't supposed to be (mis)used for this purpose.
>>>>>
>>>>
>>>> Referring to my comments in patch 1, what if we end up changing the bindings
>>>> based on DT maintainer comments? We will have these compatible strings, and
>>>> at that point is it acceptable to match against them? Or is it still better
>>>> to match to SoC compatibles? I think it makes sense to just probe against
>>>> these.
>>>
>>> But even then I think these are not correct. You should have added a
>>> single compatible string: operating-points-v2-ti-cpu.
>>>
>>> As the properties will stay the same across machines. And then you
>>> need to use SoC strings here.
>>>
>>
>> Are you opposed to moving _of_get_opp_desc_node from
>> drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
>> appropriately?
>
> I am not opposed to that, but ...
>
>> If I move the ti properties out of the cpu node, as discussed in patch 1 of
>> this series, and into the operating-points-v2 table, I need a way to get the
>> operating-points-v2 device node and I think it makes sense to reuse this as
>> it is what the opp framework uses internally to parse the phandle to the opp
>> table.
>
> I am not sure if those registers belong to the OPP bindings. What are those
> registers really? What all can be read from them? Why shouldn't they be present
> as a separate node in DT on the respective bus? Look at how it is done for
> sti-cpufreq driver.
>
The sti-cpufreq driver in v4.8-rc7 appears to do what I am already doing
in this revision of the patch, reading from a syscon phandle that is
part of the cpu node in the DT which is what I was told not to do.
The register I am referencing in the syscon is a bit-field describing
which OPPs are valid for the system, so it is very relevant to the OPP
binding. They really are already present in a separate node, I'm just
indexing into a syscon, same as the sti-cpufreq driver appears to be doing.
Regards,
Dave
^ permalink raw reply
* [PATCH v5 1/6] of: Add vendor prefix for Engicam s.r.l company
From: Rob Herring @ 2016-09-23 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473967015-8523-2-git-send-email-jagan@amarulasolutions.com>
On Fri, Sep 16, 2016 at 12:46:50AM +0530, Jagan Teki wrote:
> Engicam providing design services of electronic systems with
> high content of technology, relying on a long experience in
> electronic design.
>
> For more info visit
> http://www.engicam.com/en/
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v5:
> - none
> Changes for v4:
> - new patch
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm64: fix dump_backtrace with NULL tsk
From: Mark Rutland @ 2016-09-23 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E55117.8080907@arm.com>
On Fri, Sep 23, 2016 at 04:58:15PM +0100, James Morse wrote:
> Hi Mark,
>
> On 23/09/16 15:56, Mark Rutland wrote:
> > In some places, dump_backtrace() is called with a NULL tsk parameter,
> > e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
> > core code. The expectation is that this is treated as if current were
> > passed instead of NULL.
> >
> > Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't
> > take this into account, and compares tsk against current *before* we
> > check if tsk is NULL.
> >
> > Due to this, we won't initialise irq_stack_ptr, and when we try to dump
> > the exception regs we may call dump_mem() for memory immediately above
> > the IRQ stack range, rather than for the relevant range on the task
> > stack.
>
> Bother, I should have spotted that.
FWIW, it certainly wasn't obvious!
I only noticed because I had to vet all the callers for
try_get_task_stack() ... put_task_stack() correctness with
THREAD_INFO_IN_TASK.
> Thanks for catching this!
>
> Acked-by: James Morse <james.morse@arm.com>
Cheers!
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Stuart Yoder @ 2016-09-23 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2519047.ijr708V79a@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, September 23, 2016 10:58 AM
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org; Stuart Yoder <stuart.yoder@nxp.com>; Alison Wang
> <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam Estevam
> <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-kernel at vger.kernel.org; Scott Wood
> <scott.wood@nxp.com>; Leo Li <leoyang.li@nxp.com>; Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>
> On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote:
> > On 23/09/16 15:44, Arnd Bergmann wrote:
> > > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote:
> > >> On 23/09/16 15:01, Stuart Yoder wrote:
> > >> Otherwise you can
> > >> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
> > >> need to trap and translate subsequent SMC calls for e.g. PSCI).
> > >>
> > >>> If there is such a requirement, it's something begging for standardization.
> > >>> Doesn't make sense for multiple divergent approaches for switching from
> > >>> aarch64/EL2 to aarch32/EL2.
> > >>
> > >> Perhaps - I did briefly look into how hard it would be to write a proper
> > >> SMC service handler to do this (since ATF does have a framework for such
> > >> things), but concluded it would be more than 10 minutes' work and just
> > >> cheated instead. It's certainly something which could be raised with the
> > >> firmware folks.
> > >
> > > If we end up allowing all arm64 platforms to be enabled in arch/arm,
> > > we could perhaps create a generic implementation that does both of
> > > those things, i.e.
> > >
> > > - Take the arm32 kernel Image or zImage file, wrap it inside of a binary
> > > that implements the arm64 boot protocol.
> > > - When that starts up, try to use the new PSCI call to jump into
> > > the arm32 kernel
> > > - If PSCI failed and we are running in EL2, implement the shim
> > > and start the arm32 kernel in EL1 mode
> >
> > Really, though, the firmware call thing is an incredibly niche use-case.
> > Beyond development, the only real benefit of starting an AArch32 kernel
> > in Hyp is that you can run AArch32 KVM guests, which you can do equally
> > well (if not better) under an AArch64 kernel.
>
> This was my question earlier in the thread, apparently Alison has
> another use case in mind, but I don't yet know what that is. If
> that use case is important enough, we could do it this way.
>
> The only use case I can think of at the moment is boot testing
> on kernelci.org, which could be used to check whether all the drivers
> work in 32-bit environments.
The reason we want aarch32 kernel support is for specific customers that
have requirements for legacy 32-bit kernel drivers that function on ARMv7
but for some reason are very problematic to port to a 64-bit kernel. So,
the way to ease the 64-bit transition is allow them to run an aarch32 kernel
and their driver on an ARMv8 SoC. I don't think we specifically care
whether the kernel starts at EL2 or EL1.
Stuart
^ 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