* [PATCH] Adding Support for Coresight Components on Zynq 7000.
From: Sören Brinkmann @ 2016-09-29 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6836102-9b7e-a9d9-bad9-34b100d4ae49@supelec.fr>
Hi Muhammad,
On Thu, 2016-09-29 at 12:26:13 +0200, Muhammad Abdul WAHAB wrote:
> The Coresight components are present on the Zynq SoC but the corresponding
> device tree entries are missing. This patch adds device tree entries for
> coresight components while explaining how it was done in order to allow
> porting towards other boards easily.
>
> By adding the entries for Coresight components in the device tree: if no
> files are created in sysfile system, you need to contact the board designer
> to sort out the problem. On some boards, Coresight components are not
> powered on boot.
>
> Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
> ---
> The documentation file was very helpful
> (Documentation/devicetree/bindings/arm/coresight.txt). However, few details
> can be added to make it more clear for beginners.
>
> Things to modify in device tree when changing the board are mainly:
>
> - address
> - `clocks` field
> - some references in other entries may be missing (e.g. for `CPU` field in
> ETM/PTM component, references need to be created)
>
> Furthermore, the `reg` field should be adapted according to
> `#address-cells` and `#size-cells`. It may appear obvious, not for
> beginners.
>
> ## Testing
>
> The trace sink components need to be enabled by accessing through sysfile
> system.
>
> echo 1 > /sys/bus/coresight/devices/@addr.etb/enable\_sink
>
> Then enable the CS source component:
>
> echo 1 > /sys/bus/coresight/devices/@addr.ptm/enable\_source
>
> By default, CS Source components are configured to trace the kernel.
>
> Then the trace can be read by dumping ETB.
>
> dd if=/dev/@addr.etb of=trace_kernel.bin
>
> The trace can be visualized by:
>
> hexdump -C trace_kernel.bin
>
> Or stored using:
>
> hexdump -C trace_kernel.bin > trace_kernel.txt
>
> The trace need to be decoded to be readable. All these above steps can now
> be performed with Perf Library which was not available at the time I was
> playing with DT entries.
I'm curious, did you test that with external debug tools. I have the
feeling the kernel using the debug HW could interfere with JTAG
debuggers, external trace tools, etc.
>
> --- linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi.orig 2016-07-24
> 21:23:50.000000000 +0200
> +++ linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi 2016-09-28
> 19:13:52.651881000 +0200
> @@ -363,5 +363,159 @@
> reg = <0xf8005000 0x1000>;
> timeout-sec = <10>;
> };
> +
> + etb at F8801000 {
> + compatible = "arm,coresight-etb10", "arm,primecell";
> + reg = <0xf8801000 0x1000>;
> + coresight-default-sink;
> + clocks = <&clkc 47>;
> + clock-names = "apb_pclk";
> +
> + port {
> +
> + endpoint at 0 {
> + slave-mode;
> + remote-endpoint = <0x8>;
Use labels please.
> + linux,phandle = <0xd>;
> + phandle = <0xd>;
Do these phandle properties need to be here?
> + };
> + };
> + };
> +
> + tpiu at F8803000 {
> + compatible = "arm,coresight-tpiu", "arm,primecell";
> + reg = <0xf8803000 0x1000>;
> + clocks = <&clkc 47>, <&clkc 16>;
I'm not sure this is correct for every setup. Sorry, that I don't recall
all the details, I haven't used tracing in a long time. But I guess this
clock is configurable as you're referring an fclk here. The other thing
that makes me a little suspicious is, that nothing in here uses the
'dbg_trc' clock that the clock controller provides.
> + clock-names = "apb_pclk", "fclk1";
Those names (at least fclk1) is not a good name for tpiu to identify
it's input. fclk1 is a zynq-specific clock, and as mentioned above, it
seems likely that this could easily become a different one. The
clock-names are meant to identify an input from the consumer's
perspective. The correct names should be documented in the DT binding.
> + clock-frequency=<0xee6b280>;
I cannot find this property in the binding.
> +
> + port {
> +
> + endpoint at 0 {
> + slave-mode;
> + remote-endpoint = <0x9>;
> + linux,phandle = <0xe>;
> + phandle = <0xe>;
> + };
> + };
> + };
> +
> + funnel at F8804000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0xf8804000 0x1000>;
> + clocks = <&clkc 47>;
> + clock-names = "apb_pclk";
> +
> + ports {
> + #address-cells = <0x1>;
> + #size-cells = <0x0>;
> +
> + port at 0 {
> + reg = <0x0>;
> +
> + endpoint {
> + remote-endpoint = <0xa>;
> + linux,phandle = <0xf>;
> + phandle = <0xf>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0x0>;
> +
> + endpoint {
> + slave-mode;
> + remote-endpoint = <0xb>;
> + linux,phandle = <0x11>;
> + phandle = <0x11>;
> + };
> + };
> +
> + port at 2 {
> + reg = <0x1>;
> +
> + endpoint {
> + slave-mode;
> + remote-endpoint = <0xc>;
> + linux,phandle = <0x13>;
> + phandle = <0x13>;
> + };
> + };
> + };
> + };
> +
> + replicator {
> + compatible = "arm,coresight-replicator";
> +
> + ports {
> + #address-cells = <0x1>;
> + #size-cells = <0x0>;
> +
> + port at 0 {
> + reg = <0x0>;
> +
> + endpoint {
> + remote-endpoint = <0xd>;
> + linux,phandle = <0x8>;
> + phandle = <0x8>;
> + };
> + };
> +
> + port at 1 {
> + reg = <0x1>;
> +
> + endpoint {
> + remote-endpoint = <0xe>;
> + linux,phandle = <0x9>;
> + phandle = <0x9>;
> + };
> + };
> +
> + port at 2 {
> + reg = <0x0>;
> +
> + endpoint {
> + slave-mode;
> + remote-endpoint = <0xf>;
> + linux,phandle = <0xa>;
> + phandle = <0xa>;
> + };
> + };
> + };
> + };
> +
> + ptm0 at F889C000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0xf889c000 0x1000>;
> + cpu = <0x10>;
> + clocks = <&clkc 47>;
> + clock-names = "apb_pclk";
> +
> + port {
> +
> + endpoint {
> + remote-endpoint = <0x11>;
> + linux,phandle = <0xb>;
> + phandle = <0xb>;
> + };
> + };
> + };
> +
> + ptm1 at F889D000 {
> + compatible = "arm,coresight-etm3x", "arm,primecell";
> + reg = <0xf889d000 0x1000>;
> + cpu = <0x12>;
> + clocks = <&clkc 47>;
> + clock-names = "apb_pclk";
> +
> + port {
> +
> + endpoint {
> + remote-endpoint = <0x13>;
> + linux,phandle = <0xc>;
> + phandle = <0xc>;
> + };
> + };
> + };
> };
> };
I think nodes were ordered alphabetically in our DTs.
S?ren
^ permalink raw reply
* [PATCH] arm64: make rpm failed due to incorrect path to Image.gz
From: Vadim Lomovtsev @ 2016-09-29 14:32 UTC (permalink / raw)
To: linux-arm-kernel
The "make rpm" and "make rpm-pkg" commands for arm64 platform are broken
due to rpmbuild couldn't find Image.gz file at default location (which
is kernel src root):
cp: cannot stat 'Image.gz': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.ocFBmP (%install)
While the correct path to arm64 kernel image file
is "arch/arm64/boot/Image.gz".
The exact file name (Image.gz) is stored at KBUILD_IMAGE variable
and read by rpmbuild with "make image_name" command at
install phase after kernel build is complete.
Accordingly to Michal's Marek comment it is necesary
that the KBUILD_IMAGE variable value has to be set
accordingly to point to actual file and thus fix that issue.
Since the KBUILD_IMAGE variable is used in general cases of
build we need to prevent other build types breakage by changing it.
The solution is to add to arch/arm64/Makefie extra target "image_name"
with dependency "KBUILD_IMAGE:=<proper path to Image.gz file>".
Thus it will allow to set proper path to Image.gz file only for
the "image_name" build target and this exact value will be picked up
while rpm build install phase.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
---
arch/arm64/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index ab51aed..09926d3 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -101,6 +101,8 @@ all: $(KBUILD_IMAGE) $(KBUILD_DTBS)
boot := arch/arm64/boot
+image_name: KBUILD_IMAGE :=$(boot)/$(KBUILD_IMAGE)
+
Image: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
--
1.8.3.1
^ permalink raw reply related
* [PATCH] clk: mvebu: armada-37xx-periph: Fix the clock provider registration
From: Gregory CLEMENT @ 2016-09-29 14:28 UTC (permalink / raw)
To: linux-arm-kernel
While trying using a peripheral clock on a driver, I saw that the clock
pointer returned by the provider was NULL.
The problem was a missing indirection. It was the pointer stored in the
hws array which needed to be updated not the value it contains.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/clk/mvebu/armada-37xx-periph.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c
index 45905fc0d75b..d5dfbad4ceab 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -305,7 +305,7 @@ static const struct of_device_id armada_3700_periph_clock_of_match[] = {
};
static int armada_3700_add_composite_clk(const struct clk_periph_data *data,
void __iomem *reg, spinlock_t *lock,
- struct device *dev, struct clk_hw *hw)
+ struct device *dev, struct clk_hw **hw)
{
const struct clk_ops *mux_ops = NULL, *gate_ops = NULL,
*rate_ops = NULL;
@@ -353,13 +353,13 @@ static int armada_3700_add_composite_clk(const struct clk_periph_data *data,
}
}
- hw = clk_hw_register_composite(dev, data->name, data->parent_names,
+ *hw = clk_hw_register_composite(dev, data->name, data->parent_names,
data->num_parents, mux_hw,
mux_ops, rate_hw, rate_ops,
gate_hw, gate_ops, CLK_IGNORE_UNUSED);
- if (IS_ERR(hw))
- return PTR_ERR(hw);
+ if (IS_ERR(*hw))
+ return PTR_ERR(*hw);
return 0;
}
@@ -400,7 +400,7 @@ static int armada_3700_periph_clock_probe(struct platform_device *pdev)
spin_lock_init(&driver_data->lock);
for (i = 0; i < num_periph; i++) {
- struct clk_hw *hw = driver_data->hw_data->hws[i];
+ struct clk_hw **hw = &driver_data->hw_data->hws[i];
if (armada_3700_add_composite_clk(&data[i], reg,
&driver_data->lock, dev, hw))
--
2.9.3
^ permalink raw reply related
* [PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type
From: Lorenzo Pieralisi @ 2016-09-29 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909142343.13314-2-lorenzo.pieralisi@arm.com>
Hi Rafael,
On Fri, Sep 09, 2016 at 03:23:30PM +0100, Lorenzo Pieralisi wrote:
> On systems booting with a device tree, every struct device is
> associated with a struct device_node, that represents its DT
> representation. The device node can be used in generic kernel
> contexts (eg IRQ translation, IOMMU streamid mapping), to
> retrieve the properties associated with the device and carry
> out kernel operation accordingly. Owing to the 1:1 relationship
> between the device and its device_node, the device_node can also
> be used as a look-up token for the device (eg looking up a device
> through its device_node), to retrieve the device in kernel paths
> where the device_node is available.
>
> On systems booting with ACPI, the same abstraction provided by
> the device_node is required to provide look-up functionality.
>
> Therefore, mirroring the approach implemented in the IRQ domain
> kernel layer, this patch adds an additional fwnode type FWNODE_IOMMU.
>
> This patch also implements a glue kernel layer that allows to
> allocate/free FWNODE_IOMMU fwnode_handle structures and associate
> them with IOMMU devices.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> ---
> include/linux/fwnode.h | 1 +
> include/linux/iommu.h | 25 +++++++++++++++++++++++++
> 2 files changed, 26 insertions(+)
>
> diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> index 8516717..6e10050 100644
> --- a/include/linux/fwnode.h
> +++ b/include/linux/fwnode.h
> @@ -19,6 +19,7 @@ enum fwnode_type {
> FWNODE_ACPI_DATA,
> FWNODE_PDATA,
> FWNODE_IRQCHIP,
> + FWNODE_IOMMU,
This patch provides groundwork for this series and it is key for
the rest of it, basically the point here is that we need a fwnode
to differentiate platform devices created out of static ACPI tables
entries (ie IORT), that represent IOMMU components.
The corresponding device is not an ACPI device (I could fabricate one as
it is done for other static tables entries eg FADT power button, but I
do not necessarily see the reason for doing that given that all we need
the fwnode for is a token identifier), so FWNODE_ACPI does not apply
here.
Please let me know if it is reasonable how I sorted this out (it
is basically identical to IRQCHIP, just another enum entry), the
remainder of the code depends on this.
Thanks !
Lorenzo
> };
>
> struct fwnode_handle {
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index a35fb8b..6456528 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -38,6 +38,7 @@ struct bus_type;
> struct device;
> struct iommu_domain;
> struct notifier_block;
> +struct fwnode_handle;
>
> /* iommu fault flags */
> #define IOMMU_FAULT_READ 0x0
> @@ -543,4 +544,28 @@ static inline void iommu_device_unlink(struct device *dev, struct device *link)
>
> #endif /* CONFIG_IOMMU_API */
>
> +/* IOMMU fwnode handling */
> +static inline bool is_fwnode_iommu(struct fwnode_handle *fwnode)
> +{
> + return fwnode && fwnode->type == FWNODE_IOMMU;
> +}
> +
> +static inline struct fwnode_handle *iommu_alloc_fwnode(void)
> +{
> + struct fwnode_handle *fwnode;
> +
> + fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
> + fwnode->type = FWNODE_IOMMU;
> +
> + return fwnode;
> +}
> +
> +static inline void iommu_free_fwnode(struct fwnode_handle *fwnode)
> +{
> + if (WARN_ON(!is_fwnode_iommu(fwnode)))
> + return;
> +
> + kfree(fwnode);
> +}
> +
> #endif /* __LINUX_IOMMU_H */
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH] dmaengine: pxa_dma: remove unused function
From: Baoyou Xie @ 2016-09-29 13:09 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/dma/pxa_dma.c:1525:5: warning: no previous prototype for 'pxad_toggle_reserved_channel' [-Wmissing-prototypes]
In fact, this function is called by no one, so this patch removes it.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/dma/pxa_dma.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 3f56f9c..7d9b1cc 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -1522,15 +1522,6 @@ bool pxad_filter_fn(struct dma_chan *chan, void *param)
}
EXPORT_SYMBOL_GPL(pxad_filter_fn);
-int pxad_toggle_reserved_channel(int legacy_channel)
-{
- if (legacy_unavailable & (BIT(legacy_channel)))
- return -EBUSY;
- legacy_reserved ^= BIT(legacy_channel);
- return 0;
-}
-EXPORT_SYMBOL_GPL(pxad_toggle_reserved_channel);
-
module_platform_driver(pxad_driver);
MODULE_DESCRIPTION("Marvell PXA Peripheral DMA Driver");
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] Add DMA support for ti_am335x_adc driver
From: Mugunthan V N @ 2016-09-29 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22588f2d-d0de-7911-35ed-92094f7dd28d@kernel.org>
On Sunday 25 September 2016 03:11 PM, Jonathan Cameron wrote:
> On 21/09/16 17:11, Mugunthan V N wrote:
>> > The ADC has a 64 work depth fifo length which holds the ADC data
>> > till the CPU reads. So when a user program needs a large ADC data
>> > to operate on, then it has to do multiple reads to get its
>> > buffer. Currently if the application asks for 4 samples per
>> > channel with all 8 channels are enabled, kernel can provide only
>> > 3 samples per channel when all 8 channels are enabled (logs at
>> > [1]). So with DMA support user can request for large number of
>> > samples at a time (logs at [2]).
>> >
>> > Tested the patch on AM437x-gp-evm and AM335x Boneblack with the
>> > patch [3] to enable ADC and pushed a branch for testing [4]
>> >
>> > [1] - http://pastebin.ubuntu.com/23211490/
>> > [2] - http://pastebin.ubuntu.com/23211492/
>> > [3] - http://pastebin.ubuntu.com/23211494/
>> > [4] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git iio-dma
> Just curious. How fast is the ADC sampling at in these? Never that
> obvious for this driver!
>
> I'm also curious as to whether you started to hit the limits of the
> kfifo based interface. Might be worth considering adding alternative
> support for the dma buffers interface which is obviously much lower
> overhead.
>
> Good to have this work prior to that as the kfifo stuff is somewhat
> easier to use.
Currently ADC clock is 3MHz, which can produce a data rate of 225KBps
per channel with no open delay and no averaging of samples. So when all
8 Channels are enables the data rate will be 1.75MBps
ADC can be operated at 24MHz, which can generate a data rate of 28MBps
with all 8 channels enabled and no open delay and averaging, but our
target is to get 800K samples per second per channel which has a data
rate of 12.5MBps
I think with this data rate, DMA will be the best option to implement
without any data loss and less cpu overload to read the ADC samples.
Regards
Mugunthan V N
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Venkatesh Vivekanandan @ 2016-09-29 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5dc4d096-d580-900c-5750-38e0db1ccbce@arm.com>
On Thu, Sep 29, 2016 at 2:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 29/09/16 09:49, Rabin Vincent wrote:
>>
>> On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
>
> [...]
>
>>> Thanks you for reporting this Vankatesh,
>>>
>>> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
>>> to test with.
>>
>>
>> I've seen this too, on other platforms. This should fix it:
>>
>> 8<-----------
>> From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
>> From: Rabin Vincent <rabinv@axis.com>
>> Date: Tue, 30 Aug 2016 08:54:21 +0200
>> Subject: [PATCH] coresight: check for NULL child_name
>>
>> Connection child names associated to ports can sometimes be NULL, which
>> is the case when booting a system on QEMU or when the Coresight power
>> domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
>> string in coresight_name_match()") fixed one place to handle this but
>> the same check is needed in coresight_orphan_match() to prevent a crash
>> there.
>>
>
> Thanks Rabin, we have exact same fix in linux-next already.
Thanks Rabin/Sudeep for pointing out the patch. It is booting now with
coresight enabled.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-29 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbKxJeSZYsCwVWYbVosZUK+FfBq1ytrpRUNpbH+kM6Ow6Q@mail.gmail.com>
Hi,
On Tue, Sep 27, 2016 at 10:42:09AM -0400, Sean Paul wrote:
> As an aside, it seems like (from the diff, I haven't looked at the
> code) the bridge_pre_enable and bridge_post_disable calls are missing,
> and the enable/disable calls are in the wrong place.
Actually, I don't even think that's necessary. The atomic helpers
already call drm_bridge_pre_enable and drm_bridge_enable at the right
time. So I guess the proper fix would be to just remove the driver's
call to drm_bridge_enable.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160929/7c5646a7/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: KVM: Take S1 walks into account when determining S2 write faults
From: Will Deacon @ 2016-09-29 11:37 UTC (permalink / raw)
To: linux-arm-kernel
The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was
generated by a read or a write instruction. For stage 2 data aborts
generated by a stage 1 translation table walk (i.e. the actual page
table access faults at EL2), the WnR bit therefore reports whether the
instruction generating the walk was a load or a store, *not* whether the
page table walker was reading or writing the entry.
For page tables marked as read-only at stage 2 (e.g. due to KSM merging
them with the tables from another guest), this could result in livelock,
where a page table walk generated by a load instruction attempts to
set the access flag in the stage 1 descriptor, but fails to trigger
CoW in the host since only a read fault is reported.
This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to
take into account stage 2 faults in stage 1 walks. Since DBM cannot be
disabled at EL2 for CPUs that implement it, we assume that these faults
are always causes by writes, avoiding the livelock situation at the
expense of occasional, spurious CoWs.
We could, in theory, do a bit better by checking the guest TCR
configuration and inspecting the page table to see why the PTE faulted.
However, I doubt this is measurable in practice, and the threat of
livelock is real.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Julien Grall <julien.grall@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/kvm_emulate.h | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 4cdeae3b17c6..948a9a8a9297 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -167,11 +167,6 @@ static inline bool kvm_vcpu_dabt_isvalid(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_ISV);
}
-static inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
-{
- return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR);
-}
-
static inline bool kvm_vcpu_dabt_issext(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SSE);
@@ -192,6 +187,12 @@ static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
}
+static inline bool kvm_vcpu_dabt_iswrite(const struct kvm_vcpu *vcpu)
+{
+ return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WNR) ||
+ kvm_vcpu_dabt_iss1tw(vcpu); /* AF/DBM update */
+}
+
static inline bool kvm_vcpu_dabt_is_cm(const struct kvm_vcpu *vcpu)
{
return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
--
2.1.4
^ permalink raw reply related
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Jisheng Zhang @ 2016-09-29 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929110714.GF28107@nuc-i3427.alporthouse.com>
On Thu, 29 Sep 2016 12:07:14 +0100 Chris Wilson wrote:
> On Thu, Sep 29, 2016 at 04:28:08PM +0800, Jisheng Zhang wrote:
> > On Thu, 29 Sep 2016 09:18:18 +0100 Chris Wilson wrote:
> >
> > > On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> > > > On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> > > > a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> > > > awfully bad for STB. And the ftrace log also shows __free_vmap_area
> > > > contributes most latency now. I noticed that Joel mentioned the same
> > > > issue[1] on x86 platform and gave two solutions, but it seems no patch
> > > > is sent out for this purpose.
> > > >
> > > > This patch adopts Joel's first solution, but I use 16MB per core
> > > > rather than 8MB per core for the number of lazy_max_pages. After this
> > > > patch, the preemptoff tracer reports a max 6455us latency, reduced to
> > > > 1/4 of original result.
> > >
> > > My understanding is that
> > >
> > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > > index 91f44e78c516..3f7c6d6969ac 100644
> > > --- a/mm/vmalloc.c
> > > +++ b/mm/vmalloc.c
> > > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> > > static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > > int sync, int force_flush)
> > > {
> > > - static DEFINE_SPINLOCK(purge_lock);
> > > struct llist_node *valist;
> > > struct vmap_area *va;
> > > struct vmap_area *n_va;
> > > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > > * should not expect such behaviour. This just simplifies locking for
> > > * the case that isn't actually used at the moment anyway.
> > > */
> > > - if (!sync && !force_flush) {
> > > - if (!spin_trylock(&purge_lock))
> > > - return;
> > > - } else
> > > - spin_lock(&purge_lock);
> > > -
> > > if (sync)
> > > purge_fragmented_blocks_allcpus();
> > >
> > > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > > __free_vmap_area(va);
> > > spin_unlock(&vmap_area_lock);
> >
> > Hi Chris,
> >
> > Per my test, the bottleneck now is __free_vmap_area() over the valist, the
> > iteration is protected with spinlock vmap_area_lock. So the larger lazy max
> > pages, the longer valist, the bigger the latency.
> >
> > So besides above patch, we still need to remove vmap_are_lock or replace with
> > mutex.
>
> Or follow up with
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 3f7c6d6969ac..67b5475f0b0a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -656,8 +656,10 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>
> if (nr) {
> spin_lock(&vmap_area_lock);
> - llist_for_each_entry_safe(va, n_va, valist, purge_list)
> + llist_for_each_entry_safe(va, n_va, valist, purge_list) {
> __free_vmap_area(va);
> + cond_resched_lock(&vmap_area_lock);
oh, great! This seems works fine. I'm not sure there's any side effect or
performance regression, but this patch plus previous purge_lock removing do
addressed my problem.
Thanks,
Jisheng
> + }
> spin_unlock(&vmap_area_lock);
> }
> }
>
> ?
> -Chris
>
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-09-29 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929162808.745c869b@xhacker>
On Thu, Sep 29, 2016 at 04:28:08PM +0800, Jisheng Zhang wrote:
> On Thu, 29 Sep 2016 09:18:18 +0100 Chris Wilson wrote:
>
> > On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> > > On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> > > a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> > > awfully bad for STB. And the ftrace log also shows __free_vmap_area
> > > contributes most latency now. I noticed that Joel mentioned the same
> > > issue[1] on x86 platform and gave two solutions, but it seems no patch
> > > is sent out for this purpose.
> > >
> > > This patch adopts Joel's first solution, but I use 16MB per core
> > > rather than 8MB per core for the number of lazy_max_pages. After this
> > > patch, the preemptoff tracer reports a max 6455us latency, reduced to
> > > 1/4 of original result.
> >
> > My understanding is that
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 91f44e78c516..3f7c6d6969ac 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> > static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > int sync, int force_flush)
> > {
> > - static DEFINE_SPINLOCK(purge_lock);
> > struct llist_node *valist;
> > struct vmap_area *va;
> > struct vmap_area *n_va;
> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > * should not expect such behaviour. This just simplifies locking for
> > * the case that isn't actually used at the moment anyway.
> > */
> > - if (!sync && !force_flush) {
> > - if (!spin_trylock(&purge_lock))
> > - return;
> > - } else
> > - spin_lock(&purge_lock);
> > -
> > if (sync)
> > purge_fragmented_blocks_allcpus();
> >
> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > __free_vmap_area(va);
> > spin_unlock(&vmap_area_lock);
>
> Hi Chris,
>
> Per my test, the bottleneck now is __free_vmap_area() over the valist, the
> iteration is protected with spinlock vmap_area_lock. So the larger lazy max
> pages, the longer valist, the bigger the latency.
>
> So besides above patch, we still need to remove vmap_are_lock or replace with
> mutex.
Or follow up with
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3f7c6d6969ac..67b5475f0b0a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -656,8 +656,10 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
if (nr) {
spin_lock(&vmap_area_lock);
- llist_for_each_entry_safe(va, n_va, valist, purge_list)
+ llist_for_each_entry_safe(va, n_va, valist, purge_list) {
__free_vmap_area(va);
+ cond_resched_lock(&vmap_area_lock);
+ }
spin_unlock(&vmap_area_lock);
}
}
?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply related
* [PATCH v3 3/7] i2c: bcm2835: Use dev_dbg logging on transfer errors
From: Martin Sperl @ 2016-09-29 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475085056-5205-4-git-send-email-noralf@tronnes.org>
On 28.09.2016, at 19:50, Noralf Tr?nnes <noralf@tronnes.org> wrote:
>
> Writing to an AT24C32 generates on average 2x i2c transfer errors per
> 32-byte page write. Which amounts to a lot for a 4k write. This is due
> to the fact that the chip doesn't respond during it's internal write
> cycle when the at24 driver tries and retries the next write.
> Only a handful drivers use dev_err() on transfer error, so switch to
> dev_dbg() instead.
>
> Signed-off-by: Noralf Tr?nnes <noralf@tronnes.org>
Reviewed-by: Martin Sperl <kernel@martin.sperl.org>
^ permalink raw reply
* [PATCH v2] MAINTAINERS: add myself as Marvell berlin SoC maintainer
From: Jisheng Zhang @ 2016-09-29 10:51 UTC (permalink / raw)
To: linux-arm-kernel
I would like to take maintainership for Marvell berlin SoCs.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b003d0c..3dfb8c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1410,6 +1410,7 @@ F: drivers/cpufreq/mvebu-cpufreq.c
F: arch/arm/configs/mvebu_*_defconfig
ARM/Marvell Berlin SoC support
+M: Jisheng Zhang <jszhang@marvell.com>
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
--
2.9.3
^ permalink raw reply related
* [PATCH 00/10] ARM: dts: berlin: fix dtc warnings
From: Jisheng Zhang @ 2016-09-29 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57EC1CA5.2030102@gmail.com>
Hi Sebastian,
On Wed, 28 Sep 2016 21:40:21 +0200 Sebastian Hesselbarth wrote:
> On 06.09.2016 10:40, Jisheng Zhang wrote:
> > This is a clean up series to fix berlin arm platforms dtc warnings.
> > Firstly we remove skeleton.dtsi inclusion. Then add missing unit name
> > of /soc node and /memory node. Lastly, we fix regulators' name
> >
> > Jisheng Zhang (10):
> > ARM: dts: berlin2q: Remove skeleton.dtsi inclusion
> > ARM: dts: berlin2cd: Remove skeleton.dtsi inclusion
> > ARM: dts: berlin2: Remove skeleton.dtsi inclusion
> > ARM: dts: berlin2q: Add missing unit name to /soc node
> > ARM: dts: berlin2cd: Add missing unit name to /soc node
> > ARM: dts: berlin2: Add missing unit name to /soc node
> > ARM: dts: berlin2q-marvell-dmp: add missing unit name to /memory node
> > ARM: dts: chromecast: add missing unit name to /memory node
>
> Jisheng,
>
> Applied the 8 patches above.
>
> > ARM: dts: sony-nsz-gs7: add missing unit name to /memory node
>
> I didn't receive this one and could not find it online.
> I recreated the patch by using the chromecast patch above, so
> applied.
>
> > ARM: dts: berlin2q-marvell-dmp: fix regulators' name
>
> I have no clue what it should be fixed to.
DTC will complain with W=1:
Warning (unit_address_vs_reg): Node /regulators/regulator at 0 has a unit
name, but no reg property
This patch tries to fix that warning.
Thanks,
Jisheng
>
> Sebastian
>
> > arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 +-
> > arch/arm/boot/dts/berlin2.dtsi | 5 +++--
> > arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
> > arch/arm/boot/dts/berlin2cd.dtsi | 5 +++--
> > arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 12 ++++++------
> > arch/arm/boot/dts/berlin2q.dtsi | 6 +++---
> > 6 files changed, 17 insertions(+), 15 deletions(-)
> >
>
^ permalink raw reply
* [PATCH V5 4/4] dts/imx6q-b850v3: Use GE B850v3 LVDS/DP++ Bridge
From: Shawn Guo @ 2016-09-29 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <137a-57e8dc00-1-42b5770@58989149>
On Mon, Sep 26, 2016 at 09:27:59AM +0100, Peter Senna Tschudin wrote:
> Patch 1/4 is already on linux-next, but what about this one? Ping?
Ping me after driver part (patch #3) lands on mainline.
Shawn
^ permalink raw reply
* [PATCH] MAINTAINERS: add myself as Marvell berlin SoC co-maintainers
From: Sebastian Hesselbarth @ 2016-09-29 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929065514.2784-1-jszhang@marvell.com>
On 09/29/2016 08:55 AM, Jisheng Zhang wrote:
> I would like to help maintaining Marvell berlin SoCs.
NAK. ;)
Let's face it, you'd be lucky if _I_ can co-maintain berlin. So,
let's be honest and describe it as it will be:
You'll be maintaining berlin and both the Commit msg and the order
of the E-mails below should represent that.
Thanks for taking over and if you reword the Patch, feel free to
add my
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Sebastian
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b003d0c..b1e5243 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1411,6 +1411,7 @@ F: arch/arm/configs/mvebu_*_defconfig
>
> ARM/Marvell Berlin SoC support
> M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> +M: Jisheng Zhang <jszhang@marvell.com>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-berlin/
>
^ permalink raw reply
* [PATCH] Adding missing features of Coresight PTM components
From: Muhammad Abdul WAHAB @ 2016-09-29 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In the current driver for Coresight components, two features of PTM
components are missing:
1. Branch Broadcasting (present also in ETM but called Branch Output)
2. Return Stack (only present in PTM v1.0 and PTMv1.1)
These features can be added simply to the code using `mode` field of
`etm_config` struct.
### Modifications in coresight-etm.h
Two defines are added in register definition part of `coresight_etm.h` file
that corresponds to the bitfield of these options. Two defines for mode
field are added as well in the same file. The `ETM_MODE_ALL` field is
modified accordingly.
### Modifs in coresight-etm3x-sysfs.c
As the return stack feature is only available in PTM components, a test is
made to make sure that for ETM components, this part is never executed.
In addition, these two options (Branch Broadcasting and Return Stack) must
not be enabled at the same time because the obtained trace is unpredictable
in this case (as described in
[PFT architecture v1.1](https://goo.gl/lZ72R1)). For now, a warning is
shown to alert user that the behavior is unpredictable. However, only one
option could be allowed to trace. The user need to change configuration
of PTM.
To enable these features, the correct value should be written in `mode`
file. The values are :
1. Branch Broadcasting (1 << 5)
2. Return Stack (1 << 6)
Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
#### Purpose
1. **Branch Broadcast** : The branch broadcast feature is present in ETM
components as well and is called Branch output. It allows to retrieve
addresses for direct branch addresses alongside the indirect branch
addresses. For example, it could be useful in cases when tracing without
source code.
2. **Return Stack** : The return stack option allows to retrieve the return
addresses of function calls. It can be useful to avoid CRA
(Code Reuse Attacks) by keeping a shadowstack.
### Testing
The trace sink components need to be enabled by accessing through sys file
system.
echo 1 > /sys/bus/coresight/devices/@addr.etb/enable\_sink
Then enable the CS source component:
echo 1 > /sys/bus/coresight/devices/@addr.ptm/enable\_source
By default, CS Source components are configured to trace the kernel.
Then the trace can be read by dumping ETB.
dd if=/dev/@addr.etb of=trace_kernel.bin
The trace can be visualized by
hexdump -C trace_kernel.bin
Or stored using
hexdump -C trace_kernel.bin > trace_kernel.txt
The trace need to be decoded to be readable.All these above steps can now
be performed with Perf Library which was not available at the time I was
playing with DT entries.
diff -uprN -X linux-4.7-vanilla/Documentation/dontdiff
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
linux-4.7/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
---
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
2016-07-24 21:23:50.000000000 +0200
+++ linux-4.7/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
2016-09-28 15:36:39.886542702 +0200
@@ -145,7 +145,7 @@ static ssize_t mode_store(struct device
goto err_unlock;
}
config->ctrl |= ETMCR_STALL_MODE;
- } else
+ } else
config->ctrl &= ~ETMCR_STALL_MODE;
if (config->mode & ETM_MODE_TIMESTAMP) {
@@ -163,6 +163,20 @@ static ssize_t mode_store(struct device
else
config->ctrl &= ~ETMCR_CTXID_SIZE;
+ if (config->mode & ETM_MODE_BBROAD)
+ config->ctrl |= ETMCR_BRANCH_BROADCAST;
+ else
+ config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
+
+ if (drvdata->arch == (PFT_ARCH_V1_0 | PFT_ARCH_V1_1)) {
+ if (config->mode & ETM_MODE_RET_STACK) {
+ if (config->mode & ETM_MODE_BBROAD)
+ dev_warn(drvdata->dev, "behavior is unpredictable\n");
+ config->ctrl |= ETMCR_RETURN_STACK_EN;
+ } else
+ config->ctrl &= ~ETMCR_RETURN_STACK_EN;
+ }
+
if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
etm_config_trace_mode(config);
diff -uprN -X linux-4.7-vanilla/Documentation/dontdiff
linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm.h
linux-4.7/drivers/hwtracing/coresight/coresight-etm.h
--- linux-4.7-vanilla/drivers/hwtracing/coresight/coresight-etm.h
2016-07-24 21:23:50.000000000 +0200
+++ linux-4.7/drivers/hwtracing/coresight/coresight-etm.h 2016-09-28
15:35:59.862544418 +0200
@@ -89,11 +89,13 @@
/* ETMCR - 0x00 */
#define ETMCR_PWD_DWN BIT(0)
#define ETMCR_STALL_MODE BIT(7)
+#define ETMCR_BRANCH_BROADCAST BIT(8)
#define ETMCR_ETM_PRG BIT(10)
#define ETMCR_ETM_EN BIT(11)
#define ETMCR_CYC_ACC BIT(12)
#define ETMCR_CTXID_SIZE (BIT(14)|BIT(15))
#define ETMCR_TIMESTAMP_EN BIT(28)
+#define ETMCR_RETURN_STACK_EN BIT(29) /* PTM v1.0 & PTM v1.1 */
/* ETMCCR - 0x04 */
#define ETMCCR_FIFOFULL BIT(23)
/* ETMPDCR - 0x310 */
@@ -110,8 +112,11 @@
#define ETM_MODE_STALL BIT(2)
#define ETM_MODE_TIMESTAMP BIT(3)
#define ETM_MODE_CTXID BIT(4)
+#define ETM_MODE_BBROAD BIT(5)
+#define ETM_MODE_RET_STACK BIT(6)
#define ETM_MODE_ALL (ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+ ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
ETM_MODE_EXCL_USER)
^ permalink raw reply
* [PATCH] Adding Support for Coresight Components on Zynq 7000.
From: Muhammad Abdul WAHAB @ 2016-09-29 10:26 UTC (permalink / raw)
To: linux-arm-kernel
The Coresight components are present on the Zynq SoC but the corresponding
device tree entries are missing. This patch adds device tree entries for
coresight components while explaining how it was done in order to allow
porting towards other boards easily.
By adding the entries for Coresight components in the device tree: if no
files are created in sysfile system, you need to contact the board designer
to sort out the problem. On some boards, Coresight components are not
powered on boot.
Signed-off-by: Muhammad Abdul Wahab <muhammadabdul.wahab@centralesupelec.fr>
---
The documentation file was very helpful
(Documentation/devicetree/bindings/arm/coresight.txt). However, few details
can be added to make it more clear for beginners.
Things to modify in device tree when changing the board are mainly:
- address
- `clocks` field
- some references in other entries may be missing (e.g. for `CPU` field in
ETM/PTM component, references need to be created)
Furthermore, the `reg` field should be adapted according to
`#address-cells` and `#size-cells`. It may appear obvious, not for
beginners.
## Testing
The trace sink components need to be enabled by accessing through sysfile
system.
echo 1 > /sys/bus/coresight/devices/@addr.etb/enable\_sink
Then enable the CS source component:
echo 1 > /sys/bus/coresight/devices/@addr.ptm/enable\_source
By default, CS Source components are configured to trace the kernel.
Then the trace can be read by dumping ETB.
dd if=/dev/@addr.etb of=trace_kernel.bin
The trace can be visualized by:
hexdump -C trace_kernel.bin
Or stored using:
hexdump -C trace_kernel.bin > trace_kernel.txt
The trace need to be decoded to be readable. All these above steps can now
be performed with Perf Library which was not available at the time I was
playing with DT entries.
--- linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi.orig 2016-07-24
21:23:50.000000000 +0200
+++ linux-4.7/arch/arm/boot/dts/zynq-7000.dtsi 2016-09-28
19:13:52.651881000 +0200
@@ -363,5 +363,159 @@
reg = <0xf8005000 0x1000>;
timeout-sec = <10>;
};
+
+ etb at F8801000 {
+ compatible = "arm,coresight-etb10", "arm,primecell";
+ reg = <0xf8801000 0x1000>;
+ coresight-default-sink;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <0x8>;
+ linux,phandle = <0xd>;
+ phandle = <0xd>;
+ };
+ };
+ };
+
+ tpiu at F8803000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0xf8803000 0x1000>;
+ clocks = <&clkc 47>, <&clkc 16>;
+ clock-names = "apb_pclk", "fclk1";
+ clock-frequency=<0xee6b280>;
+
+ port {
+
+ endpoint at 0 {
+ slave-mode;
+ remote-endpoint = <0x9>;
+ linux,phandle = <0xe>;
+ phandle = <0xe>;
+ };
+ };
+ };
+
+ funnel at F8804000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0xf8804000 0x1000>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+
+ endpoint {
+ remote-endpoint = <0xa>;
+ linux,phandle = <0xf>;
+ phandle = <0xf>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x0>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xb>;
+ linux,phandle = <0x11>;
+ phandle = <0x11>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x1>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xc>;
+ linux,phandle = <0x13>;
+ phandle = <0x13>;
+ };
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ ports {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+
+ port at 0 {
+ reg = <0x0>;
+
+ endpoint {
+ remote-endpoint = <0xd>;
+ linux,phandle = <0x8>;
+ phandle = <0x8>;
+ };
+ };
+
+ port at 1 {
+ reg = <0x1>;
+
+ endpoint {
+ remote-endpoint = <0xe>;
+ linux,phandle = <0x9>;
+ phandle = <0x9>;
+ };
+ };
+
+ port at 2 {
+ reg = <0x0>;
+
+ endpoint {
+ slave-mode;
+ remote-endpoint = <0xf>;
+ linux,phandle = <0xa>;
+ phandle = <0xa>;
+ };
+ };
+ };
+ };
+
+ ptm0 at F889C000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889c000 0x1000>;
+ cpu = <0x10>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint {
+ remote-endpoint = <0x11>;
+ linux,phandle = <0xb>;
+ phandle = <0xb>;
+ };
+ };
+ };
+
+ ptm1 at F889D000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0xf889d000 0x1000>;
+ cpu = <0x12>;
+ clocks = <&clkc 47>;
+ clock-names = "apb_pclk";
+
+ port {
+
+ endpoint {
+ remote-endpoint = <0x13>;
+ linux,phandle = <0xc>;
+ phandle = <0xc>;
+ };
+ };
+ };
};
};
^ permalink raw reply
* [PATCH 3.12 003/119] arm64: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
From: Jiri Slaby @ 2016-09-29 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a528a0fa6d67ebe60bfc762c72b316d28ed21dea.1475144721.git.jslaby@suse.cz>
From: James Hogan <james.hogan@imgtec.com>
3.12-stable review patch. If anyone has any objections, please let me know.
===============
commit 3146bc64d12377a74dbda12b96ea32da3774ae07 upstream.
AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for arm64 at all even though ARCH_DLINFO will contain one NEW_AUX_ENT
for the VDSO address.
This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which arm64 doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
date.
Fixes: f668cd1673aa ("arm64: ELF definitions")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
arch/arm64/include/asm/elf.h | 1 +
arch/arm64/include/uapi/asm/auxvec.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index e7fa87f9201b..a4e1758c44dc 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -124,6 +124,7 @@ extern unsigned long randomize_et_dyn(unsigned long base);
#define SET_PERSONALITY(ex) clear_thread_flag(TIF_32BIT);
+/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
#define ARCH_DLINFO \
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index 22d6d8885854..4cf0c17787a8 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,4 +19,6 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+
#endif
--
2.10.0
^ permalink raw reply related
* [PATCH v1] usb: ohci-at91: Set RemoteWakeupConnected bit explicitly.
From: Wenyou Yang @ 2016-09-29 10:07 UTC (permalink / raw)
To: linux-arm-kernel
The reset value of RWC is 0, set RemoteWakeupConnected bit explicitly
before calling ohci_run, it also fixes the issue that the mass
storage stick connected wasn't suspended when the system suspend.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
drivers/usb/host/ohci-at91.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 98047bf..ff0d31a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -202,6 +202,12 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
ohci->num_ports = board->ports;
at91_start_hc(pdev);
+ /*
+ * The RemoteWakeupConnected bit has to be set explicitly
+ * before calling ohci_run. The reset value of this bit is 0.
+ */
+ ohci->hc_control = OHCI_CTRL_RWC;
+
retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval == 0) {
device_wakeup_enable(hcd->self.controller);
@@ -554,9 +560,6 @@ ohci_hcd_at91_drv_suspend(struct device *dev)
* REVISIT: some boards will be able to turn VBUS off...
*/
if (!ohci_at91->wakeup) {
- ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
- ohci->hc_control &= OHCI_CTRL_RWC;
- ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
ohci->rh_state = OHCI_RH_HALTED;
/* flush the writes */
--
2.7.4
^ permalink raw reply related
* [PATCH v2] usb: ohci-at91: Use descriptor-based gpio APIs
From: Wenyou Yang @ 2016-09-29 9:59 UTC (permalink / raw)
To: linux-arm-kernel
Use the descriptor-based interface to manipulate GPIOs, instead of
the legacy integer-based interface.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
Changes in v2:
- Retain the vbus_pin_active_low[] member and its manipulations.
drivers/usb/host/ohci-at91.c | 121 +++++++++++--------------------------------
1 file changed, 31 insertions(+), 90 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..98047bf 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -14,8 +14,8 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_platform.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/atmel.h>
#include <linux/io.h>
@@ -36,8 +36,8 @@
#define AT91_MAX_USBH_PORTS 3
struct at91_usbh_data {
- int vbus_pin[AT91_MAX_USBH_PORTS]; /* port power-control pin */
- int overcurrent_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *vbus_pin[AT91_MAX_USBH_PORTS];
+ struct gpio_desc *overcurrent_pin[AT91_MAX_USBH_PORTS];
u8 ports; /* number of ports on root hub */
u8 overcurrent_supported;
u8 vbus_pin_active_low[AT91_MAX_USBH_PORTS];
@@ -243,11 +243,8 @@ static void ohci_at91_usb_set_power(struct at91_usbh_data *pdata, int port, int
if (!valid_port(port))
return;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return;
-
- gpio_set_value(pdata->vbus_pin[port],
- pdata->vbus_pin_active_low[port] ^ enable);
+ gpiod_set_value(pdata->vbus_pin[port],
+ pdata->vbus_pin_active_low[port] ^ enable);
}
static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
@@ -255,11 +252,8 @@ static int ohci_at91_usb_get_power(struct at91_usbh_data *pdata, int port)
if (!valid_port(port))
return -EINVAL;
- if (!gpio_is_valid(pdata->vbus_pin[port]))
- return -EINVAL;
-
- return gpio_get_value(pdata->vbus_pin[port]) ^
- pdata->vbus_pin_active_low[port];
+ return gpiod_get_value(pdata->vbus_pin[port]) ^
+ pdata->vbus_pin_active_low[port];
}
/*
@@ -406,16 +400,13 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
{
struct platform_device *pdev = data;
struct at91_usbh_data *pdata = dev_get_platdata(&pdev->dev);
- int val, gpio, port;
+ int val, port;
/* From the GPIO notifying the over-current situation, find
* out the corresponding port */
at91_for_each_port(port) {
- if (gpio_is_valid(pdata->overcurrent_pin[port]) &&
- gpio_to_irq(pdata->overcurrent_pin[port]) == irq) {
- gpio = pdata->overcurrent_pin[port];
+ if (gpiod_to_irq(pdata->overcurrent_pin[port]) == irq)
break;
- }
}
if (port == AT91_MAX_USBH_PORTS) {
@@ -423,7 +414,7 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, void *data)
return IRQ_HANDLED;
}
- val = gpio_get_value(gpio);
+ val = gpiod_get_value(pdata->overcurrent_pin[port]);
/* When notified of an over-current situation, disable power
on the corresponding port, and mark this port in
@@ -454,9 +445,8 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct at91_usbh_data *pdata;
int i;
- int gpio;
int ret;
- enum of_gpio_flags flags;
+ int err;
u32 ports;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -477,38 +467,16 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
pdata->ports = ports;
at91_for_each_port(i) {
- /*
- * do not configure PIO if not in relation with
- * real USB port on board
- */
- if (i >= pdata->ports) {
- pdata->vbus_pin[i] = -EINVAL;
- pdata->overcurrent_pin[i] = -EINVAL;
+ pdata->vbus_pin[i] = devm_gpiod_get_optional(&pdev->dev,
+ "atmel,vbus-gpio",
+ GPIOD_IN);
+ if (IS_ERR(pdata->vbus_pin[i])) {
+ err = PTR_ERR(pdata->vbus_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"vbus\": %d\n", err);
continue;
}
- gpio = of_get_named_gpio_flags(np, "atmel,vbus-gpio", i,
- &flags);
- pdata->vbus_pin[i] = gpio;
- if (!gpio_is_valid(gpio))
- continue;
- pdata->vbus_pin_active_low[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_request(gpio, "ohci_vbus");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request vbus gpio %d\n", gpio);
- continue;
- }
- ret = gpio_direction_output(gpio,
- !pdata->vbus_pin_active_low[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "can't put vbus gpio %d as output %d\n",
- gpio, !pdata->vbus_pin_active_low[i]);
- gpio_free(gpio);
- continue;
- }
+ pdata->vbus_pin_active_low[i] = gpiod_get_value(pdata->vbus_pin[i]);
ohci_at91_usb_set_power(pdata, i, 1);
}
@@ -518,37 +486,21 @@ static int ohci_hcd_at91_drv_probe(struct platform_device *pdev)
break;
pdata->overcurrent_pin[i] =
- of_get_named_gpio_flags(np, "atmel,oc-gpio", i, &flags);
-
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- gpio = pdata->overcurrent_pin[i];
-
- ret = gpio_request(gpio, "ohci_overcurrent");
- if (ret) {
- dev_err(&pdev->dev,
- "can't request overcurrent gpio %d\n",
- gpio);
+ devm_gpiod_get_optional(&pdev->dev,
+ "atmel,oc-gpio", GPIOD_IN);
+ if (IS_ERR(pdata->overcurrent_pin[i])) {
+ err = PTR_ERR(pdata->overcurrent_pin[i]);
+ dev_err(&pdev->dev, "unable to claim gpio \"overcurrent\": %d\n", err);
continue;
}
- ret = gpio_direction_input(gpio);
- if (ret) {
- dev_err(&pdev->dev,
- "can't configure overcurrent gpio %d as input\n",
- gpio);
- gpio_free(gpio);
- continue;
- }
-
- ret = request_irq(gpio_to_irq(gpio),
- ohci_hcd_at91_overcurrent_irq,
- IRQF_SHARED, "ohci_overcurrent", pdev);
- if (ret) {
- gpio_free(gpio);
- dev_err(&pdev->dev,
- "can't get gpio IRQ for overcurrent\n");
- }
+ ret = devm_request_irq(&pdev->dev,
+ gpiod_to_irq(pdata->overcurrent_pin[i]),
+ ohci_hcd_at91_overcurrent_irq,
+ IRQF_SHARED,
+ "ohci_overcurrent", pdev);
+ if (ret)
+ dev_info(&pdev->dev, "failed to request gpio \"overcurrent\" IRQ\n");
}
device_init_wakeup(&pdev->dev, 1);
@@ -561,19 +513,8 @@ static int ohci_hcd_at91_drv_remove(struct platform_device *pdev)
int i;
if (pdata) {
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->vbus_pin[i]))
- continue;
+ at91_for_each_port(i)
ohci_at91_usb_set_power(pdata, i, 0);
- gpio_free(pdata->vbus_pin[i]);
- }
-
- at91_for_each_port(i) {
- if (!gpio_is_valid(pdata->overcurrent_pin[i]))
- continue;
- free_irq(gpio_to_irq(pdata->overcurrent_pin[i]), pdev);
- gpio_free(pdata->overcurrent_pin[i]);
- }
}
device_init_wakeup(&pdev->dev, 0);
--
2.7.4
^ permalink raw reply related
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Sudeep Holla @ 2016-09-29 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160929084953.GA24154@lnxartpec.se.axis.com>
On 29/09/16 09:49, Rabin Vincent wrote:
> On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
[...]
>> Thanks you for reporting this Vankatesh,
>>
>> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
>> to test with.
>
> I've seen this too, on other platforms. This should fix it:
>
> 8<-----------
> From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rabinv@axis.com>
> Date: Tue, 30 Aug 2016 08:54:21 +0200
> Subject: [PATCH] coresight: check for NULL child_name
>
> Connection child names associated to ports can sometimes be NULL, which
> is the case when booting a system on QEMU or when the Coresight power
> domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
> string in coresight_name_match()") fixed one place to handle this but
> the same check is needed in coresight_orphan_match() to prevent a crash
> there.
>
Thanks Rabin, we have exact same fix in linux-next already.
--
Regards,
Sudeep
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Sudeep Holla @ 2016-09-29 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkypz383Smuqv3B5K3i9mzGxMdc1OJdc_tWQZ5qHWQCeJw@mail.gmail.com>
Hi Mathieu,
On 28/09/16 18:41, Mathieu Poirier wrote:
> On 28 September 2016 at 10:35, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
>> Hi All,
>>
>> I am trying to boot 4.8-rc8 in ARM Juno r1 board with coresight
>> enabled and could see crash. When coresight is disabled at kernel
>> config, then it boots to the linux prompt with rootfs in USB.
>>
>> I am using UEFI binary that came along with Juno-r1 board.
>>
>> Used following Image and dtb,
>>
[...]
>
> Thanks you for reporting this Vankatesh,
>
> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
> to test with.
>
R1 and R2 are almost same except A57 is replaced by A72.
Anyways I reported the exact crash along with the fix sometime in June.
It got missed in v4.8, but is already queued in linux-next(in-fact twice
;), from your tree as well as greg's).
e05b386c878d coresight: access conn->child_name only if it's initialised
b8392153721c coresight: access conn->child_name only if it's initialised
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: *: mm: Implement get_user_pages_fast()
From: Rabin Vincent @ 2016-09-29 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACOPJM6AC5TwSEPUA7Df8F-FuChrjVP1TWVNeSrHt6ZaSyFiGg@mail.gmail.com>
On Tue, Sep 20, 2016 at 07:00:28PM -0700, Yuriy Romanenko wrote:
> +int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> + struct page **pages)
> +{
> + struct mm_struct *mm = current->mm;
> + int ret;
> + unsigned long page_addr = (start & PAGE_MASK);
> + int nr = 0;
> +
> + struct gup_private_data private_data = {
> + .nr = 0,
> + .pages = pages,
> + .write = write
> + };
> +
> + struct mm_walk gup_walk = {
> + .pte_entry = gup_pte_entry,
> + .pte_hole = gup_pte_hole_entry,
> + .mm = mm,
> + .private = (void *)&private_data
> + };
> +
> + ret = walk_page_range(page_addr,
> + page_addr + nr_pages * PAGE_SIZE,
> + &gup_walk);
> + nr = ret ? ret : nr_pages;
walk_page_range() can't be called without the mmap_sem.
* Locking:
* Callers of walk_page_range() and walk_page_vma() should hold
* @walk->mm->mmap_sem, because these function traverse vma list and/or
* access to vma's data.
*/
int walk_page_range(unsigned long start, unsigned long end,
struct mm_walk *walk)
{
int err = 0;
unsigned long next;
struct vm_area_struct *vma;
if (start >= end)
return -EINVAL;
if (!walk->mm)
return -EINVAL;
VM_BUG_ON_MM(!rwsem_is_locked(&walk->mm->mmap_sem), walk->mm);
^ permalink raw reply
* Crash seen on ARM Juno r1 with 4.8-rc8 when Coresight is enabled
From: Rabin Vincent @ 2016-09-29 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkypz383Smuqv3B5K3i9mzGxMdc1OJdc_tWQZ5qHWQCeJw@mail.gmail.com>
On Wed, Sep 28, 2016 at 11:41:41AM -0600, Mathieu Poirier wrote:
> On 28 September 2016 at 10:35, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
> > [ 5.479353] Unable to handle kernel NULL pointer dereference at
> > virtual address 00000000
> > [ 5.487372] pgd = ffff000008db1000
> > [ 5.490739] [00000000] *pgd=00000009ffffe003,
> > *pud=00000009ffffd003, *pmd=0000000000000000
> > [ 5.498940] Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > [ 5.504451] Modules linked in:
> > [ 5.507474] CPU: 0 PID: 449 Comm: kworker/0:1 Not tainted 4.8.0-rc8-dirty #1
> > [ 5.514447] Hardware name: ARM Juno development board (r1) (DT)
> > [ 5.520310] Workqueue: events amba_deferred_retry_func
> > [ 5.525394] task: ffff800976bfd780 task.stack: ffff8009760bc000
> > [ 5.531253] PC is at strcmp+0x1c/0x160
> > [ 5.534962] LR is at coresight_orphan_match+0x78/0xc8
> > [ 5.539957] pc : [<ffff00000835f14c>] lr : [<ffff00000870231c>]
> > pstate: 40000145
> > [ 5.547272] sp : ffff8009760bfa00
> > [ 5.550547] x29: ffff8009760bfa00 x28: ffff8009762c7f00
> > [ 5.555807] x27: ffff000008d66e46 x26: 0000000000000000
> > [ 5.561066] x25: 0000000000000001 x24: ffff000008702048
> > [ 5.566325] x23: 0000000000000000 x22: ffff800973ce5000
> > [ 5.571584] x21: ffff800973ce0800 x20: 0000000000000000
> > [ 5.576843] x19: ffff800976b08600 x18: 0000000000000000
> > [ 5.582101] x17: 0000000000000000 x16: ffff000008e52fff
> > [ 5.587360] x15: ffff000008e52fff x14: ffffffffffffffff
> > [ 5.592619] x13: ffff000008ca5000 x12: 0000000000000008
> > [ 5.597878] x11: 0000000000000020 x10: 0101010101010101
> > [ 5.603137] x9 : 0000000000000000 x8 : 7fff7f7f7f7f7f7f
> > [ 5.608396] x7 : 0000000000000000 x6 : 000000008008cb22
> > [ 5.613655] x5 : 22cb080000000000 x4 : ffff800973ce0828
> > [ 5.618914] x3 : 0000000000000000 x2 : 3030303031303032
> > [ 5.624173] x1 : 0000000000000000 x0 : ffff8009760f1d08
> > [ 5.629432]
>
> Thanks you for reporting this Vankatesh,
>
> Sudeep and Suzuki, can you guys help me with this - I don't have an R1
> to test with.
I've seen this too, on other platforms. This should fix it:
8<-----------
>From a9da7d7b47e67dd6ffcafddadb50e6f97503f296 Mon Sep 17 00:00:00 2001
From: Rabin Vincent <rabinv@axis.com>
Date: Tue, 30 Aug 2016 08:54:21 +0200
Subject: [PATCH] coresight: check for NULL child_name
Connection child names associated to ports can sometimes be NULL, which
is the case when booting a system on QEMU or when the Coresight power
domain isn't switched on. fadf3a44e974 ("coresight: checking for NULL
string in coresight_name_match()") fixed one place to handle this but
the same check is needed in coresight_orphan_match() to prevent a crash
there.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
drivers/hwtracing/coresight/coresight.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index d08d1ab..ceeaaea 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -725,7 +725,8 @@ static int coresight_orphan_match(struct device *dev, void *data)
/* We have found at least one orphan connection */
if (conn->child_dev == NULL) {
/* Does it match this newly added device? */
- if (!strcmp(dev_name(&csdev->dev), conn->child_name)) {
+ if (conn->child_name &&
+ !strcmp(dev_name(&csdev->dev), conn->child_name)) {
conn->child_dev = csdev;
} else {
/* This component still has an orphan */
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox