* latest version of bluetooth for n950?
From: Sebastian Reichel @ 2016-10-11 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011145140.cq3jex2r23wuayph@earth>
Hi,
On Tue, Oct 11, 2016 at 04:51:40PM +0200, Sebastian Reichel wrote:
> On Tue, Oct 11, 2016 at 09:47:04AM +0200, Pavel Machek wrote:
> > I got some free cycles to play with n900 and bluetooth. There's still
> > some unrelated config option that breaks even the old vesion of
> > patches, but I'm ready for more debugging now.
> >
> > Could I have the latest version of the (clean) bluetooth patch? I have
> > feeling it might work with the right config option, and would like to
> > try.
> >
> > For the record, here's working .config and the tricky tricky oneliner
> > that took me week to figure out.
>
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/log/?h=n950-bluetooth
>
> My local branch is based on 4.8 and fixes a few of Marcel's
> comments. I'm currently at ELCE, but I will push my local
> stuff later in the hotel after verifying, that it works as
> expected (luckily I brought N950 with me :)).
It does not. Rebasing the pushed branch to v4.8 works, so the
problem is somewhere in my new changes. I will try to have a
look at it tomorrow.
The changes shouldn't affect you for any tests, though. Just
take the branch from above (and optionally rebase to v4.8).
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161011/59a1c8ba/attachment.sig>
^ permalink raw reply
* [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry
From: Rafael J. Wysocki @ 2016-10-11 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005112540.22189-1-lorenzo.pieralisi@arm.com>
On Wednesday, October 05, 2016 12:25:40 PM Lorenzo Pieralisi wrote:
> The ARM64 architecture defines ARM64 specific ACPI bindings to
> configure and set-up arch specific components. To simplify
> code reviews/updates and streamline the maintainership structure
> supporting the arch specific code, a new arm64 directory was created in
> /drivers/acpi, to contain ACPI code that is specific to ARM64
> architecture.
>
> Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
> the newly created subdirectory and respective code content.
>
> Lorenzo Pieralisi will be in charge of submitting and managing
> the pull requests on behalf of all maintainers listed.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Link: http://lkml.kernel.org/r/1603704.EGiVTcCxLR at vostro.rjw.lan
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f593300..2a70dd9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -316,6 +316,14 @@ W: https://01.org/linux-acpi
> S: Supported
> F: drivers/acpi/fan.c
>
> +ACPI FOR ARM64 (ACPI/arm64)
> +M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> +M: Hanjun Guo <hanjun.guo@linaro.org>
> +M: Sudeep Holla <sudeep.holla@arm.com>
> +L: linux-acpi at vger.kernel.org
> +S: Maintained
> +F: drivers/acpi/arm64
> +
> ACPI THERMAL DRIVER
> M: Zhang Rui <rui.zhang@intel.com>
> L: linux-acpi at vger.kernel.org
>
Applied (with tags).
Thanks,
Rafael
^ permalink raw reply
* [PATCH V2 0/3] ACPI,PCI,IRQ: revert penalty calculation for SCI
From: Rafael J. Wysocki @ 2016-10-11 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475615720-31047-1-git-send-email-okaya@codeaurora.org>
On Tuesday, October 04, 2016 05:15:16 PM Sinan Kaya wrote:
> Restoring the old behavior for IRQ < 256 and the dynamic penalty behavior
> will remain effective for IRQ >= 256.
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The reverted changes were in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA, SCI as well as PCI
> IRQS. This didn't work out well with the existing platforms.
>
> Changes from V1 (https://lkml.org/lkml/2016/10/1/106):
> * Commit message updates
>
> Sinan Kaya (3):
> Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
> ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
> Revert "ACPI,PCI,IRQ: remove SCI penalize function"
>
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 71 ++++++++++++++++++++++-----------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 37 insertions(+), 36 deletions(-)
>
I've queued up the series, but still waiting on Bjorn's response.
Thanks,
Rafael
^ permalink raw reply
* [PATCH v1 1/2] include: dt-bindings: Add GPIO pin index definition for rockchip pinctrl
From: Heiko Stuebner @ 2016-10-11 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473210053-23743-1-git-send-email-andy.yan@rock-chips.com>
Am Mittwoch, 7. September 2016, 09:00:53 CEST schrieb Andy Yan:
> Add gpio pin index definition to make it easier to describe
> GPIO in dts.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
just as a heads up, as I didn't respond yet:
Looks good and I'll take them, I just want to wait for the merge-window to
close (should be the coming sunday), to be able to put the header change in a
shared branch for the case that other users appear during the 4.10 cycle.
Heiko
> ---
>
> Changes in v1:
> - remove gpio bank definition RK_GPIO7/8
> - redefine GPIO PIN as RK_PA/B/C/Dx
>
> include/dt-bindings/pinctrl/rockchip.h | 33
> +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/rockchip.h
> b/include/dt-bindings/pinctrl/rockchip.h index 743e66a..aaec8ba 100644
> --- a/include/dt-bindings/pinctrl/rockchip.h
> +++ b/include/dt-bindings/pinctrl/rockchip.h
> @@ -25,6 +25,39 @@
> #define RK_GPIO4 4
> #define RK_GPIO6 6
>
> +#define RK_PA0 0
> +#define RK_PA1 1
> +#define RK_PA2 2
> +#define RK_PA3 3
> +#define RK_PA4 4
> +#define RK_PA5 5
> +#define RK_PA6 6
> +#define RK_PA7 7
> +#define RK_PB0 8
> +#define RK_PB1 9
> +#define RK_PB2 10
> +#define RK_PB3 11
> +#define RK_PB4 12
> +#define RK_PB5 13
> +#define RK_PB6 14
> +#define RK_PB7 15
> +#define RK_PC0 16
> +#define RK_PC1 17
> +#define RK_PC2 18
> +#define RK_PC3 19
> +#define RK_PC4 20
> +#define RK_PC5 21
> +#define RK_PC6 22
> +#define RK_PC7 23
> +#define RK_PD0 24
> +#define RK_PD1 25
> +#define RK_PD2 26
> +#define RK_PD3 27
> +#define RK_PD4 28
> +#define RK_PD5 29
> +#define RK_PD6 30
> +#define RK_PD7 31
> +
> #define RK_FUNC_GPIO 0
> #define RK_FUNC_1 1
> #define RK_FUNC_2 2
^ permalink raw reply
* [PATCH] arm64: defconfig: enable EEPROM_AT25 config option
From: Scott Branden @ 2016-10-11 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1503155.onL8VV3RJv@wuerfel>
Hi Arnd,
On 16-10-10 02:20 AM, Arnd Bergmann wrote:
> On Monday, October 10, 2016 2:08:05 AM CEST Florian Fainelli wrote:
>> On 10/07/2016 02:23 PM, Scott Branden wrote:
>>> Enable support for on board SPI EEPROM by turning on
>>> CONFIG_EEPROM_AT25.
>>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>
>> Looks fine to me, unless this needs to be a module, Arnd, what do you think?
>
> Please either make it a module or explain in the patch description
> why it should be built-in.
We use a fixed rootfs image to test the kernel. For simplicity we don't
construct a rootfs or load any modules. We just test the kernel image.
So for us every defconfig we use needs to be set to y to use the
upstreamed kernel.
>
> Arnd
>
Regards,
Scott
^ permalink raw reply
* [PATCH] ARM: multi_v7_defconfig: Enable Intel e1000e driver
From: Scott Branden @ 2016-10-11 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8265935.TobkRj9BnG@wuerfel>
Hi Arnd,
On 16-10-10 12:47 AM, Arnd Bergmann wrote:
> On Saturday, October 8, 2016 1:41:04 PM CEST Scott Branden wrote:
>> Enable support for the Intel e1000e driver
>>
>> Signed-off-by: Ray Jui <rjui@broadcom.com>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>
>
> Can we make this a loadable module and group it with the other
> ethernet drivers?
>
We use a fixed rootfs image to test the kernel. For simplicity we don't
construct a rootfs or load any modules. We just test the kernel image.
So for us every defconfig we use needs to be set to y to use the
upstreamed kernel.
Plus, how do you NFS mount a rootfs if the ethernet driver is a loadable
module?
> Arnd
>
Regards,
Scott
^ permalink raw reply
* [PATCH 1/2] arm64: dts: zx: Change gic node to fix boot failure
From: Jun Nie @ 2016-10-12 2:14 UTC (permalink / raw)
To: linux-arm-kernel
GICR for multiple CPU can be described with start address and stride,
or with multiple address. Current multiple address and stride are
both used. Fix it.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index a223066..6b239a3 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -239,16 +239,11 @@
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <0>;
- #redistributor-regions = <6>;
- redistributor-stride = <0x0 0x40000>;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x20000>;
interrupt-controller;
reg = <0x02a00000 0x10000>,
- <0x02b00000 0x20000>,
- <0x02b20000 0x20000>,
- <0x02b40000 0x20000>,
- <0x02b60000 0x20000>,
- <0x02b80000 0x20000>,
- <0x02ba0000 0x20000>;
+ <0x02b00000 0xc0000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: zx: Add clock controller nodes
From: Jun Nie @ 2016-10-12 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-1-git-send-email-jun.nie@linaro.org>
Add clock controller nodes, including one top controller
two low speed controllers and one audio controller.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..33e42d5 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -279,9 +279,33 @@
dma-requests = <32>;
};
+ lsp0crm: clock-controller at 01420000 {
+ compatible = "zte,zx296718-lsp0crm";
+ reg = <0x01420000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ lsp1crm: clock-controller at 01430000 {
+ compatible = "zte,zx296718-lsp1crm";
+ reg = <0x01430000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ topcrm: clock-controller at 01461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
};
+
+ audiocrm: clock-controller at 01480000 {
+ compatible = "zte,zx296718-audiocrm";
+ reg = <0x01480000 0x1000>;
+ #clock-cells = <1>;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: zx: Change gic node to fix boot failure
From: Shawn Guo @ 2016-10-12 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-1-git-send-email-jun.nie@linaro.org>
On Wed, Oct 12, 2016 at 10:14:15AM +0800, Jun Nie wrote:
> GICR for multiple CPU can be described with start address and stride,
> or with multiple address. Current multiple address and stride are
> both used. Fix it.
I think we need to tell the full story about this boot failure in commit
log, i.e. it boots fine on v4.8-rc and fails on linux-next because of
the mm/vmalloc.c changes.
Shawn
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index a223066..6b239a3 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -239,16 +239,11 @@
> compatible = "arm,gic-v3";
> #interrupt-cells = <3>;
> #address-cells = <0>;
> - #redistributor-regions = <6>;
> - redistributor-stride = <0x0 0x40000>;
> + #redistributor-regions = <1>;
> + redistributor-stride = <0x20000>;
> interrupt-controller;
> reg = <0x02a00000 0x10000>,
> - <0x02b00000 0x20000>,
> - <0x02b20000 0x20000>,
> - <0x02b40000 0x20000>,
> - <0x02b60000 0x20000>,
> - <0x02b80000 0x20000>,
> - <0x02ba0000 0x20000>;
> + <0x02b00000 0xc0000>;
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: zx: Add clock controller nodes
From: Shawn Guo @ 2016-10-12 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-2-git-send-email-jun.nie@linaro.org>
On Wed, Oct 12, 2016 at 10:14:16AM +0800, Jun Nie wrote:
> Add clock controller nodes, including one top controller
> two low speed controllers and one audio controller.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 6b239a3..33e42d5 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -279,9 +279,33 @@
> dma-requests = <32>;
> };
>
> + lsp0crm: clock-controller at 01420000 {
Please drop the leading zeros from unit-address in node name.
Shawn
> + compatible = "zte,zx296718-lsp0crm";
> + reg = <0x01420000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + lsp1crm: clock-controller at 01430000 {
> + compatible = "zte,zx296718-lsp1crm";
> + reg = <0x01430000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + topcrm: clock-controller at 01461000 {
> + compatible = "zte,zx296718-topcrm";
> + reg = <0x01461000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> sysctrl: sysctrl at 1463000 {
> compatible = "zte,zx296718-sysctrl", "syscon";
> reg = <0x1463000 0x1000>;
> };
> +
> + audiocrm: clock-controller at 01480000 {
> + compatible = "zte,zx296718-audiocrm";
> + reg = <0x01480000 0x1000>;
> + #clock-cells = <1>;
> + };
> };
> };
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next 0/2] drivers: net: xgene: fix: Use GPIO to get link status
From: David Miller @ 2016-10-12 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 6 Oct 2016 14:35:56 -0700
> Since the link value reported by the link status register is not
> reliable if no SPF module inserted, this patchset fixes the issue by
> using GPIO to determine the link status when no module inserted.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH 0/4] ARM64: More flexible HW watchpoint
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
Currently, we do not support all the byte select option provided by ARM64
specs for a HW watchpoint.
This patch set will help user to instrument a watchpoint with all possible
byte select options.
Pratyush Anand (4):
hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
arm64: Allow hw watchpoint at varied offset from base address
arm64: Allow hw watchpoint of length 3,5,6 and 7
selftests: arm64: add test for unaligned watchpoint address handling
arch/arm64/include/asm/hw_breakpoint.h | 6 +-
arch/arm64/kernel/hw_breakpoint.c | 79 ++++++--
arch/arm64/kernel/ptrace.c | 5 +-
include/uapi/linux/hw_breakpoint.h | 4 +
tools/include/uapi/linux/hw_breakpoint.h | 4 +
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 223 +++++++++++++++++++++
7 files changed, 300 insertions(+), 26 deletions(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/4] hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
We only support breakpoint/watchpoint of length 1, 2, 4 and 8. If we can
support other length as well, then user may watch more data with less
number of watchpoints (provided hardware supports it). For example: if we
have to watch only 4th, 5th and 6th byte from a 64 bit aligned address, we
will have to use two slots to implement it currently. One slot will watch a
half word at offset 4 and other a byte at offset 6. If we can have a
watchpoint of length 3 then we can watch it with single slot as well.
ARM64 hardware does support such functionality, therefore adding these new
definitions in generic layer.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
include/uapi/linux/hw_breakpoint.h | 4 ++++
tools/include/uapi/linux/hw_breakpoint.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/include/uapi/linux/hw_breakpoint.h b/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/include/uapi/linux/hw_breakpoint.h
+++ b/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
diff --git a/tools/include/uapi/linux/hw_breakpoint.h b/tools/include/uapi/linux/hw_breakpoint.h
index b04000a2296a..2b65efd19a46 100644
--- a/tools/include/uapi/linux/hw_breakpoint.h
+++ b/tools/include/uapi/linux/hw_breakpoint.h
@@ -4,7 +4,11 @@
enum {
HW_BREAKPOINT_LEN_1 = 1,
HW_BREAKPOINT_LEN_2 = 2,
+ HW_BREAKPOINT_LEN_3 = 3,
HW_BREAKPOINT_LEN_4 = 4,
+ HW_BREAKPOINT_LEN_5 = 5,
+ HW_BREAKPOINT_LEN_6 = 6,
+ HW_BREAKPOINT_LEN_7 = 7,
HW_BREAKPOINT_LEN_8 = 8,
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] arm64: Allow hw watchpoint at varied offset from base address
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
ARM64 hardware supports watchpoint at any double word aligned address.
However, it can select any consecutive bytes from offset 0 to 7 from that
base address. For example, if base address is programmed as 0x420030 and
byte select is 0x1C, then access of 0x420032,0x420033 and 0x420034 will
generate a watchpoint exception.
Currently, we do not have such modularity. We can only program byte,
halfword, word and double word access exception from any base address.
This patch adds support to overcome above limitations.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 43 +++++++++++++++++-----------------
arch/arm64/kernel/ptrace.c | 5 ++--
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 115ea2a64520..4f4e58bee9bc 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -118,7 +118,7 @@ struct perf_event;
struct pmu;
extern int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type);
+ int *gen_len, int *gen_type, int *offset);
extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 26a6bf77d272..c888c23149ad 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -349,7 +349,7 @@ int arch_check_bp_in_kernelspace(struct perf_event *bp)
* to generic breakpoint descriptions.
*/
int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
- int *gen_len, int *gen_type)
+ int *gen_len, int *gen_type, int *offset)
{
/* Type */
switch (ctrl.type) {
@@ -369,8 +369,10 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
return -EINVAL;
}
+ *offset = ffs(ctrl.len) - 1;
+
/* Len */
- switch (ctrl.len) {
+ switch (ctrl.len >> *offset) {
case ARM_BREAKPOINT_LEN_1:
*gen_len = HW_BREAKPOINT_LEN_1;
break;
@@ -517,18 +519,17 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
default:
return -EINVAL;
}
-
- info->address &= ~alignment_mask;
- info->ctrl.len <<= offset;
} else {
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE)
alignment_mask = 0x3;
else
alignment_mask = 0x7;
- if (info->address & alignment_mask)
- return -EINVAL;
+ offset = info->address & alignment_mask;
}
+ info->address &= ~alignment_mask;
+ info->ctrl.len <<= offset;
+
/*
* Disallow per-task kernel breakpoints since these would
* complicate the stepping code.
@@ -671,6 +672,7 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct debug_info *debug_info;
struct arch_hw_breakpoint *info;
struct arch_hw_breakpoint_ctrl ctrl;
+ u32 lens, lene;
slots = this_cpu_ptr(wp_on_reg);
debug_info = ¤t->thread.debug;
@@ -684,25 +686,22 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
goto unlock;
info = counter_arch_bp(wp);
- /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
- if (is_compat_task()) {
- if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
- alignment_mask = 0x7;
- else
- alignment_mask = 0x3;
- } else {
- alignment_mask = 0x7;
- }
- /* Check if the watchpoint value matches. */
+ /* Check if the watchpoint value and byte select match. */
val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- if (val != (addr & ~alignment_mask))
- goto unlock;
-
- /* Possible match, check the byte address select to confirm. */
ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
decode_ctrl_reg(ctrl_reg, &ctrl);
- if (!((1 << (addr & alignment_mask)) & ctrl.len))
+ lens = ffs(ctrl.len) - 1;
+ lene = fls(ctrl.len) - 1;
+ /*
+ * Ideally, a read/write type information such as
+ * byte/hw/word/dw would have provided a good check. But
+ * I do not see such possibility. So, considering that max
+ * rd/wr size as 8, i.e. this watchpoint interrupt would
+ * have generated because any of the address from `addr` to
+ * `addr + 7` would have been accessed.
+ */
+ if (addr + 7 < val + lens || addr > val + lene)
goto unlock;
/*
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e0c81da60f76..0eb366a94382 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -327,13 +327,13 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
struct arch_hw_breakpoint_ctrl ctrl,
struct perf_event_attr *attr)
{
- int err, len, type, disabled = !ctrl.enabled;
+ int err, len, type, offset, disabled = !ctrl.enabled;
attr->disabled = disabled;
if (disabled)
return 0;
- err = arch_bp_generic_fields(ctrl, &len, &type);
+ err = arch_bp_generic_fields(ctrl, &len, &type, &offset);
if (err)
return err;
@@ -352,6 +352,7 @@ static int ptrace_hbp_fill_attr_ctrl(unsigned int note_type,
attr->bp_len = len;
attr->bp_type = type;
+ attr->bp_addr += offset;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
Since, arm64 can support all offset within a double word limit. Therefore,
now support other lengths within that range as well.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 4 ++++
arch/arm64/kernel/hw_breakpoint.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 4f4e58bee9bc..7a18c8520588 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -76,7 +76,11 @@ static inline void decode_ctrl_reg(u32 reg,
/* Lengths */
#define ARM_BREAKPOINT_LEN_1 0x1
#define ARM_BREAKPOINT_LEN_2 0x3
+#define ARM_BREAKPOINT_LEN_3 0x7
#define ARM_BREAKPOINT_LEN_4 0xf
+#define ARM_BREAKPOINT_LEN_5 0x1f
+#define ARM_BREAKPOINT_LEN_6 0x3f
+#define ARM_BREAKPOINT_LEN_7 0x7f
#define ARM_BREAKPOINT_LEN_8 0xff
/* Kernel stepping */
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index c888c23149ad..7ff2c3cfeb46 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -317,9 +317,21 @@ static int get_hbp_len(u8 hbp_len)
case ARM_BREAKPOINT_LEN_2:
len_in_bytes = 2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ len_in_bytes = 3;
+ break;
case ARM_BREAKPOINT_LEN_4:
len_in_bytes = 4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ len_in_bytes = 5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ len_in_bytes = 6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ len_in_bytes = 7;
+ break;
case ARM_BREAKPOINT_LEN_8:
len_in_bytes = 8;
break;
@@ -379,9 +391,21 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
case ARM_BREAKPOINT_LEN_2:
*gen_len = HW_BREAKPOINT_LEN_2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ *gen_len = HW_BREAKPOINT_LEN_3;
+ break;
case ARM_BREAKPOINT_LEN_4:
*gen_len = HW_BREAKPOINT_LEN_4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ *gen_len = HW_BREAKPOINT_LEN_5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ *gen_len = HW_BREAKPOINT_LEN_6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ *gen_len = HW_BREAKPOINT_LEN_7;
+ break;
case ARM_BREAKPOINT_LEN_8:
*gen_len = HW_BREAKPOINT_LEN_8;
break;
@@ -425,9 +449,21 @@ static int arch_build_bp_info(struct perf_event *bp)
case HW_BREAKPOINT_LEN_2:
info->ctrl.len = ARM_BREAKPOINT_LEN_2;
break;
+ case HW_BREAKPOINT_LEN_3:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_3;
+ break;
case HW_BREAKPOINT_LEN_4:
info->ctrl.len = ARM_BREAKPOINT_LEN_4;
break;
+ case HW_BREAKPOINT_LEN_5:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_5;
+ break;
+ case HW_BREAKPOINT_LEN_6:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_6;
+ break;
+ case HW_BREAKPOINT_LEN_7:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_7;
+ break;
case HW_BREAKPOINT_LEN_8:
info->ctrl.len = ARM_BREAKPOINT_LEN_8;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] selftests: arm64: add test for unaligned watchpoint address handling
From: Pratyush Anand @ 2016-10-12 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476251587.git.panand@redhat.com>
ARM64 hardware expects 64bit aligned address for watchpoint invocation.
However, it provides byte selection method to select any number of
consecutive byte set within the range of 1-8.
This patch adds support to test all such byte selection option for
different memory write sizes.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 223 +++++++++++++++++++++
2 files changed, 227 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
diff --git a/tools/testing/selftests/breakpoints/Makefile b/tools/testing/selftests/breakpoints/Makefile
index 74e533fd4bc5..61b79e8df1f4 100644
--- a/tools/testing/selftests/breakpoints/Makefile
+++ b/tools/testing/selftests/breakpoints/Makefile
@@ -5,6 +5,9 @@ ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
ifeq ($(ARCH),x86)
TEST_PROGS := breakpoint_test
endif
+ifeq ($(ARCH),aarch64)
+TEST_PROGS := breakpoint_test_arm64
+endif
TEST_PROGS += step_after_suspend_test
@@ -13,4 +16,4 @@ all: $(TEST_PROGS)
include ../lib.mk
clean:
- rm -fr breakpoint_test step_after_suspend_test
+ rm -fr breakpoint_test breakpoint_test_arm64 step_after_suspend_test
diff --git a/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
new file mode 100644
index 000000000000..f56331831182
--- /dev/null
+++ b/tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (C) 2016 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Original Code by Pavel Labath <test.tberghammer@gmail.com>
+ *
+ * Code modified by Pratyush Anand <panand@redhat.com>
+ * for testing different byte select for each access size.
+ *
+ */
+
+#define _GNU_SOURCE
+
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <sys/ptrace.h>
+#include <sys/param.h>
+#include <sys/uio.h>
+#include <stdint.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <elf.h>
+#include <errno.h>
+#include <signal.h>
+
+#include "../kselftest.h"
+
+static volatile uint8_t var[96] __attribute__((__aligned__(32)));
+
+static void child(int size, int wr)
+{
+ volatile uint8_t *addr = &var[32 + wr];
+
+ if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) != 0) {
+ perror("ptrace(PTRACE_TRACEME) failed");
+ _exit(1);
+ }
+
+ if (raise(SIGSTOP) != 0) {
+ perror("raise(SIGSTOP) failed");
+ _exit(1);
+ }
+
+ if ((uintptr_t) addr % size) {
+ perror("Wrong address write for the given size\n");
+ _exit(1);
+ }
+ switch (size) {
+ case 1:
+ *addr = 47;
+ break;
+ case 2:
+ *(uint16_t *)addr = 47;
+ break;
+ case 4:
+ *(uint32_t *)addr = 47;
+ break;
+ case 8:
+ *(uint64_t *)addr = 47;
+ break;
+ case 16:
+ __asm__ volatile ("stp x29, x30, %0" : "=m" (addr[0]));
+ break;
+ case 32:
+ __asm__ volatile ("stp q29, q30, %0" : "=m" (addr[0]));
+ break;
+ }
+
+ _exit(0);
+}
+
+static bool set_watchpoint(pid_t pid, int size, int wp)
+{
+ const volatile uint8_t *addr = &var[32 + wp];
+ const int offset = (uintptr_t)addr % 8;
+ const unsigned int byte_mask = ((1 << size) - 1) << offset;
+ const unsigned int type = 2; /* Write */
+ const unsigned int enable = 1;
+ const unsigned int control = byte_mask << 5 | type << 3 | enable;
+ struct user_hwdebug_state dreg_state;
+ struct iovec iov;
+
+ memset(&dreg_state, 0, sizeof(dreg_state));
+ dreg_state.dbg_regs[0].addr = (uintptr_t)(addr - offset);
+ dreg_state.dbg_regs[0].ctrl = control;
+ iov.iov_base = &dreg_state;
+ iov.iov_len = offsetof(struct user_hwdebug_state, dbg_regs) +
+ sizeof(dreg_state.dbg_regs[0]);
+ if (ptrace(PTRACE_SETREGSET, pid, NT_ARM_HW_WATCH, &iov) == 0)
+ return true;
+
+ if (errno == EIO) {
+ printf("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) "
+ "not supported on this hardware\n");
+ ksft_exit_skip();
+ }
+ perror("ptrace(PTRACE_SETREGSET, NT_ARM_HW_WATCH) failed");
+ return false;
+}
+
+static bool run_test(int size, int wr, int wp)
+{
+ int status;
+ siginfo_t siginfo;
+ pid_t pid = fork();
+ pid_t wpid;
+
+ if (pid < 0) {
+ perror("fork() failed");
+ return false;
+ }
+ if (pid == 0)
+ child(size, wr);
+
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGSTOP) {
+ printf("child did not stop with SIGSTOP\n");
+ return false;
+ }
+
+ if (!set_watchpoint(pid, MIN(size, 8), wp))
+ return false;
+
+ if (ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) {
+ perror("ptrace(PTRACE_SINGLESTEP) failed");
+ return false;
+ }
+
+ alarm(3);
+ wpid = waitpid(pid, &status, __WALL);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ alarm(0);
+ if (WIFEXITED(status)) {
+ printf("child did not single-step\t");
+ return false;
+ }
+ if (!WIFSTOPPED(status)) {
+ printf("child did not stop\n");
+ return false;
+ }
+ if (WSTOPSIG(status) != SIGTRAP) {
+ printf("child did not stop with SIGTRAP\n");
+ return false;
+ }
+ if (ptrace(PTRACE_GETSIGINFO, pid, NULL, &siginfo) != 0) {
+ perror("ptrace(PTRACE_GETSIGINFO)");
+ return false;
+ }
+ if (siginfo.si_code != TRAP_HWBKPT) {
+ printf("Unexpected si_code %d\n", siginfo.si_code);
+ return false;
+ }
+
+ kill(pid, SIGKILL);
+ wpid = waitpid(pid, &status, 0);
+ if (wpid != pid) {
+ perror("waitpid() failed");
+ return false;
+ }
+ return true;
+}
+
+static void sigalrm(int sig)
+{
+}
+
+int main(int argc, char **argv)
+{
+ int opt;
+ bool succeeded = true;
+ struct sigaction act;
+ int wr, wp, size;
+ bool result;
+
+ act.sa_handler = sigalrm;
+ sigemptyset(&act.sa_mask);
+ act.sa_flags = 0;
+ sigaction(SIGALRM, &act, NULL);
+ for (size = 1; size <= 32; size = size*2) {
+ for (wr = 0; wr <= 32; wr = wr + size) {
+ for (wp = wr - size; wp <= wr + size; wp = wp + size) {
+ printf("Test size = %d write offset = %d watchpoint offset = %d\t", size, wr, wp);
+ result = run_test(size, wr, wp);
+ if ((result && wr == wp) || (!result && wr != wp)) {
+ printf("[OK]\n");
+ ksft_inc_pass_cnt();
+ } else {
+ printf("[FAILED]\n");
+ ksft_inc_fail_cnt();
+ succeeded = false;
+ }
+ }
+ }
+ }
+
+ ksft_print_cnts();
+ if (succeeded)
+ ksft_exit_pass();
+ else
+ ksft_exit_fail();
+}
--
2.7.4
^ permalink raw reply related
* [patch] serial: stm32: fix a type issue
From: Dan Carpenter @ 2016-10-12 6:21 UTC (permalink / raw)
To: linux-arm-kernel
We store UNDEF_REG in a u8. It causes a problem in functions like
stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
Fixes: 3489187204eb ('serial: stm32: adding dma support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 41d9749..f9887cc 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -31,7 +31,7 @@ struct stm32_usart_info {
struct stm32_usart_config cfg;
};
-#define UNDEF_REG ~0
+#define UNDEF_REG 0xFF
/* Register offsets */
struct stm32_usart_info stm32f4_info = {
^ permalink raw reply related
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-10-12 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12cfb59f-f7ca-d4df-eb7f-42348e357979@samsung.com>
Hi Marek,
>Hi Sricharan,
>
>
>On 2016-10-04 19:03, Sricharan R wrote:
>> Initial post from Laurent Pinchart[1]. This is
>> series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>>
>> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> | |
>> pci_bus_add_device (device_add/driver_register)
>> | |
>> device_attach device_initial_probe
>> | |
>> __device_attach_driver __device_attach_driver
>> |
>> driver_probe_device
>> |
>> really_probe
>> |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> If the ACPI bus code follows the same, we can add acpi_dma_configure
>> at the same place as of_dma_configure.
>>
>> This series is based on the recently merged Generic DT bindings for
>> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>>
>> This time tested this with platform and pci device for probe deferral
>> and reprobe on arm64 based platform. There is an issue on the cleanup
>> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
>> device is attached to an domain in arch_teardown_dma_ops.
>> But with iommu_groups created from the iommu driver, the device is always
>> attached to a domain/default_domain. So so the WARN has to be removed/handled
>> probably.
>
>Thanks for continuing work on this feature! Your can add my:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
Thanks for testing this. So the for the below fix, the remove_device callback
gets called on the dma_ops cleanup path, so would it be easy to remove the
data for the device there ?
Regards,
Sricharan
>It works fine with Exynos SYSMMU driver, although a patch is needed to fix
>infinite loop due to list corruption (same element is added twice if master
>device fails with deferred probe):
>
>From: Marek Szyprowski <m.szyprowski@samsung.com>
>Date: Mon, 10 Oct 2016 14:22:42 +0200
>Subject: [PATCH] iommu/exynos: ensure that sysmmu is added only once to its
> master
>
>Since adding IOMMU deferred probing support, of_xlate() callback might
>be called more than once for given master device (for example it happens
>when masters device driver fails with EPROBE_DEFER), so ensure that
>SYSMMU controller is added to its master device (owner) only once.
>
>Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>---
> drivers/iommu/exynos-iommu.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
>index 30808e91b775..1525a86eb829 100644
>--- a/drivers/iommu/exynos-iommu.c
>+++ b/drivers/iommu/exynos-iommu.c
>@@ -1253,7 +1253,7 @@ static int exynos_iommu_of_xlate(struct device *dev,
> {
> struct exynos_iommu_owner *owner = dev->archdata.iommu;
> struct platform_device *sysmmu = of_find_device_by_node(spec->np);
>- struct sysmmu_drvdata *data;
>+ struct sysmmu_drvdata *data, *entry;
>
> if (!sysmmu)
> return -ENODEV;
>@@ -1271,6 +1271,10 @@ static int exynos_iommu_of_xlate(struct device *dev,
> dev->archdata.iommu = owner;
> }
>
>+ list_for_each_entry(entry, &owner->controllers, owner_node)
>+ if (entry == data)
>+ return 0;
>+
> list_add_tail(&data->owner_node, &owner->controllers);
> return 0;
> }
>--
>1.9.1
>
^ permalink raw reply
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Marcin Nowakowski @ 2016-10-12 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011133623.GE9532@arm.com>
Hi Will,
On 11.10.2016 15:36, Will Deacon wrote:
> On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote:
>> Add arch_syscall_addr for arm64 and define NR_compat_syscalls, as the
>> number of compat syscalls for arm64 exceeds the number defined by
>> NR_syscalls.
>>
>> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> ---
>> arch/arm64/include/asm/ftrace.h | 12 +-----------
>> arch/arm64/include/asm/unistd.h | 1 +
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/ftrace.c | 16 ++++++++++++++++
>> 4 files changed, 19 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
>> index caa955f..b57ff7c 100644
>> --- a/arch/arm64/include/asm/ftrace.h
>> +++ b/arch/arm64/include/asm/ftrace.h
>> @@ -41,17 +41,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
>>
>> #define ftrace_return_address(n) return_address(n)
>>
>> -/*
>> - * Because AArch32 mode does not share the same syscall table with AArch64,
>> - * tracing compat syscalls may result in reporting bogus syscalls or even
>> - * hang-up, so just do not trace them.
>> - * See kernel/trace/trace_syscalls.c
>> - *
>> - * x86 code says:
>> - * If the user really wants these, then they should use the
>> - * raw syscall tracepoints with filtering.
>> - */
>> -#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
>> +#define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP 1
>> static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
>> {
>> return is_compat_task();
>> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
>> index e78ac26..276d049 100644
>> --- a/arch/arm64/include/asm/unistd.h
>> +++ b/arch/arm64/include/asm/unistd.h
>> @@ -45,6 +45,7 @@
>> #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5)
>>
>> #define __NR_compat_syscalls 394
>> +#define NR_compat_syscalls (__NR_compat_syscalls)
>
> We may as well just define NR_compat_syscalls instead of
> __NR_compat_syscalls and move the handful of users over.
I had tried to minimise the amount of arch-specific changes here -
especially those that are not directly related to the proposed syscall
handling change. But I agree having these 2 #defines is a bit
unnecessary ...
>> diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
>> index 40ad08a..75d010f 100644
>> --- a/arch/arm64/kernel/ftrace.c
>> +++ b/arch/arm64/kernel/ftrace.c
>> @@ -176,4 +176,20 @@ int ftrace_disable_ftrace_graph_caller(void)
>> return ftrace_modify_graph_caller(false);
>> }
>> #endif /* CONFIG_DYNAMIC_FTRACE */
>> +
>> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>> +
>> +#if (defined CONFIG_FTRACE_SYSCALLS) && (defined CONFIG_COMPAT)
>> +
>> +extern const void *sys_call_table[];
>> +extern const void *compat_sys_call_table[];
>> +
>> +unsigned long __init arch_syscall_addr(int nr, bool compat)
>> +{
>> + if (compat)
>> + return (unsigned long)compat_sys_call_table[nr];
>> +
>> + return (unsigned long)sys_call_table[nr];
>> +}
>
> Do we care about the compat private syscalls (from base 0x0f0000)? We
> need to make sure that we exhibit the same behaviour as a native
> 32-bit ARM machine.
>
> Will
Tracing of such syscalls has been disabled for a long time (see
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=086ba77a6db0).
Apart from using non-contiguous numbers, they are not defined using
standard SYSCALL macros, so they do not have any metadata generated either.
My suggestion is that if you wanted those to be included in the trace
then it should be done separately from these changes.
Marcin
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Gerald Baeza @ 2016-10-12 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012062103.GS12841@mwanda>
Hi Dan and thanks for the patch
On 10/12/2016 08:21 AM, Dan Carpenter wrote:
> We store UNDEF_REG in a u8. It causes a problem in functions like
> stm32_tx_dma_complete() where we check "if (ofs->icr == UNDEF_REG)".
>
> Fixes: 3489187204eb ('serial: stm32: adding dma support')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
> index 41d9749..f9887cc 100644
> --- a/drivers/tty/serial/stm32-usart.h
> +++ b/drivers/tty/serial/stm32-usart.h
> @@ -31,7 +31,7 @@ struct stm32_usart_info {
> struct stm32_usart_config cfg;
> };
>
> -#define UNDEF_REG ~0
> +#define UNDEF_REG 0xFF
>
> /* Register offsets */
> struct stm32_usart_info stm32f4_info = {
>
Reviewed-by: Gerald Baeza <gerald.baeza@st.com>
^ permalink raw reply
* [PATCH v6 1/2] serial: xuartps: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-10-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
Changes for v6:
-Added New patch.
drivers/tty/serial/xilinx_uartps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index f37edaa..dd4c02f 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1200,6 +1200,7 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,zynqmp-uart", cdns_early_console_setup);
/**
* cdns_uart_console_write - perform write operation
@@ -1438,6 +1439,7 @@ static const struct of_device_id cdns_uart_of_match[] = {
{ .compatible = "xlnx,xuartps", },
{ .compatible = "cdns,uart-r1p8", },
{ .compatible = "cdns,uart-r1p12", .data = &zynqmp_uart_def },
+ { .compatible = "xlnx,zynqmp-uart", .data = &zynqmp_uart_def },
{}
};
MODULE_DEVICE_TABLE(of, cdns_uart_of_match);
--
2.1.1
^ permalink raw reply related
* [PATCH v6 2/2] devicetree: bindings: uart: Add new compatible string for ZynqMP
From: Nava kishore Manne @ 2016-10-12 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476258448-20483-1-git-send-email-navam@xilinx.com>
From: Nava kishore Manne <nava.manne@xilinx.com>
This patch Adds the new compatible string for ZynqMP SoC.
Signed-off-by: Nava kishore Manne <navam@xilinx.com>
---
Changes for v6:
-Added New compatiable string for ZynqMP SoC as
suggested by Rob Herring.
Changes for v5:
-Mofified the compatible session.
Changes for v4:
-Modified the ChangeLog comment.
Changes for v3:
-Added changeLog comment.
Changes for v2:
-None
Documentation/devicetree/bindings/serial/cdns,uart.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt
index a3eb154..227bb77 100644
--- a/Documentation/devicetree/bindings/serial/cdns,uart.txt
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -1,7 +1,9 @@
Binding for Cadence UART Controller
Required properties:
-- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- compatible :
+ Use "xlnx,xuartps","cdns,uart-r1p8" for Zynq-7xxx SoC.
+ Use "xlnx,zynqmp-uart","cdns,uart-r1p12" for Zynq Ultrascale+ MPSoC.
- reg: Should contain UART controller registers location and length.
- interrupts: Should contain UART controller interrupts.
- clocks: Must contain phandles to the UART clocks
--
2.1.1
^ permalink raw reply related
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-10-12 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5be99d76-a082-129b-1aa6-b6f7402ae79b@cogentembedded.com>
On Fri, Oct 07, 2016 at 07:40:34PM +0300, Sergei Shtylyov wrote:
> On 10/06/2016 12:23 AM, Sergei Shtylyov wrote:
>
> > Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
> >'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
> >the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> >seems identical to the R8A7791/Porter board. The device tree patches depend on
> >the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>
> Forgot to mention that this version causes a regression with the sh_eth
> driver (well, actually with phylib): since IRQC now gets a deferred probing,
> PHY IRQ doesn't work anymore -- phylib falls back to polling.
Is there a resolution to that problem?
^ permalink raw reply
* [PATCH v3 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-12 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010131841.GA8391@rob-hp-laptop>
On Monday 10 October 2016 06:48 PM, Rob Herring wrote:
> On Thu, Oct 06, 2016 at 10:43:52AM +0530, Mugunthan V N wrote:
>> Add documention of ti,impedance-control which can be used to
>
> Needs updating.
Oops, will update this in next version.
>
>> correct MAC impedance mismatch using phy extended registers.
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> index 5d21141..85bf945 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
>> @@ -9,6 +9,18 @@ Required properties:
>> - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
>> for applicable values
>>
>> +Optional property:
>> + - ti,min-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + minimum value (35 ohms).
>> + - ti,max-output-impedance - MAC Interface Impedance control to set
>> + the programmable output impedance to
>> + maximum value (70 ohms).
>
> Define what are valid range of values for these.
The values are already mentioned in documentation as 35/70 ohms.
Are you mentioning about the register values?
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH v3 0/11] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012080905.GD31183@verge.net.au>
On 10/12/2016 11:09 AM, Simon Horman wrote:
>>> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20161003-v4.8' tag. I'm adding the device tree support for
>>> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
>>> seems identical to the R8A7791/Porter board. The device tree patches depend on
>>> the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
>>
>> Forgot to mention that this version causes a regression with the sh_eth
>> driver (well, actually with phylib): since IRQC now gets a deferred probing,
>> PHY IRQ doesn't work anymore -- phylib falls back to polling.
>
> Is there a resolution to that problem?
Geert has posted his IRQC driver patch recently. Not sure if it was
intended for merging but it solves the issue.
MBR, Sergei
^ 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