Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Linus,
Am 12.08.2015 um 01:20 schrieb NeilBrown :
> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
> wrote:
>
>> Hi Neil,
>>
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>>
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown wrote:
>>
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>>
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>>
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection. The driver
>>> does all the extra control beyond Tx/Rx.
>>
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>>
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>>
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>>
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>>
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>>
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver. I guess it is time to rebase to -rc3.
>>
>> You have a hardware taget I see. Which one?
>
> GTA04 (www.gta04.org - openmoko successor).
>
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
>
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
>
> For the bluetooth, the power is a (shared) regulator. As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
>
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
>
> NeilBrown
we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.
See:
https://lkml.org/lkml/2015/6/28/91
Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/3] ARM: dts: rockchip: add core rk3036 dts
Initial release for rk3036, node definitions rk3036 sdk board.
Signed-off-by: Xing Zheng
---
Changes in v1: None
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/rk3036-sdk.dts | 362 ++
2 files changed, 363 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6d7cec1..7014a3b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -501,6 +501,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
+ rk3036-sdk.dtb \
rk3188-radxarock.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
diff --git a/arch/arm/boot/dts/rk3036-sdk.dts b/arch/arm/boot/dts/rk3036-sdk.dts
new file mode 100644
index 000..0149c9a
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-sdk.dts
@@ -0,0 +1,362 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "rockchip,rk3036";
+
+ interrupt-parent = <>;
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ };
+
+ memory {
+ reg = <0x6000 0x4000>;
+ };
+
+arm-pmu {
+compatible = "arm,cortex-a7-pmu";
+interrupts = ,
+ ;
+};
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ //enable-method = "rockchip,rk3066-smp";
+
+ cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ operating-points = <
+ /* KHzuV */
+816000 100
+ >;
+ #cooling-cells = <2>; /* min followed by max */
+ clock-latency = <4>;
+ clocks = < ARMCLK>;
+ resets = < SRST_CORE0>;
+ };
+ cpu@f01 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ resets = < SRST_CORE1>;
+ };
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+pdma: pdma@20078000 {
+compatible = "arm,pl330", "arm,primecell";
+reg = <0x20078000 0x4000>;
+interrupts = ,
+ ;
+#dma-cells = <1>;
+clocks = < ACLK_DMAC2>;
+clock-names = "apb_pclk";
+};
+ };
+
+ xin24m:
[PATCH v1 0/3] Port and support rk3036 SoC platform
Hi, We need to support rk3036 soc platform via upstream, there are 3 parts for the initial release of minimum system: dts, pinctrl, and clock tree for rk3036, startup and run to init processs. Thanks. Changes in v1: Signed-off-by: Xing Zheng Xing Zheng (3): ARM: dts: rockchip: add core rk3036 dts pinctrl: rockchip: add support for the rk3036 clk: rockchip: add clock controller for rk3036 arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/rk3036-sdk.dts | 362 + drivers/clk/rockchip/Makefile |1 + drivers/clk/rockchip/clk-pll.c | 247 ++- drivers/clk/rockchip/clk-rk3036.c | 539 drivers/clk/rockchip/clk.h | 30 ++ drivers/pinctrl/pinctrl-rockchip.c | 17 + include/dt-bindings/clock/rk3036-cru.h | 247 +++ 8 files changed, 1443 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts create mode 100644 drivers/clk/rockchip/clk-rk3036.c create mode 100644 include/dt-bindings/clock/rk3036-cru.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 3/3] clk: rockchip: add clock controller for rk3036
Add the clock tree definition for the new rk3036 SoC,
but there are some issues to be fixed:
1. soc will crash if gpll run rate_change_remuxed
2. rk3036_clk_suspend and rk3036_clk_resume should be done
in clk-rk3036.c
---
Changes in v1:
Signed-off-by: Xing Zheng
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-pll.c | 247 ++-
drivers/clk/rockchip/clk-rk3036.c | 539
drivers/clk/rockchip/clk.h | 30 ++
include/dt-bindings/clock/rk3036-cru.h | 247 +++
5 files changed, 1063 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-rk3036.c
create mode 100644 include/dt-bindings/clock/rk3036-cru.h
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index b27edd6..d599829 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-rk3036.o
obj-y += clk-rk3188.o
obj-y += clk-rk3288.o
obj-y += clk-rk3368.o
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 96903ae..cf56826 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -2,6 +2,9 @@
* Copyright (c) 2014 MundoReader S.L.
* Author: Heiko Stuebner
*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -48,6 +51,8 @@ struct rockchip_clk_pll {
#define to_rockchip_clk_pll_nb(nb) \
container_of(nb, struct rockchip_clk_pll, clk_nb)
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll);
+
static const struct rockchip_pll_rate_table *rockchip_get_pll_settings(
struct rockchip_clk_pll *pll, unsigned long rate)
{
@@ -90,6 +95,11 @@ static int rockchip_pll_wait_lock(struct rockchip_clk_pll
*pll)
unsigned int val;
int delay = 2400, ret;
+ /* the plls of rk3036 wait lock */
+ if (pll->type == pll_rk3036 || pll->lock_offset == -1) {
+ return rockchip_rk3036_pll_wait_lock(pll);
+ }
+
while (delay > 0) {
ret = regmap_read(grf, pll->lock_offset, );
if (ret) {
@@ -305,6 +315,235 @@ static void rockchip_rk3066_pll_init(struct clk_hw *hw)
rockchip_rk3066_pll_set_rate(hw, drate, prate);
}
}
+/**
+ * PLL used in RK3036
+ */
+
+#define RK3036_PLL_RESET_DELAY(nr) ((nr * 500) / 24 + 1)
+
+#define RK3036_PLLCON(i) (i * 0x4)
+#define RK3036_PLLCON0_FBDIV_MASK 0xfff
+#define RK3036_PLLCON0_FBDIV_SHIFT 0
+#define RK3036_PLLCON0_POSTDIV1_MASK 0x7
+#define RK3036_PLLCON0_POSTDIV1_SHIFT 12
+#define RK3036_PLLCON1_REFDIV_MASK 0x3f
+#define RK3036_PLLCON1_REFDIV_SHIFT0
+#define RK3036_PLLCON1_POSTDIV2_MASK 0x7
+#define RK3036_PLLCON1_POSTDIV2_SHIFT 6
+#define RK3036_PLLCON1_DSMPD_MASK 0x1
+#define RK3036_PLLCON1_DSMPD_SHIFT 12
+#define RK3036_PLLCON2_FRAC_MASK 0xff
+#define RK3036_PLLCON2_FRAC_SHIFT 0
+
+#define RK3036_MODECON 0x40
+#define RK3036_MODECON_AWM (1 << 0) /* apll work mode */
+
+#define RK3036_PLLCON0_BYPASS (1 << 15)
+#define RK3036_PLLCON1_LOCK_STATUS (1 << 10)
+#define RK3036_PLLCON1_RESET (1 << 14)
+
+static int rockchip_rk3036_pll_wait_lock(struct rockchip_clk_pll *pll)
+{
+ u32 pllcon;
+ int delay = 2400;
+
+ /* poll check the lock status in rk3036 xPLLCON1 */
+ while (delay > 0) {
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+ if (pllcon & RK3036_PLLCON1_LOCK_STATUS)
+ return 0;
+
+ delay--;
+ }
+
+ pr_err("%s: timeout waiting for pll to lock\n", __func__);
+ return -ETIMEDOUT;
+}
+
+static unsigned long rockchip_rk3036_pll_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
+{
+ struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
+ unsigned int fbdiv, postdiv1, refdiv, postdiv2, dsmpd, frac;
+ u64 rate64 = prate;
+ u32 pllcon;
+
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(0));
+ fbdiv = ((pllcon >> RK3036_PLLCON0_FBDIV_SHIFT) &
RK3036_PLLCON0_FBDIV_MASK);
+ postdiv1 = ((pllcon >> RK3036_PLLCON0_POSTDIV1_SHIFT) &
RK3036_PLLCON0_POSTDIV1_MASK);
+
+ pllcon = readl_relaxed(pll->reg_base + RK3036_PLLCON(1));
+ refdiv = ((pllcon >> RK3036_PLLCON1_REFDIV_SHIFT) &
[PATCH v1 2/3] pinctrl: rockchip: add support for the rk3036
Many parts of pinctrl rk3036 are similar to rk2928's.
Signed-off-by: Xing Zheng
---
Changes in v1: None
drivers/pinctrl/pinctrl-rockchip.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index cc2843a..d06631d 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -2042,6 +2042,21 @@ static struct rockchip_pin_ctrl rk2928_pin_ctrl = {
.pull_calc_reg = rk2928_calc_pull_reg_and_bit,
};
+static struct rockchip_pin_bank rk3036_pin_banks[] = {
+ PIN_BANK(0, 32, "gpio0"),
+ PIN_BANK(1, 32, "gpio1"),
+ PIN_BANK(2, 32, "gpio2"),
+};
+
+static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
+ .pin_banks = rk3036_pin_banks,
+ .nr_banks = ARRAY_SIZE(rk3036_pin_banks),
+ .label = "RK3036-GPIO",
+ .type = RK2928,
+ .grf_mux_offset = 0xa8,
+ .pull_calc_reg = rk2928_calc_pull_reg_and_bit,
+};
+
static struct rockchip_pin_bank rk3066a_pin_banks[] = {
PIN_BANK(0, 32, "gpio0"),
PIN_BANK(1, 32, "gpio1"),
@@ -2160,6 +2175,8 @@ static struct rockchip_pin_ctrl rk3368_pin_ctrl = {
static const struct of_device_id rockchip_pinctrl_dt_match[] = {
{ .compatible = "rockchip,rk2928-pinctrl",
.data = (void *)_pin_ctrl },
+ { .compatible = "rockchip,rk3036-pinctrl",
+ .data = (void *)_pin_ctrl },
{ .compatible = "rockchip,rk3066a-pinctrl",
.data = (void *)_pin_ctrl },
{ .compatible = "rockchip,rk3066b-pinctrl",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] PM / hibernate: Remove the restriction when checking memory size before/after hibernation
* Chen Yu wrote:
> Sometimes the resuming of hibernation might fail, because the
> system before/after hibernation have different number of page
> frames, and in current implementation, this situation will be
> regarded as invalud resuming process. However, consider the following
> scenario: The resuming system has a larger memory capacity than
> the one before hibernation, and the former memory region is a
> superset of the latter, it should be allowed to resume. For example,
> someone plugs more DRAMs before resuming from hibernation.
> Here's a case for this situation:
>
> e820 memory map before hibernation:
> BIOS-e820: [mem 0x2020-0x77517fff] usable
> BIOS-e820: [mem 0x77518000-0x77567fff] reserved
>
> e820 memory map during resuming:
> BIOS-e820: [mem 0x2020-0x7753] usable
> BIOS-e820: [mem 0x7754-0x77567fff] reserved
>
> In current code, the resuming process will be terminated, because
> they have different memory size(usable region), but actually we should
> let it continue to resume because [0x2020-0x7753]
> is a superset of [0x2020-0x77517fff].
>
> This patch removes the constraint that number of page frames should
> be strictly the same before/after hibernation.
>
> Note: This patch can only work after:
> Commit ec93ef809f34 ("PM / hibernate: avoid unsafe pages in e820
> reserved regions") applied.
>
> Signed-off-by: Chen Yu
> ---
> kernel/power/snapshot.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index c24d5a2..5b1a071 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -2072,8 +2072,12 @@ static int check_header(struct swsusp_info *info)
> char *reason;
>
> reason = check_image_kernel(info);
> - if (!reason && info->num_physpages != get_num_physpages())
> - reason = "memory size";
> + /*
> + * No need to check num_physpages with get_num_physpages
> + * as we did before(please refer to git log), because
> + * is_nosave_page will ensure that each page is safe
> + * to be restored.
> + */
> if (reason) {
> printk(KERN_ERR "PM: Image mismatch: %s\n", reason);
> return -EPERM;
No, this removes a useful sanity check that protects against data corruption.
If you want to relax it then you should add code that checks whether the
before/after memory image is truly a superset of each other, and warn and deny
the
hibernation in any other case. (For example when RAM got removed or moved.)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] perf/x86/intel/bts: Disallow use by unprivileged users on paranoid systems
* Alexander Shishkin wrote: > BTS leaks kernel addresses even in userspace-only mode due to imprecise IP > sampling, so sometimes syscall entry points or page fault handler addresses > end up in a userspace trace. > > Now, intel_bts driver exports trace data zero-copy, it does not scan through > it to filter out the kernel addresses and it's would be a O(n) job. > > To work around this situation, this patch forbids the use of intel_bts > driver by unprivileged users with paranoid setting higher than 1, which > forbids kernel tracing. > > Signed-off-by: Alexander Shishkin > --- > arch/x86/kernel/cpu/perf_event_intel_bts.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/x86/kernel/cpu/perf_event_intel_bts.c > b/arch/x86/kernel/cpu/perf_event_intel_bts.c > index 80df16e020..4f6daff92d 100644 > --- a/arch/x86/kernel/cpu/perf_event_intel_bts.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_bts.c > @@ -495,6 +495,16 @@ static int bts_event_init(struct perf_event *event) > if (x86_add_exclusive(x86_lbr_exclusive_bts)) > return -EBUSY; > > + /* > + * BTS leaks kernel addresses even when CPL0 tracing is > + * disabled, so disallow intel_bts driver for unprivileged > + * users on paranoid systems since it provides trace data > + * to the user in a zero-copy fashion. > + */ > + if (event->attr.exclude_kernel && perf_paranoid_kernel() && > + !capable(CAP_SYS_ADMIN)) > + return -EACCES; I.e. it's disabled by default as well, with default paranoia settings? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] KVM: dynamic halt_poll_ns adjustment
On 8/28/15 12:25 AM, David Matlack wrote:
On Thu, Aug 27, 2015 at 2:59 AM, Wanpeng Li wrote:
Hi David,
On 8/26/15 1:19 AM, David Matlack wrote:
Thanks for writing v2, Wanpeng.
On Mon, Aug 24, 2015 at 11:35 PM, Wanpeng Li
wrote:
There is a downside of halt_poll_ns since poll is still happen for idle
VCPU which can waste cpu usage. This patch adds the ability to adjust
halt_poll_ns dynamically.
What testing have you done with these patches? Do you know if this removes
the overhead of polling in idle VCPUs? Do we lose any of the performance
from always polling?
There are two new kernel parameters for changing the halt_poll_ns:
halt_poll_ns_grow and halt_poll_ns_shrink. A third new parameter,
halt_poll_ns_max, controls the maximal halt_poll_ns; it is internally
rounded down to a closest multiple of halt_poll_ns_grow. The shrink/grow
matrix is suggested by David:
if (poll successfully for interrupt): stay the same
else if (length of kvm_vcpu_block is longer than halt_poll_ns_max):
shrink
else if (length of kvm_vcpu_block is less than halt_poll_ns_max): grow
The way you implemented this wasn't what I expected. I thought you would
time
the whole function (kvm_vcpu_block). But I like your approach better. It's
simpler and [by inspection] does what we want.
I see there is more idle vCPUs overhead w/ this method even more than always
halt-poll, so I bring back grow vcpu->halt_poll_ns when interrupt arrives
and shrinks when idle VCPU is detected. The perfomance looks good in v4.
Why did this patch have a worse idle overhead than always poll?
I’m not sure. I make a mistake when I report the kernelbuild test, the
perfomance is also worse than always poll w/ your method. I think your
method didn't grow halt_poll_ns according to if interrupt arrives.
Regards,
Wanpeng Li
Regards,
Wanpeng Li
halt_poll_ns_shrink/ |
halt_poll_ns_grow| grow halt_poll_ns| shrink halt_poll_ns
-+--+---
< 1 | = halt_poll_ns | = 0
< halt_poll_ns | *= halt_poll_ns_grow | /= halt_poll_ns_shrink
otherwise| += halt_poll_ns_grow | -= halt_poll_ns_shrink
I was curious why you went with this approach rather than just the
middle row, or just the last row. Do you think we'll want the extra
flexibility?
Signed-off-by: Wanpeng Li
---
virt/kvm/kvm_main.c | 65
-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 93db833..2a4962b 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -66,9 +66,26 @@
MODULE_AUTHOR("Qumranet");
MODULE_LICENSE("GPL");
-static unsigned int halt_poll_ns;
+#define KVM_HALT_POLL_NS 50
+#define KVM_HALT_POLL_NS_GROW 2
+#define KVM_HALT_POLL_NS_SHRINK 0
+#define KVM_HALT_POLL_NS_MAX 200
The macros are not necessary. Also, hard coding the numbers in the param
definitions will make reading the comments above them easier.
+
+static unsigned int halt_poll_ns = KVM_HALT_POLL_NS;
module_param(halt_poll_ns, uint, S_IRUGO | S_IWUSR);
+/* Default doubles per-vcpu halt_poll_ns. */
+static unsigned int halt_poll_ns_grow = KVM_HALT_POLL_NS_GROW;
+module_param(halt_poll_ns_grow, int, S_IRUGO);
+
+/* Default resets per-vcpu halt_poll_ns . */
+static unsigned int halt_poll_ns_shrink = KVM_HALT_POLL_NS_SHRINK;
+module_param(halt_poll_ns_shrink, int, S_IRUGO);
+
+/* halt polling only reduces halt latency by 10-15 us, 2ms is enough */
Ah, I misspoke before. I was thinking about round-trip latency. The
latency
of a single halt is reduced by about 5-7 us.
+static unsigned int halt_poll_ns_max = KVM_HALT_POLL_NS_MAX;
+module_param(halt_poll_ns_max, int, S_IRUGO);
We can remove halt_poll_ns_max. vcpu->halt_poll_ns can always start at
zero
and grow from there. Then we just need one module param to keep
vcpu->halt_poll_ns from growing too large.
[ It would make more sense to remove halt_poll_ns and keep
halt_poll_ns_max,
but since halt_poll_ns already exists in upstream kernels, we probably
can't
remove it. ]
+
/*
* Ordering of locks:
*
@@ -1907,6 +1924,48 @@ void kvm_vcpu_mark_page_dirty(struct kvm_vcpu
*vcpu, gfn_t gfn)
}
EXPORT_SYMBOL_GPL(kvm_vcpu_mark_page_dirty);
+static unsigned int __grow_halt_poll_ns(unsigned int val)
+{
+ if (halt_poll_ns_grow < 1)
+ return halt_poll_ns;
+
+ val = min(val, halt_poll_ns_max);
+
+ if (val == 0)
+ return halt_poll_ns;
+
+ if (halt_poll_ns_grow < halt_poll_ns)
+ val *= halt_poll_ns_grow;
+ else
+ val += halt_poll_ns_grow;
+
+ return val;
+}
+
+static unsigned int __shrink_halt_poll_ns(int val, int modifier, int
minimum)
minimum never gets used.
+{
+ if (modifier < 1)
+ return 0;
+
+ if (modifier < halt_poll_ns)
+ val /= modifier;
+ else
Re: [PATCH 1/2] perf/x86/intel/ds: Work around BTS leaking kernel addresses
* Alexander Shishkin wrote:
> + for (at = base; at < top; at++) {
> + /*
> + * Note that right now *this* BTS code only works if
> + * attr::exclude_kernel is set, but let's keep this extra
> + * check here in case that changes.
> + */
> + if (event->attr.exclude_kernel &&
> + (at->from >= PAGE_OFFSET || at->to >= PAGE_OFFSET))
> + skip++;
Yeah, so that only works on 32-bit kernels, on 64-bit kernels the check for
kernel
addresses is to see whether it's a negative address. PAGE_OFFSET points to
above
any hypervisor's address, so even with your fix we could still leak hypervisor
addresses.
I.e. use the kernel_ip() primitive instead.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: A question about vring operation
On 24/07/2015 21:36, Michael S. Tsirkin wrote: >On Thu, Aug 27, 2015 at 01:18:47AM +, Wang, Wei W wrote: > Hi all, > > > > I have a question about the vring_avail: > > It only includes an idx (equivalent to the ring tail), which is used > by the frontend (virtio_net) to fill bufs. The backend (e.g. > vhost_net) maintains the ring head (last_avail_idx) by itself. The > frontend checks if the ring is full or empty via a counter (vq->num_free). > > My question is why can’t we include the ring head in the vring_avail > struct, so that the vq->num_free is not needed, and the backend can > directly use it without maintaining its own copy? > > > > Thanks, > > Wei > > > >I'm not sure I understand your proposal, and what it would accomplish. Write a >patch, that'll make it easier to discuss. >Also copy all relevant mailing lists, not just kvm. Thanks Michael. I haven’t got the patch ready yet. I am just wondering if it is better to have "last_avail_idx" in vhost_virtqueue moved into vring_avail. In other regular ring operations, we usually use *head and *tail to judge if the ring is full or empty, but it seems vring_avail does not use this method in virtio_net.c (it uses a counter). Best, Wei
Re: [PATCH 3/3] x86/math-emu: Remove define layer for undocumented opcodes
* Denys Vlasenko wrote: > No code changes. > Only compile-tested. So this series really needs to be tested for real before I can apply any of them. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/11] x86, fpu: check CPU-provided sizes against struct declarations
* Dave Hansen wrote: > @@ -447,6 +492,14 @@ static void do_extra_xstate_size_checks( > paranoid_xstate_size += xfeature_size(i); > } > XSTATE_WARN_ON(paranoid_xstate_size != xstate_size); > + /* > + * Basically, make sure that XSTATE_RESERVE has forced > + * xregs_state to be large enough. This is not fatal > + * because we reserve a *lot* of extra room in the init > + * task struct, but we should at least know we got it > + * wrong. > + */ > + XSTATE_WARN_ON(xstate_size > sizeof(struct xregs_state)); So do we need to warn about this? arch_task_struct_size is already dynamic today. The only problem would be the init task, which is allocated statically - can we fix that? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_HOLES_IN_ZONE and memory hot plug code on x86_64
On Fri, Jun 26, 2015 at 4:31 PM, Steffen Persvold wrote: > We’ve encountered an issue in a special case where we have a sparse E820 map > [1]. > > Basically the memory hotplug code is causing a “kernel paging request” BUG > [2]. the trace does not look like hotplug path. > > By instrumenting the function register_mem_sect_under_node() in > drivers/base/node.c we see that it is called two times with the same struct > memory_block argument : > > [1.901463] register_mem_sect_under_node: start = 80, end = 8f, nid = 0 > [1.908129] register_mem_sect_under_node: start = 80, end = 8f, nid = 1 Can you post whole log with SRAT related info? Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2,2/5] powerpc/rcpm: add RCPM driver
On Fri, 2015-08-28 at 08:40 +0800, Scott Wood wrote:
> On Thu, Aug 27, 2015 at 4:35 AM, Scott Wood
> wrote:
> > On Wed, Aug 26, 2015 at 08:09:45PM +0800, Chenhui Zhao wrote:
I didn't write this e-mail. Please fix your mail client.
> > > +static void rcpm_v1_cpu_up_prepare(int cpu)
> > > +{
> > > +rcpm_v1_cpu_exit_state(cpu, E500_PM_PH15);
> > > +rcpm_v1_irq_unmask(cpu);
> > > +}
> > > +
> > > +static void rcpm_v2_cpu_exit_state(int cpu, int state)
> > > +{
> > > +int hw_cpu = get_hard_smp_processor_id(cpu);
> > > +u32 mask = 1 << cpu_core_index_of_thread(hw_cpu);
> >
> > Are you sure cpu_core_index_of_thread() is supposed to take a hardware
> > cpu id? The only current user, pseries_energy.c, has the comment
> > "Convert logical cpu number to core number".
>
> Here, the method of getting core index of thread is same for physical
> and logical.
> So use this existed function to do the job.
I realize that you get the same result either way, but that doesn't make it
OK. You have "cpu"; pass that instead of "hw_cpu".
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/11] [v2] x86, fpu: XSAVE cleanups and sanity checks
* Dave Hansen wrote: > > Changes in v2: > * remove references to Processor Trace XSAVE state >(will defer to another patch set) > * Remove some cruft from last patch > * move last_good_offset fix in to the patch that >introduced it > > > These patches make some updates to the x86 XSAVE code. > > There are basically 5 things going on here: > * removal of the LWP (lightweight profiling) code > * naming and type cleanups > * removal of xfeatures_nr variable > * addition of AVX-512 C structures > * new sanity checks of XSAVE buffer sizing > > Cc: Ingo Molnar > Cc: x...@kernel.org > Cc: Borislav Petkov > Cc: Fenghua Yu > Cc: Tim Chen > Cc: linux-kernel@vger.kernel.org So conceptually I like this series, modulo the handful of small suggestions I made in my review. (The extra patch suggestions I made could be added later on in a separate series.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/11] x86, fpu: rename xfeature_bit
* Dave Hansen wrote:
> +++ b/arch/x86/include/asm/fpu/types.h2015-08-27 10:08:01.572634311
> -0700
> @@ -95,27 +95,31 @@ struct swregs_state {
> /*
> * List of XSAVE features Linux knows about:
> */
> -enum xfeature_bit {
> - XSTATE_BIT_FP,
> - XSTATE_BIT_SSE,
> - XSTATE_BIT_YMM,
> - XSTATE_BIT_BNDREGS,
> - XSTATE_BIT_BNDCSR,
> - XSTATE_BIT_OPMASK,
> - XSTATE_BIT_ZMM_Hi256,
> - XSTATE_BIT_Hi16_ZMM,
> +enum xfeature_nr {
> + XFEATURE_NR_FP,
> + XFEATURE_NR_SSE,
> + /*
> + * Values above here are "legacy states".
> + * Those below are "extended states".
> + */
> + XFEATURE_NR_YMM,
> + XFEATURE_NR_BNDREGS,
> + XFEATURE_NR_BNDCSR,
> + XFEATURE_NR_OPMASK,
> + XFEATURE_NR_ZMM_Hi256,
> + XFEATURE_NR_Hi16_ZMM,
>
> XFEATURES_NR_MAX,
> };
> +#define XSTATE_FP(1 << XFEATURE_NR_FP)
> +#define XSTATE_SSE (1 << XFEATURE_NR_SSE)
> +#define XSTATE_YMM (1 << XFEATURE_NR_YMM)
> +#define XSTATE_BNDREGS (1 << XFEATURE_NR_BNDREGS)
> +#define XSTATE_BNDCSR(1 << XFEATURE_NR_BNDCSR)
> +#define XSTATE_OPMASK(1 << XFEATURE_NR_OPMASK)
> +#define XSTATE_ZMM_Hi256 (1 << XFEATURE_NR_ZMM_Hi256)
> +#define XSTATE_Hi16_ZMM (1 << XFEATURE_NR_Hi16_ZMM)
So I think this is still somewhat confusing.
'NR' is often used as a maximum kind of thing, not as a bit index.
So I think we should instead take up the existing conventions of the
cpufeatures.h
definitions which are pretty sane, and simply name the bit indices XFEATURE_XYZ:
enum xfeatures {
XFEATURE_FP,
XFEATURE_SSE,
...
XFEATURE_MAX
};
this way we ensure that bitmasks are visibly masks, i.e.:
#define XFEATURE_MASK_FP(1 << XFEATURE_FP)
#define XFEATURE_MASK_SSE (1 << XFEATURE_SSE)
it's slightly longer to write but unambiguous, and it also matches what we use
for
the x86 CPU ID feature definitions.
Similarly we could rename other mask fields from 'xstate' to 'xfeature_mask',
to
make it all consistent throughout.
What do you think?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2,5/5] PowerPC/mpc85xx: Add CPU hotplug support for E6500
On Fri, 2015-08-28 at 09:42 +0800, Chenhui Zhao wrote:
> On Thu, Aug 27, 2015 at 6:42 AM, Scott Wood
> wrote:
> > On Wed, Aug 26, 2015 at 08:09:48PM +0800, Chenhui Zhao wrote:
> > > +.globl booting_thread_hwid
> > > +booting_thread_hwid:
> > > +.long INVALID_THREAD_HWID
> > > +.align 3
> >
> > The commit message goes into no detail about the changes you're
> > making to
> > thread handling, nor are there relevant comments.
>
> OK. Will add some comments.
>
> >
> > > +/*
> > > + * r3 = the thread physical id
> > > + */
> > > +_GLOBAL(book3e_stop_thread)
> > > +li r4, 1
> > > +sld r4, r4, r3
> > > +mtspr SPRN_TENC, r4
> > > +isync
> > > +blr
> >
> > Why did the C code not have an isync, if it's required here?
>
> Just make sure "mtspr" has completed before the routine returns.
>
> >
> >
> > > _GLOBAL(fsl_secondary_thread_init)
> > > /* Enable branch prediction */
> > > lis r3,BUCSR_INIT@h
> > > @@ -197,8 +236,10 @@ _GLOBAL(fsl_secondary_thread_init)
> > >* but the low bit right by two bits so that the cpu numbering
> > > is
> > >* continuous.
> > >*/
> > > -mfspr r3, SPRN_PIR
> > > -rlwimi r3, r3, 30, 2, 30
> > > +bl 10f
> > > +10: mflrr5
> > > +addir5,r5,(booting_thread_hwid - 10b)
> > > +lwz r3,0(r5)
> > > mtspr SPRN_PIR, r3
> > > #endif
> >
> > I assume the reason for this is that, unlike the kexec case, the cpu
> > has
> > been reset so PIR has been reset? Don't make me guess -- document.
>
> We can not rely on the value saved in SPRN_PIR. Every time running
> fsl_secondary_thread_init, SPRN_PIR may not always has a reset value.
> Using booting_thread_hwid to ensure SPRN_PIR has a correct value.
But when will the cpu ever be in a state other than "reset PIR value and
reset BUCSR value" or "Software-desired PIR value and BUCSR value"?
> > > @@ -245,6 +286,30 @@ _GLOBAL(generic_secondary_smp_init)
> > > mr r3,r24
> > > mr r4,r25
> > > bl book3e_secondary_core_init
> > > +
> > > +/*
> > > + * If we want to boot Thread1, start Thread1 and stop Thread0.
> > > + * Note that only Thread0 will run the piece of code.
> > > + */
> >
> > What ensures that only thread 0 runs this? Especially if we're
> > entering
> > via kdump on thread 1?
>
> This piece of code will be executed only when core resets (Thead0 will
> start first).
This is not true with kexec/kdump.
> Thead1 will run fsl_secondary_thread_init() to start.
>
> How can kdump run this on Thread1? I know little about kexec.
kexec/kdump involves booting a new kernel image without resetting the
hardware.
+ /* start Thread1 */
> > > +LOAD_REG_ADDR(r5, fsl_secondary_thread_init)
> > > +ld r4, 0(r5)
> > > +li r3, 1
> > > +bl book3e_start_thread
> > > +
> > > +/* stop Thread0 */
> > > +li r3, 0
> > > +bl book3e_stop_thread
> > > +10:
> > > +b 10b
> > > +20:
> > > #endif
> > >
> > > generic_secondary_common_init:
> > > diff --git a/arch/powerpc/platforms/85xx/smp.c
> > > b/arch/powerpc/platforms/85xx/smp.c
> > > index 73eb994..61f68ad 100644
> > > --- a/arch/powerpc/platforms/85xx/smp.c
> > > +++ b/arch/powerpc/platforms/85xx/smp.c
> > > @@ -181,17 +181,11 @@ static inline u32 read_spin_table_addr_l(void
> > > *spin_table)
> > > static void wake_hw_thread(void *info)
> > > {
> > > void fsl_secondary_thread_init(void);
> > > -unsigned long imsr1, inia1;
> > > -int nr = *(const int *)info;
> > > +unsigned long inia;
> > > +int hw_cpu = get_hard_smp_processor_id(*(const int *)info);
> > >
> > > -imsr1 = MSR_KERNEL;
> > > -inia1 = *(unsigned long *)fsl_secondary_thread_init;
> > > -
> > > -mttmr(TMRN_IMSR1, imsr1);
> > > -mttmr(TMRN_INIA1, inia1);
> > > -mtspr(SPRN_TENS, TEN_THREAD(1));
> > > -
> > > -smp_generic_kick_cpu(nr);
> > > +inia = *(unsigned long *)fsl_secondary_thread_init;
> > > +book3e_start_thread(cpu_thread_in_core(hw_cpu), inia);
> > > }
> > > #endif
> > >
> > > @@ -279,7 +273,6 @@ static int smp_85xx_kick_cpu(int nr)
> > > int ret = 0;
> > > #ifdef CONFIG_PPC64
> > > int primary = nr;
> > > -int primary_hw = get_hard_smp_processor_id(primary);
> > > #endif
> > >
> > > WARN_ON(nr < 0 || nr >= num_possible_cpus());
> > > @@ -287,33 +280,43 @@ static int smp_85xx_kick_cpu(int nr)
> > > pr_debug("kick CPU #%d\n", nr);
> > >
> > > #ifdef CONFIG_PPC64
> > > +booting_thread_hwid = INVALID_THREAD_HWID;
> > > /* Threads don't use the spin table */
> > > -if (cpu_thread_in_core(nr) != 0) {
> > > -
Re: [PATCH 04/11] x86, fpu: remove xfeature_nr
* Dave Hansen wrote: > > From: Dave Hansen > > xfeature_nr ended up being initialized too late for me to > use it in the "xsave size sanity check" patch which is > later in the series. I tried to move around its initialization > but realized that it was just as easy to get rid of it. > > We only have 9 XFEATURES. Instead of dynamically calculating > and storing the last feature, just use the compile-time max: > XFEATURES_NR_MAX. Note that even with 'xfeatures_nr' we can > had "holes" in the xfeatures_mask that we had to deal with. s/we can had/we can have Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/11] x86, fpu: add helper xfeature_nr_enabled() instead of test_bit()
* Dave Hansen wrote: > > From: Dave Hansen > > We currently use test_bit() in a few places to see if an xfeature > is enabled. It ends up being a bit ugly because 'xfeatures_mask' > is a u64 and test_bit wants an 'unsigned long' so it requires a > cast. The *_bit() functions are also techincally atomic, which > we have no need for here. > > So, remove the test_bit()s and replace with the new > xfeature_nr_enabled() helper. Small nit: please name it xfeature_enabled(), as it's shorter and already pretty unambiguous. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/11] x86, fpu: add C structures for AVX-512 state components
* Dave Hansen wrote:
>
> From: Dave Hansen
>
> AVX-512 has 3 separate state components:
> 1. opmask registers
> 2. zmm upper half of registers 0-15
> 3. new zmm registers (16-31)
>
> This patch adds C structures for the three components along with
> a few comments mostly lifted from the SDM to explain what they
> do. This will allow us to check our structures against what the
> hardware tells us about the sizes of the components.
>
> Signed-off-by: Dave Hansen
> Cc: Ingo Molnar
> Cc: x...@kernel.org
> Cc: Borislav Petkov
> Cc: Fenghua Yu
> Cc: Tim Chen
> Cc: linux-kernel@vger.kernel.org
> ---
>
> b/arch/x86/include/asm/fpu/types.h | 43
> ++---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff -puN arch/x86/include/asm/fpu/types.h~avx-512-structs
> arch/x86/include/asm/fpu/types.h
> --- a/arch/x86/include/asm/fpu/types.h~avx-512-structs2015-08-27
> 10:08:03.909740783 -0700
> +++ b/arch/x86/include/asm/fpu/types.h2015-08-27 10:08:03.912740919
> -0700
> @@ -129,6 +129,12 @@ enum xfeature_nr {
> struct reg_128_bit {
> u8 regbytes[128/8];
> };
> +struct reg_256_bit {
> + u8 regbytes[256/8];
> +};
> +struct reg_512_bit {
> + u8 regbytes[512/8];
> +};
>
> /*
> * State component 2:
> @@ -177,6 +183,33 @@ struct mpx_bndcsr_state {
> };
> } __packed;
>
> +/* AVX-512 Components: */
> +
> +/*
> + * State component 5 is used for the 8 64-bit opmask registers
> + * k0–k7 (opmask state).
> + */
> +struct avx_512_opmask_state {
> + u64 opmask_reg[8];
> +} __packed;
> +
> +/*
> + * State component 6 is used for the upper 256 bits of the
> + * registers ZMM0–ZMM15. These 16 256-bit values are denoted
> + * ZMM0_H–ZMM15_H (ZMM_Hi256 state).
> + */
> +struct avx_512_zmm_uppers_state {
> + struct reg_256_bit zmm_upper[16];
> +} __packed;
> +
> +/*
> + * State component 7 is used for the 16 512-bit registers
> + * ZMM16–ZMM31 (Hi16_ZMM state).
> + */
> +struct avx_512_hi16_state {
> + struct reg_512_bit hi16_zmm[16];
> +} __packed;
> +
> struct xstate_header {
> u64 xfeatures;
> u64 xcomp_bv;
> @@ -184,9 +217,13 @@ struct xstate_header {
> } __attribute__((packed));
>
> /* New processor state extensions should be added here: */
> -#define XSTATE_RESERVE (sizeof(struct ymmh_struct) + \
> - sizeof(struct mpx_bndreg_state) + \
> - sizeof(struct mpx_bndcsr_state) )
> +#define XSTATE_RESERVE (sizeof(struct ymmh_struct)
> + \
> + sizeof(struct mpx_bndreg_state)+ \
> + sizeof(struct mpx_bndcsr_state)+ \
> + sizeof(struct avx_512_opmask_state)+ \
> + sizeof(struct avx_512_zmm_uppers_state) + \
> + sizeof(struct avx_512_hi16_state))
So in a previous mail I suggested getting rid of XSTATE_RESERVE, which removes
the
usage of the C structures..
What we could use these C structures for is to double check that the xstate
size
given by CPUID for that particular xstate feature is equal to the C structure
size
- or if it's larger, it's a multiple of the natural cache line size, or so?
Any 'failure' in such a check should be print-once and non-fatal, as in 90% of
the
cases I'd expect the kernel assumptions/checks to be buggy, not the hardware
itself.
We should perhaps also print a gentle (non-warning) kernel message if we find
an
xfeature that the kernel doesn't know about, with its essential parameters: the
bit number, the size and the offset position within the xstate buffer.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations
* Dave Hansen wrote:
> +static int xfeature_is_supervisor(int xfeature_nr)
> +{
> + /*
> + * We currently do not suport supervisor states, but if
> + * we did, we could find out like this.
> + *
> + * SDM says: If state component i is a user state component,
> + * ECX[0] return 0; if state component i is a supervisor
> + * state component, ECX[0] returns 1.
> + u32 eax, ebx, ecx, edx;
> + cpuid_count(XSTATE_CPUID, xfeature_nr, , , , );
> + return !!(ecx & 1);
> + */
> + return 0;
> +}
So if this CPUID is documented to work, why not use it to sanity check things?
I.e. do something like:
u32 eax, ebx, ecx, edx;
cpuid_count(XSTATE_CPUID, xfeature_nr, , , , );
/* Linux doesn't support supervisor states (yet): */
WARN_ON_ONCE(ecx & 1);
return 0;
That would give us a gentle way to double check our assumptions here.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] x86, fpu: kill LWP support
* Dave Hansen wrote:
>
> From: Dave Hansen
>
> LightWeight Profiling was evidently an AMD profiling feature that
> we never got around to implementing. Remove the references to it.
>
> This patch is a *bit* worrisome becuase it will implicitly cause
> 'struct xregs_state' to shrink. This effectively removes some
> unused padding that we had in there. It might expose other bugs.
>
> Signed-off-by: Dave Hansen
> Cc: Ingo Molnar
> Cc: x...@kernel.org
> Cc: Borislav Petkov
> Cc: Fenghua Yu
> Cc: Tim Chen
> Cc: linux-kernel@vger.kernel.org
> ---
>
> b/arch/x86/include/asm/fpu/types.h |6 --
> 1 file changed, 6 deletions(-)
>
> diff -puN arch/x86/include/asm/fpu/types.h~axe-lwp
> arch/x86/include/asm/fpu/types.h
> --- a/arch/x86/include/asm/fpu/types.h~axe-lwp2015-08-27
> 10:08:01.195617135 -0700
> +++ b/arch/x86/include/asm/fpu/types.h2015-08-27 10:08:01.198617272
> -0700
> @@ -132,11 +132,6 @@ struct ymmh_struct {
> u8 ymmh_space[256];
> };
>
> -/* We don't support LWP yet: */
> -struct lwp_struct {
> - u8 reserved[128];
> -};
> -
> /* Intel MPX support: */
> struct bndreg {
> u64 lower_bound;
> @@ -161,7 +156,6 @@ struct xstate_header {
>
> /* New processor state extensions should be added here: */
> #define XSTATE_RESERVE (sizeof(struct ymmh_struct) + \
> - sizeof(struct lwp_struct) + \
>sizeof(struct mpx_struct) )
Btw., now that we allocate all this dynamically and sanity-check that the CPU
gives us, I'd suggest we remove the XSTATE_RESERVE define altogether, and any
excess __reserved[] bytes from the xstate header:
struct xregs_state {
struct fxregs_state i387;
struct xstate_headerheader;
u8 __reserved[XSTATE_RESERVE];
} __attribute__ ((packed, aligned (64)));
any latent bug this might trigger we want to fix.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
On Thu, 2015-08-27 at 18:43 -0400, George Spelvin wrote: > Jason Low wrote: > > Frederic suggested that we just use a single "status" variable and > > access the bits for the running and checking field. I am leaning towards > > that method, so I might not include the rest of the boolean changes in > > this patchset. > > Don't worry, I'm not offended. I just started editing and figured > I might as well share it. > > Whichever solution is easier. My only complaint about bitmapped variables > is that so many are "unsigned long" because the Linux atomic access > primitives, originally designed for file system bitmaps, use that type. > > But using that for a non array wastes 4 bytes on 64-bit platforms that > can't be used if the code is to work on 32-bit ones. > > >> E.g. suppose a process fails to notice that it blew past a CPU time > >> timeout before blocking. Does anything guarantee that it will get > >> the timeout signal in finite real time? > > > > Yep, the check_process_timers will get called again during the next > > scheduler interrupt (approximately after 1 jiffy) and send the signal if > > it finds that the timer expired then. > > Will it? I thought it got called on the running process only. > Which is not the (blocked by assumption) process of interest. > > I don't suspect that this would be a problem in practice, as CPU-time > timers are used on activities which use a *lot* of it. But it > seemed like a flaw worth either acknowledging or disproving. You're right, this is only called on running processes. If the process is blocked, sending the signal can get delayed. However, in practice, this is not really a problem as you mentioned. Also, this "issue" is also not really avoidable even without this patch. For instance, a timer may expire and the process can get block before the next scheduler interrupt. Thanks, Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma/ipu: change ipu_irq_handler() to remove compile warning
On Fri, Aug 28, 2015 at 10:03:32AM +0530, Vinod Koul wrote: > On Tue, Aug 25, 2015 at 04:01:08PM +0800, yalin wang wrote: > > Change ipu_irq_handler() to avoid gcc warning: > > > > drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used > > uninitialized in this function [-Wmaybe-uninitialized] > > generic_handle_irq(irq); > > Applied after fixing subsystem name Just to be clear, V2 of this patch was applied -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma/ipu: change ipu_irq_handler() to remove compile warning
On Tue, Aug 25, 2015 at 04:01:08PM +0800, yalin wang wrote: > Change ipu_irq_handler() to avoid gcc warning: > > drivers/dma/ipu/ipu_irq.c:305:4: warning: 'irq' may be used > uninitialized in this function [-Wmaybe-uninitialized] > generic_handle_irq(irq); Applied after fixing subsystem name -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On 27 August 2015 at 17:19, punnaiah choudary kalluri wrote: > On Thu, Aug 27, 2015 at 3:45 PM, Jagan Teki wrote: >> On 27 August 2015 at 14:18, punnaiah choudary kalluri >> wrote: >>> On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki wrote: On 26 August 2015 at 21:02, punnaiah choudary kalluri wrote: > On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki wrote: >> On 26 August 2015 at 11:56, Ranjit Waghmode >> wrote: >>> This series adds dual parallel mode support for Zynq Ultrascale+ >>> MPSoC GQSPI controller driver. >>> >>> What is dual parallel mode? >>> --- >>> ZynqMP GQSPI controller supports Dual Parallel mode with following >>> functionalities: >>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. >>> 2) Chip selects and clock are shared to both the flash devices >>> 3) This mode is targeted for faster read/write speed and also doubles >>> the size >>> 4) Commands/data can be transmitted/received from both the >>> devices(mirror), >>>or only upper or only lower flash memory devices. >>> 5) Data arrangement: >>>With stripe enabled, >>>Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus >>>Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. >>> >> I don't find any previous discussion about way to inform flash >> dual-ness into spi-nor >> from spi drivers. >> >> Here is my idea, probably others may think same. >> Informing dual_flash from drivers/spi through flags or any other mode >> bits is not a better approach as dual flash feature is specific to >> spi-nor flash controller (controller specially designed for spi-nor >> flash not the generic spi controller). So if the driver sits on >> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash >> specific things to spi-nor as it's not touching generic spi stack in >> Linux. But there is a defined-drawback if the driver is moved to >> drivers/mtd/spi-nor ie it can't use spi core API's at-all. > > Xilinx GQSPI is a generic quad spi controller. The primary goal is to > support > Generic/Future command sequences and Future NOR/NAND flash devices. > This core can also be used for legacy SPI devices. Due to the generic > nature > of the core, software can generate any command sequence. It also has > additional > features like parallel and stacked configurations to double the data > rate and size. > Accessing spi-nor flash device is one particular use case and like > that there will be > many. So, we decided to keep this driver in generic spi framework and > that is the ideal > thing to do for the GQSPI controller. Yes, I understand the generic nature of the GQSPI and it's good to have all-in-one like generic spi, spi-nor and spi-nand and more together, but Linux stacks were implemented in such a way to support the each type of controller with connected slaves separably for better handling. >>> >>> True and this is the reason we have controller drivers and protocol drivers. >>> GQSPI is the controller driver and spi-nor and spi-nand are the >>> protocol drivers. >>> Currently GQSPI driver is added in drivers/spi as it supports generic spi nature and now it enhanced more through flags for supporting spi-nor, what if we add spi-nand support for the same controller? do we add one more driver in spi-nand framework (drivers/mtd/spi-nand - an on going implementation)? My only observation here is even if the controller is more generic to support more number of device classes, and adding same driver and populate the slave stuff through flags or different kind of mechanism to different driver stack, this is not a better approach I thought. >>> >>> Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific >>> to flash parts, one can use for any other custom streaming protocols >>> I would say exporting dual parallel connection to protocol drivers is >>> something like depicting the spi bus topology to the protocol layer. >> >> So dual parallel may not used for spi-nor flash it can also used other >> spi slaves that's what your saying is it? > > Yes. As i said above, the main intention of this feature is to improve > the data rate with an overhead of few IO lines. > >> >>> >>> AFAIK, spi-nor and spi-nand are protocol drivers for accessing the >>> nor and nand flash devices sitting on the spi bus using the spi >>> controller driver. >> >> Yes, I do agree with your point, but though driver stacks are >> different with same kind of bus here, I'm trying to spit the GQSPI >> into 3 different controller drivers as Linux understand it and fit on >> to Linux stack with out disturbing the generic-ness. > > I feel this is not a nice idea. if there are 'n' functionalities and having >
[PATCH v2] Coresight: ETMv4: Prevent TRCRSCTLR0&1 from being accessed
1. TRCRSCTLRn - Resource Selection Control Registers n=0~1 are reserved,
we shouldn't access them.
2. The max number of 'n' here is defined in TRCIDR4.NUMRSPAIR whoes value
indicates the number of resource selection *pairs*, and 0 indicates
one resource selection pair, 1 indicates two pairs, and so on ...
So, the total number of resource selection control registers which we can
access is (TRCIDR4.NUMRSPAIR * 2)
Signed-off-by: Chunyan Zhang
---
drivers/hwtracing/coresight/coresight-etm4x.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 1312e99..fe93b47 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -136,7 +136,9 @@ static void etm4_enable_hw(void *info)
writel_relaxed(drvdata->cntr_val[i],
drvdata->base + TRCCNTVRn(i));
}
- for (i = 0; i < drvdata->nr_resource; i++)
+
+ /* Resource selector pair 0 is always implemented and reserved */
+ for (i = 2; i < drvdata->nr_resource * 2; i++)
writel_relaxed(drvdata->res_ctrl[i],
drvdata->base + TRCRSCTLRn(i));
@@ -489,8 +491,9 @@ static ssize_t reset_store(struct device *dev,
drvdata->cntr_val[i] = 0x0;
}
- drvdata->res_idx = 0x0;
- for (i = 0; i < drvdata->nr_resource; i++)
+ /* Resource selector pair 0 is always implemented and reserved */
+ drvdata->res_idx = 0x2;
+ for (i = 2; i < drvdata->nr_resource * 2; i++)
drvdata->res_ctrl[i] = 0x0;
for (i = 0; i < drvdata->nr_ss_cmp; i++) {
@@ -1729,7 +1732,7 @@ static ssize_t res_idx_store(struct device *dev,
if (kstrtoul(buf, 16, ))
return -EINVAL;
/* Resource selector pair 0 is always implemented and reserved */
- if ((val == 0) || (val >= drvdata->nr_resource))
+ if (val < 2 || val >= drvdata->nr_resource * 2)
return -EINVAL;
/*
@@ -2410,8 +2413,8 @@ static void etm4_init_arch_data(void *info)
drvdata->nr_addr_cmp = BMVAL(etmidr4, 0, 3);
/* NUMPC, bits[15:12] number of PE comparator inputs for tracing */
drvdata->nr_pe_cmp = BMVAL(etmidr4, 12, 15);
- /* NUMRSPAIR, bits[19:16] the number of resource pairs for tracing */
- drvdata->nr_resource = BMVAL(etmidr4, 16, 19);
+ /* NUMRSPAIR, bits[19:16] the number of resource pairs minus one */
+ drvdata->nr_resource = BMVAL(etmidr4, 16, 19) + 1;
/*
* NUMSSCC, bits[23:20] the number of single-shot
* comparator control for tracing
@@ -2498,6 +2501,8 @@ static void etm4_init_default_data(struct etmv4_drvdata
*drvdata)
drvdata->cntr_val[i] = 0x0;
}
+ /* Resource selector pair 0 is always implemented and reserved */
+ drvdata->res_idx = 0x2;
for (i = 2; i < drvdata->nr_resource * 2; i++)
drvdata->res_ctrl[i] = 0x0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
LF Ftrace parsers
Hello All, Is there any available ftrace parser tools to fetch various latency values especially for Scheduler task placement related. -- Thanks & Regards, M.Srikanth Kumar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
[ cut here ]
WARNING: CPU: 0 PID: 13 at kernel/sched/core.c:1156
do_set_cpus_allowed+0x7e/0x80()
Modules linked in:
CPU: 0 PID: 13 Comm: migration/0 Not tainted 4.2.0-rc1-00049-g25834c7 #2
Call Trace:
dump_stack+0x4b/0x75
warn_slowpath_common+0x8b/0xc0
? do_set_cpus_allowed+0x7e/0x80
? do_set_cpus_allowed+0x7e/0x80
warn_slowpath_null+0x22/0x30
do_set_cpus_allowed+0x7e/0x80
cpuset_cpus_allowed_fallback+0x7c/0x170
? cpuset_cpus_allowed+0x180/0x180
select_fallback_rq+0x221/0x280
migration_call+0xe3/0x250
notifier_call_chain+0x53/0x70
__raw_notifier_call_chain+0x1e/0x30
cpu_notify+0x28/0x50
take_cpu_down+0x22/0x40
multi_cpu_stop+0xd5/0x140
? __stop_cpus+0x80/0x80
cpu_stopper_thread+0xbc/0x170
? preempt_count_sub+0x9/0x50
? _raw_spin_unlock_irq+0x37/0x50
? _raw_spin_unlock_irqrestore+0x55/0x70
? trace_hardirqs_on_caller+0x144/0x1e0
? cpu_stop_should_run+0x35/0x40
? preempt_count_sub+0x9/0x50
? _raw_spin_unlock_irqrestore+0x41/0x70
smpboot_thread_fn+0x174/0x2f0
? sort_range+0x30/0x30
kthread+0xc4/0xe0
ret_from_kernel_thread+0x21/0x30
? kthread_create_on_node+0x180/0x180
---[ end trace 15f4c86d404693b0 ]---
As Peterz pointed out:
| So the normal rules for changing task_struct::cpus_allowed are holding
| both pi_lock and rq->lock, such that holding either stabilizes the mask.
|
| This is so that wakeup can happen without rq->lock and load-balance
| without pi_lock.
|
| From this we already get the relaxation that we can omit acquiring
| rq->lock if the task is not on the rq, because in that case
| load-balancing will not apply to it.
|
| ** these are the rules currently tested in do_set_cpus_allowed() **
|
| Now, since __set_cpus_allowed_ptr() uses task_rq_lock() which
| unconditionally acquires both locks, we could get away with holding just
| rq->lock when on_rq for modification because that'd still exclude
| __set_cpus_allowed_ptr(), it would also work against
| __kthread_bind_mask() because that assumes !on_rq.
|
| That said, this is all somewhat fragile.
|
| Now, I don't think dropping rq->lock is quite as disastrous as it
| usually is because !cpu_active at this point, which means load-balance
| will not interfere, but that too is somewhat fragile.
|
| So we end up with a choice of two fragile..
This patch fix it by following the rules for changing task_struct::cpus_allowed
w/ both pi_lock and rq->lock are held.
Reported-by: kernel test robot
Reported-by: Sasha Levin
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* fix the silly double lock stuff
* follow the rules for changing task_struct::cpus_allowed
kernel/sched/core.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b3386c6..8cf87e3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5186,6 +5186,27 @@ static void migrate_tasks(struct rq *dead_rq)
BUG_ON(!next);
next->sched_class->put_prev_task(rq, next);
+ /*
+* Rules for changing task_struct::cpus_allowed are holding
+* both pi_lock and rq->lock, such that holding either
+* stabilizes the mask.
+*
+* Drop rq->lock is not quite as disastrous as it usually is
+* because !cpu_active at this point, which means load-balance
+* will not interfere.
+*/
+ lockdep_unpin_lock(>lock);
+ raw_spin_unlock(>lock);
+ raw_spin_lock(>pi_lock);
+ raw_spin_lock(>lock);
+ lockdep_pin_lock(>lock);
+ if (!(task_rq(next) == rq && task_on_rq_queued(next))) {
+ lockdep_unpin_lock(>lock);
+ raw_spin_unlock(>lock);
+ raw_spin_unlock(>pi_lock);
+ continue;
+ }
+
/* Find suitable destination for @next, with force if needed. */
dest_cpu = select_fallback_rq(dead_rq->cpu, next);
@@ -5196,6 +5217,7 @@ static void migrate_tasks(struct rq *dead_rq)
rq = dead_rq;
raw_spin_lock(>lock);
}
+ raw_spin_unlock(>pi_lock);
}
rq->stop = stop;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
On Thu, 2015-08-27 at 13:31 +0200, Martin Schwidefsky wrote: > On Thu, 27 Aug 2015 13:12:05 +1000 > Michael Ellerman wrote: > > On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote: > > > On Thu, 20 Aug 2015, Michael Ellerman wrote: > > > > I'm reluctant to proceed with merging them though until we've heard at > > > > least > > > > *something* from the other maintainers. > > > > > > Ping again for the other-architecture maintainers (alpha, s390, sh, > > > sparc) > > > > OK I've put this whole series in a branch with the acks we have so far. > > > > I'll ask Stephen to put it in linux-next once 4.3-rc1 is out, and I'll ask > > Linus to pull it for 4.4 > > > > I haven't published the branch yet, so if the s390 and sparc maintainers > > want > > to send me acks I'll rebase and add them. > > For the s390 parts: > Acked-by: Martin Schwidefsky Thanks. So we're just waiting on davem for an ack for arch/sparc :D cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Thu, Aug 27, 2015 at 4:32 PM, Sean Fu wrote:
> On Thu, Aug 27, 2015 at 10:32 AM, Steven Rostedt wrote:
>> On Thu, 27 Aug 2015 08:17:29 +0800
>> Sean Fu wrote:
>>
>>> On Thu, Aug 27, 2015 at 4:36 AM, Steven Rostedt wrote:
>>> > On Wed, 26 Aug 2015 23:48:01 +0800
>>> > Sean Fu wrote:
>>> >
>>> >
>>> >> > Defending the patch, I can't imagine any user space code expecting the
>>> >> > current behavior. The current behavior is that if you write "1\0" it
>>> >> > will error out instead of accepting the "1". I can't come up with a
>>> >> > scenario that would require userspace to expect "1\0" to fail. Can you?
>>> >> Thanks
>>> >
>>> > Although, with the current patch, would "1\02" fail? It should.
>>> Yes, "1\02" is equal to "1\2"(count=2) or "1\2\0"(count=3), So it should
>>> fail.
>>
>> Sorry, I meant "1\0 2"
> In this case, The patch behavior is accepting the "1" and discarding
> other bytes.
> for (; left && vleft--; i++, first=0) {//vleft is 1 for integer
> type or unsigned long type proc file
>
>>
>> -- Steve
>>
>>>
>>> code
>>> len = write(fd, "1\0\2", 3);
>>>
>>> strace execute result:
>>> write(3, "1\2\0", 3)= -1 EINVAL (Invalid argument)
If vleft > 1, "1\0 2" is treated as invalid paraments and all string
include '\0' will be invalid.
>>>
>>> >
>>> > -- Steve
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] mmc: core: fix race condition in mmc_wait_data_done
On 2015/8/28 11:13, Shawn Lin wrote:
From: Jialing Fu
The following panic is captured in ker3.14, but the issue still exists
in latest kernel.
-
[ 20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer
dereference
at virtual address 0578
..
[ 20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
[ 20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
[ 20.740134] c0 3136 (Compiler) Call trace:
[ 20.740165] c0 3136 (Compiler) []
_raw_spin_lock_irqsave+0x24/0x60
[ 20.740200] c0 3136 (Compiler) [] __wake_up+0x1c/0x54
[ 20.740230] c0 3136 (Compiler) []
mmc_wait_data_done+0x28/0x34
[ 20.740262] c0 3136 (Compiler) []
mmc_request_done+0xa4/0x220
[ 20.740314] c0 3136 (Compiler) []
sdhci_tasklet_finish+0xac/0x264
[ 20.740352] c0 3136 (Compiler) [] tasklet_action+0xa0/0x158
[ 20.740382] c0 3136 (Compiler) [] __do_softirq+0x10c/0x2e4
[ 20.740411] c0 3136 (Compiler) [] irq_exit+0x8c/0xc0
[ 20.740439] c0 3136 (Compiler) [] handle_IRQ+0x48/0xac
[ 20.740469] c0 3136 (Compiler) [] gic_handle_irq+0x38/0x7c
--
Because in SMP, "mrq" has race condition between below two paths:
path1: CPU0:
static void mmc_wait_data_done(struct mmc_request *mrq)
{
mrq->host->context_info.is_done_rcv = true;
//
// If CPU0 has just finished "is_done_rcv = true" in path1, and at
// this moment, IRQ or ICache line missing happens in CPU0.
// What happens in CPU1 (path2)?
//
// If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
// path2 would have chance to break from wait_event_interruptible
// in mmc_wait_for_data_req_done and continue to run for next
// mmc_request (mmc_blk_rw_rq_prep).
//
// Within mmc_blk_rq_prep, mrq is cleared to 0.
// If below line still gets host from "mrq" as the result of
// compiler, the panic happens as we traced.
wake_up_interruptible(>host->context_info.wait);
}
path2: CPU1:
static int mmc_wait_for_data_req_done(...
{
...
while (1) {
wait_event_interruptible(context_info->wait,
(context_info->is_done_rcv ||
context_info->is_new_req));
static void mmc_blk_rw_rq_prep(...
{
...
memset(brq, 0, sizeof(struct mmc_blk_request));
This issue happens very coincidentally; however adding mdelay(1) in
mmc_wait_data_done as below could duplicate it easily.
static void mmc_wait_data_done(struct mmc_request *mrq)
{
mrq->host->context_info.is_done_rcv = true;
+mdelay(1);
wake_up_interruptible(>host->context_info.wait);
}
Hi, ulf
We find this bug on Intel-C3230RK platform for very small probability.
Whereas I can easily reproduce this case if I add a mdelay(1) or longer
delay as Jialing did.
This patch seems useful to me. Should we push it forward? :)
At runtime, IRQ or ICache line missing may just happen at the same place
of the mdelay(1).
This patch gets the mmc_context_info at the beginning of function, it can
avoid this race condition.
Signed-off-by: Jialing Fu
Tested-by: Shawn Lin
---
drivers/mmc/core/core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 664b617..0520064 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -358,8 +358,10 @@ EXPORT_SYMBOL(mmc_start_bkops);
*/
static void mmc_wait_data_done(struct mmc_request *mrq)
{
- mrq->host->context_info.is_done_rcv = true;
- wake_up_interruptible(>host->context_info.wait);
+ struct mmc_context_info *context_info = >host->context_info;
+
+ context_info->is_done_rcv = true;
+ wake_up_interruptible(_info->wait);
}
static void mmc_wait_done(struct mmc_request *mrq)
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] mmc: core: fix race condition in mmc_wait_data_done
From: Jialing Fu
The following panic is captured in ker3.14, but the issue still exists
in latest kernel.
-
[ 20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer
dereference
at virtual address 0578
..
[ 20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
[ 20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
[ 20.740134] c0 3136 (Compiler) Call trace:
[ 20.740165] c0 3136 (Compiler) []
_raw_spin_lock_irqsave+0x24/0x60
[ 20.740200] c0 3136 (Compiler) [] __wake_up+0x1c/0x54
[ 20.740230] c0 3136 (Compiler) []
mmc_wait_data_done+0x28/0x34
[ 20.740262] c0 3136 (Compiler) []
mmc_request_done+0xa4/0x220
[ 20.740314] c0 3136 (Compiler) []
sdhci_tasklet_finish+0xac/0x264
[ 20.740352] c0 3136 (Compiler) [] tasklet_action+0xa0/0x158
[ 20.740382] c0 3136 (Compiler) [] __do_softirq+0x10c/0x2e4
[ 20.740411] c0 3136 (Compiler) [] irq_exit+0x8c/0xc0
[ 20.740439] c0 3136 (Compiler) [] handle_IRQ+0x48/0xac
[ 20.740469] c0 3136 (Compiler) [] gic_handle_irq+0x38/0x7c
--
Because in SMP, "mrq" has race condition between below two paths:
path1: CPU0:
static void mmc_wait_data_done(struct mmc_request *mrq)
{
mrq->host->context_info.is_done_rcv = true;
//
// If CPU0 has just finished "is_done_rcv = true" in path1, and at
// this moment, IRQ or ICache line missing happens in CPU0.
// What happens in CPU1 (path2)?
//
// If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
// path2 would have chance to break from wait_event_interruptible
// in mmc_wait_for_data_req_done and continue to run for next
// mmc_request (mmc_blk_rw_rq_prep).
//
// Within mmc_blk_rq_prep, mrq is cleared to 0.
// If below line still gets host from "mrq" as the result of
// compiler, the panic happens as we traced.
wake_up_interruptible(>host->context_info.wait);
}
path2: CPU1:
static int mmc_wait_for_data_req_done(...
{
...
while (1) {
wait_event_interruptible(context_info->wait,
(context_info->is_done_rcv ||
context_info->is_new_req));
static void mmc_blk_rw_rq_prep(...
{
...
memset(brq, 0, sizeof(struct mmc_blk_request));
This issue happens very coincidentally; however adding mdelay(1) in
mmc_wait_data_done as below could duplicate it easily.
static void mmc_wait_data_done(struct mmc_request *mrq)
{
mrq->host->context_info.is_done_rcv = true;
+mdelay(1);
wake_up_interruptible(>host->context_info.wait);
}
At runtime, IRQ or ICache line missing may just happen at the same place
of the mdelay(1).
This patch gets the mmc_context_info at the beginning of function, it can
avoid this race condition.
Signed-off-by: Jialing Fu
Tested-by: Shawn Lin
---
drivers/mmc/core/core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 664b617..0520064 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -358,8 +358,10 @@ EXPORT_SYMBOL(mmc_start_bkops);
*/
static void mmc_wait_data_done(struct mmc_request *mrq)
{
- mrq->host->context_info.is_done_rcv = true;
- wake_up_interruptible(>host->context_info.wait);
+ struct mmc_context_info *context_info = >host->context_info;
+
+ context_info->is_done_rcv = true;
+ wake_up_interruptible(_info->wait);
}
static void mmc_wait_done(struct mmc_request *mrq)
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Lockups with 4.2-rc kernels and qemu
On Thu, Aug 27, 2015 at 05:52:58PM +0100, Ken Moffat wrote: > On Thu, Aug 27, 2015 at 12:59:14PM +0100, Ken Moffat wrote: > > On Tue, Aug 25, 2015 at 12:40:15AM +0100, Ken Moffat wrote: > > > (Cc'ing qemu-devel, please keep me in the Cc). > > > > > > TL;DR - qemu locks up my machine when I use 4.2-rc kernels. > > > > > Previous mail, or at least the copy to qemu, archived at > > https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg02784.html > > > > I started bisecting, but it is going to be a slow business - kernels > > which seem to be ok after e.g. 3 hours can still lock the box. I > > left it running overnight, and this morning it was still up - but > > firefox could no longer connect externally. I eventually tracked > > that to my logs taking the space. But one reason the logs had > > become so big was the following (found from this morning's restart): > > > > Aug 27 09:50:28 ac4tv kernel: [ 124.279813] BUG: scheduling while > > atomic: qemu-system-x86/1789/0x0002 > > Aug 27 09:50:28 ac4tv kernel: [ 124.279819] Modules linked in: > > psmouse i2c_piix4 asus_atk0110 microcode k10temp > > Aug 27 09:50:28 ac4tv kernel: [ 124.279828] Preemption disabled > > at:[] kvm_vcpu_ioctl+0x7c/0x580 > > This is definitely a *different* bug - I just tried the next kernel, > and started to get these messages (almost 100,000 lines of them in > the next 4 minutes) : if that had been happening a couple of weeks > ago, I would have noticed ;-) > > But, the end result is that I cannot attempt to bisect the lockups, > this scheduling while atomic business is preventing me looking for a > good kernel. > > Has anybody had success qith qemu on an x86_64 host running a 4.2-rc > kernel ? Looks as if I'll have to give up, and hope that the main > problem doe not spread to 4.1. > What will (hopefully) be my last comment on this - I went back to 4.1.3 on the host, and after a couple of hours it locked up. Maybe in the past I have jsut been lucky. I think in future I'll probably stick to native builds., it seems to be less painful. ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] arm64: dts: Add spi bus dts
Matthias,
On Mon, Aug 17, 2015 at 12:32 PM, Daniel Kurtz wrote:
> On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu wrote:
>>
>> This patch adds MT8173 spi bus controllers into device tree.
>>
>> Signed-off-by: Leilk Liu
>
> Reviewed-by: Daniel Kurtz
The other SPI patches have already been picked up in broonie's spi tree.
Can you pick this one into your mediatek tree?
Thanks.
-Dan
>
>> ---
>> Change in this patch:
>> pinctl and pad-select fields are board specific, so move to
>> mt8173-evb.dtsi, and status = "okay".
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
>> 2 files changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index 4be66ca..811cb76 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -387,6 +387,24 @@
>> };
>> };
>>
>> + {
>> + spi_pins_a: spi0 {
>> + pins_spi {
>> + pinmux = ,
>> + ,
>> + ,
>> + ;
>> + };
>> + };
>> +};
>> +
>> + {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_a>;
>> + mediatek,pad-select = <0>;
>> + status = "okay";
>> +};
>> +
>> {
>> status = "okay";
>> };
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..3dfb6ed 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,18 @@
>> status = "disabled";
>> };
>>
>> + spi: spi@1100a000 {
>> + compatible = "mediatek,mt8173-spi";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0 0x1100a000 0 0x1000>;
>> + interrupts = ;
>> + clocks = < CLK_TOP_SPI_SEL>,
>> +< CLK_TOP_SYSPLL3_D2>;
>> + clock-names = "spi-clk", "parent-clk";
>> + status = "disabled";
>> + };
>> +
>> i2c3: i2c3@1101 {
>> compatible = "mediatek,mt8173-i2c";
>> reg = <0 0x1101 0 0x70>,
>> --
>> 1.8.1.1.dirty
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
On 08/27/2015 06:30 PM, Yang, Wenyou wrote: -Original Message- From: Guenter Roeck [mailto:li...@roeck-us.net] Sent: 2015年8月7日 23:26 To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free- electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- watch...@vger.kernel.org Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer On 08/06/2015 03:16 AM, Wenyou Yang wrote: >From SAMA5D4, the watchdog timer is upgrated with a new feature, which is describled as in the datasheet, "WDT_MR can be written until a LOCKMR command is issued in WDT_CR". That is to say, as long as the bootstrap and u-boot don't issue a LOCKMR command, WDT_MR can be written more than once in the driver. So the SAMA5D4 watchdog driver's implementation is different from the at91sam9260 watchdog driver implemented in file at91sam9_wdt.c. The user application open the device file to enable the watchdog timer hardware, and close to disable it, and set the watchdog timer timeout by seting WDV and WDD fields of WDT_MR register, and ping the watchdog by issuing WDRSTT command to WDT_CR register with hard-coded key. Signed-off-by: Wenyou Yang Reviewed-by: Guenter Roeck Hi Vim, Can this patch series be merged? Could you please? It is included in the pull request I sent to Wim last week. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/5] atomics: introduce arch_atomic_op_{acquire,release,fence} helpers
Some architectures may have their special barriers for acquire, release
and fence semantics, general memory barriers(smp_mb__*_atomic()) in
__atomic_op_*() may be too strong, so arch_atomic_op_*() helpers are
introduced for architectures to provide their own version helpers to
build different variants based on _relaxed variants.
Signed-off-by: Boqun Feng
---
include/linux/atomic.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 00a5763..622255b 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -34,20 +34,33 @@
* The idea here is to build acquire/release variants by adding explicit
* barriers on top of the relaxed variant. In the case where the relaxed
* variant is already fully ordered, no additional barriers are needed.
+ *
+ * Besides, if an arch has a special barrier for acquire/release, it could
+ * implement its own arch_atomic_op_* and use the same framework for building
+ * variants
*/
+#ifndef arch_atomic_op_acquire
#define __atomic_op_acquire(op, args...) \
({ \
typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
smp_mb__after_atomic(); \
__ret; \
})
+#else
+#define __atomic_op_acquire arch_atomic_op_acquire
+#endif
+#ifndef arch_atomic_op_release
#define __atomic_op_release(op, args...) \
({ \
smp_mb__before_atomic();\
op##_relaxed(args); \
})
+#else
+#define __atomic_op_release arch_atomic_op_release
+#endif
+#ifndef arch_atomic_op_fence
#define __atomic_op_fence(op, args...) \
({ \
typeof(op##_relaxed(args)) __ret; \
@@ -56,6 +69,9 @@
smp_mb__after_atomic(); \
__ret; \
})
+#else
+#define __atomic_op_fence arch_atomic_op_fence
+#endif
/* atomic_add_return_relaxed */
#ifndef atomic_add_return_relaxed
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/5] atomics: add test for atomic operations with _relaxed variants
Some atomic operations now have _{relaxed, acquire, release} variants,
this patch then adds some trivial tests for two purpose:
1. test the behavior of these new operations in single-CPU
environment.
2. make their code generated before we actually use them somewhere,
so that we can examine their assembly code.
Signed-off-by: Boqun Feng
---
lib/atomic64_test.c | 91 ++---
1 file changed, 59 insertions(+), 32 deletions(-)
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index 83c33a5b..0484437 100644
--- a/lib/atomic64_test.c
+++ b/lib/atomic64_test.c
@@ -27,6 +27,50 @@ do {
\
(unsigned long long)r); \
} while (0)
+#define TEST_RETURN(bit, op, c_op, val)\
+do { \
+ atomic##bit##_set(, v0); \
+ r = v0; \
+ r c_op val; \
+ BUG_ON(atomic##bit##_##op(val, ) != r); \
+ BUG_ON(atomic##bit##_read() != r);\
+} while (0)
+
+#define TEST_RETURN_FAMILY(bit, op, c_op, val) \
+do { \
+ TEST_RETURN(bit, op, c_op, val);\
+ TEST_RETURN(bit, op##_acquire, c_op, val); \
+ TEST_RETURN(bit, op##_release, c_op, val); \
+ TEST_RETURN(bit, op##_relaxed, c_op, val); \
+} while (0)
+
+#define TEST_ARGS(bit, op, init, ret, expect, args...) \
+do { \
+ atomic##bit##_set(, init);\
+ BUG_ON(atomic##bit##_##op(, args) != ret);\
+ BUG_ON(atomic##bit##_read() != expect); \
+} while (0)
+
+#define TEST_XCHG_FAMILY(bit, init, new) \
+do { \
+ TEST_ARGS(bit, xchg, init, init, new, new); \
+ TEST_ARGS(bit, xchg_acquire, init, init, new, new); \
+ TEST_ARGS(bit, xchg_release, init, init, new, new); \
+ TEST_ARGS(bit, xchg_relaxed, init, init, new, new); \
+} while (0)
+
+#define TEST_CMPXCHG_FAMILY(bit, init, new, wrong) \
+do { \
+ TEST_ARGS(bit, cmpxchg, init, init, new, init, new);\
+ TEST_ARGS(bit, cmpxchg, init, init, init, wrong, new); \
+ TEST_ARGS(bit, cmpxchg_acquire, init, init, new, init, new);\
+ TEST_ARGS(bit, cmpxchg_acquire, init, init, init, wrong, new); \
+ TEST_ARGS(bit, cmpxchg_release, init, init, new, init, new);\
+ TEST_ARGS(bit, cmpxchg_release, init, init, init, wrong, new); \
+ TEST_ARGS(bit, cmpxchg_relaxed, init, init, new, init, new);\
+ TEST_ARGS(bit, cmpxchg_relaxed, init, init, init, wrong, new); \
+} while (0)
+
static __init void test_atomic(void)
{
int v0 = 0xaaa31337;
@@ -45,6 +89,15 @@ static __init void test_atomic(void)
TEST(, and, &=, v1);
TEST(, xor, ^=, v1);
TEST(, andnot, &= ~, v1);
+
+ TEST_RETURN_FAMILY(, add_return, +=, onestwos);
+ TEST_RETURN_FAMILY(, add_return, +=, -one);
+ TEST_RETURN_FAMILY(, sub_return, -=, onestwos);
+ TEST_RETURN_FAMILY(, sub_return, -=, -one);
+
+ TEST_XCHG_FAMILY(, v0, v1);
+ TEST_CMPXCHG_FAMILY(, v0, v1, onestwos);
+
}
#define INIT(c) do { atomic64_set(, c); r = c; } while (0)
@@ -74,25 +127,10 @@ static __init void test_atomic64(void)
TEST(64, xor, ^=, v1);
TEST(64, andnot, &= ~, v1);
- INIT(v0);
- r += onestwos;
- BUG_ON(atomic64_add_return(onestwos, ) != r);
- BUG_ON(v.counter != r);
-
- INIT(v0);
- r += -one;
- BUG_ON(atomic64_add_return(-one, ) != r);
- BUG_ON(v.counter != r);
-
- INIT(v0);
- r -= onestwos;
- BUG_ON(atomic64_sub_return(onestwos, ) != r);
- BUG_ON(v.counter != r);
-
- INIT(v0);
- r -= -one;
- BUG_ON(atomic64_sub_return(-one, ) != r);
- BUG_ON(v.counter != r);
+ TEST_RETURN_FAMILY(64, add_return, +=, onestwos);
+ TEST_RETURN_FAMILY(64, add_return, +=, -one);
+ TEST_RETURN_FAMILY(64, sub_return, -=, onestwos);
+ TEST_RETURN_FAMILY(64, sub_return, -=, -one);
INIT(v0);
atomic64_inc();
@@ -114,19 +152,8 @@ static __init void test_atomic64(void)
BUG_ON(atomic64_dec_return() != r);
BUG_ON(v.counter != r);
- INIT(v0);
- BUG_ON(atomic64_xchg(, v1) != v0);
- r = v1;
- BUG_ON(v.counter != r);
-
- INIT(v0);
- BUG_ON(atomic64_cmpxchg(, v0, v1) !=
[RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants
On powerpc, we don't need a general memory barrier to achieve acquire and
release semantics, so arch_atomic_op_{acquire,release} can be implemented
using "lwsync" and "isync".
For release semantics, since we only need to ensure all memory accesses
that issue before must take effects before the -store- part of the
atomics, "lwsync" is what we only need. On the platform without
"lwsync", "sync" should be used. Therefore, smp_lwsync() is used here.
For acquire semantics, "lwsync" is what we only need for the similar
reason. However on the platform without "lwsync", we can use "isync"
rather than "sync" as an acquire barrier. So a new kind of barrier
smp_acquire_barrier__after_atomic() is introduced, which is barrier() on
UP, "lwsync" if available and "isync" otherwise.
For full ordered semantics, like the original ones, smp_lwsync() is put
before relaxed variants and smp_mb__after_atomic() is put after.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 88 ---
1 file changed, 64 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 55f106e..806ce50 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -12,6 +12,39 @@
#define ATOMIC_INIT(i) { (i) }
+/*
+ * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
+ * a "bne-" instruction at the end, so an isync is enough as a acquire barrier
+ * on the platform without lwsync.
+ */
+#ifdef CONFIG_SMP
+#define smp_acquire_barrier__after_atomic() \
+ __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory")
+#else
+#define smp_acquire_barrier__after_atomic() barrier()
+#endif
+#define arch_atomic_op_acquire(op, args...)\
+({ \
+ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
+ smp_acquire_barrier__after_atomic();\
+ __ret; \
+})
+
+#define arch_atomic_op_release(op, args...)\
+({ \
+ smp_lwsync(); \
+ op##_relaxed(args); \
+})
+
+#define arch_atomic_op_fence(op, args...) \
+({ \
+ typeof(op##_relaxed(args)) __ret; \
+ smp_lwsync(); \
+ __ret = op##_relaxed(args); \
+ smp_mb__after_atomic(); \
+ __ret; \
+})
+
static __inline__ int atomic_read(const atomic_t *v)
{
int t;
@@ -42,27 +75,27 @@ static __inline__ void atomic_##op(int a, atomic_t *v)
\
: "cc");\
} \
-#define ATOMIC_OP_RETURN(op, asm_op) \
-static __inline__ int atomic_##op##_return(int a, atomic_t *v) \
+#define ATOMIC_OP_RETURN_RELAXED(op, asm_op) \
+static inline int atomic_##op##_return_relaxed(int a, atomic_t *v) \
{ \
int t; \
\
__asm__ __volatile__( \
- PPC_ATOMIC_ENTRY_BARRIER\
-"1:lwarx %0,0,%2 # atomic_" #op "_return\n" \
- #asm_op " %0,%1,%0\n" \
- PPC405_ERR77(0,%2) \
-" stwcx. %0,0,%2 \n" \
+"1:lwarx %0,0,%3 # atomic_" #op "_return_relaxed\n" \
+ #asm_op " %0,%2,%0\n" \
+ PPC405_ERR77(0, %3) \
+" stwcx. %0,0,%3\n" \
" bne-1b\n" \
- PPC_ATOMIC_EXIT_BARRIER \
- : "=" (t) \
+ : "=" (t), "+m" (v->counter) \
: "r" (a), "r" (>counter)\
- : "cc", "memory"); \
+ : "cc");
[RFC 4/5] powerpc: atomic: implement xchg_* and atomic{,64}_xchg_* variants
Implement xchg_relaxed and define atomic{,64}_xchg_* as xchg_relaxed,
based on these _relaxed variants, release/acquire variants can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 2 ++
arch/powerpc/include/asm/cmpxchg.h | 64 ++
2 files changed, 66 insertions(+)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 806ce50..4965dcf 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -193,6 +193,7 @@ static __inline__ int atomic_dec_return(atomic_t *v)
#define atomic_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
+#define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
* __atomic_add_unless - add unless the number is a given value
@@ -461,6 +462,7 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t
*v)
#define atomic64_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
+#define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
/**
* atomic64_add_unless - add unless the number is a given value
diff --git a/arch/powerpc/include/asm/cmpxchg.h
b/arch/powerpc/include/asm/cmpxchg.h
index ad6263c..66374f4 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -54,6 +54,32 @@ __xchg_u32_local(volatile void *p, unsigned long val)
return prev;
}
+/*
+ * Atomic exchange relaxed
+ *
+ * Changes the memory location '*p' to be val and returns
+ * the previous value stored there.
+ *
+ * Note that this is not a compiler barrier, there is no order
+ * guarantee around.
+ */
+static __always_inline unsigned long
+__xchg_u32_relaxed(u32 *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1:lwarx %0,0,%2\n"
+ PPC405_ERR77(0, %2)
+" stwcx. %3,0,%2\n"
+" bne-1b"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (val)
+ : "cc");
+
+ return prev;
+}
+
#ifdef CONFIG_PPC64
static __always_inline unsigned long
__xchg_u64(volatile void *p, unsigned long val)
@@ -90,6 +116,23 @@ __xchg_u64_local(volatile void *p, unsigned long val)
return prev;
}
+
+static __always_inline unsigned long
+__xchg_u64_relaxed(u64 *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1:ldarx %0,0,%2\n"
+ PPC405_ERR77(0, %2)
+" stdcx. %3,0,%2\n"
+" bne-1b"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (val)
+ : "cc");
+
+ return prev;
+}
#endif
/*
@@ -127,6 +170,21 @@ __xchg_local(volatile void *ptr, unsigned long x, unsigned
int size)
__xchg_called_with_bad_pointer();
return x;
}
+
+static __always_inline unsigned long
+__xchg_relaxed(void *ptr, unsigned long x, unsigned int size)
+{
+ switch (size) {
+ case 4:
+ return __xchg_u32_relaxed(ptr, x);
+#ifdef CONFIG_PPC64
+ case 8:
+ return __xchg_u64_relaxed(ptr, x);
+#endif
+ }
+ __xchg_called_with_bad_pointer();
+ return x;
+}
#define xchg(ptr,x) \
({\
__typeof__(*(ptr)) _x_ = (x); \
@@ -140,6 +198,12 @@ __xchg_local(volatile void *ptr, unsigned long x, unsigned
int size)
(unsigned long)_x_, sizeof(*(ptr))); \
})
+#define xchg_relaxed(ptr, x) \
+({ \
+ __typeof__(*(ptr)) _x_ = (x); \
+ (__typeof__(*(ptr))) __xchg_relaxed((ptr), \
+ (unsigned long)_x_, sizeof(*(ptr)));\
+})
/*
* Compare and exchange - if *p == old, set it to new,
* and return the old value of *p.
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 5/5] powerpc: atomic: implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants
Unlike other atomic operation variants, cmpxchg{,64}_acquire and
atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
fails, so we need to implement these using assembly.
Note cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed are not
compiler barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 141 -
2 files changed, 150 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index 4965dcf..ef8d062 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -192,6 +192,11 @@ static __inline__ int atomic_dec_return(atomic_t *v)
}
#define atomic_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
+#define atomic_cmpxchg_relaxed(v, o, n) \
+ cmpxchg_relaxed(&((v)->counter), (o), (n))
+#define atomic_cmpxchg_acquire(v, o, n) \
+ cmpxchg_acquire(&((v)->counter), (o), (n))
+
#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
@@ -461,6 +466,11 @@ static __inline__ long atomic64_dec_if_positive(atomic64_t
*v)
}
#define atomic64_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
+#define atomic64_cmpxchg_relaxed(v, o, n) \
+ cmpxchg_relaxed(&((v)->counter), (o), (n))
+#define atomic64_cmpxchg_acquire(v, o, n) \
+ cmpxchg_acquire(&((v)->counter), (o), (n))
+
#define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
#define atomic64_xchg_relaxed(v, new) xchg_relaxed(&((v)->counter), (new))
diff --git a/arch/powerpc/include/asm/cmpxchg.h
b/arch/powerpc/include/asm/cmpxchg.h
index 66374f4..f40f295 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -254,6 +254,48 @@ __cmpxchg_u32_local(volatile unsigned int *p, unsigned
long old,
return prev;
}
+static __always_inline unsigned long
+__cmpxchg_u32_relaxed(u32 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1:lwarx %0,0,%2 # __cmpxchg_u32_relaxed\n"
+" cmpw0,%0,%3\n"
+" bne-2f\n"
+ PPC405_ERR77(0, %2)
+" stwcx. %4,0,%2\n"
+" bne-1b\n"
+"2:"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u32_acquire(u32 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1:lwarx %0,0,%2 # __cmpxchg_u32_acquire\n"
+" cmpw0,%0,%3\n"
+" bne-2f\n"
+ PPC405_ERR77(0, %2)
+" stwcx. %4,0,%2\n"
+" bne-1b\n"
+ PPC_ACQUIRE_BARRIER
+ "\n"
+"2:"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
#ifdef CONFIG_PPC64
static __always_inline unsigned long
__cmpxchg_u64(volatile unsigned long *p, unsigned long old, unsigned long new)
@@ -297,6 +339,46 @@ __cmpxchg_u64_local(volatile unsigned long *p, unsigned
long old,
return prev;
}
+
+static __always_inline unsigned long
+__cmpxchg_u64_relaxed(u64 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1:ldarx %0,0,%2 # __cmpxchg_u64_relaxed\n"
+" cmpd0,%0,%3\n"
+" bne-2f\n"
+" stdcx. %4,0,%2\n"
+" bne-1b\n"
+"2:"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u64_acquire(u64 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1:ldarx %0,0,%2 # __cmpxchg_u64_acquire\n"
+" cmpd0,%0,%3\n"
+" bne-2f\n"
+" stdcx. %4,0,%2\n"
+" bne-1b\n"
+ PPC_ACQUIRE_BARRIER
+ "\n"
+"2:"
+ : "=" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
#endif
/* This function doesn't exist, so you'll get a linker error
@@ -335,6 +417,37 @@ __cmpxchg_local(volatile void *ptr, unsigned long old,
unsigned long new,
return old;
}
+static __always_inline unsigned long
+__cmpxchg_relaxed(void *ptr, unsigned long old, unsigned long new,
+ unsigned int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32_relaxed(ptr, old, new);
+#ifdef CONFIG_PPC64
+ case 8:
+ return __cmpxchg_u64_relaxed(ptr, old, new);
+#endif
+ }
+ __cmpxchg_called_with_bad_pointer();
+ return old;
+}
+
+static __always_inline unsigned long
+__cmpxchg_acquire(void *ptr, unsigned long old, unsigned long new,
+ unsigned int size)
+{
+ switch (size) {
+ case 4:
+
[RFC 0/5] atomics: powerpc: implement relaxed/acquire/release variants of some atomics
Relaxed/acquire/release variants of atomic operations {add,sub}_return and
{cmp,}xchg are introduced by commit:
"atomics: add acquire/release/relaxed variants of some atomic operations"
which is now on locking/core branch of tip tree.
By default, the generic code will implement relaxed variants as a full
ordered atomic operation and release/acquire variants as a relaxed variants
with a necessary general barrier before or after.
On powerpc, which has a weak memory order model, a relaxed variant can be
implemented more lightweightly than a full ordered one. Further more,
release and acquire variants can be implemented with arch-specific
lightweight barriers.
Therefore this patchset implements the relaxed/acquire/release variants
based on powerpc memory model and specific barriers. A trivial test for
these new variants is also included in this series, because some of these
variants are not used in kernel for now, I would like to make the code of
these variants at least generated somewhere.
The patchset consists of 5 parts:
1. add trivial tests for the new variants in lib/atomic64_test.c
2. introduce arch_atomic_op_*() helpers as the arch-specific helpers
to build other variants based on relaxed.
3. implement atomic{,64}_{add,sub}_return_* variants
4. implement xchg_* and atomic{,64}_xchg_* variants
5. implement cmpxchg_* atomic{,64}_cmpxchg_* variants
This patchset is based on locking/core branch of tip tree and all patches
are built and boot tested for LE pseries.
Regards,
Boqun
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote: > > Hi, > > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen > > wrote: > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: > > >> Hi, > > >> > > >> > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan > > >> wrote: > > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, > > >> > unlike the default platform data. Add platform data specific to the > > >> > Zynq udc. > > >> > > > >> > Based on a patch by the same name from the Xilinx vendor tree. > > >> > > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as > > >> temporary fix and > > >> I did not debug further why UDC works only when streaming is enabled. > > >> Probably this is right time to post my question here. > > >> I was expecting like: > > >> Streaming disabled - both low bandwidth and high bandwidth systems > > >> should work fine > > >> Streaming enabled - only for high bandwidth systems > > >> but this is not the case, Zynq UDC works only when Streaming is enabled. > > >> Please correct me if I am wrong. > > > > > > You are right, stream mode disabled should work at anytime. > > > It is so strange why zynq UDC only works when stream mode is enabled. > > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc > > 2.20a, > > this is what it says about SDIS (streaming mode disable option) > > > > Before activating this mode, the user must check if the TX latency > > buffers per endpoint are able to > > accommodate at least one entire maximum size packet. The RX buffer > > size must, at least, double the TX > > buffer size per endpoint. To optimize the stream disable performance, > > system bus burst must be set as high > > as possible. > > When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST > > and VUSB_HS_TX_BURST) > > must be a integer sub-multiple of the latency buffer size > > (VUSB_HS_RX_DEPTH for RX buffer and > > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the > > controller will not work properly in stream > > disable mode. > > The stream disable mode should just be used in situations where the > > available system bandwidth is low or the > > system bus access latency is high, in order to avoid underruns and > > overruns in the latency buffers. This works > > for all types of endpoints, except for ISO endpoints. > > Such a system can't ensure the real time support that the ISO > > endpoints require, so the ISO endpoints are not > > supported when the SDIS bit is set. > > > > Definitely we need to root cause why disable streaming mode is not > > working for zynq but from controller spec > > point of view it is possible that controller not work properly in > > stream disable mode. > > > > Regards, > > Punnaiah > > > > Maybe the burst size isn't set correctly by default? It does say the > controller > won't work correctly with stream disable set and an invalid burst size. Looks > like TX and RX burst both default to 16, per the Zynq manual. > > With the stream disable bit set, the behvior we see on our hardware is > that priming just stops, with an outstanding transfer in memory marked > active in the status field by the controller. This happens at random, even > when doing single transfers at a time like with g_ether set to have a queue > size of 1. With SDIS clear everything works great. Given that the Zynq is > not > bandwidth constrained, it seems like SDIS clear should be the default. > I suspect the possible reason is the tx buffer for each endpoint is small (<=512 bytes), so it can't copy one packet (assume max packet size for bulk) to tx buffer, then the prime can't be finished. Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS ($BASE + 124)? tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * (DWORD_PER_BYTES) DWORD_PER_BYTES is 4 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] macvtap/macvlan: use IFF_NO_QUEUE
On 08/27/2015 06:43 PM, Michael S. Tsirkin wrote:
> On Wed, Aug 26, 2015 at 01:45:30PM +0800, Jason Wang wrote:
>>
>> On 08/26/2015 12:32 AM, Vlad Yasevich wrote:
>>> On 08/25/2015 07:30 AM, Jason Wang wrote:
On 08/25/2015 06:17 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 24, 2015 at 04:33:12PM +0800, Jason Wang wrote:
>>> For macvlan, switch to use IFF_NO_QUEUE instead of tx_queue_len = 0.
>>>
>>> For macvtap, after commit 6acf54f1cf0a6747bac9fea26f34cfc5a9029523
>>> ("macvtap: Add support of packet capture on macvtap
>>> device."). Multiqueue macvtap suffers from single qdisc lock
>>> contention. This is because macvtap claims a non zero tx_queue_len and
>>> it reuses this value as it socket receive queue size.Thanks to
>>> IFF_NO_QUEUE, we can remove the lock contention without breaking
>>> existing socket receive queue length logic.
>>>
>>> Cc: Patrick McHardy
>>> Cc: Vladislav Yasevich
>>> Cc: Michael S. Tsirkin
>>> Signed-off-by: Jason Wang
> Seems to make sense. Give me a day or two to get over the jet lag
> (and get out from under the pile of mail accumulated while I was
> traveling),
> I'll review properly and ack.
>
A note on this patch: only default qdisc were removed but we don't lose
the ability to attach a qdisc to macvtap (though it may cause lock
contention on multiqueue case).
>>> Wouldn't that lock contention be solved if we really had multiple queues
>>> for multi-queue macvtaps?
>>>
>>> -vlad
>> Yes, but this introduce another layer of txq locks contention?
> I don't follow - why does it? Could you clarify please?
I believe Vlad wants to remove NETIF_F_LLTX. If yes, core will do an
extra tx lock at macvlan layer.
>
>> And it
>> also needs macvlan multiqueue support. We used to do something like this
>> but switch to NETIF_F_LLTX finally. You may refer:
>>
>> 2c11455321f37da6fe6cc36353149f9ac9183334 macvlan: add multiqueue capability
>> 8ffab51b3dfc54876f145f15b351c41f3f703195 macvlan: lockless tx path
> My concern is that the moment someone configures a non-standard qdisc
> scalability suddenly disappears. That would also be tricky to debug in the
> field as not a lot of developers use non-standard qdiscs.
> What do you think?
Probably not an issue. Non-standard qdisc may need be attached manually
after device creation, and we don't lose this ability with this patch.
(Unless somebody changes default_qdisc). Actually, user before
6acf54f1cf0a6747bac9fea26f34cfc5a9029523 does not expect any qdisc work
for macvtap like other stacked devices. This patch also restore this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Module signing broken after SYSTEM_DATA_VERIFICATION commit?
I build kernels with MODULE_SIG=y, MODULE_SIG_FORCE=n (for build and run coverage, but it shouldn't dork my system if it breaks). next-20150810 works just fine, but next-20150826 breaks modprobe - all calls to it drop this in the dmesg: [ 31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3 [ 31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3 [ 31.829330] Unsupported digest algo: 55 and the modprobe fails. This looks like the most suspicious commit in the area: commit 091f6e26eb326adbd718f406e440c838bed8ebb6 Author: David Howells Date: Mon Jul 20 21:16:28 2015 +0100 MODSIGN: Extract the blob PKCS#7 signature verifier from module signing though it could be something else equally recent. Is this ringing any bells, or should I go bisect it? pgpey9XpFGLjW.pgp Description: PGP signature
Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
On Thu, Aug 27, 2015 at 7:49 PM, Punit Agrawal wrote:
> [ + device tree folks ]
>
> Hi Sascha,
>
> When introducing a new binding, it is a good idea to get reviews from
> the device tree maintainers. I've added a few folks here. Please keep
> them in the loop for future postings.
>
> Sascha Hauer writes:
>
>> Signed-off-by: Sascha Hauer
>> Reviewed-by: Daniel Kurtz
>
> Please add a commit log.
>
>> ---
>> .../bindings/thermal/mediatek-thermal.txt | 38
>> ++
>> include/dt-bindings/thermal/mt8173.h | 13
>> 2 files changed, 51 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> create mode 100644 include/dt-bindings/thermal/mt8173.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> new file mode 100644
>> index 000..1697375
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> @@ -0,0 +1,38 @@
>> +* Mediatek Thermal
>> +
>> +This describes the device tree binding for the Mediatek thermal controller
>> +which measures the on-SoC temperatures. This device does not have its own
>> ADC,
>> +instead it directly controls the AUXADC via AHB bus accesses. For this
>> reason
>> +this device needs phandles to the AUXADC. Also it controls a mux in the
>> +apmixedsys register space via AHB bus accesses, so a phandle to the
>> APMIXEDSYS
>> +is also needed.
>> +
>> +Required properties:
>> +- compatible: "mediatek,mt8173-thermal"
>> +- reg: Address range of the thermal controller
>> +- interrupts: IRQ for the thermal controller
>> +- clocks, clock-names: Clocks needed for the thermal controller. required
>> + clocks are:
>> +"therm": Main clock needed for register access
>> +"auxadc": The AUXADC clock
>> +- resets: Reference to the reset controller controlling the thermal
>> controller.
>> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
>> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
>> +- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
>> See
>> + include/dt-bindings/thermal/mt8173.h for valid sensor
>> + numbers.
>> +
>> +Example:
>> +
>> + thermal: thermal@1100b000 {
>> + #thermal-sensor-cells = <1>;
>> + compatible = "mediatek,mt8173-thermal";
>> + reg = <0 0x1100b000 0 0x1000>;
>> + interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = < CLK_PERI_THERM>, < CLK_PERI_AUXADC>;
>> + clock-names = "therm", "auxadc";
>> + resets = < MT8173_PERI_THERM_SW_RST>;
>> + reset-names = "therm";
>> + mediatek,auxadc = <>;
>> + mediatek,apmixedsys = <>;
>> + };
>> diff --git a/include/dt-bindings/thermal/mt8173.h
>> b/include/dt-bindings/thermal/mt8173.h
>> new file mode 100644
>> index 000..692e74c
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/mt8173.h
>> @@ -0,0 +1,13 @@
>> +/*
>> + * This header provides constants for mediatek,mt8173-thermal
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +#define _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +
>> +#define MT8173_THERMAL_ZONE_CA53 0
>> +#define MT8173_THERMAL_ZONE_CA57 1
>> +#define MT8173_THERMAL_ZONE_GPU 2
>> +#define MT8173_THERMAL_ZONE_CORE 3
>> +
>> +#endif /* _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H */
>
> The constants in this include are not used in the patchset. Please drop
> this hunk and introduce it when you use it.
These constants are part of the devicetree ABI, and I believe they
should be included with the binding.
To make this more concrete, I think these constants could be used as
array indices when initializing the corresponding banks of "bank_data"
in patch 2 (like you do when initializing scp_domain_data in the
scpsys driver).
-Dan
>
> Thanks,
> Punit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/5] thermal: power_allocator: don't require tzp to be present for the thermal zone
On Wed, Aug 26, 2015 at 9:26 PM, Javi Merino wrote:
> Thermal zones created using thermal_zone_device_create() may not have
> tzp. As the governor gets its parameters from there, allocate it while
> the governor is bound to the thermal zone so that it can operate in it.
> In this case, tzp is freed when the thermal zone switches to another
> governor.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Javi Merino
> ---
>
> While this would be easier to do by just ignoring the thermal zone if
> there was no tzp, I think the approach in this patch provides a better
> behavior.
Why?
Just ignoring the thermal zone seems reasonable and simpler.
>
> drivers/thermal/power_allocator.c | 32 +++-
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/power_allocator.c
> b/drivers/thermal/power_allocator.c
> index 2dfb8ade4d1b..85ce0aac9a41 100644
> --- a/drivers/thermal/power_allocator.c
> +++ b/drivers/thermal/power_allocator.c
> @@ -58,6 +58,8 @@ static inline s64 div_frac(s64 x, s64 y)
>
> /**
> * struct power_allocator_params - parameters for the power allocator
> governor
> + * @allocated_tzp: whether we have allocated tzp for this thermal zone
> and
> + * it needs to be freed on unbind
> * @err_integral: accumulated error in the PID controller.
> * @prev_err: error in the previous iteration of the PID controller.
> * Used to calculate the derivative term.
> @@ -70,6 +72,7 @@ static inline s64 div_frac(s64 x, s64 y)
> * controlling for.
> */
> struct power_allocator_params {
> + bool allocated_tzp;
> s64 err_integral;
> s32 prev_err;
> int trip_switch_on;
> @@ -530,8 +533,7 @@ static void allow_maximum_power(struct
> thermal_zone_device *tz)
> * Initialize the PID controller parameters and bind it to the thermal
> * zone.
> *
> - * Return: 0 on success, -EINVAL if the thermal zone doesn't have tzp or
> -ENOMEM
> - * if we ran out of memory.
> + * Return: 0 on success, or -ENOMEM if we ran out of memory.
> */
> static int power_allocator_bind(struct thermal_zone_device *tz)
> {
> @@ -539,13 +541,20 @@ static int power_allocator_bind(struct
> thermal_zone_device *tz)
> struct power_allocator_params *params;
> unsigned long control_temp;
>
> - if (!tz->tzp)
> - return -EINVAL;
> -
> params = kzalloc(sizeof(*params), GFP_KERNEL);
> if (!params)
> return -ENOMEM;
>
> + if (!tz->tzp) {
> + tz->tzp = kzalloc(sizeof(*tz->tzp), GFP_KERNEL);
Why bother to allocate this dummy struct?
Can't we just leave tz->tzp as NULL, and do a NULL check where needed?
> + if (!tz->tzp) {
> + ret = -ENOMEM;
> + goto free_params;
> + }
> +
> + params->allocated_tzp = true;
> + }
> +
> if (!tz->tzp->sustainable_power)
> dev_warn(>device, "power_allocator: sustainable_power
> will be estimated\n");
>
> @@ -562,11 +571,24 @@ static int power_allocator_bind(struct
> thermal_zone_device *tz)
> tz->governor_data = params;
>
> return 0;
> +
> +free_params:
> + kfree(params);
> +
> + return ret;
> }
>
> static void power_allocator_unbind(struct thermal_zone_device *tz)
> {
> + struct power_allocator_params *params = tz->governor_data;
> +
> dev_dbg(>device, "Unbinding from thermal zone %d\n", tz->id);
> +
> + if (params->allocated_tzp) {
> + kfree(tz->tzp);
> + tz->tzp = NULL;
> + }
> +
> kfree(tz->governor_data);
> tz->governor_data = NULL;
> }
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
YOUR CONSENT REQUIRED
Dear Beneficiary, I work with a financial firm(Bank), as an Independent Auditor. I have discovered an abandoned client's unserviced bank account having the same account holder's last name as yours. Please I would like us to work together to secure this funds. Kindly get back to me for more details. Best Regards, Mustafa Mahmoud Jaga. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: dts: mediatek: mt8173 PSCI-1.0 support
From: Fan Chen
This patch adds psci comatible properties to support all mandatory
functions of PSCI-1.0, PSCI-0.2 and PSCI-0.1, and system suspend
can be supported in PSCI-1.0.
Signed-off-by: Fan Chen
---
Because PSCI-1.0 patches hadn't landed on mainline, this patch is
based on three patch sets below:
[0] http://www.spinics.net/lists/arm-kernel/msg425793.html
PSCI: system suspend support
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
psci/unification
[2] http://www.spinics.net/lists/devicetree/msg82017.html
[PATCH 0/6] drivers: firmware: psci: add basic v1.0 support
Before they are merged in, this patch still works fine with psci-0.2
support in current mainline.
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index d18ee42..b9b4205 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -95,7 +95,7 @@
};
psci {
- compatible = "arm,psci";
+ compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
method = "smc";
cpu_suspend = <0x8401>;
cpu_off = <0x8402>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs
Kevin, On Thu, Aug 27, 2015 at 5:24 PM, Kevin Hilman wrote: >> That is not really workable: the attach and detach happen in >> probe/remove path; if you do not have driver for the device you will >> miss the clocks for it. > > And in my proposal, I suggested that clocks without drivers are > good candidates to list in the domain, with the caveat that the be > called out (documented) as being device clocks that are missing a > driver, so when a driver shows up they can be moved accordingly, and in > a way that actually describes the hardware. What happens if someone disables the driver using the CONFIG subsystem? What happens if this is a device that someone has set to 'status = "disabled";' in the device tree? Even if the device is disabled in one of those two ways, we still need the clocks to be turned on. ...so if we turn on/off the VIO domain we need to turn on the EDP clock even if there's no EDP in the current board / config. We might turn on/off VIO for one of the other devices in the VIO domain for one of the other devices in VIO that we are using. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MIPS: BCM63XX: Use pr_* instead of printk
On Thu, 2015-08-27 at 18:30 -0700, Gregory Fong wrote:
>
If you ever do more of these, here are a few trivial style notes:
> diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +#define pr_fmt(fmt) "board_bcm963xx: " fmt
Using:
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
is more common
> @@ -740,7 +741,7 @@ int bcm63xx_get_fallback_sprom(struct ssb_bus *bus,
> struct ssb_sprom *out)
> memcpy(out, _sprom, sizeof(struct ssb_sprom));
> return 0;
> } else {
> - printk(KERN_ERR PFX "unable to fill SPROM for given
> bustype.\n");
> + pr_err("unable to fill SPROM for given bustype.\n");
The periods at the end of logging lines are generally
superfluous and can be removed.
> @@ -808,7 +809,7 @@ void __init board_prom_init(void)
> char name[17];
> memcpy(name, board_name, 16);
> name[16] = 0;
> - printk(KERN_ERR PFX "unknown bcm963xx board: %s\n",
> + pr_err("unknown bcm963xx board: %s\n",
> name);
It's nicer to unwrap lines where appropriate:
pr_err("unknown bcm963xx board: %s\n", name);
> diff --git a/arch/mips/bcm63xx/cpu.c b/arch/mips/bcm63xx/cpu.c
[]
> @@ -376,10 +376,10 @@ void __init bcm63xx_cpu_init(void)
> bcm63xx_cpu_freq = detect_cpu_clock();
> bcm63xx_memory_size = detect_memory_size();
>
> - printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
> + pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
> bcm63xx_cpu_id, bcm63xx_cpu_rev);
It's nicer to reflow alignment for the entire statement to
keep the subsequent line arguments at the open parenthesis:
pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
bcm63xx_cpu_id, bcm63xx_cpu_rev);
> + pr_info("CPU frequency is %u MHz\n",
> bcm63xx_cpu_freq / 100);
pr_info("CPU frequency is %u MHz\n", bcm63xx_cpu_freq / 100);
etc...
> diff --git a/arch/mips/bcm63xx/timer.c b/arch/mips/bcm63xx/timer.c
[]
> @@ -195,7 +195,7 @@ int bcm63xx_timer_init(void)
> irq = bcm63xx_get_irq_number(IRQ_TIMER);
> ret = request_irq(irq, timer_interrupt, 0, "bcm63xx_timer", NULL);
> if (ret) {
> - printk(KERN_ERR "bcm63xx_timer: failed to register irq\n");
> + pr_err("bcm63xx_timer: failed to register irq\n");
It's sometimes nicer to change embedded function names
to use "%s: ", __func__
pr_err("%s: failed to register irq\n", __func__);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] bpf: add support for %s specifier to bpf_trace_printk()
On 8/27/15 4:43 PM, Steven Rostedt wrote: On Thu, 27 Aug 2015 16:20:39 -0700 (PDT) David Miller wrote: From: Alexei Starovoitov Date: Thu, 27 Aug 2015 16:06:14 -0700 Fair or you still think it should be per byte copy? I'm terribly surprised we don't have an equivalent of strncpy() for unsafe kernel pointers. You probably won't be the last person to want this, and it's silly to optimize it in one place and then wait for cut into the next guy. If it doesn't exist. Perhaps its time to create it. all makes sense. Working on generalizing FETCH_FUNC_NAME from trace_kprobe.c. Seems to fit quite well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
On 28.08.2015 10:48, Jaehoon Chung wrote:
> On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
>> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
>>> Currently vmmc's property is wrong.
>>> If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
>>> (Card supply power and I/O Line supply Power.)
>>>
>>> Signed-off-by: Jaehoon Chung
>>> ---
>>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> index ca7d168..4ddabfd 100644
>>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> @@ -461,10 +461,10 @@
>>> _0 {
>>> pinctrl-0 = <_clk _cmd _bus4 _bus8>;
>>> pinctrl-names = "default";
>>> - vmmc-supply = <_reg _reg>;
>>> + vmmc-supply = <_reg>;
>>> + vqmmc-supply = <_reg>;
>>
>> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
>> so it should be VQMMC?
>
> If my schematics is right thing, buck8 is used LAN card power.
> I will send after removing buck8_reg. how about?
> Anyway, Thanks for pointing out. :)
Removing this regulator from this node would effectively disable it.
That could affect other components like LAN.
Anyway before fixing the order I would prefer to find the right
regulators used by MSHC node.
Best regards,
Krzysztof
>
> I don't know who this regulator applied. I have guessed that it used for eMMC.
> Sorry for guessing.
>
> Best Regards,
> Jaehoon Chung
>
>>
>> In the same time I can't find on schematics where BUCK8 goes...
>>
>> The SDHCI_2 node below looks good.
>>
>> Best regards,
>> Krzysztof
>>
>>> mmc-pwrseq = <_pwrseq>;
>>> status = "okay";
>>> -
>>> num-slots = <1>;
>>> broken-cd;
>>> card-detect-delay = <200>;
>>> @@ -485,7 +485,8 @@
>>> bus-width = <4>;
>>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>>> pinctrl-names = "default";
>>> - vmmc-supply = <_reg _reg>;
>>> + vmmc-supply = <_reg>;
>>> + vqmmc-supply = <_reg>;
>>> cd-gpios = < 2 0>;
>>> cd-inverted;
>>> status = "okay";
>>>
>>
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from sound/soc/codecs/ics43432.c:12:0:
sound/soc/codecs/ics43432.c:60:25: error: 'ics43432_dt_ids' undeclared here
(not in a function)
MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
^
include/linux/module.h:223:21: note: in definition of macro
'MODULE_DEVICE_TABLE'
extern const typeof(name) __mod_##type##__##name##_device_table \
^
include/linux/module.h:223:27: error: '__mod_of__ics43432_dt_ids_device_table'
aliased to undefined symbol 'ics43432_dt_ids'
extern const typeof(name) __mod_##type##__##name##_device_table \
^
sound/soc/codecs/ics43432.c:60:1: note: in expansion of macro
'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
^
Caused by commit
3b7ce99748f0 ("ASoC: ics43432: Add codec driver for InvenSense ICS-43432")
Not really build tested with CONFIG_OF set, right? :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix tsk->pi_lock isn't held when do_set_cpus_allowed()
On 8/28/15 6:18 AM, Peter Zijlstra wrote:
On Tue, Aug 25, 2015 at 07:47:44PM +0800, Wanpeng Li wrote:
On 8/25/15 6:32 PM, Peter Zijlstra wrote:
So Possibly, Maybe (I'm still to wrecked to say for sure), something
like this would work:
WARN_ON(debug_locks && (lockdep_is_held(>pi_lock) ||
(p->on_rq && lockdep_is_held(>lock;
Instead of those two separate lockdep asserts.
Please consider carefully.
So the normal rules for changing task_struct::cpus_allowed are holding
both pi_lock and rq->lock, such that holding either stabilizes the mask.
This is so that wakeup can happen without rq->lock and load-balance
without pi_lock.
From this we already get the relaxation that we can omit acquiring
rq->lock if the task is not on the rq, because in that case
load-balancing will not apply to it.
** these are the rules currently tested in do_set_cpus_allowed() **
Now, since __set_cpus_allowed_ptr() uses task_rq_lock() which
unconditionally acquires both locks, we could get away with holding just
rq->lock when on_rq for modification because that'd still exclude
__set_cpus_allowed_ptr(), it would also work against
__kthread_bind_mask() because that assumes !on_rq.
That said, this is all somewhat fragile.
Commit (5e16bbc2f: sched: Streamline the task migration locking a little)
won't hold the pi_lock in migrate_tasks() path any more, actually pi_lock
was still not held when call select_fallback_rq() and it was held in
__migrate_task() before the commit. Then commit (25834c73f93: sched: Fix a
race between __kthread_bind() and sched_setaffinity()) add a
lockdep_assert_held() in do_set_cpus_allowed(), the bug is triggered. How
about something like below:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5186,6 +5186,15 @@ static void migrate_tasks(struct rq *dead_rq)
BUG_ON(!next);
next->sched_class->put_prev_task(rq, next);
+ raw_spin_unlock(>lock);
+ raw_spin_lock(>pi_lock);
+ raw_spin_lock(>lock);
+ if (!(task_rq(next) == rq && task_on_rq_queued(next))) {
+ raw_spin_unlock(>lock);
+ raw_spin_unlock(>pi_lock);
+ continue;
+ }
Yeah, that's quite disgusting.. also you'll trip over the lockdep_pin if
you were to actually run this.
Indeed. I will handle lockdep_pin in these codes if you choice the
second fragile. :-)
Regards,
Wanpeng Li
Now, I don't think dropping rq->lock is quite as disastrous as it
usually is because !cpu_active at this point, which means load-balance
will not interfere, but that too is somewhat fragile.
So we end up with a choice of two fragile.. let me ponder that a wee
bit more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: use vqmmc-supply of emmc/sd for exynos4412-odroid-common
On 08/27/2015 09:26 PM, Krzysztof Kozlowski wrote:
> W dniu 27.08.2015 o 18:29, Jaehoon Chung pisze:
>> Currently vmmc's property is wrong.
>> If it needs to control two supplies, then it has to use vmmc/vqmmc-supply.
>> (Card supply power and I/O Line supply Power.)
>>
>> Signed-off-by: Jaehoon Chung
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ca7d168..4ddabfd 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -461,10 +461,10 @@
>> _0 {
>> pinctrl-0 = <_clk _cmd _bus4 _bus8>;
>> pinctrl-names = "default";
>> -vmmc-supply = <_reg _reg>;
>> +vmmc-supply = <_reg>;
>> +vqmmc-supply = <_reg>;
>
> Shouldn't this be reversed? LDO20 has 1.8V and it goes to MMC connector,
> so it should be VQMMC?
If my schematics is right thing, buck8 is used LAN card power.
I will send after removing buck8_reg. how about?
Anyway, Thanks for pointing out. :)
I don't know who this regulator applied. I have guessed that it used for eMMC.
Sorry for guessing.
Best Regards,
Jaehoon Chung
>
> In the same time I can't find on schematics where BUCK8 goes...
>
> The SDHCI_2 node below looks good.
>
> Best regards,
> Krzysztof
>
>> mmc-pwrseq = <_pwrseq>;
>> status = "okay";
>> -
>> num-slots = <1>;
>> broken-cd;
>> card-detect-delay = <200>;
>> @@ -485,7 +485,8 @@
>> bus-width = <4>;
>> pinctrl-0 = <_clk _cmd _cd _bus4>;
>> pinctrl-names = "default";
>> -vmmc-supply = <_reg _reg>;
>> +vmmc-supply = <_reg>;
>> +vqmmc-supply = <_reg>;
>> cd-gpios = < 2 0>;
>> cd-inverted;
>> status = "okay";
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
32-bit vdso syscall cancellation proposal
Hi- After chatting with Rich Felker on IRC, he's convinced me that the 32-bit vsyscall mechanism is annoying for syscall cancellation. To help, I propose we add two functions: unsigned long __vdso_pending_vsyscall_eip(void *context); If context is a signal context pointing to the AT_SYSINFO entry and if that entry has *not* executed its syscall yet (or if it has but it's about to resume it), then returns the EIP to which the vsyscall will return. Otherwise returns -1. int __vdso_cancel_pending_vsyscall(void *context); If not in a valid pending vsyscall, returns -EINVAL. Otherwise clobbers all vsyscall return registers except ESP, EIP, and EAX and arranges for EAX to be -ENOSYS on return and for the vsyscall to be skipped. Returns 0. (Musl would slightly prefer -EINTR, but that's harder to implement. Musl would like the ability to *change* the return EIP even more, but that's considerably harder, given that the location of the saved EIP will vary depending on where we are in the vsyscall.) Ingo, if I implement something like this, it'll come with a careful test case. I already have a test case that tests the CFI annotations (by single-stepping through a syscall and asserting that it unwinds correctly from every single SIGTRAP). It'll also be on top of a series that turns __kernel_vsyscall into a *single* function. __vdso_pending_vsyscall_eip can't be reliably implemented using the CFI annotations, because you can't tell which side of the syscall you're on. __vdso_cancel_pending_vsyscall could be, but that's quite heavyweight, and implementing it directly will only be a couple lines of code. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] add multiple times opening support to a virtserialport
Hello Christoffer, On Fri, Aug 28, 2015 at 2:30 AM, Christoffer Dall wrote: > On Thu, Aug 27, 2015 at 10:23:38AM -0400, Christopher Covington wrote: >> On 07/24/2015 08:00 AM, Matt Ma wrote: >> > Hi all, >> > >> > Linaro has developed the foundation for the new Android Emulator code >> > base based on a fairly recent upstream QEMU code base, when we >> > re-based the code, we updated the device model to be more virtio based >> > (for example the drives are now virtio block devices). The aim of this >> > is to minimise the delta between upstream and the Android specific >> > changes to QEMU. One Android emulator specific feature is the >> > AndroidPipe. >> > >> > AndroidPipe is a communication channel between the guest system and >> > the emulator itself. Guest side device node can be opened by multi >> > processes at the same time with different service name. It has a >> > de-multiplexer on the QEMU side to figure out which service the guest >> > actually wanted, so the first write after opening device node is the >> > service name guest wanted, after QEMU backend receive this service >> > name, create a corresponding communication channel, initialize related >> > component, such as file descriptor which connect to the host socket >> > serve. So each opening in guest will create a separated communication >> > channel. >> > >> > We can create a separate device for each service type, however some >> > services, such as the OpenGL emulation, need to have multiple open >> > channels at a time. This is currently not possible using the >> > virtserialport which can only be opened once. >> > >> > Current virtserialport can not be opened by multiple processes at the >> > same time. I know virtserialport has provided buffers beforehand to >> > cache data from host to guest, so even there is no guest read, data >> > can still be transported from host to guest kernel, when there is >> > guest read request, just copy cached data to user space. >> > >> > We are not sure clearly whether virtio can support >> > multi-open-per-device semantics or not, followings are just our >> > initial ideas about adding multi-open-per-device feature to a port: >> > >> > * when there is a open request on a port, kernel will allocate a >> > portclient with new id and __wait_queue_head to track this request >> > * save this portclient in file->private_data >> > * guest kernel pass this portclient info to QEMU and notify that the >> > port has been opened >> > * QEMU backend will create a clientinfo struct to track this >> > communication channel, initialize related component >> > * we may change the kernel side strategy of allocating receiving >> > buffers in advance to a new strategy, that is when there is a read >> > request: >> > - allocate a port_buffer, put user space buffer address to >> > port_buffer.buf, share memory to avoid memcpy >> > - put both portclient id(or portclient addrss) and port_buffer.buf >> > to virtqueue, that is the length of buffers chain is 2 >> > - kick to notify QEMU backend to consume read buffer >> > - QEMU backend read portclient info firstly to find the correct >> > clientinfo, then read host data directly into virtqueue buffer to >> > avoid memcpy >> > - guest kernel will wait(similarly in block mode, because the user >> > space address has been put into virtqueue) until QEMU backend has >> > consumed buffer(all data/part data/nothing have been sent to host >> > side) >> > - if nothing has been read from host and file descriptor is in >> > block mode, read request will wait through __wait_queue_head until >> > host side is readable >> > >> > * above read logic may change the current behavior of transferring >> > data to guest kernel even without guest user read >> > >> > * when there is a write request: >> > - allocate a port_buffer, put user space buffer address to >> > port_buffer.buf, share memory to avoid memcpy >> > - put both portclient id(or portclient addrss) and port_buffer.buf >> > to virtqueue, the length of buffers chain is 2 >> > - kick to notify QEMU backend to consume write buffer >> > - QEMU backend read portclient info firstly to find the correct >> > clientinfo, then write the virtqueue buffer content to host side as >> > current logic >> > - guest kernel will wait(similarly in block mode, because the user >> > space address has been put into virtqueue) until QEMU backend has >> > consumed buffer(all data/part data/nothing have been receive from host >> > side) >> > - if nothing has been sent out and file descriptor is in block >> > mode, write request will wait through __wait_queue_head until host >> > side is writable >> > >> > We obviously don't want to regress existing virtio behaviour and >> > performance and welcome the communities expertise to point out >> > anything we may have missed out before we get to far down implementing >> > our initial proof-of-concept. > > Hi Chris, > >> >> Would virtio-vsock be interesting for your
Re: [PATCH v2,5/5] PowerPC/mpc85xx: Add CPU hotplug support for E6500
On Thu, Aug 27, 2015 at 6:42 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:48PM +0800, Chenhui Zhao wrote:
+ .globl booting_thread_hwid
+booting_thread_hwid:
+ .long INVALID_THREAD_HWID
+ .align 3
The commit message goes into no detail about the changes you're
making to
thread handling, nor are there relevant comments.
OK. Will add some comments.
+/*
+ * r3 = the thread physical id
+ */
+_GLOBAL(book3e_stop_thread)
+ li r4, 1
+ sld r4, r4, r3
+ mtspr SPRN_TENC, r4
+ isync
+ blr
Why did the C code not have an isync, if it's required here?
Just make sure "mtspr" has completed before the routine returns.
_GLOBAL(fsl_secondary_thread_init)
/* Enable branch prediction */
lis r3,BUCSR_INIT@h
@@ -197,8 +236,10 @@ _GLOBAL(fsl_secondary_thread_init)
* but the low bit right by two bits so that the cpu numbering is
* continuous.
*/
- mfspr r3, SPRN_PIR
- rlwimi r3, r3, 30, 2, 30
+ bl 10f
+10: mflrr5
+ addir5,r5,(booting_thread_hwid - 10b)
+ lwz r3,0(r5)
mtspr SPRN_PIR, r3
#endif
I assume the reason for this is that, unlike the kexec case, the cpu
has
been reset so PIR has been reset? Don't make me guess -- document.
We can not rely on the value saved in SPRN_PIR. Every time running
fsl_secondary_thread_init, SPRN_PIR may not always has a reset value.
Using booting_thread_hwid to ensure SPRN_PIR has a correct value.
@@ -245,6 +286,30 @@ _GLOBAL(generic_secondary_smp_init)
mr r3,r24
mr r4,r25
bl book3e_secondary_core_init
+
+/*
+ * If we want to boot Thread1, start Thread1 and stop Thread0.
+ * Note that only Thread0 will run the piece of code.
+ */
What ensures that only thread 0 runs this? Especially if we're
entering
via kdump on thread 1?
This piece of code will be executed only when core resets (Thead0 will
start first). Thead1 will run fsl_secondary_thread_init() to start.
How can kdump run this on Thread1? I know little about kexec.
s/the piece/this piece/
+ LOAD_REG_ADDR(r3, booting_thread_hwid)
+ lwz r4, 0(r3)
+ cmpwi r4, INVALID_THREAD_HWID
+ beq 20f
+ cmpwr4, r24
+ beq 20f
Do all cores get released from the spin table before the first thread
gets kicked?
Yes.
+
+ /* start Thread1 */
+ LOAD_REG_ADDR(r5, fsl_secondary_thread_init)
+ ld r4, 0(r5)
+ li r3, 1
+ bl book3e_start_thread
+
+ /* stop Thread0 */
+ li r3, 0
+ bl book3e_stop_thread
+10:
+ b 10b
+20:
#endif
generic_secondary_common_init:
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 73eb994..61f68ad 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -181,17 +181,11 @@ static inline u32 read_spin_table_addr_l(void
*spin_table)
static void wake_hw_thread(void *info)
{
void fsl_secondary_thread_init(void);
- unsigned long imsr1, inia1;
- int nr = *(const int *)info;
+ unsigned long inia;
+ int hw_cpu = get_hard_smp_processor_id(*(const int *)info);
- imsr1 = MSR_KERNEL;
- inia1 = *(unsigned long *)fsl_secondary_thread_init;
-
- mttmr(TMRN_IMSR1, imsr1);
- mttmr(TMRN_INIA1, inia1);
- mtspr(SPRN_TENS, TEN_THREAD(1));
-
- smp_generic_kick_cpu(nr);
+ inia = *(unsigned long *)fsl_secondary_thread_init;
+ book3e_start_thread(cpu_thread_in_core(hw_cpu), inia);
}
#endif
@@ -279,7 +273,6 @@ static int smp_85xx_kick_cpu(int nr)
int ret = 0;
#ifdef CONFIG_PPC64
int primary = nr;
- int primary_hw = get_hard_smp_processor_id(primary);
#endif
WARN_ON(nr < 0 || nr >= num_possible_cpus());
@@ -287,33 +280,43 @@ static int smp_85xx_kick_cpu(int nr)
pr_debug("kick CPU #%d\n", nr);
#ifdef CONFIG_PPC64
+ booting_thread_hwid = INVALID_THREAD_HWID;
/* Threads don't use the spin table */
- if (cpu_thread_in_core(nr) != 0) {
- int primary = cpu_first_thread_sibling(nr);
+ if (threads_per_core == 2) {
+ booting_thread_hwid = get_hard_smp_processor_id(nr);
What does setting booting_thread_hwid to INVALID_THREAD_HWID here
accomplish? If threads_per_core != 2 it would never have been set to
anything else, and if threads_per_core == 2 you immediately overwrite
it.
booting_thread_hwid is valid only for the case that one core has two
threads (e6500). For e5500 and e500mc, one core one thread,
"booting_thread_hwid" is invalid.
"booting_thread_hwid" will determine starting which thread in
generic_secondary_smp_init().
+ primary = cpu_first_thread_sibling(nr);
if (WARN_ON_ONCE(!cpu_has_feature(CPU_FTR_SMT)))
Re: [PATCH 0/6] ACPI / properties: Hierarchical properties support
Hi, On Fri, Aug 28, 2015 at 2:10 AM, Dustin Byford wrote: > On Thu Aug 27 04:34, Rafael J. Wysocki wrote: > > Hi Rafael, > >> The issue at hand is that we need to be able to support hierarchical device >> properties in ACPI, like when the set of properties of an entity called >> "Fred" >> may include a subset called "dog" containing the properties of the Fred's dog >> rather than those of Fred himself. And it may make sense to have the same >> property, like "hair color", for both Fred and the dog, but with different >> values. > > OK. I have a couple of questions. > >> We (I, Darren and Dave at least) have explored many possible ways to deal >> with >> that in ACPI, but the majority of them turned out to be unattractive for >> various >> reasons. Our first take was to use ACPI device objects to make the "child" >> property sets available via _DSD, but that approach is generally incompatible >> with the PnP Manager in Windows following the notion that all device objects >> in ACPI tables are supposed to represent real devices. It can still be made >> work by adding _STA that returns 0 to those "property-only" device objects, >> but that leads to complications in other places and is error prone (if the >> _STA >> is forgotten, for example). Moreover, it adds quite a bit of overhead even >> in >> Linux (an ACPICA representation, struct acpi_device, driver core mechanics >> etc) >> for things that are only supposed to represent sets of device properties. >> And, >> in addition to that, we'd need to figure out how to give those things >> arbitrary >> names in a consistent way. All of that caused us to drop the approach based >> on >> device objects and look for other options. > > What's the overhead/effect on Windows for an ACPI object without a _HID (_ADR > only)? That seems like a case where the OS shouldn't be expecting to load > another driver for the ACPI object and the _ADR gives each node a unique name > (even if it is an unfriendly integer) I'm not sure about the driver thing in Windows in the case of _ADR devices to be honest. That said, by the spec you're only supposed to use _ADR with things listed in Table 6-168 (page 278) as of ACPI 6. So that already is a stretch to use _ADR for something not listed there. The fact that this is an integer rather than a name is slightly problematic too, because it does not fit into some use cases we already have drivers for. In some cases the "child" entities are referred to by names, because things have been developed with DT in mind. We generally would like to avoid having to provide a separate ACPI code path at least in some of those cases if possible. As for the overhead, if something is a device object, it already has a scope associated with it in the ACPI namespace which adds complexity. Further, we create a struct acpi_device for it, which is based on struct device and registered with the driver core etc. All of those things are not small objects so they take up quite a bit of memory. Not to mention sysfs interfaces created for them and so on. They also are taken into account by things like acpi_walk_namespace() and generally cause those operations to be slightly slower. The are taken into account by the system suspend/resume code too. >> The idea is that _DSD may return a package containing the properties of the >> device it belongs to along with a directory of objects that need to be >> evaluated >> in order to obtain the "child" property sets of it. That directory needs to >> be >> present in a separate section of the _DSD package (after the new UUID >> defined in >> the above document) and is a list of two-element sub-packages (entries) where >> the first element is the name of the entry (the name of the "child" property >> set >> represented by it) and the second element is a "pointer" (essentially, a path >> or "namestring" in the ACPI terminology) to the control method or a static >> data package that needs to be evaluated to obtain the entry's data. The data >> returned by it is then interpreted in the same way as a _DSD return package, >> so it may also contain properties and a directory of its own "child" property >> sets. > > Do you expect there to be cases where using an ACPI device object is more > desirable than hierarchical properties? Or is it just impossible given the > PNP > manager in Windows? > > The best example I can think of is perhaps a multi function device where each > sub-function really does look like a separate device and you probably want to > reference that sub-device, as a device, in other ASL code. In those cases you may need to use device objects, but you can still do that just fine. It is just more heavy-weight and may be problematic for other OSes at least in principle, so by doing that you may end up with Linux-specific firmware. The new mechanism introduced here is for the situations in which you don't have to do that and by using it you can avoid having to worry about things
RE: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: 2015年8月7日 23:26 > To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com; > mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org > Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free- > electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux- > watch...@vger.kernel.org > Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 > watchdog timer > > On 08/06/2015 03:16 AM, Wenyou Yang wrote: > >>From SAMA5D4, the watchdog timer is upgrated with a new feature, > > which is describled as in the datasheet, "WDT_MR can be written until > > a LOCKMR command is issued in WDT_CR". > > That is to say, as long as the bootstrap and u-boot don't issue a > > LOCKMR command, WDT_MR can be written more than once in the driver. > > > > So the SAMA5D4 watchdog driver's implementation is different from the > > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c. > > The user application open the device file to enable the watchdog timer > > hardware, and close to disable it, and set the watchdog timer timeout > > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog > > by issuing WDRSTT command to WDT_CR register with hard-coded key. > > > > Signed-off-by: Wenyou Yang > > Reviewed-by: Guenter Roeck Hi Vim, Can this patch series be merged? Could you please? Best Regards, Wenyou Yang
[PATCH] MIPS: BCM63XX: Use pr_* instead of printk
Signed-off-by: Gregory Fong
Cc: Florian Fainelli
Cc: Jonas Gorski
---
arch/mips/bcm63xx/boards/board_bcm963xx.c | 11 ++-
arch/mips/bcm63xx/cpu.c | 6 +++---
arch/mips/bcm63xx/dev-pcmcia.c| 2 +-
arch/mips/bcm63xx/irq.c | 2 +-
arch/mips/bcm63xx/setup.c | 8
arch/mips/bcm63xx/timer.c | 2 +-
6 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
index 33727e7..7e001d3 100644
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
@@ -7,6 +7,8 @@
* Copyright (C) 2008 Florian Fainelli
*/
+#define pr_fmt(fmt) "board_bcm963xx: " fmt
+
#include
#include
#include
@@ -31,7 +33,6 @@
#include
-#define PFX"board_bcm963xx: "
#define HCS_OFFSET_128K0x2
@@ -740,7 +741,7 @@ int bcm63xx_get_fallback_sprom(struct ssb_bus *bus, struct
ssb_sprom *out)
memcpy(out, _sprom, sizeof(struct ssb_sprom));
return 0;
} else {
- printk(KERN_ERR PFX "unable to fill SPROM for given
bustype.\n");
+ pr_err("unable to fill SPROM for given bustype.\n");
return -EINVAL;
}
}
@@ -784,7 +785,7 @@ void __init board_prom_init(void)
cfe[5], cfe[6], cfe[7], cfe[8], cfe[9]);
else
strcpy(cfe_version, "unknown");
- printk(KERN_INFO PFX "CFE version: %s\n", cfe_version);
+ pr_info("CFE version: %s\n", cfe_version);
bcm63xx_nvram_init(boot_addr + BCM963XX_NVRAM_OFFSET);
@@ -808,7 +809,7 @@ void __init board_prom_init(void)
char name[17];
memcpy(name, board_name, 16);
name[16] = 0;
- printk(KERN_ERR PFX "unknown bcm963xx board: %s\n",
+ pr_err("unknown bcm963xx board: %s\n",
name);
return;
}
@@ -854,7 +855,7 @@ void __init board_setup(void)
{
if (!board.name[0])
panic("unable to detect bcm963xx board");
- printk(KERN_INFO PFX "board name: %s\n", board.name);
+ pr_info("board name: %s\n", board.name);
/* make sure we're running on expected cpu */
if (bcm63xx_get_cpu_id() != board.expected_cpu_id)
diff --git a/arch/mips/bcm63xx/cpu.c b/arch/mips/bcm63xx/cpu.c
index 307ec8b..57dfe7c 100644
--- a/arch/mips/bcm63xx/cpu.c
+++ b/arch/mips/bcm63xx/cpu.c
@@ -376,10 +376,10 @@ void __init bcm63xx_cpu_init(void)
bcm63xx_cpu_freq = detect_cpu_clock();
bcm63xx_memory_size = detect_memory_size();
- printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
+ pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
bcm63xx_cpu_id, bcm63xx_cpu_rev);
- printk(KERN_INFO "CPU frequency is %u MHz\n",
+ pr_info("CPU frequency is %u MHz\n",
bcm63xx_cpu_freq / 100);
- printk(KERN_INFO "%uMB of RAM installed\n",
+ pr_info("%uMB of RAM installed\n",
bcm63xx_memory_size >> 20);
}
diff --git a/arch/mips/bcm63xx/dev-pcmcia.c b/arch/mips/bcm63xx/dev-pcmcia.c
index a551bab..9496cd2 100644
--- a/arch/mips/bcm63xx/dev-pcmcia.c
+++ b/arch/mips/bcm63xx/dev-pcmcia.c
@@ -139,6 +139,6 @@ int __init bcm63xx_pcmcia_register(void)
return platform_device_register(_pcmcia_device);
out_err:
- printk(KERN_ERR "unable to set pcmcia chip select\n");
+ pr_err("unable to set pcmcia chip select\n");
return ret;
}
diff --git a/arch/mips/bcm63xx/irq.c b/arch/mips/bcm63xx/irq.c
index e3e808a..99d3d14 100644
--- a/arch/mips/bcm63xx/irq.c
+++ b/arch/mips/bcm63xx/irq.c
@@ -311,7 +311,7 @@ static int bcm63xx_external_irq_set_type(struct irq_data *d,
break;
default:
- printk(KERN_ERR "bogus flow type combination given !\n");
+ pr_err("bogus flow type combination given !\n");
return -EINVAL;
}
diff --git a/arch/mips/bcm63xx/setup.c b/arch/mips/bcm63xx/setup.c
index 240fb4f..2be9caa 100644
--- a/arch/mips/bcm63xx/setup.c
+++ b/arch/mips/bcm63xx/setup.c
@@ -24,7 +24,7 @@
void bcm63xx_machine_halt(void)
{
- printk(KERN_INFO "System halted\n");
+ pr_info("System halted\n");
while (1)
;
}
@@ -34,7 +34,7 @@ static void bcm6348_a1_reboot(void)
u32 reg;
/* soft reset all blocks */
- printk(KERN_INFO "soft-resetting all blocks ...\n");
+ pr_info("soft-resetting all blocks ...\n");
reg = bcm_perf_readl(PERF_SOFTRESET_REG);
reg &= ~SOFTRESET_6348_ALL;
bcm_perf_writel(reg, PERF_SOFTRESET_REG);
@@ -46,7 +46,7 @@ static void bcm6348_a1_reboot(void)
mdelay(10);
/* Jump to the power on address. */
- printk(KERN_INFO "jumping to reset vector.\n");
+
linux-next: manual merge of the rdma tree with the net-next tree
Hi Doug,
Today's linux-next merge of the rdma tree got a conflict in:
net/core/dev.c
between commit:
0e4ead9d7b36 ("net: introduce change upper device notifier change info")
from the net-next tree and commit:
133b5b93c734 ("net: Add info for NETDEV_CHANGEUPPER event")
from the rdma tree.
They are doing very similar things, but not identical.
I fixed it up (see bottom of email and the below extra patch) and can
carry the fix as necessary (no action is required unless something more
correct is supplied, of course).
From: Stephen Rothwell
Date: Fri, 28 Aug 2015 11:14:38 +1000
Subject: [PATCH] net: merge change upper notifier changes
Signed-off-by: Stephen Rothwell
---
drivers/infiniband/core/roce_gid_mgmt.c | 12 ++--
include/linux/netdevice.h | 23 +--
2 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/infiniband/core/roce_gid_mgmt.c
b/drivers/infiniband/core/roce_gid_mgmt.c
index 6eecdfbf3aef..69e2ffa35d91 100644
--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@ -529,7 +529,7 @@ static const struct netdev_event_work_cmd add_cmd = {
static const struct netdev_event_work_cmd add_cmd_upper_ips = {
.cb = add_netdev_upper_ips, .filter = is_eth_port_of_netdev};
-static void netdevice_event_changeupper(struct netdev_changeupper_info
*changeupper_info,
+static void netdevice_event_changeupper(struct
netdev_notifier_changeupper_info *changeupper_info,
struct netdev_event_work_cmd *cmds)
{
static const struct netdev_event_work_cmd upper_ips_del_cmd = {
@@ -540,15 +540,15 @@ static void netdevice_event_changeupper(struct
netdev_changeupper_info *changeup
if (changeupper_info->event ==
NETDEV_CHANGEUPPER_UNLINK) {
cmds[0] = upper_ips_del_cmd;
- cmds[0].ndev = changeupper_info->upper;
+ cmds[0].ndev = changeupper_info->upper_dev;
cmds[1] = add_cmd;
} else if (changeupper_info->event ==
NETDEV_CHANGEUPPER_LINK) {
cmds[0] = bonding_default_del_cmd;
- cmds[0].ndev = changeupper_info->upper;
+ cmds[0].ndev = changeupper_info->upper_dev;
cmds[1] = add_cmd_upper_ips;
- cmds[1].ndev = changeupper_info->upper;
- cmds[1].filter_ndev = changeupper_info->upper;
+ cmds[1].ndev = changeupper_info->upper_dev;
+ cmds[1].filter_ndev = changeupper_info->upper_dev;
}
}
@@ -590,7 +590,7 @@ static int netdevice_event(struct notifier_block *this,
unsigned long event,
case NETDEV_CHANGEUPPER:
netdevice_event_changeupper(
- container_of(ptr, struct netdev_changeupper_info, info),
+ container_of(ptr, struct
netdev_notifier_changeupper_info, info),
cmds);
break;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0aa7d19ac85e..4ce420487d07 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2115,13 +2115,22 @@ struct netdev_notifier_change_info {
unsigned int flags_changed;
};
+enum netdev_changeupper_event {
+ NETDEV_CHANGEUPPER_LINK,
+ NETDEV_CHANGEUPPER_UNLINK,
+};
+
struct netdev_notifier_changeupper_info {
struct netdev_notifier_info info; /* must be first */
+ enum netdev_changeupper_event event;
struct net_device *upper_dev; /* new upper dev */
bool master; /* is upper dev master */
bool linking; /* is the nofication for link or unlink */
};
+void netdev_changeupper_info_change(struct net_device *dev,
+ struct netdev_notifier_changeupper_info
*info);
+
static inline void netdev_notifier_info_init(struct netdev_notifier_info *info,
struct net_device *dev)
{
@@ -3606,20 +3615,6 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
netdev_features_t features);
-enum netdev_changeupper_event {
- NETDEV_CHANGEUPPER_LINK,
- NETDEV_CHANGEUPPER_UNLINK,
-};
-
-struct netdev_changeupper_info {
- struct netdev_notifier_info info; /* must be first */
- enum netdev_changeupper_event event;
- struct net_device *upper;
-};
-
-void netdev_changeupper_info_change(struct net_device *dev,
- struct netdev_changeupper_info *info);
-
struct netdev_bonding_info {
ifslave slave;
ifbond master;
--
2.5.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/core/dev.c
index a8e6cf4298d3,6e6f14e5d44f..
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@@ -5330,10 -5320,6 +5330,11 @@@ static int
Re: [PATCH v2 1/2] watchdog: bcm7038: add device tree binding documentation
On Thu, Aug 27, 2015 at 03:53:23PM -0700, Justin Chen wrote:
> Add device tree binding documentation for the watchdog hardware block
> on bcm7038 and newer SoCs.
>
> Signed-off-by: Justin Chen
Acked-by: Guenter Roeck
> ---
> .../devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt | 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> new file mode 100644
> index 000..39e5cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt
> @@ -0,0 +1,19 @@
> +BCM7038 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be "brcm,bcm7038-wdt"
> +- reg : Specifies base physical address and size of the registers.
> +
> +Optional properties:
> +
> +- clocks: The clock running the watchdog. If no clock is found the
> + driver will default to 2700 HZ.
> +
> +Example:
> +
> +watchdog {
> + compatible = "brcm,bcm7038-wdt";
> + clocks = <_fixed>;
> + reg = <0xf040a7e8 0x16>;
> +};
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2,4/5] PowerPC/mpc85xx: Add hotplug support on E5500 and E500MC cores
On Thu, Aug 27, 2015 at 4:55 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:47PM +0800, Chenhui Zhao wrote:
+int check_cpu_dead(unsigned int cpu)
+{
+ return per_cpu(cpu_state, cpu) == CPU_DEAD;
+}
I'm not sure this needs to be a function versus open-coded, but if
you do
want to make it a function, make it more obvious from the caller side
by
changing it to:
bool is_cpu_dead(unsigned int cpu);
Otherwise if I see "if (check_cpu_dead(cpu))" I don't know if the
if-block is executed if the CPU is dead or if it isn't.
OK.
diff --git a/arch/powerpc/platforms/85xx/smp.h
b/arch/powerpc/platforms/85xx/smp.h
index 0b20ae3..8ee19a3 100644
--- a/arch/powerpc/platforms/85xx/smp.h
+++ b/arch/powerpc/platforms/85xx/smp.h
@@ -6,6 +6,7 @@
#ifdef CONFIG_SMP
void __init mpc85xx_smp_init(void);
int __init mpc85xx_setup_pmc(void);
+int __init fsl_rcpm_init(void);
#else
Why wasn't this added in the patch that added fsl_rcpm_init()?
-Scott
Will move it to there.
Thanks,
-Chenhui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] watchdog: Watchdog driver for Broadcom Set-Top Box
Hi Justin,
On Thu, Aug 27, 2015 at 03:53:24PM -0700, Justin Chen wrote:
> Watchdog driver for Broadcom 7038 and newer chips.
>
> Signed-off-by: Justin Chen
Almost good. Two little but important details left ...
> ---
> drivers/watchdog/Kconfig | 8 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/bcm7038_wdt.c | 235
> +
> 3 files changed, 244 insertions(+)
> create mode 100644 drivers/watchdog/bcm7038_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 241fafd..4fbe8ab 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1291,6 +1291,14 @@ config BCM_KONA_WDT_DEBUG
>
> If in doubt, say 'N'.
>
> +config BCM7038_WDT
> + tristate "BCM7038 Watchdog"
> + select WATCHDOG_CORE
> + help
> + Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
> +
> + Say 'Y or 'M' here to enable the driver.
> +
> config IMGPDC_WDT
> tristate "Imagination Technologies PDC Watchdog Timer"
> depends on HAS_IOMEM
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 59ea9a1..65d4169 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
> obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
> obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
> obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
> +obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
>
> # AVR32 Architecture
> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/bcm7038_wdt.c b/drivers/watchdog/bcm7038_wdt.c
> new file mode 100644
> index 000..5e54c1b
> --- /dev/null
> +++ b/drivers/watchdog/bcm7038_wdt.c
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright (C) 2015 Broadcom Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define WDT_START_1 0xff00
> +#define WDT_START_2 0x00ff
> +#define WDT_STOP_1 0xee00
> +#define WDT_STOP_2 0x00ee
> +
> +#define WDT_TIMEOUT_REG 0x0
> +#define WDT_CMD_REG 0x4
> +
> +#define WDT_MIN_TIMEOUT 1 /* seconds */
> +#define WDT_DEFAULT_TIMEOUT 30 /* seconds */
> +#define WDT_DEFAULT_RATE 2700
> +
> +struct bcm7038_watchdog {
> + void __iomem*base;
> + struct watchdog_device wdd;
> + u32 rate;
> + struct clk *clk;
> +};
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +static void bcm7038_wdt_set_timeout_reg(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> + u32 timeout;
> +
> + timeout = wdt->rate * wdog->timeout;
> +
> + writel(timeout, wdt->base + WDT_TIMEOUT_REG);
> +}
> +
> +static int bcm7038_wdt_ping(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> +
> + writel(WDT_START_1, wdt->base + WDT_CMD_REG);
> + writel(WDT_START_2, wdt->base + WDT_CMD_REG);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_start(struct watchdog_device *wdog)
> +{
> + bcm7038_wdt_set_timeout_reg(wdog);
> + bcm7038_wdt_ping(wdog);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_stop(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> +
> + writel(WDT_STOP_1, wdt->base + WDT_CMD_REG);
> + writel(WDT_STOP_2, wdt->base + WDT_CMD_REG);
> +
> + return 0;
> +}
> +
> +static int bcm7038_wdt_set_timeout(struct watchdog_device *wdog,
> +unsigned int t)
> +{
> + /* Can't modify timeout value if watchdog timer is running */
> + bcm7038_wdt_stop(wdog);
> + wdog->timeout = t;
> + bcm7038_wdt_start(wdog);
> +
> + return 0;
> +}
> +
> +static unsigned int bcm7038_wdt_get_timeleft(struct watchdog_device *wdog)
> +{
> + struct bcm7038_watchdog *wdt = watchdog_get_drvdata(wdog);
> + u32 time_left;
> +
> + time_left = readl(wdt->base + WDT_CMD_REG);
> +
> + return time_left / wdt->rate;
> +}
> +
> +static struct watchdog_info bcm7038_wdt_info = {
> + .identity = "Broadcom BCM7038 Watchdog Timer",
> + .options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> + WDIOF_MAGICCLOSE
> +};
> +
> +static struct
Re: [PATCH v2 1/2] Documentation: dt: add Broadcom BCM7038 PWM controller binding
On 24/08/15 11:27, Florian Fainelli wrote:
> Add a binding documentation for the Broadcom BCM7038 PWM controller found in
> BCM7xxx chips.
Got to think about this some more, I will just remove the optional
"clocks" phandle, since the PWM block really needs a input clock to
operate, will respin a v3 with these changes shortly.
>
> Signed-off-by: Florian Fainelli
> ---
> .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> new file mode 100644
> index ..8b9bc43b561e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
> @@ -0,0 +1,22 @@
> +Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller)
> +
> +Required properties:
> +
> +- compatible: must be "brcm,bcm7038-pwm"
> +- reg: physical base address and length for this controller
> +- #pwm-cells: should be 2. See pwm.txt in this directory for a description
> + of the cells format.
> +
> +Optional properties:
> +
> +- clocks: a phandle to the reference clock for this block which is fed
> through
> + its internal variable clock frequency generator
> +
> +Example:
> +
> + pwm: pwm@f0408000 {
> + compatible = "brcm,bcm7038-pwm";
> + reg = <0xf0408000 0x28>;
> + #pwm-cells = <2>;
> + clocks = <_fixed>;
> + };
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] ARM: multi_v7_defconfig: Add NSP to defconfig
On 26/08/15 15:35, Jon Mason wrote: > Add the Broadcom Northstar Plus SoC to the multi_v7_defconfig > > Signed-off-by: Jon Mason Applied to defconfig/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/5] MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs
On 26/08/15 15:35, Jon Mason wrote: > Modify the iProc MAINTAINER to cover the Nortstar Plus SoCs, and add me > to the list of people responsible for it. Since iProc is a family of > SoCs that includes more than just Cygnus (i.e., Northstar (BCM5301X), > Northstar Plus, Northstar 2, and a number of other platforms), remove it > from the title to avoid any future confusion. > > Signed-off-by: Jon Mason > Acked-by: Scott Branden Applied to maintainers/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] ARM: NSP: add minimal Northstar Plus device tree
On 26/08/15 15:35, Jon Mason wrote: > Add a very minimalistic set of Northstar Plus Device Tree files which > describes the SoC and the BCM958625 implementation. The perpherials > described are: > > ARM Cortex A9 CPU > 2 8250 UARTs > ARM GIC > PL310 L2 Cache > ARM A9 Global timer > > Signed-off-by: Kapil Hali > Signed-off-by: Jon Mason Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v5 5/5] PM / devfreq: drop comment about thermal setting max_freq
> On Thu, Aug 27, 2015 at 11:58:39AM +0100, MyungJoo Ham wrote: > > > The thermal infrastructure should use the devfreq cooling device, which > > > uses the OPP library to disable OPPs as necessary. > > > > > > Fix a couple of typos in the same comment while we are at it. > > > > > > Cc: MyungJoo Ham > > > Signed-off-by: Javi Merino > > > > Your patches (1/5, 5/5) are already merged in > > https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git > > and will be "pull-request"ed with other patches later. > > > > Do your "V5" patches have updates from last patches? > > No they haven't. I should have based this series on top of your > branch. I'll do that in the future. > > Sorry for that, > Javi > Oh.. no you don't need to do so. Being based on the recent RC-x is already enough. Cheers, MyungJoo
Re: [PATCH v2 1/5] dt-bindings: Create Documentation for NSP DT bindings
On 26/08/15 15:35, Jon Mason wrote: > Add the documentation for the Broadcom Northstar Plus device tree > bindings. > > Signed-off-by: Jon Mason Applied to devicetree/next, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc/linux.git powerpc-4.2-4 tag
Hi Linus, Please pull one fix for powerpc for 4.2: The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b: Linux 4.2-rc8 (2015-08-23 20:52:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.2-4 for you to fetch changes up to 4d9aac397a5d8f4ee26a4178b5e4a5c474a3a76a: powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case (2015-08-26 21:40:50 +1000) powerpc fixes for 4.2 #3 - Fix MSI/MSI-X on pseries from Guilherme Guilherme G. Piccoli (2): PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case arch/powerpc/kernel/pci_of_scan.c | 3 +++ drivers/pci/probe.c | 2 +- include/linux/pci.h | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3/5] ARM: NSP: Add basic support for Broadcom Northstar Plus SoC
On 26/08/15 15:35, Jon Mason wrote: > Broadcom Northstar Plus family of SoCs are used for switching > control and management applications as well as residential > router/gateway applications. The SoC features dual core Cortex > A9 ARM CPUs, integrating several peripheral interfaces including > multiple Gigabit Ethernet PHYs, DDR3 memory, PCIE Gen-2, USB 2.0 > and USB 3.0, serial and NAND flash, SATA and several other IO > controllers. > > Signed-off-by: Kapil Hali > Signed-off-by: Jon Mason Applied to soc/next at github.com/stblinux, thanks! This is a little late for 4.3, so this will be queued for 4.4, thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
Some straggler bug fixes here:
1) Netlink_sendmsg() doesn't check iterator type properly in mmap case,
from Ken-ichirou MATSUZAWA.
2) Don't sleep in atomic context in bcmgenet driver, from Florian
Fainelli.
3) The pfkey_broadcast() code patch can't actually ever use anything other
than GFP_ATOMIC. And the cases that right now pass GFP_KERNEL or similar
will currently trigger an RCU splat. Just use GFP_ATOMIC unconditionally.
From David Ahern.
4) Fix FD bit timings handling in pcan_usb driver, from Marc
Kleine-Budde.
5) Cache dst leaked in ip6_gre tunnel removal, fix from Huaibin Wang.
6) Traversal into drivers/net/ethernet/renesas should be triggered by
CONFIG_NET_VENDOR_RENESAS, not a particular driver's config option.
From Kazuya Mizuguchi.
7) Fix regression in handling of igmp_join errors in vxlan, from
Marcelo Ricardo Leitner.
8) Make phy_{read,write}_mmd_indirect() properly take the mdio_lock mutex
when programming the registers. From Russell King.
9) Fix non-forced handling in u32_destroy(), from WANG Cong.
10) Test the EVENT_NO_RUNTIME_PM flag before it is cleared in
usbnet_stop(), from Eugene Shatokhin.
11) In sfc driver, don't fetch statistics firmware isn't capable of,
from Bert Kenward.
12) Verify ASCONF address parameter location in SCTP, from Xin Long.
Please pull, thanks a lot!
The following changes since commit 0bad90985d39e69ca035fdd70bcc743812641d18:
Merge tag 'pm+acpi-4.2-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2015-08-20
17:06:11 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to f648f807f61e64d247d26611e34cc97e4ed03401:
sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state
(2015-08-27 17:11:44 -0700)
Bert Kenward (1):
sfc: only use vadaptor stats if firmware is capable
David Ahern (1):
net: Fix RCU splat in af_key
David Daney (1):
phylib: Make PHYs children of their MDIO bus, not the bus' parent.
David S. Miller (1):
Merge tag 'linux-can-fixes-for-4.2-20150825' of
git://git.kernel.org/.../mkl/linux-can
Eugene Shatokhin (1):
usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
Florian Fainelli (1):
net: bcmgenet: Avoid sleeping in bcmgenet_timeout
Iyappan Subramanian (1):
drivers: net: xgene: fix: Oops in linkwatch_fire_event
Jaedon Shin (1):
net: bcmgenet: fix uncleaned dma flags
Kazuya Mizuguchi (1):
net: compile renesas directory if NET_VENDOR_RENESAS is configured
Ken-ichirou MATSUZAWA (1):
netlink: mmap: fix tx type check
Madalin Bucur (1):
net: phy: fixed: propagate fixed link values to struct
Marc Kleine-Budde (1):
can: pcan_usb: don't provide CAN FD bittimings by non-FD adapters
Marcelo Ricardo Leitner (1):
vxlan: re-ignore EADDRINUSE from igmp_join
Russell King (2):
net: phy: add locking to phy_read_mmd_indirect()/phy_write_mmd_indirect()
net: fec: use reinit_completion() in mdio accessor functions
WANG Cong (1):
cls_u32: complete the check for non-forced case in u32_destroy()
huaibin Wang (1):
ip6_gre: release cached dst on tunnel removal
lucien (2):
sctp: asconf's process should verify address parameter is in the beginning
sctp: donot reset the overall_error_count in SHUTDOWN_RECEIVE state
drivers/net/can/usb/peak_usb/pcan_usb.c | 24 ++-
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++--
drivers/net/can/usb/peak_usb/pcan_usb_core.h | 4 ++--
drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 96
--
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 24 ++-
drivers/net/ethernet/Makefile| 2 +-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +++
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 5 ++--
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 20
drivers/net/ethernet/freescale/fec_main.c| 4 ++--
drivers/net/ethernet/sfc/ef10.c | 27 -
drivers/net/phy/fixed_phy.c | 9 +++
drivers/net/phy/phy.c| 16 +
drivers/net/phy/phy_device.c | 2 +-
drivers/net/usb/usbnet.c | 7 +++---
drivers/net/vxlan.c | 2 ++
net/ipv6/ip6_gre.c | 1 +
net/key/af_key.c | 46
+--
net/netlink/af_netlink.c | 2 +-
net/sched/cls_u32.c | 13 ++
net/sctp/sm_make_chunk.c | 7 ++
net/sctp/sm_sideeffect.c | 2 +-
22 files changed, 207
[PATCH] clk: qcom: Allow clk_set_parent() to work on display clocks
Sometimes the display driver may want to change the parent PLL of
the display clocks (byte and pixel clocks) depending on the
use-case. Currently the parent is fixed by means of having a
frequency table with one entry that chooses a particular parent.
Remove this restriction and use the parent the clock is
configured for in the hardware during clk_set_rate(). This
requires consumers to rely on the default parent or to configure
the parent with clk_set_parent()/assigned-clock-parents on the
clocks before calling clk_set_rate().
Cc: Archit Taneja
Cc: Hai Li
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/clk-rcg.h | 1 +
drivers/clk/qcom/clk-rcg2.c | 91 +
drivers/clk/qcom/gcc-msm8916.c | 14 +--
drivers/clk/qcom/mmcc-apq8084.c | 18 +---
drivers/clk/qcom/mmcc-msm8974.c | 11 +
5 files changed, 89 insertions(+), 46 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index 56028bb31d87..31f92d70e8e0 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -171,6 +171,7 @@ struct clk_rcg2 {
extern const struct clk_ops clk_rcg2_ops;
extern const struct clk_ops clk_edp_pixel_ops;
extern const struct clk_ops clk_byte_ops;
+extern const struct clk_ops clk_byte2_ops;
extern const struct clk_ops clk_pixel_ops;
#endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 9aec1761fd29..d941dea6f7c7 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -485,6 +485,76 @@ const struct clk_ops clk_byte_ops = {
};
EXPORT_SYMBOL_GPL(clk_byte_ops);
+static int clk_byte2_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+ unsigned long parent_rate, div;
+ u32 mask = BIT(rcg->hid_width) - 1;
+ struct clk_hw *p;
+ unsigned long rate = req->rate;
+
+ if (rate == 0)
+ return -EINVAL;
+
+ p = req->best_parent_hw;
+ req->best_parent_rate = parent_rate = clk_hw_round_rate(p, rate);
+
+ div = DIV_ROUND_UP((2 * parent_rate), rate) - 1;
+ div = min_t(u32, div, mask);
+
+ req->rate = calc_rate(parent_rate, 0, 0, 0, div);
+
+ return 0;
+}
+
+static int clk_byte2_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate)
+{
+ struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+ struct freq_tbl f = { 0 };
+ unsigned long div;
+ int i, num_parents = clk_hw_get_num_parents(hw);
+ u32 mask = BIT(rcg->hid_width) - 1;
+ u32 cfg;
+
+ div = DIV_ROUND_UP((2 * parent_rate), rate) - 1;
+ div = min_t(u32, div, mask);
+
+ f.pre_div = div;
+
+ regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr + CFG_REG, );
+ cfg &= CFG_SRC_SEL_MASK;
+ cfg >>= CFG_SRC_SEL_SHIFT;
+
+ for (i = 0; i < num_parents; i++) {
+ if (cfg == rcg->parent_map[i].cfg) {
+ f.src = rcg->parent_map[i].src;
+ return clk_rcg2_configure(rcg, );
+ }
+ }
+
+ return -EINVAL;
+}
+
+static int clk_byte2_set_rate_and_parent(struct clk_hw *hw,
+ unsigned long rate, unsigned long parent_rate, u8 index)
+{
+ /* Read the hardware to determine parent during set_rate */
+ return clk_byte2_set_rate(hw, rate, parent_rate);
+}
+
+const struct clk_ops clk_byte2_ops = {
+ .is_enabled = clk_rcg2_is_enabled,
+ .get_parent = clk_rcg2_get_parent,
+ .set_parent = clk_rcg2_set_parent,
+ .recalc_rate = clk_rcg2_recalc_rate,
+ .set_rate = clk_byte2_set_rate,
+ .set_rate_and_parent = clk_byte2_set_rate_and_parent,
+ .determine_rate = clk_byte2_determine_rate,
+};
+EXPORT_SYMBOL_GPL(clk_byte2_ops);
+
static const struct frac_entry frac_table_pixel[] = {
{ 3, 8 },
{ 2, 9 },
@@ -496,14 +566,9 @@ static const struct frac_entry frac_table_pixel[] = {
static int clk_pixel_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
{
- struct clk_rcg2 *rcg = to_clk_rcg2(hw);
unsigned long request, src_rate;
int delta = 10;
- const struct freq_tbl *f = rcg->freq_tbl;
const struct frac_entry *frac = frac_table_pixel;
- int index = qcom_find_src_index(hw, rcg->parent_map, f->src);
-
- req->best_parent_hw = clk_hw_get_parent_by_index(hw, index);
for (; frac->num; frac++) {
request = (req->rate * frac->den) / frac->num;
@@ -525,12 +590,23 @@ static int clk_pixel_set_rate(struct clk_hw *hw, unsigned
long rate,
unsigned long parent_rate)
{
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
- struct freq_tbl f = *rcg->freq_tbl;
+ struct freq_tbl f = { 0 };
const struct frac_entry *frac = frac_table_pixel;
unsigned long request;
int delta =
Re: [PATCH v2,2/5] powerpc/rcpm: add RCPM driver
On Thu, Aug 27, 2015 at 4:35 AM, Scott Wood
wrote:
On Wed, Aug 26, 2015 at 08:09:45PM +0800, Chenhui Zhao wrote:
+#ifdef CONFIG_PPC_BOOK3E
+static void qoriq_disable_thread(int cpu)
+{
+ int hw_cpu = get_hard_smp_processor_id(cpu);
+ int thread = cpu_thread_in_core(hw_cpu);
+
+ mtspr(SPRN_TENC, TEN_THREAD(thread));
+}
+#endif
This file is always used on book3e. If the intent is to only build
this
on 64-bit, use CONFIG_PPC64 rather than relying on the fact that this
one
of the confusing mess of BOOKE/BOOK3E symbols is 64-bit-only.
OK. Will use CONFIG_PPC64.
+static void rcpm_v2_cpu_die(int cpu)
+{
+#ifdef CONFIG_PPC_BOOK3E
+ int primary;
+
+ if (threads_per_core == 2) {
+ primary = cpu_first_thread_sibling(cpu);
+ if (cpu_is_offline(primary) && cpu_is_offline(primary + 1)) {
+ /* if both threads are offline, put the cpu in PH20 */
+ rcpm_v2_cpu_enter_state(cpu, E500_PM_PH20);
+ } else {
+ /* if only one thread is offline, disable the thread */
+ qoriq_disable_thread(cpu);
+ }
+ }
+#endif
+
+ if (threads_per_core == 1) {
+ rcpm_v2_cpu_enter_state(cpu, E500_PM_PH20);
+ return;
+ }
+}
That "return;" adds nothing, and it's even more awkward having it on
the
one-thread case but not the two-thread case.
Will get rid of it.
+static void rcpm_v1_cpu_up_prepare(int cpu)
+{
+ rcpm_v1_cpu_exit_state(cpu, E500_PM_PH15);
+ rcpm_v1_irq_unmask(cpu);
+}
+
+static void rcpm_v2_cpu_exit_state(int cpu, int state)
+{
+ int hw_cpu = get_hard_smp_processor_id(cpu);
+ u32 mask = 1 << cpu_core_index_of_thread(hw_cpu);
Are you sure cpu_core_index_of_thread() is supposed to take a hardware
cpu id? The only current user, pseries_energy.c, has the comment
"Convert logical cpu number to core number".
Here, the method of getting core index of thread is same for physical
and logical.
So use this existed function to do the job.
+static const struct of_device_id rcpm_matches[] = {
+ {
+ .compatible = "fsl,qoriq-rcpm-1.0",
+ .data = (void *)_rcpm_v1_ops,
+ },
+ {
+ .compatible = "fsl,qoriq-rcpm-2.0",
+ .data = (void *)_rcpm_v2_ops,
+ },
+ {
+ .compatible = "fsl,qoriq-rcpm-2.1",
+ .data = (void *)_rcpm_v2_ops,
+ },
+ {},
+};
Unnecessary (and const-unsafe) casts.
+
+int __init fsl_rcpm_init(void)
+{
+ struct device_node *np;
+ const struct of_device_id *match;
+ void __iomem *base;
+
+ np = of_find_matching_node_and_match(NULL, rcpm_matches, );
+ if (!np) {
+ pr_err("can't find the rcpm node.\n");
+ return -ENODEV;
+ }
It's not an error for the device tree node to not have this.
-Scott
Thanks.
-Chenhui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] module: export param_free_charp()
Dan Streetman writes:
> Change the param_free_charp() function from static to exported.
>
> It is used by zswap in the next patch.
>
> Signed-off-by: Dan Streetman
Acked-by: Rusty Russell
Thanks!
Rusty.
> ---
> include/linux/moduleparam.h | 1 +
> kernel/params.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index c12f214..52666d9 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -386,6 +386,7 @@ extern int param_get_ullong(char *buffer, const struct
> kernel_param *kp);
> extern const struct kernel_param_ops param_ops_charp;
> extern int param_set_charp(const char *val, const struct kernel_param *kp);
> extern int param_get_charp(char *buffer, const struct kernel_param *kp);
> +extern void param_free_charp(void *arg);
> #define param_check_charp(name, p) __param_check(name, p, char *)
>
> /* We used to allow int as well as bool. We're taking that away! */
> diff --git a/kernel/params.c b/kernel/params.c
> index b6554aa..93a380a 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -325,10 +325,11 @@ int param_get_charp(char *buffer, const struct
> kernel_param *kp)
> }
> EXPORT_SYMBOL(param_get_charp);
>
> -static void param_free_charp(void *arg)
> +void param_free_charp(void *arg)
> {
> maybe_kfree_parameter(*((char **)arg));
> }
> +EXPORT_SYMBOL(param_free_charp);
>
> const struct kernel_param_ops param_ops_charp = {
> .set = param_set_charp,
> --
> 2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] DMA: pl330: add quirk for broken no flushp
From: Addy Ke
This patch add "arm,pl330-broken-no-flushp" quirk to avoid execute
DMAFLUSHP if Soc doesn't support it.
Signed-off-by: Addy Ke
Signed-off-by: Shawn Lin
cc: Doug Anderson
cc: Heiko Stuebner
cc: Olof Johansson
---
Changes in v2:
- amend the author
- amend Olof's mail address
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
by Krzysztof.
- remove Sunny's tag
drivers/dma/pl330.c | 87 ++---
1 file changed, 62 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0d544d2..3b9b426 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -34,6 +34,8 @@
#define PL330_MAX_IRQS 32
#define PL330_MAX_PERI 32
+#define PL330_QUIRK_BROKEN_NO_FLUSHP BIT(0)
+
enum pl330_cachectrl {
CCTRL0, /* Noncacheable and nonbufferable */
CCTRL1, /* Bufferable only */
@@ -488,6 +490,17 @@ struct pl330_dmac {
/* Peripheral channels connected to this DMAC */
unsigned int num_peripherals;
struct dma_pl330_chan *peripherals; /* keep at end */
+ int quirks;
+};
+
+static struct pl330_of_quirks {
+ char *quirk;
+ int id;
+} of_quirks[] = {
+ {
+ .quirk = "arm,pl330-broken-no-flushp",
+ .id = PL330_QUIRK_BROKEN_NO_FLUSHP,
+ }
};
struct dma_pl330_desc {
@@ -1137,53 +1150,68 @@ static inline int _ldst_memtomem(unsigned dry_run, u8
buf[],
return off;
}
-static inline int _ldst_devtomem(unsigned dry_run, u8 buf[],
- const struct _xfer_spec *pxs, int cyc)
+static inline int _ldst_devtomem(struct pl330_dmac *pl330, unsigned dry_run,
+u8 buf[], const struct _xfer_spec *pxs,
+int cyc)
{
int off = 0;
enum pl330_cond cond;
- cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+ if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
+ cond = BURST;
+ else
+ cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
while (cyc--) {
off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LDP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_ST(dry_run, [off], ALWAYS);
- off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
+
+ if (!(pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP))
+ off += _emit_FLUSHP(dry_run, [off],
+ pxs->desc->peri);
}
return off;
}
-static inline int _ldst_memtodev(unsigned dry_run, u8 buf[],
- const struct _xfer_spec *pxs, int cyc)
+static inline int _ldst_memtodev(struct pl330_dmac *pl330,
+unsigned dry_run, u8 buf[],
+const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
enum pl330_cond cond;
- cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+ if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
+ cond = BURST;
+ else
+ cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
+
while (cyc--) {
off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LD(dry_run, [off], ALWAYS);
off += _emit_STP(dry_run, [off], cond, pxs->desc->peri);
- off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
+
+ if (!(pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP))
+ off += _emit_FLUSHP(dry_run, [off],
+ pxs->desc->peri);
}
return off;
}
-static int _bursts(unsigned dry_run, u8 buf[],
+static int _bursts(struct pl330_dmac *pl330, unsigned dry_run, u8 buf[],
const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
switch (pxs->desc->rqtype) {
case DMA_MEM_TO_DEV:
- off += _ldst_memtodev(dry_run, [off], pxs, cyc);
+ off += _ldst_memtodev(pl330, dry_run, [off], pxs, cyc);
break;
case DMA_DEV_TO_MEM:
- off += _ldst_devtomem(dry_run, [off], pxs, cyc);
+ off += _ldst_devtomem(pl330, dry_run, [off], pxs, cyc);
break;
case DMA_MEM_TO_MEM:
off += _ldst_memtomem(dry_run, [off], pxs, cyc);
@@ -1197,7 +1225,7 @@ static int _bursts(unsigned dry_run, u8 buf[],
}
/* Returns bytes consumed and updates bursts */
-static inline int _loop(unsigned dry_run, u8 buf[],
+static inline int _loop(struct pl330_dmac *pl330, unsigned dry_run, u8 buf[],
unsigned long *bursts, const struct _xfer_spec *pxs)
{
int cyc, cycmax, szlp, szlpend, szbrst, off;
@@ -1220,7 +1248,7 @@ static inline int _loop(unsigned dry_run, u8 buf[],
}
[PATCH v2 1/5] DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit
From: Boojin Kim
This patch adds to support burst mode for dev-to-mem and
mem-to-dev transmit.
Signed-off-by: Boojin Kim
Signed-off-by: Addy Ke
Signed-off-by: Shawn Lin
cc: Heiko Stuebner
cc: Doug Anderson
cc: Olof Johansson
---
Changes in v2:
- amend the author
- amend Olof's mail address
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
by Krzysztof.
- add From original author.
- remove Sunny's tag
drivers/dma/pl330.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index ecab4ea0..0d544d2 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1141,10 +1141,13 @@ static inline int _ldst_devtomem(unsigned dry_run, u8
buf[],
const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
+ enum pl330_cond cond;
+
+ cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
while (cyc--) {
- off += _emit_WFP(dry_run, [off], SINGLE, pxs->desc->peri);
- off += _emit_LDP(dry_run, [off], SINGLE, pxs->desc->peri);
+ off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
+ off += _emit_LDP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_ST(dry_run, [off], ALWAYS);
off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
}
@@ -1156,11 +1159,14 @@ static inline int _ldst_memtodev(unsigned dry_run, u8
buf[],
const struct _xfer_spec *pxs, int cyc)
{
int off = 0;
+ enum pl330_cond cond;
+
+ cond = (pxs->desc->rqcfg.brst_len == 1) ? SINGLE : BURST;
while (cyc--) {
- off += _emit_WFP(dry_run, [off], SINGLE, pxs->desc->peri);
+ off += _emit_WFP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_LD(dry_run, [off], ALWAYS);
- off += _emit_STP(dry_run, [off], SINGLE, pxs->desc->peri);
+ off += _emit_STP(dry_run, [off], cond, pxs->desc->peri);
off += _emit_FLUSHP(dry_run, [off], pxs->desc->peri);
}
@@ -2557,7 +2563,7 @@ static struct dma_async_tx_descriptor
*pl330_prep_dma_cyclic(
desc->rqtype = direction;
desc->rqcfg.brst_size = pch->burst_sz;
- desc->rqcfg.brst_len = 1;
+ desc->rqcfg.brst_len = pch->burst_len;
desc->bytes_requested = period_len;
fill_px(>px, dst, src, period_len);
@@ -2702,7 +2708,7 @@ pl330_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
}
desc->rqcfg.brst_size = pch->burst_sz;
- desc->rqcfg.brst_len = 1;
+ desc->rqcfg.brst_len = pch->burst_len;
desc->rqtype = direction;
desc->bytes_requested = sg_dma_len(sg);
}
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform
From: Addy Ke
Pl330 integrated in rk3288 platform doesn't support
DMAFLUSHP function. So we add arm,pl330-broken-no-flushp quirk
for it.
Signed-off-by: Addy Ke
Signed-off-by: Shawn Lin
cc: Heiko Stuebner
cc: Olof Johansson
Reviewed-by: Doug Anderson
---
Changes in v2:
- amend the author
- add Reviewed-by: Doug Anderson
- amend Olof's mail address
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
by Krzysztof.
- remove Sunny's tag
arch/arm/boot/dts/rk3288.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 22316d0..106adf7 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -144,6 +144,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC2>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
};
dmac_bus_ns: dma-controller@ff60 {
@@ -155,6 +156,7 @@
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
status = "disabled";
+ arm,pl330-broken-no-flushp;
};
dmac_bus_s: dma-controller@ffb2 {
@@ -165,6 +167,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
};
};
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform
Pl330 integrated in rk3xxx platform doesn't support
DMAFLUSHP function. So we add arm,pl330-broken-no-flushp quirk
for it.
Signed-off-by: Shawn Lin
cc: Heiko Stuebner
cc: Doug Anderson
cc: Olof Johansson
---
Changes in v2: None
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
by Krzysztof.
arch/arm/boot/dts/rk3xxx.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index a2ae9f3..a8ca4b3 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -79,6 +79,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA1>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
};
dmac1_ns: dma-controller@2001c000 {
@@ -89,6 +90,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA1>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
status = "disabled";
};
@@ -100,6 +102,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMA2>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
};
};
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp
Signed-off-by: Shawn Lin Reviewed-by: Doug Anderson --- Changes in v2: - add Reviewed-by: Doug Anderson - reorder this patch before the usage of the quirk Changes in v1: - rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested by Krzysztof. Documentation/devicetree/bindings/dma/arm-pl330.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt index 2675658..db7e226 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt @@ -15,6 +15,7 @@ Optional properties: cells in the dmas property of client device. - dma-channels: contains the total number of DMA channels supported by the DMAC - dma-requests: contains the total number of DMA requests supported by the DMAC + - arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP Example: -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: make module.c itself more explicitly non-modular
Paul Gortmaker writes: > On 2015-08-26 12:06 AM, Rusty Russell wrote: >> Paul Gortmaker writes: >>> The Kconfig currently controlling compilation of this code is: >>> >>> menuconfig MODULES >>>bool "Enable loadable module support" >>> >>> ...meaning that it currently is not being built as a module by anyone. >>> No surprise here, since modular support being a module would be an >>> interesting chicken before the egg problem. >>> >>> Lets remove the use of module_init in this code so that when reading >>> the file, there is less doubt that it is builtin-only. >>> >>> Since module_init translates to device_initcall in the non-modular >>> case, the init ordering remains unchanged with this commit. However >>> one could argue that fs_initcall makes more sense for proc stuff, >>> and we can change the initcall order later and watch for fallout >>> if so desired. >> >> This patch is just weird; is this part of something larger you are >> trying to do? > > Yes, it is part of a larger cleanup; for subsystems with more than > one patch I created a 0/N explanatory note; such as: > > https://lkml.kernel.org/r/1440459295-21814-1-git-send-email-paul.gortma...@windriver.com > https://lkml.kernel.org/r/1437530538-5078-1-git-send-email-paul.gortma...@windriver.com > > and others. Apologies for the lack of context on this single patch. > >> I would argue that module_init() should be the default; it implies >> no dependencies on the initialization, and it's a common pattern. > > To summarize briefly, module_init forces everything into one > initcall priority bin That's a feature. Everything should be in one bin unless there's reason to specify; once you've specified, it's almost impossible to change because our system is now so complicated. module_init() says "I don't care". > , it encourages people to write module_exit > functions that are never used Then write a checker. It's not that hard for kbuild to show stuff that can never be a module, I'm sure. >, and it can make the code appear > inconsistent with the Kconfig and/or Makefile settings. So I'd > hope you'd agree that there is value in not using module_init > in code that can never be modular. On the other hand, people cut & paste like crazy, so it makes sense to have them all use module_init() and not build non-modular code, because most code is a module. Since this is total bikeshed, you can apply this yourself: Acked-by: Rusty Russell (disagree, but hey...) Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] Fix broken DMAFLUSHP on Rockchips platform
The purpose of the DMAFLUSHP instruction: - Tell the peripheral to clear its status and control registers. - Send a message to the peripheral to resend its level status. There are 3 timings described in PL330 Technical Reference Manual: - Timing 1: Burst request, can work well without DMAFLUSHP. - Timing 2: Single and burst request, DMAC will ignore the single transfer request. This timing happens if there are single and burst request. - Timing 3: Single transfers for a burst request, DMAC should signals datype to request the peripheral to flush the contents of any control registers. This timing happens if there is not enough MFIFO to places the burst data. A peripheral may signal a DMA request during the execution of DMAFLUSHP instruction, that cause DMA request being ignored by DMAC. But DMAC and all peripherals on RK3X SoCs DO NOT support DMAFLUSHP. It can't send a message to the peripheral to resend DMA request, and the peripheral can't acknowledge a flush request from DMAC. So all DMA requests should NOT be ignored by DMAC, and DMAC will not notify the peripheral to flush. To fix this problem, we need: - Do NOT execute DMAFLUSHP instruction. - Timing 2 and timing 3 should not happen. Because on RK3X SoCs, there are 6 or below channels and 32 MFIFO depth for DMAC_BUS, and 8 channels and 64 MFIFO depth for DMAC_PERI, it is impossible to hit the timing 3 if burst length is equal or less than 4. Since the request type signal by the peripheral can only be set by software. We can set Rockchip Soc's GRF_PERIDMAC_CON0[2:1] to select single or burst request, if it is set b01, all of the peripharals will signal a brust request. So the timing 2 will not happen, too. So DMAC on RK3X can support single or burst transfer, but can't support mixed transfer. Because burst transfer is more efficient than single transfer, this is confirmed by our ASIC team, who strongly suggest to use burst transfer. And this is confirmed by Addy's test on RK3288-Pink2 board, the speed of spi flash burst transfer will increase about two times than single transfer. Also, I have tested dw_mmc with pl330 on RK3188 platform to double confirm the result. That means burst transfer is reansonable. So we need a quirk not to execute DMAFLUSHP instruction and to use burst transfer. Note: - The Rockchip Soc default value of GRF_PERIDMAC_CON0[2:1] is b01. To support brust transfer, these bits should not be changed in bootloader. Changes in v2: - amend the author - reorder the patches suggested by Doug - add Reviewed-by: Doug Anderson for rk3288.dtsi patch and arm-pl330.txt patch - amend Olof's mail address Changes in v1: - rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested by Krzysztof. - add From original author. - remove Sunny's tag Addy Ke (2): DMA: pl330: add quirk for broken no flushp ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3288 platform Boojin Kim (1): DMA: pl330: support burst mode for dev-to-mem and mem-to-dev transmit Shawn Lin (2): Documentation: arm-pl330: add description of arm,pl330-broken-no-flushp ARM: dts: Add arm,pl330-broken-no-flushp quirk for rk3xxx platform .../devicetree/bindings/dma/arm-pl330.txt | 1 + arch/arm/boot/dts/rk3288.dtsi | 3 + arch/arm/boot/dts/rk3xxx.dtsi | 3 + drivers/dma/pl330.c| 101 +++-- 4 files changed, 79 insertions(+), 29 deletions(-) -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mmc: block: disable the reliable write If the card does not support CMD23
Hi Uffe, Since Reliable Write depends on the CMD23. I think we need to disable Reliable Write if the card does not support CMD23(due to performance impact issue), so I add this patch. Do you think we still need to enable Reliable Write even if the card does not support CMD23? Thanks, Yong Li > Date: Thu, 27 Aug 2015 15:22:44 +0200 > Subject: Re: [PATCH] mmc: block: disable the reliable write If the card does > not support CMD23 > From: ulf.hans...@linaro.org > To: sdliy...@gmail.com > CC: ch...@printf.net; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > On 25 August 2015 at 14:06, Ulf Hansson wrote: >> On 14 August 2015 at 09:30, wrote: >>> From: Yong Li >>> >>> Signed-off-by: Yong Li >>> --- >>> drivers/mmc/card/block.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c >>> index 452782b..d9e3c45 100644 >>> --- a/drivers/mmc/card/block.c >>> +++ b/drivers/mmc/card/block.c >>> @@ -1366,7 +1366,8 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req >>> *mqrq, >>> bool do_rel_wr = ((req->cmd_flags & REQ_FUA) || >>> (req->cmd_flags & REQ_META)) && >>> (rq_data_dir(req) == WRITE) && >>> - (md->flags & MMC_BLK_REL_WR); >>> + (md->flags & MMC_BLK_REL_WR) && >>> + !(card->quirks & MMC_QUIRK_BLK_NO_CMD23); >> >> Further down in mmc_blk_rw_rq_prep() we check for >> MMC_QUIRK_BLK_NO_CMD23. That check becomes redundant after this >> change, please remove that check as a part of this patch as well. >> >>> >>> memset(brq, 0, sizeof(struct mmc_blk_request)); >>> brq->mrq.cmd = >cmd; >>> -- >>> 2.1.0 >>> >> > > Please ignore my previous answer. MMC_QUIRK_BLK_NO_CMD23 is intended > to indicate to the mmc block layer whether using CMD23 for regular > block IO request could have a performance impact for some cards. If > that's the case we don't use it - except when using reliable write! > > So this patch is just plain wrong. > > Kind regards > Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 5/5] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Reviewed-by: Brian Norris
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <_i2c0>;
};
+ {
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_nfc>;
+ status = "okay";
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
@@ -156,6 +176,25 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 3/5] mtd: nand: vf610_nfc: add device tree bindings
Signed-off-by: Bill Pringlemeir
Acked-by: Shawn Guo
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..6be4871
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,59 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc".
+- reg: address range of the NFC.
+- interrupts: interrupt of the NFC.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- assigned-clocks: main clock from the SoC, for Vybrid < VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+
+Required children nodes:
+Children nodes represent the available nand chips. Currently the driver can
+only handle one NAND chip.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc-cs".
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400e 0x4000>;
+ interrupts = ;
+ clocks = < VF610_CLK_NFC>;
+ clock-names = "nfc";
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+ };
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v11 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).
Limitations:
- HW ECC: Only 2K page with 64+ OOB.
- HW ECC: Only 24 and 32-bit error correction implemented.
Raw writes have been tested using the generic nand_write_page_raw
implementation. However, raw reads are currently not possible
because the controller need to know whether we are going to use
the ECC mode already at NAND_CMD_READ0 command time. At this point
we do not have the information whether it is a raw read or a
regular read at driver level...
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/Kconfig | 6 +-
drivers/mtd/nand/vf610_nfc.c | 204 ++-
2 files changed, 206 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 9f9736c..ccd1158 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -466,8 +466,10 @@ config MTD_NAND_VF610_NFC
help
Enables support for NAND Flash Controller on some Freescale
processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index eba67dc..14f51c8 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,8 +19,8 @@
* - Untested on MPC5125 and M54418.
* - DMA and pipelining not used.
* - 2K pages or less.
- * - No chip select, one NAND chip per controller.
- * - No hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
*/
#include
@@ -77,6 +77,8 @@
/* NFC ECC mode define */
#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
/*** Register Mask and bit definitions */
@@ -129,6 +131,18 @@
#define CMD_DONE_CLEAR_BIT BIT(18)
#define IDLE_CLEAR_BIT BIT(17)
+/*
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
+ */
+#define ECC_SRAM_ADDR (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT 0x3F
+
enum vf610_nfc_alt_buf {
ALT_BUF_DATA = 0,
ALT_BUF_ID = 1,
@@ -152,10 +166,40 @@ struct vf610_nfc {
enum vf610_nfc_alt_buf alt_buf;
enum vf610_nfc_variant variant;
struct clk *clk;
+ bool use_hw_ecc;
+ u32 ecc_mode;
};
#define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+ .eccbytes = 60,
+ .eccpos = { 4, 5, 6, 7, 8, 9, 10, 11,
+ 12, 13, 14, 15, 16, 17, 18, 19,
+ 20, 21, 22, 23, 24, 25, 26, 27,
+ 28, 29, 30, 31, 32, 33, 34, 35,
+ 36, 37, 38, 39, 40, 41, 42, 43,
+ 44, 45, 46, 47, 48, 49, 50, 51,
+ 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63 },
+ .oobfree = {
+ {.offset = 2,
+.length = 2} }
+};
+
static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
{
return readl(nfc->regs + reg);
@@ -298,6 +342,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc,
int column, int page)
ROW_ADDR_SHIFT, page);
}
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+ vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+ CONFIG_ECC_MODE_MASK,
+ CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
{
[PATCH v11 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
In this 11th revision the driver now rereads the OOB area in case hardware ECC fails. This allows to count the flipped bits accross the whole page reliably. Also the device tree bindings have been updated: NAND chips can be specified using sub-nodes, the ECC properties are part of those chip nodes. Note however that the driver currently only supports one NAND chip. The driver has been verified again using the MTD tests. More information and the full test log of earlier patchset version can be found in the cover letter of the last revision v6: http://thread.gmane.org/gmane.linux.kernel/1979868 Changes since v10: - Rebased onto l2-mtd/master - Use children nodes for NAND chips in device tree bindings - Support exactly one NAND chip using the new device tree bindings - Reread page OOB on ECC error in order to reliable determine the amount of bit flips on a erased page - Use ECC strength/2 as the only bit flip threshold - Rely on endianness aware word read to read the ECC status - Introduce vf610_nfc_variant which reflects the variant according to the device tree compatible string - Use variant to determine chip select implementation - Use enum for alternate buffer indication - Renamed page_sz variable in struct vf610_nfc as well as in the function vf610_nfc_command to more specific names - Some smaller code cleanup (altered ECC_SRAM_ADDR, introduce OOB_MAX) Changes since v9: - Remove inline of vf610_nfc_done - Add __iomem to src argument of vf610_nfc_memcpy - Handle return value of mtd_device_parse_register correctly - Count bits in OOB too (only non-ECC bits) - Return bitflips in ecc.read_page callback vf610_nfc_read_page - Fall-through ALT_BUF_ONFI - Use BIT macros Changes since v8: - Fix 16-Bit NAND flash support by splitting up initialization (introduce vf610_nfc_preinit_controller) - Updated comments in initialziation functions Changes since v7: - vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node and sort new nfc node behind the existing iomuxc node as well. - vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes Changes since v6: - Rebased ontop of l2-mtd/master (v4.2-rc1 based) - Removed HAVE_NAND_VF610_NFC and use depends on. This made "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary Changes since v5: - Removed fsl,mpc5125-nfc compatible string - Removed readl/writel_relaxed - Change interface of vf610_nfc_transfer_size to match other accessors Changes since v4: - Rebased ontop of l2-mtd/master (v4.1-rc4 based) - Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does not support sub-page writes anyway (improves write performance) - Support ONFI by enabling READID command with offset and parameter page reads (CMD_PARAM) - Change to dedicated read_page/write_page function, enables raw writes - Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements - Eliminated vf610_nfc_probe_dt in favor of common DT init code - Use wait_for_completion_timeout - Some style fixes (spaces, etc.) Changes since v3: - Make the driver selectable when COMPILE_TEST is set - Fix compile error due to superfluous ECC_STATUS configuration in initial patch (without ECC correction ECC_STATUS does not need to be configured) - Remove custom BBT pattern and switch to in-band BBT in the initial patch - Include two bug fixes, for details see the corresponding U-Boot patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 Changes since v2: - Updated binding documentation Changes since v1: - Nest nfc_config struct within the main nfc struct - Use assigned clock binding to specify NFC clock - Rebased ontop of MSCM IR patchset (driver parts have been merged) - Split out arch Kconfig in a separate config - Fix module license - Updated MAINTAINERS Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes which uses up to 60 bytes on 64 byte OOB - Removed custom (downstream) BBT pattern since BBT table won't be compatible anyway (due to the change above) mtd_speedtest of this 11th revision on a Colibri VF61: [ 2321.921612] = [ 2321.927459] mtd_speedtest: MTD device: 3 [ 2321.936619] mtd_speedtest: MTD device size 104857600, eraseblock size 131072, page size 2048, count of eraseblocks 800, pages per eraseblock 64, OOB size 64 [ 2321.954428] mtd_test: scanning for bad eraseblocks [ 2321.959626] mtd_test: block 142 is bad [ 2321.966038] mtd_test: scanned 800 eraseblocks, 1 are bad [ 2322.370120] mtd_speedtest: testing eraseblock write speed [ 2344.047677] mtd_speedtest:
[PATCH v11 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
This driver supports Freescale NFC (NAND flash controller) found on Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has been tested using 8-bit and 16-bit NAND interface on the ARM based Vybrid SoC VF500 and VF610 platform. parameter page reading. Limitations: - Untested on MPC5125 and M54418. - DMA and pipelining not used. - 2K pages or less. - No chip select, one NAND chip per controller. - No hardware ECC. Some paths have been hand-optimized and evaluated by measurements made using mtd_speedtest.ko on a 100MB MTD partition. Colibri VF50 eb write % eb read % page write % page read % rel/opt 5175 115374560 11039 opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10 none5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58 Colibri VF61 eb write % eb read % page write % page read % rel/opt 5766 130965459 12846 opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34 none5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86 rel = using readl_relaxed/writel_relaxed in optimized paths opt = hand-optimized by combining multiple accesses into one read/write The measurements have not been statistically verfied, hence use them with care. The author came to the conclusion that using the relaxed variants of readl/writel are not worth the additional code. Signed-off-by: Bill Pringlemeir Tested-by: Albert ARIBAUD Signed-off-by: Stefan Agner --- MAINTAINERS | 6 + drivers/mtd/nand/Kconfig | 9 + drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 690 +++ 4 files changed, 706 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/MAINTAINERS b/MAINTAINERS index 9567329..59975c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10835,6 +10835,12 @@ S: Maintained F: Documentation/fb/uvesafb.txt F: drivers/video/fbdev/uvesafb.* +VF610 NAND DRIVER +M: Stefan Agner +L: linux-...@lists.infradead.org +S: Supported +F: drivers/mtd/nand/vf610_nfc.c + VFAT/FAT/MSDOS FILESYSTEM M: OGAWA Hirofumi S: Maintained diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..9f9736c 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -460,6 +460,15 @@ config MTD_NAND_MPC5121_NFC This enables the driver for the NAND flash controller on the MPC5121 SoC. +config MTD_NAND_VF610_NFC + tristate "Support for Freescale NFC for VF610/MPC5125" + depends on (SOC_VF610 || COMPILE_TEST) + help + Enables support for NAND Flash Controller on some Freescale + processors like the VF610, MPC5125, MCF54418 or Kinetis K70. + The driver supports a maximum 2k page size. The driver + currently does not support hardware ECC. + config MTD_NAND_MXC tristate "MXC NAND support" depends on ARCH_MXC diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..a490af8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..eba67dc --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,690 @@ +/* + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Jason ported to M54418TWR and MVFA5 (VF610). + * Authors: Stefan Agner + * Bill Pringlemeir + * Shaohui Xie + * Jason Jin + * + * Based on original driver mpc5121_nfc.c. + * + * This is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA and pipelining not used. + * - 2K pages or less. + * - No chip select, one NAND chip per controller. + * - No hardware ECC. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDRV_NAME"vf610_nfc" + +/* Register Offsets */ +#define NFC_FLASH_CMD1
[PATCH v11 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir
Reviewed-by: Brian Norris
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf610-twr.dts | 47 +
arch/arm/boot/dts/vfxxx.dtsi| 10 +
2 files changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..64d1696 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
};
+ {
+ assigned-clocks = < VF610_CLK_NFC>;
+ assigned-clock-rates = <3300>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_nfc>;
+ status = "okay";
+
+ nand@0 {
+ compatible = "fsl,vf610-nfc-nandcs";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <24>;
+ nand-ecc-step-size = <2048>;
+ nand-on-flash-bbt;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..17066a2 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,16 @@
status = "disabled";
};
+ nfc: nand@400e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-nfc";
+ reg = <0x400e 0x4000>;
+ interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_NFC>;
+ clock-names = "nfc";
+ status = "disabled";
+ };
};
};
};
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: Fix module autoload for rtc-{ab8500,max8997,s5m} drivers
On 27.08.2015 19:34, Javier Martinez Canillas wrote: > These platform drivers have a platform device ID table but the module > alias information is not created so module autoloading will not work. > > Signed-off-by: Javier Martinez Canillas > > --- > > drivers/rtc/rtc-ab8500.c | 1 + > drivers/rtc/rtc-max8997.c | 1 + > drivers/rtc/rtc-s5m.c | 1 + > 3 files changed, 3 insertions(+) Makes sense: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs
Dmitry Torokhov writes: > On Tue, Aug 25, 2015 at 3:45 PM, Kevin Hilman wrote: >> Doug Anderson writes: >> >>> To put things in a >>> concrete way, for pd_vio we'd go through the entire device tree >>> ourselves and find all properties that look like "power-domains = >>> < RK3288_PD_VIO>;". We'd then find the parent of those >>> properties and look for a property named "clocks". We'd then iterate >>> over all those clocks and turn those on. Did I get that right? >> >> ... but you make it sound like more work than it is. The genpd already >> keeps a list of devices that refer to the power domain. In fact, the >> genpd 'attach' method can be platform-specific, so could be used to keep >> track of a list (or a subset) of clocks which are needed for reset. > > That is not really workable: the attach and detach happen in > probe/remove path; if you do not have driver for the device you will > miss the clocks for it. And in my proposal, I suggested that clocks without drivers are good candidates to list in the domain, with the caveat that the be called out (documented) as being device clocks that are missing a driver, so when a driver shows up they can be moved accordingly, and in a way that actually describes the hardware. > And the quirk of this SoC is that we need to > turn all clocks during domain transition, regardless of whether there > is a driver for all devices. I understand. And that "quirk" is not unique to rockchip socs. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI / properties: Hierarchical properties support
On Thu Aug 27 04:34, Rafael J. Wysocki wrote:
Hi Rafael,
> The issue at hand is that we need to be able to support hierarchical device
> properties in ACPI, like when the set of properties of an entity called "Fred"
> may include a subset called "dog" containing the properties of the Fred's dog
> rather than those of Fred himself. And it may make sense to have the same
> property, like "hair color", for both Fred and the dog, but with different
> values.
OK. I have a couple of questions.
> We (I, Darren and Dave at least) have explored many possible ways to deal with
> that in ACPI, but the majority of them turned out to be unattractive for
> various
> reasons. Our first take was to use ACPI device objects to make the "child"
> property sets available via _DSD, but that approach is generally incompatible
> with the PnP Manager in Windows following the notion that all device objects
> in ACPI tables are supposed to represent real devices. It can still be made
> work by adding _STA that returns 0 to those "property-only" device objects,
> but that leads to complications in other places and is error prone (if the
> _STA
> is forgotten, for example). Moreover, it adds quite a bit of overhead even in
> Linux (an ACPICA representation, struct acpi_device, driver core mechanics
> etc)
> for things that are only supposed to represent sets of device properties.
> And,
> in addition to that, we'd need to figure out how to give those things
> arbitrary
> names in a consistent way. All of that caused us to drop the approach based
> on
> device objects and look for other options.
What's the overhead/effect on Windows for an ACPI object without a _HID (_ADR
only)? That seems like a case where the OS shouldn't be expecting to load
another driver for the ACPI object and the _ADR gives each node a unique name
(even if it is an unfriendly integer)
> The idea is that _DSD may return a package containing the properties of the
> device it belongs to along with a directory of objects that need to be
> evaluated
> in order to obtain the "child" property sets of it. That directory needs to
> be
> present in a separate section of the _DSD package (after the new UUID defined
> in
> the above document) and is a list of two-element sub-packages (entries) where
> the first element is the name of the entry (the name of the "child" property
> set
> represented by it) and the second element is a "pointer" (essentially, a path
> or "namestring" in the ACPI terminology) to the control method or a static
> data package that needs to be evaluated to obtain the entry's data. The data
> returned by it is then interpreted in the same way as a _DSD return package,
> so it may also contain properties and a directory of its own "child" property
> sets.
Do you expect there to be cases where using an ACPI device object is more
desirable than hierarchical properties? Or is it just impossible given the PNP
manager in Windows?
The best example I can think of is perhaps a multi function device where each
sub-function really does look like a separate device and you probably want to
reference that sub-device, as a device, in other ASL code.
Stating the above more generally, by taking this approach you loose the ability
to reference these child nodes as a device object. In this LED example, I
think it would be nice to set the "trigger" for the led by adding a reference
to the LED from another device (such as a NIC).
Device (NIC0)
{
...
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"activity-led", LEDS.LEDM },
Package () {"link-led", LEDS.LEDH },
},
}
}
I'm not sure that's even supported in devicetree or LEDs are the best example
of this, but the pattern seems generally useful.
Without a device you're also forced to use a "label" property instead of a
_STR.
> As an example, consider the following ASL from an experimental MinnowBoard
> firmware:
>
> Device (LEDS)
> {
> Name (_HID, "PRP0001")
>
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {10}
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {11}
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"gpio-leds"}},
> },
> // Data extension
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () {
> Package () {"heartbeat", "LEDH"},
> Package () {"mmc-activity", "LEDM"},
I guess LEDH and LEDM have to be strings here. It would be
Re: [PATCH v4 2/4] PCI: st: Add Device Tree bindings for sti pcie
On Thu, Aug 27, 2015 at 7:34 AM, Gabriel Fernandez
wrote:
> sti pcie is built around a Synopsis Designware PCIe IP.
>
> Signed-off-by: Fabrice Gasnier
> Signed-off-by: Gabriel Fernandez
> ---
> Documentation/devicetree/bindings/pci/st-pcie.txt | 53
> +++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt
> b/Documentation/devicetree/bindings/pci/st-pcie.txt
> new file mode 100644
> index 000..25fcab3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
> @@ -0,0 +1,53 @@
> +STMicroelectronics STi PCIe controller
> +
> +This PCIe host controller is based on the Synopsis Designware PCIe IP
> +and thus inherits all the common properties defined in designware-pcie.txt.
> +
> +Required properties:
> + - compatible: "st,stih407-pcie"
What about "snps,dw-pcie" as well?
> + - reg: base address and length of the pcie controller, mem-window address
> + and length available to the controller.
What is mem-window? Seems rather large and perhaps should be under ranges.
> + - interrupts: A list of interrupt outputs of the controller. Must contain an
> + entry for each entry in the interrupt-names property.
Define how many interrupts.
> + - interrupt-names: Should be "msi". STi interrupt that is asserted when an
> + MSI is received.
Kind of pointless with a single interrupt.
> + - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
> + offset for IP configuration.
> + - resets, reset-names: the power-down and soft-reset lines of PCIe IP.
> + Associated names must be "powerdown" and "softreset".
> + - phys, phy-names: the phandle for the PHY device.
> + Associated name must be "pcie"
What does this mean?
> +
> +Optional properties:
> + - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
> +
> +Example:
> +
> +pcie0: pcie@9b0 {
> + compatible = "st,pcie", "snps,dw-pcie";
> + device_type = "pci";
> + reg = <0x09b0 0x4000>, /* dbi cntrl registers */
> + <0x2fff 0x0001>, /* configuration space */
> + <0x4000 0x8000>; /* lmi mem window */
> + reg-names = "dbi", "config", "mem-window";
> + st,syscfg = <_core 0xd8 0xe0>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /*
> non-prefetchable memory */
No i/o support?
> + num-lanes = <1>;
> + interrupts = ;
> + interrupt-names = "msi";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /*
> INT A */
> + <0 0 0 2 GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /*
> INT B */
> + <0 0 0 3 GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /*
> INT C */
> + <0 0 0 4 GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /*
> INT D */
> +
> + resets = < STIH407_PCIE0_POWERDOWN>,
> +< STIH407_PCIE0_SOFTRESET>;
> + reset-names = "powerdown",
> + "softreset";
> + phys = <_port0 PHY_TYPE_PCIE>;
> + phy-names = "pcie";
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: at91: add audio pll clock driver
Quoting Boris Brezillon (2015-08-27 02:30:35)
> Hi Nicolas,
>
> On Fri, 31 Jul 2015 12:17:44 +0200
> Nicolas Ferre wrote:
>
> > This new clock driver set allows to have a fractional divided clock
> > that would generate a precise clock particularly suitable for
> > audio applications.
> >
> > The main audio pll clock has two children clocks: one that is connected
> > to the PMC, the other that can directly drive a pad. As these two routes
> > have different enable bits and different dividers and divider formula,
> > they are handled by two different drivers.
> > Each of them would modify the rate of the main audio pll parent.
>
> Hm, not sure allowing both children to modify the parent clk rate is
> a good idea, but let's see how it works.
Might be a good idea to use clk_set_rate_range? Of course most audio use
cases need exact rates...
Regards,
Mike
>
> >
> > Signed-off-by: Nicolas Ferre
> > ---
> > .../devicetree/bindings/clock/at91-clock.txt | 38 +++
> > drivers/clk/at91/Makefile | 2 +
> > drivers/clk/at91/clk-audio-pll-pad.c | 220 +
> > drivers/clk/at91/clk-audio-pll-pmc.c | 171 ++
> > drivers/clk/at91/clk-audio-pll.c | 261
> > +
> > drivers/clk/at91/pmc.c | 14 ++
> > drivers/clk/at91/pmc.h | 7 +
> > include/linux/clk/at91_pmc.h | 25 ++
> > 8 files changed, 738 insertions(+)
> > create mode 100644 drivers/clk/at91/clk-audio-pll-pad.c
> > create mode 100644 drivers/clk/at91/clk-audio-pll-pmc.c
> > create mode 100644 drivers/clk/at91/clk-audio-pll.c
> >
>
> [...]
>
> > +
> > +static int clk_audio_pll_compute_qdpad(unsigned long q_rate, unsigned long
> > rate,
> > +unsigned long *qd, u8 *div, u8
> > *ext_div)
> > +{
> > + unsigned long tmp_qd;
> > + unsigned long rem2, rem3;
> > + unsigned long ldiv, lext_div;
> > +
> > + if (!rate)
> > + return -EINVAL;
> > +
> > + tmp_qd = q_rate / rate;
> > + if (!tmp_qd || tmp_qd > AUDIO_PLL_QDPAD_MAX)
> > + return -EINVAL;
>
> Do you really want to return an error in this case?
> I mean, you're calling this function from ->round_rate(), and
> ->round_rate() is supposed to find the closest rate, not to return an
> error if the rate is too low or to high.
> ITOH, you're calling the same function from ->set_rate(), which is
> supposed to complain if the requested rate is not exactly met.
>
> Maybe you can deal with that by passing an additional argument to this
> function. Something like:
>
> tmp_qd = q_rate / rate;
>
> if (!strict) {
> if (!tmp_qd)
> tmp_qd = 1;
> else if (tmp_qd > AUDIO_PLL_QDPAD_MAX)
> tmp_qd = AUDIO_PLL_QDPAD_MAX;
> }
>
> if (!tmp_qd || tmp_qd > AUDIO_PLL_QDPAD_MAX)
> return -EINVAL;
>
> > +
> > + if (tmp_qd <= AT91_PMC_AUDIO_PLL_QDPAD_EXTDIV_MAX) {
> > + ldiv = 1;
> > + lext_div = tmp_qd;
> > + } else {
> > + rem2 = tmp_qd % 2;
> > + rem3 = tmp_qd % 3;
> > +
> > + if (rem3 == 0 ||
> > + tmp_qd > AT91_PMC_AUDIO_PLL_QDPAD_EXTDIV_MAX * 2 ||
> > + rem3 < rem2) {
> > + ldiv = 3;
> > + lext_div = tmp_qd / 3;
> > + } else {
> > + ldiv = 2;
> > + lext_div = tmp_qd >> 1;
> > + }
> > + }
> > +
> > + pr_debug("A PLL/PAD: %s, qd = %lu (div = %lu, ext_div = %lu)\n",
> > + __func__, ldiv * lext_div, ldiv, lext_div);
> > +
> > + /* if we were given variable to store, we can provide them */
> > + if (qd)
> > + *qd = ldiv * lext_div;
> > + if (div && ext_div) {
> > + /* we can cast here as we verified the bounds just above */
> > + *div = (u8)ldiv;
> > + *ext_div = (u8)lext_div;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static long clk_audio_pll_pad_round_rate(struct clk_hw *hw, unsigned long
> > rate,
> > + unsigned long *parent_rate)
>
> I thought we were trying to get rid of the ->round_rate() function in
> favor of the ->determine_rate() one (which is more flexible), but maybe
> I'm wrong. Stephen, Mike, what's your opinion?
>
> > +{
> > + struct clk *pclk = __clk_get_parent(hw->clk);
> > + long best_rate = -EINVAL;
> > + unsigned long best_parent_rate = 0;
> > + unsigned long tmp_qd;
> > +
> > + pr_debug("A PLL/PAD: %s, rate = %lu (parent_rate = %lu)\n",
> > + __func__, rate, *parent_rate);
> > +
> > + if (clk_audio_pll_compute_qdpad(AUDIO_PLL_REFERENCE_FOUT, rate,
> > + _qd, NULL, NULL))
> > +
Re: Linux Firmware Signing
On Thu, Aug 27, 2015 at 5:29 PM, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
>
> SELinux uses: security_load_policy(data, len), refer to selinuxfs
> sel_load_ops.
> Since its write operation on its file_operation is sel_write_load() and that
> is as follows:
>
> static ssize_t sel_write_load(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
> {
> ...
> }
>
> We should be able to add yet-another LSM hook here to let the kernel / LSM
> have
> access to the inode, is that LSM hook desirable ? But folks, before you answer
> note that there's a growing trend here! Its point 1 Kees had made earlier. I
> was hesitant to go into details as I think fw signing needs to be baked first
> but.. since we're reviewing all these details now it seems logical to go down
> the rabbit hole further.
>
> Everywhere where we fetch a file from within the kernel either directly (say
> firmware load, 802.11 regulatory request) or from userspace request (SELinux
> policy load node) we end up having to sprinkle a new LSM hook. In fact for
> modules and kexec there were syscalls added too. There might be a possiblity
> for sharing some of these requests / code so some review is in order for it.
>
> Here's my review if we wanted to try sharing things, in consideration and
> review of:
>
> * SELinux policy files
> * modules
> * firmware / system data (consider replacing CRDA)
> * kexec
>
>
>
> * SELinux policy files:
>
> sel_write_load() is very specific, its part of the selinuxfs and it just
> uses copy_from_user() to dump the data from the file onto a vmalloc'd
> piece of memory. We don't exactly read arbitrary files from the fs then.
> If we *really* wanted to generalize things further we probably could
> but I'm not going to lead any discussion about design over selinuxfs,
> I'll let the folks behind it think about that themselves.
While I question the usefulness of a SELinux policy signature in the
general case, there are some situations where it might make sense,
e.g. embedded systems with no post-build customizations, and I'm not
opposed to added a signature to the policy file for that reason.
However, I haven't given any serious thought yet to how we would
structure the new blob format so as to support both signed/unsigned
policies as well as existing policies which predate any PKCS #7
changes.
--
paul moore
www.paul-moore.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> On Thu, Aug 27, 2015 at 10:57:23AM -, David Woodhouse wrote:
> > > Luis R. Rodriguez wrote:
> > >
> > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name"
> > >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good
> > >>
> > >> 1.3.6.1.4.1.2312.16 Linux kernel
> > >> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types
> > >> 1.3.6.1.4.1.2312.16.2.1 - firmwareName
> > >>
> > >> I take it you are referring to this?
> > >
> > > Yes.
> > >
> > >> If we follow this model we'd then need something like:
> > >>
> > >> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName
> > >>
> > >> That should mean each OID that has different file names would need to be
> > >> explicit about and have a similar entry on the registry. I find that
> > >> pretty redundant and would like to avoid that if possible.
> > >
> > > firmwareName is easy for people to understand - it's the name the kernel
> > > asks for and the filename of the blob. seLinuxPolicyName is, I think, a
> > > lot more tricky since a lot of people don't use SELinux, and most that do
> > > don't understand it (most people that use it aren't even really aware of
> > > it).
> > >
> > > If you can use the firmwareName as the SELinux/LSM key, I would suggest
> > > doing so - even if you dress it up as a path
> > > (/lib/firmware/).
> >
> > In conversation with Mimi last week she was very keen on the model where
> > we load modules & firmware in such a fashion that the kernel has access to
> > the original inode -- by passing in a fd,
>
> Sure, so let's be specific to ensure what Mimi needs is there. I though there
> was work needed on modules but that seems covered and work then seems only
> needed for kexec and SELinux policy files (and a review of other possible file
> consumers in the kernel) for what you describe.
At last year's LSS linux-integrity status update, I mentioned 6
measurement/appraisal gaps, kernel modules (linux-3.7), firmware
(linux-3.17), kexec, initramfs, eBPF/seccomp and policies, that have
been or need to be addressed. Since then, a new kexec syscall, file
descriptor based, was upstreamed that appraises the image. Until we can
preserve the measurement list across kexec, it doesn't make sense to
measure the image just to have it thrown away. (skipping initramfs as
that isn't related to LSM hooks.) Lastly, measuring/appraising policies
(eg. IMA, SELinux, Smack, iptables/ebtables) or any other files consumed
by the kernel.
> I also went ahead and studied
> areas where we can share code now as I was looking at this code now, and also
> would like to recap on the idea of possibly just sharing the same LSM hook
> for all "read this special file from the fs in the kernel" cases. Details
> below.
>
> Fortnately the LSM hooks uses struct file and with this you can get the inode
> with this:
>
> struct inode *inode = file_inode(file);
>
> For modules we have this LSM hook:
>
> int (*kernel_module_from_file)(struct file *file);
>
> This can be used for finit_module(). Its used as follows, the fd comes from
> finit_module() syscall.
>
> SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags)
> {
> ...
> err = copy_module_from_fd(fd, );
> if (err)
> return err;
> ...
> }
>
> static int copy_module_from_fd(int fd, struct load_info *info)
> {
> struct fd f = fdget(fd);
> ...
> err = security_kernel_module_from_file(f.file);
> if (err)
> goto out;
> }
>
> For firmware we have this LSM hook:
>
> int (*kernel_fw_from_file)(struct file *file, char *buf, size_t size);
>
> > or in the firmware case by doing the fs lookup directly.
>
> Right so now that firmware usermode helper is behind us (systemd ripped it) we
> do the fs lookup directly ourselves. One of my side goals with the extensible
> firmware API was also to allow for us to take a leap and let drivers
> skip completely the usermode helper so we can then phase that code to the
> only required remainign user: the dell-rbu driver. Anyway, once we have the
> path built up we use it as follows.
>
> static int fw_read_file(const char *path, void **_buf, size_t *_size)
>
> {
> struct file *file;
> ...
> file = filp_open(path, O_RDONLY, 0);
> if (IS_ERR(file))
> return PTR_ERR(file);
> ...
> rc = security_kernel_fw_from_file(file, buf, size);
> if (rc)
Re: [PATCH v1 3/5] ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3288 platform
On 2015/8/28 0:52, Doug Anderson wrote:
Hi,
On Thu, Aug 27, 2015 at 7:24 AM, Shawn Lin wrote:
From: Addy Ke
Looks like you just added the "From" here. I think that's fine, but
better to set the author so you get the right cover letter...
Pl330 integrated in rk3288 platform doesn't support
DMAFLUSHP function. So we add broken-no-flushp quirk
for it.
Signed-off-by: Addy Ke
Signed-off-by: Shawn Lin
cc: Heiko Stuebner
cc: Doug Anderson
cc: Olof Johansson
---
Changes in v1:
- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
by Krzysztof.
- remove Sunny's tag
Note that typically for patches I see people go from "no v" to "v2". AKA:
* PATCH
* PATCH v2
* PATCH v3
arch/arm/boot/dts/rk3288.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 22316d0..106adf7 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -144,6 +144,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC2>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
Note that you should add bindings _before_ the usage of them. So
patch #5 (Documentation) needs to come before this one.
Cool! That makes sense.
Thanks, Doug.
};
dmac_bus_ns: dma-controller@ff60 {
@@ -155,6 +156,7 @@
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
status = "disabled";
+ arm,pl330-broken-no-flushp;
};
dmac_bus_s: dma-controller@ffb2 {
@@ -165,6 +167,7 @@
#dma-cells = <1>;
clocks = < ACLK_DMAC1>;
clock-names = "apb_pclk";
+ arm,pl330-broken-no-flushp;
};
};
Other than the small nits above, this looks fine to me.
Reviewed-by: Douglas Anderson
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
