* [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Yao Qi @ 2016-10-12 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d6ebb3e9776154da4c1a41f17446e9e31c891a7d.1476251587.git.panand@redhat.com>
On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand <panand@redhat.com> wrote:
> Since, arm64 can support all offset within a double word limit. Therefore,
> now support other lengths within that range as well.
How does ptracer (like GDB) detect kernel has already supported all byte
address select values? I suppose ptrace(NT_ARM_HW_WATCH, ) with
len is 3 or 5 fail on current kernel but is of success after your patches
applied.
GDB is aware of the byte address select limitation in kernel, so it always
sets 1,2,4,8 in len in ctrl. GDB needs to know whether the limitation is still
there or not.
--
Yao (??)
^ permalink raw reply
* [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot
From: Vignesh R @ 2016-10-12 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1a4b59e-5524-9851-425e-5e86e05a593c@oracle.com>
Hi,
On Monday 10 October 2016 09:31 PM, Santosh Shilimkar wrote:
> Vignesh,
>
> On 10/10/2016 7:31 AM, Russell King - ARM Linux wrote:
>> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote:
>>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
>>> cannot fit into existing partition. So, increase the SPI Flash partition
>>> for U-Boot to 1MB for all Keystone2 devices.
>>>
>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>> ---
>>>
>>> This was submitted to v4.9 merge window but was never picked up:
>>> https://patchwork.kernel.org/patch/9135023/
>
> Another point is, if you want me to pick your patch, please copy
> me next time :-). AFAIK, am seeing this patch in my inbox first time.
>
Sorry, I did address the previous patch to you. Not sure what happened :(
>>
>> I think you need to explain why it's safe to change the layout of the
>> flash partitions like this.
>>
>> - What is this "misc" partition?
>>
>> - Why is it safe to move the "misc" partition in this way?
>>
>> - Do users need to do anything with data stored in the "misc" partition
>> when changing kernels?
>>
>> If the "misc" partition is simply unused space on the flash device, why
>> list it in DT?
>>
> Thanks Russell. Yes, above clarification would be good to get first.
Ok, will send v2 with updated commit message as per my reply in other
thread.
--
Regards
Vignesh
^ permalink raw reply
* [PATCH RESEND] ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-Boot
From: Vignesh R @ 2016-10-12 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010143144.GB1041@n2100.armlinux.org.uk>
Hi,
On Monday 10 October 2016 08:01 PM, Russell King - ARM Linux wrote:
> On Mon, Oct 10, 2016 at 07:41:41PM +0530, Vignesh R wrote:
>> U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
>> cannot fit into existing partition. So, increase the SPI Flash partition
>> for U-Boot to 1MB for all Keystone2 devices.
>>
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>>
>> This was submitted to v4.9 merge window but was never picked up:
>> https://patchwork.kernel.org/patch/9135023/
>
> I think you need to explain why it's safe to change the layout of the
> flash partitions like this.
>
> - What is this "misc" partition?
>
This partition seems to exists from the very beginning. I believe, this
is just a spare area of flash that can be used as per end-user
requirement. Either to store a small filesystem or kernel. Copying
Murali who added above partition if he has any input here.
> - Why is it safe to move the "misc" partition in this way?
>
> - Do users need to do anything with data stored in the "misc" partition
> when changing kernels?
>
MTD layer will take care of most abstractions (like start address etc).
Will add a note in commit message informing about the reduction in size
of the partition.
> If the "misc" partition is simply unused space on the flash device, why
> list it in DT?
>
If the unused space is not listed in the DT, then there is no /dev/mtdX
node created for the unused section. User will then have to manually
edit DT, in order to get the node and mount it. Instead, lets make it
available by default.
--
Regards
Vignesh
^ permalink raw reply
* [bug report] PCI: rockchip: Add Rockchip PCIe controller support
From: Dan Carpenter @ 2016-10-12 10:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello Shawn Lin,
The patch e77f847df54c: "PCI: rockchip: Add Rockchip PCIe controller
support" from Sep 3, 2016, leads to the following static checker
warning:
drivers/pci/host/pcie-rockchip.c:552 rockchip_pcie_init_port()
warn: mask and shift to zero
drivers/pci/host/pcie-rockchip.c
549
550 /* Check the final link width from negotiated lane counter from MGMT */
551 status = rockchip_pcie_read(rockchip, PCIE_CORE_CTRL);
552 status = 0x1 << ((status & PCIE_CORE_PL_CONF_LANE_MASK) >>
553 PCIE_CORE_PL_CONF_LANE_MASK);
Presumably we should be shifting by PCIE_CORE_PL_CONF_LANE_SHIFT but
this still looks all kind of jumbled up.
554 dev_dbg(dev, "current link width is x%d\n", status);
555
regards,
dan carpenter
^ permalink raw reply
* [PATCH v3 2/2] clk: imx: improve precision of AV PLL to 1 Hz
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
The audio and video PLLs are designed to have a precision of 1 Hz if some
conditions are met. The current implementation only allows a precision that
depends on the rate of the parent clock. E.g., if the parent clock is 24
MHz, the precision will be 24 Hz; or more generally the precision will be
p / 10^6 Hz
where p is the parent clock rate. This comes down to how the register
values for the PLL's fractional loop divider are chosen.
The clock rate calculation for the PLL is
PLL output frequency = Fref * (DIV_SELECT + NUM / DENOM)
or with a shorter notation
r = p * (d + a / b)
In addition to all variables being integers, we also have the following
conditions:
27 <= d <= 54
-2^29 <= a <= 2^29-1
0 < b <= 2^30-1
|a| < b
Here, d, a and b are register values for the fractional loop divider. We
want to chose d, a and b such that f(p, r) = p, i.e. f is our round_rate
function. Currently, d and b are chosen as
d = r / p
b = 10^6
hence we get the poor precision. And a is defined in terms of r, d, p and
b:
a = (r - d * p) * b / p
I propose that if p <= 2^30-1 (i.e., the max value for b), we chose b as
b = p
We can do this since
|a| < b
|(r - d * p) * b / p| < b
|r - d * p| < p
Which have two solutions, one of them is when p < 0, so we can skip that
one. The other is when p > 0 and
p * (d - 1) < r < p * (d + 1)
Substitute d = r / p:
(r - p) < r < (r + p) <=> p > 0
So, as long as p > 0, we can chose b = p. This is a good choise for b since
a = (r - d * p) * b / p
= (r - d * p) * p / p
= r - d * p
r = p * (d + a / b)
= p * d + p * a / b
= p * d + p * a / p
= p * d + a
and if d = r / p:
a = r - d * p
= r - r / p * p
= 0
r = p * d + a
= p * d + 0
= p * r / p
= r
I reckon this is the intention by the design of the clock rate formula.
Signed-off-by: Emil Lundmark <emil@limesaudio.com>
---
drivers/clk/imx/clk-pllv3.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 7a6acc3e4a92..ed3a2df536ea 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -234,6 +234,7 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long max_rate = parent_rate * 54;
u32 div;
u32 mfn, mfd = 1000000;
+ u32 max_mfd = 0x3FFFFFFF;
u64 temp64;
if (rate > max_rate)
@@ -241,6 +242,9 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
else if (rate < min_rate)
rate = min_rate;
+ if (parent_rate <= max_mfd)
+ mfd = parent_rate;
+
div = rate / parent_rate;
temp64 = (u64) (rate - div * parent_rate);
temp64 *= mfd;
@@ -262,11 +266,15 @@ static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long max_rate = parent_rate * 54;
u32 val, div;
u32 mfn, mfd = 1000000;
+ u32 max_mfd = 0x3FFFFFFF;
u64 temp64;
if (rate < min_rate || rate > max_rate)
return -EINVAL;
+ if (parent_rate <= max_mfd)
+ mfd = parent_rate;
+
div = rate / parent_rate;
temp64 = (u64) (rate - div * parent_rate);
temp64 *= mfd;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] clk: imx: fix integer overflow in AV PLL round rate
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1476267249.git.emil@limesaudio.com>
Since 'parent_rate * mfn' may overflow 32 bits, the result should be
stored using 64 bits.
The problem was discovered when trying to set the rate of the audio PLL
(pll4_post_div) on an i.MX6Q. The desired rate was 196.608 MHz, but
the actual rate returned was 192.000570 MHz. The round rate function should
have been able to return 196.608 MHz, i.e., the desired rate.
Fixes: ba7f4f557eb6 ("clk: imx: correct AV PLL rate formula")
Cc: Anson Huang <b20788@freescale.com>
Signed-off-by: Emil Lundmark <emil@limesaudio.com>
---
drivers/clk/imx/clk-pllv3.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
index 19f9b622981a..7a6acc3e4a92 100644
--- a/drivers/clk/imx/clk-pllv3.c
+++ b/drivers/clk/imx/clk-pllv3.c
@@ -223,7 +223,7 @@ static unsigned long clk_pllv3_av_recalc_rate(struct clk_hw *hw,
temp64 *= mfn;
do_div(temp64, mfd);
- return (parent_rate * div) + (u32)temp64;
+ return parent_rate * div + (unsigned long)temp64;
}
static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -247,7 +247,11 @@ static long clk_pllv3_av_round_rate(struct clk_hw *hw, unsigned long rate,
do_div(temp64, parent_rate);
mfn = temp64;
- return parent_rate * div + parent_rate * mfn / mfd;
+ temp64 = (u64)parent_rate;
+ temp64 *= mfn;
+ do_div(temp64, mfd);
+
+ return parent_rate * div + (unsigned long)temp64;
}
static int clk_pllv3_av_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] clk: imx: fix AV PLL rate setting
From: Emil Lundmark @ 2016-10-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I discovered a problem when trying to set the rate of the audio PLL
(pll4_post_div) on an i.MX6Q. The rate I wanted to set was 196.608 MHz, but
the actual rate I got was 192.000570 MHz. This patch series fixes this
issue and also improves the precision of the audio/video PLLs.
Changes since v2:
- Cast result of 'parent_rate * mfn / mfd' to unsigned long instead of u32.
- Clarify how this issue was discovered in the commit message.
- Rebased on Linux 4.8.
Changes since v1:
- Use correct subsystem name in commit summary.
- Use 'Fixes:' tag to indicate bug fix.
- Revise argument for choosing the denominator register value after
comments from Lothar Wa?mann.
v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460809.html
v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460350.html
Emil Lundmark (2):
clk: imx: fix integer overflow in AV PLL round rate
clk: imx: improve precision of AV PLL to 1 Hz
drivers/clk/imx/clk-pllv3.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v7 2/8] power: add power sequence library
From: Heiko Stuebner @ 2016-10-12 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-3-git-send-email-peter.chen@nxp.com>
Hi,
Am Dienstag, 20. September 2016, 11:36:41 CEST schrieb Peter Chen:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> Tested-by Joshua Clayton <stillcompiling@gmail.com>
> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
first of all, glad to see this move forward. I've only some qualms with the
static number of allocated power sequences below.
[...]
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..dff5e35
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> + It is used for drivers which needs to do power sequence
> + (eg, turn on clock, toggle reset gpio) before the related
> + devices can be found by hardware. This generic one can be
> + used for common power sequence control.
> +
> +config PWRSEQ_GENERIC_INSTANCE_NUMBER
> + int "Number of Generic Power Sequence Instance"
> + depends on PWRSEQ_GENERIC
> + range 1 10
> + default 2
> + help
> + Usually, there are not so many devices needs power sequence, we set two
> + as default value.
limiting this to some arbitary compile-time number somehow seems crippling for
the single-image approach. I.e. a distribution might select something and
during its lifetime the board requiring n+1 power-sequences appears and thus
needs a different kernel version just to support that additional sequence.
Also, board designers are creative, and there were already complex examples
mentioned elsewhere, so nothing keeps people from inventing something even
more complex.
[...]
> diff --git a/drivers/power/pwrseq/pwrseq_generic.c
> b/drivers/power/pwrseq/pwrseq_generic.c new file mode 100644
> index 0000000..bcd16c3
> --- /dev/null
> +++ b/drivers/power/pwrseq/pwrseq_generic.c
[...]
> +static int pwrseq_generic_get(struct device_node *np, struct pwrseq
> *pwrseq) +{
> + struct pwrseq_generic *pwrseq_gen = to_generic_pwrseq(pwrseq);
> + enum of_gpio_flags flags;
> + int reset_gpio, clk, ret = 0;
> +
> + for (clk = 0; clk < PWRSEQ_MAX_CLKS; clk++) {
> + pwrseq_gen->clks[clk] = of_clk_get(np, clk);
> + if (IS_ERR(pwrseq_gen->clks[clk])) {
> + ret = PTR_ERR(pwrseq_gen->clks[clk]);
> + if (ret != -ENOENT)
> + goto err_put_clks;
> + pwrseq_gen->clks[clk] = NULL;
> + break;
> + }
> + }
> +
> + reset_gpio = of_get_named_gpio_flags(np, "reset-gpios", 0, &flags);
> + if (gpio_is_valid(reset_gpio)) {
> + unsigned long gpio_flags;
> +
> + if (flags & OF_GPIO_ACTIVE_LOW)
> + gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW;
> + else
> + gpio_flags = GPIOF_OUT_INIT_HIGH;
> +
> + ret = gpio_request_one(reset_gpio, gpio_flags,
> + "pwrseq-reset-gpios");
> + if (ret)
> + goto err_put_clks;
> +
> + pwrseq_gen->gpiod_reset = gpio_to_desc(reset_gpio);
> + of_property_read_u32(np, "reset-duration-us",
> + &pwrseq_gen->duration_us);
> + } else {
> + if (reset_gpio == -ENOENT)
> + return 0;
> +
> + ret = reset_gpio;
> + pr_err("Failed to get reset gpio on %s, err = %d\n",
> + np->full_name, reset_gpio);
> + goto err_put_clks;
> + }
> +
> + return ret;
> +
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(pwrseq_gen->clks[clk]);
> + return ret;
> +}
> +
> +static const struct of_device_id generic_id_table[] = {
> + { .compatible = "generic",},
> + { /* sentinel */ }
> +};
> +
> +static int __init pwrseq_generic_register(void)
> +{
> + struct pwrseq_generic *pwrseq_gen;
> + int i;
> +
> + for (i = 0; i < CONFIG_PWRSEQ_GENERIC_INSTANCE_NUMBER; i++) {
> + pwrseq_gen = kzalloc(sizeof(*pwrseq_gen), GFP_KERNEL);
> + if (!pwrseq_gen)
> + return -ENOMEM;
> +
> + pwrseq_gen->pwrseq.pwrseq_of_match_table = generic_id_table;
> + pwrseq_gen->pwrseq.get = pwrseq_generic_get;
> + pwrseq_gen->pwrseq.on = pwrseq_generic_on;
> + pwrseq_gen->pwrseq.off = pwrseq_generic_off;
> + pwrseq_gen->pwrseq.put = pwrseq_generic_put;
> + pwrseq_gen->pwrseq.free = pwrseq_generic_free;
> +
> + pwrseq_register(&pwrseq_gen->pwrseq);
> + }
> +
> + return 0;
> +}
> +postcore_initcall(pwrseq_generic_register)
I see that you need to have it preallocated for the compatible matching, but
wouldn't it also work to either just register the type and allocate
dynamically or otherwise just allocate a new spare everytime
pwrseq_generic_get() picks up the previous spare?
That way the total number of power sequences can still be dynamic without
haggling over how many power sequences should be the build-default in the
generic configs.
^ permalink raw reply
* [PATCH v3 07/11] arm64/tracing: fix compat syscall handling
From: Will Deacon @ 2016-10-12 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fed0151c-ebfd-18d2-939c-21e315dc7584@imgtec.com>
On Wed, Oct 12, 2016 at 09:07:03AM +0200, Marcin Nowakowski wrote:
> On 11.10.2016 15:36, Will Deacon wrote:
> >On Tue, Oct 11, 2016 at 12:42:52PM +0200, Marcin Nowakowski wrote:
> >>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
There's only three users of __NR_compat_syscalls, so I think you can
move them over.
> >>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.
Fine by me -- I just wanted to make sure our compat behaviour matched
the behaviour of native arch/arm/. It sounds like it does, so no need to
change anything here.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] drm/bridge: analogix: protect power when get_modes or detect
From: Mark Yao @ 2016-10-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
The drm callback ->detect and ->get_modes seems is not power safe,
they may be called when device is power off, do register access on
detect or get_modes will cause system die.
Here is the path call ->detect before analogix_dp power on
[<ffffff800843babc>] analogix_dp_detect+0x44/0xdc
[<ffffff80083fd840>] drm_helper_probe_single_connector_modes_merge_bits+0xe8/0x41c
[<ffffff80083fdb84>] drm_helper_probe_single_connector_modes+0x10/0x18
[<ffffff8008418d24>] drm_mode_getconnector+0xf4/0x304
[<ffffff800840cff0>] drm_ioctl+0x23c/0x390
[<ffffff80081a8adc>] do_vfs_ioctl+0x4b8/0x58c
[<ffffff80081a8c10>] SyS_ioctl+0x60/0x88
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: "Ville Syrj?l?" <ville.syrjala@linux.intel.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..09dece2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1062,6 +1062,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
return 0;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (analogix_dp_handle_edid(dp) == 0) {
drm_mode_connector_update_edid_property(&dp->connector, edid);
num_modes += drm_add_edid_modes(&dp->connector, edid);
@@ -1073,6 +1080,13 @@ int analogix_dp_get_modes(struct drm_connector *connector)
if (dp->plat_data->get_modes)
num_modes += dp->plat_data->get_modes(dp->plat_data, connector);
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
@@ -1106,9 +1120,23 @@ analogix_dp_detect(struct drm_connector *connector, bool force)
return connector_status_disconnected;
}
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ pm_runtime_get_sync(dp->dev);
+
+ if (dp->plat_data->power_on)
+ dp->plat_data->power_on(dp->plat_data);
+ }
+
if (!analogix_dp_detect_hpd(dp))
status = connector_status_connected;
+ if (dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+
+ pm_runtime_put_sync(dp->dev);
+ }
+
ret = analogix_dp_prepare_panel(dp, false, false);
if (ret)
DRM_ERROR("Failed to unprepare panel (%d)\n", ret);
--
1.9.1
^ permalink raw reply related
* [RFC 0/1] misc: Add Allwinner Q8 tablet hardware manager
From: Mark Rutland @ 2016-10-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJVkPPiDh66nhfh0D7BvkZ7KKN0X7uhfPGgiYbc2Ca1rg@mail.gmail.com>
Hi,
On Fri, Sep 09, 2016 at 04:32:06PM -0500, Rob Herring wrote:
> On Thu, Sep 1, 2016 at 2:08 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > Hi All,
> >
> > Here is a first RFC for the q8 tablet hw-manager I've been talking
> > about for a while now.
> >
> > The touchscreen part is finished, I'll start working on the
> > accelerometer bits next.
>
> This at least partially overlaps with the "overlay manager" just
> posted. A dev board having different devices attached and a production
> device have 2nd source components are not really different problems.
> We need a common solution and can't have each platform making up their
> own scheme.
To follow up discussions at ELC-E, I agree that we need a common solution (if
this has to happen in the kernel rather than in an earlier stage of the boot
process).
Otherwise, we're creating pseudo-board-files, and a whole new set of problems
for ourselves.
Thanks
Mark.
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Dan Carpenter @ 2016-10-12 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012085239.GD1041@n2100.armlinux.org.uk>
On Wed, Oct 12, 2016 at 09:52:39AM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2016 at 09:21:03AM +0300, 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')
>
> Correct form is:
>
> Fixes: 12-digit-hash ("summary line")
When I originally created the Fixes tag format, I used single quotes.
I don't remember why though and I can change with the times. :)
regards,
dan carpenter
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Maxime Ripard @ 2016-10-12 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012105559.aaf9122e376fa5969a2e61d9@free.fr>
On Wed, Oct 12, 2016 at 10:55:59AM +0200, Jean-Francois Moine wrote:
> On Fri, 7 Oct 2016 10:25:55 +0200
> Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> > The sun8i-emac hardware is present on the Orange PI 2.
> > It uses the internal PHY.
> >
> > This patch create the needed emac node.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > index f93f5d1..5608eb4 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> > @@ -54,6 +54,7 @@
> >
> > aliases {
> > serial0 = &uart0;
> > + ethernet0 = &emac;
>
> As there is no 'of_alias_get_id' in the driver, this alias is
> useless.
Not really, this is used by U-Boot to set the mac address.
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/20161012/982f5d88/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node
From: Boris Brezillon @ 2016-10-12 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475711217-974-4-git-send-email-sergio.prado@e-labworks.com>
Hi Sergio,
On Wed, 5 Oct 2016 20:46:57 -0300
Sergio Prado <sergio.prado@e-labworks.com> wrote:
> Allows configuring Samsung's s3c2410 memory controller using a
> devicetree.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> drivers/mtd/nand/s3c2410.c | 171 ++++++++++++++++++++++---
> include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> 2 files changed, 156 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 174ac9dc4265..352cf2656bc8 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
[...]
> +
> +static int s3c2410_nand_init_timings(struct s3c2410_nand_info *info,
> + struct nand_chip *chip)
> +{
> + struct s3c2410_platform_nand *pdata = info->platform;
> + const struct nand_sdr_timings *t;
> + int tacls, mode;
> +
> + mode = onfi_get_async_timing_mode(chip);
> + if (mode == ONFI_TIMING_MODE_UNKNOWN)
> + mode = chip->onfi_timing_mode_default;
> +
> + t = onfi_async_timing_mode_to_sdr_timings(mode);
> + if (IS_ERR(t))
> + return PTR_ERR(t);
We recently introduced an method to automate timing selection and
configuration [1]. Can you switch to this approach (the changes are in
the nand/next branch [2] and should appear in 4.9-rc1)?
Thanks,
Boris
[1]https://www.spinics.net/lists/arm-kernel/msg532007.html
[2]https://github.com/linux-nand/linux/tree/nand/next
^ permalink raw reply
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Jean-Francois Moine @ 2016-10-12 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-9-git-send-email-clabbe.montjoie@gmail.com>
On Fri, 7 Oct 2016 10:25:55 +0200
Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
> The sun8i-emac hardware is present on the Orange PI 2.
> It uses the internal PHY.
>
> This patch create the needed emac node.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> index f93f5d1..5608eb4 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> @@ -54,6 +54,7 @@
>
> aliases {
> serial0 = &uart0;
> + ethernet0 = &emac;
As there is no 'of_alias_get_id' in the driver, this alias is useless.
> };
>
> chosen {
> @@ -184,3 +185,10 @@
> usb1_vbus-supply = <®_usb1_vbus>;
> status = "okay";
> };
> +
> +&emac {
> + phy-handle = <&int_mii_phy>;
> + phy-mode = "mii";
> + allwinner,leds-active-low;
> + status = "okay";
> +};
> --
> 2.7.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [patch] serial: stm32: fix a type issue
From: Russell King - ARM Linux @ 2016-10-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012062103.GS12841@mwanda>
On Wed, Oct 12, 2016 at 09:21:03AM +0300, 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')
Correct form is:
Fixes: 12-digit-hash ("summary line")
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: LABBE Corentin @ 2016-10-12 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011094042.GS3462@lukather>
On Tue, Oct 11, 2016 at 11:40:42AM +0200, Maxime Ripard wrote:
> On Mon, Oct 10, 2016 at 03:09:43PM +0200, Jean-Francois Moine wrote:
> > On Mon, 10 Oct 2016 14:35:11 +0200
> > LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> >
> > > On Mon, Oct 10, 2016 at 02:30:46PM +0200, Maxime Ripard wrote:
> > > > On Fri, Oct 07, 2016 at 10:25:57AM +0200, Corentin Labbe wrote:
> > > > > Enable the sun8i-emac driver in the multi_v7 default configuration
> > > > >
> > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > ---
> > > > > arch/arm/configs/multi_v7_defconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> > > > > index 5845910..f44d633 100644
> > > > > --- a/arch/arm/configs/multi_v7_defconfig
> > > > > +++ b/arch/arm/configs/multi_v7_defconfig
> > > > > @@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
> > > > > CONFIG_VIRTIO_NET=y
> > > > > CONFIG_HIX5HD2_GMAC=y
> > > > > CONFIG_SUN4I_EMAC=y
> > > > > +CONFIG_SUN8I_EMAC=y
> > > >
> > > > Any reason to build it statically?
> > >
> > > No, just copied the same than CONFIG_SUN4I_EMAC that probably do
> > > not need it also.
> >
> > All arm configs are done the same way, and, some day, the generic ARM
> > V7 kernel will not be loadable in 1Gb RAM...
>
> Yeah, if possible, I'd really like to avoid introducing statically
> built drivers to multi_v7.
>
I forgot to said it in my first answer, but yes I will change it.
Regards
^ 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
* [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: 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 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 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] 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 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 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
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