Re: [PATCH 3/3] md/raid5: per hash value and exclusive wait_for_stripe
On Thu, May 14, 2015 at 03:45:11PM +1000, NeilBrown wrote:
> On Wed, 29 Apr 2015 10:48:55 +0800 Yuanhan Liu
> wrote:
>
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index 64d5bea..697d77a 100644
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -344,7 +344,8 @@ static void release_inactive_stripe_list(struct r5conf
> > *conf,
> > int hash)
> > {
> > int size;
> > - bool do_wakeup = false;
> > + unsigned long do_wakeup = 0;
> > + int i = 0;
> > unsigned long flags;
> >
> > if (hash == NR_STRIPE_HASH_LOCKS) {
> > @@ -365,15 +366,19 @@ static void release_inactive_stripe_list(struct
> > r5conf *conf,
> > !list_empty(list))
> > atomic_dec(>empty_inactive_list_nr);
> > list_splice_tail_init(list, conf->inactive_list + hash);
> > - do_wakeup = true;
> > + do_wakeup |= 1 << (size - 1);
> > spin_unlock_irqrestore(conf->hash_locks + hash, flags);
> > }
> > size--;
> > hash--;
> > }
> >
> > + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++) {
> > + if (do_wakeup & (1 << i))
> > + wake_up(>wait_for_stripe[i]);
> > + }
> > +
>
> hi,
> I've been doing some testing and got a lock-up in resize_stripes, waiting
> on wait_for_stripe[].
>
> Looking at the above code, I think
> do_wakeup |= 1 << (size - 1);
> should be
> do_wakeup |= 1 << hash;
>
> do you agree? Or am I missing something?
Right. Sorry for the careless mistake.
--yliu
--
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 v3 4/5] phy: add Broadcom SATA3 PHY driver for Broadcom STB SoCs
Hi,
On Thursday 14 May 2015 12:19 AM, Brian Norris wrote:
On Wed, May 13, 2015 at 04:37:05PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 13 May 2015 04:58 AM, Brian Norris wrote:
Supports up to two ports which can each be powered on/off and configured
independently.
Signed-off-by: Brian Norris
couple of minor comments below
---
v3: no change
v2:
- stop sharing SATA_TOP_CTRL registers with SATA driver
- kill custom xlate function
drivers/phy/Kconfig| 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-brcmstb-sata.c | 216 +
3 files changed, 226 insertions(+)
create mode 100644 drivers/phy/phy-brcmstb-sata.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a53bd5b52df9..36788b6f0220 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -309,4 +309,13 @@ config PHY_QCOM_UFS
help
Support for UFS PHY on QCOM chipsets.
+config PHY_BRCMSTB_SATA
+ tristate "Broadcom STB SATA PHY driver"
+ depends on ARCH_BRCMSTB
+ depends on OF
+ select GENERIC_PHY
+ help
+ Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
+ Likely useful only with CONFIG_SATA_BRCMSTB enabled.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f12625178780..c61f3fdd191e 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -40,3 +40,4 @@ obj-$(CONFIG_PHY_STIH41X_USB) += phy-stih41x-usb.o
obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs.o
obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-20nm.o
obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcmstb-sata.c
new file mode 100644
index ..8387c8cbea8c
--- /dev/null
+++ b/drivers/phy/phy-brcmstb-sata.c
@@ -0,0 +1,216 @@
+/*
+ * Broadcom SATA3 AHCI Controller PHY Driver
+ *
+ * Copyright © 2009-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, 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
+#include
+
+#define SATA_MDIO_BANK_OFFSET 0x23c
+#define SATA_MDIO_REG_OFFSET(ofs) ((ofs) * 4)
+#define SATA_MDIO_REG_SPACE_SIZE 0x1000
+#define SATA_MDIO_REG_LENGTH 0x1f00
+
+#define MAX_PORTS 2
+
+/* Register offset between PHYs in PCB space */
+#define SATA_MDIO_REG_SPACE_SIZE 0x1000
+
+struct brcm_sata_port {
+ int portnum;
+ struct phy *phy;
+ struct brcm_sata_phy *phy_priv;
+ bool ssc_en;
+};
+
+struct brcm_sata_phy {
+ struct device *dev;
+ void __iomem *phy_base;
+
+ struct brcm_sata_port phys[MAX_PORTS];
+};
+
+enum sata_mdio_phy_regs_28nm {
Why should these defines be in enum?
Why not? They're logically grouped this way, and IMO, they look nicer.
You can see drivers/ata/ahci.h for a similar example.
fair enough.
+ PLL_REG_BANK_0 = 0x50,
+ PLL_REG_BANK_0_PLLCONTROL_0 = 0x81,
+
+ TXPMD_REG_BANK = 0x1a0,
+ TXPMD_CONTROL1 = 0x81,
+ TXPMD_CONTROL1_TX_SSC_EN_FRC= BIT(0),
+ TXPMD_CONTROL1_TX_SSC_EN_FRC_VAL= BIT(1),
+ TXPMD_TX_FREQ_CTRL_CONTROL1 = 0x82,
+ TXPMD_TX_FREQ_CTRL_CONTROL2 = 0x83,
+ TXPMD_TX_FREQ_CTRL_CONTROL2_FMIN_MASK = 0x3ff,
+ TXPMD_TX_FREQ_CTRL_CONTROL3 = 0x84,
+ TXPMD_TX_FREQ_CTRL_CONTROL3_FMAX_MASK = 0x3ff,
+};
+
+static inline void __iomem *brcm_sata_phy_base(struct brcm_sata_port *port)
+{
+ struct brcm_sata_phy *priv = port->phy_priv;
+
+ return priv->phy_base + (port->portnum * SATA_MDIO_REG_SPACE_SIZE);
+}
+
+static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, u32 ofs,
+ u32 msk, u32 value)
+{
+ u32 tmp;
+
+ writel(bank, addr + SATA_MDIO_BANK_OFFSET);
+ tmp = readl(addr + SATA_MDIO_REG_OFFSET(ofs));
+ tmp = (tmp & msk) | value;
+ writel(tmp, addr + SATA_MDIO_REG_OFFSET(ofs));
+}
+
+/* These defaults were characterized by H/W group */
+#define FMIN_VAL_DEFAULT 0x3df
+#define FMAX_VAL_DEFAULT 0x3df
+#define FMAX_VAL_SSC 0x83
+
+static void cfg_ssc_28nm(struct brcm_sata_port *port)
Re: [PATCH 3/3] md/raid5: per hash value and exclusive wait_for_stripe
On Wed, 29 Apr 2015 10:48:55 +0800 Yuanhan Liu
wrote:
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 64d5bea..697d77a 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -344,7 +344,8 @@ static void release_inactive_stripe_list(struct r5conf
> *conf,
>int hash)
> {
> int size;
> - bool do_wakeup = false;
> + unsigned long do_wakeup = 0;
> + int i = 0;
> unsigned long flags;
>
> if (hash == NR_STRIPE_HASH_LOCKS) {
> @@ -365,15 +366,19 @@ static void release_inactive_stripe_list(struct r5conf
> *conf,
> !list_empty(list))
> atomic_dec(>empty_inactive_list_nr);
> list_splice_tail_init(list, conf->inactive_list + hash);
> - do_wakeup = true;
> + do_wakeup |= 1 << (size - 1);
> spin_unlock_irqrestore(conf->hash_locks + hash, flags);
> }
> size--;
> hash--;
> }
>
> + for (i = 0; i < NR_STRIPE_HASH_LOCKS; i++) {
> + if (do_wakeup & (1 << i))
> + wake_up(>wait_for_stripe[i]);
> + }
> +
hi,
I've been doing some testing and got a lock-up in resize_stripes, waiting
on wait_for_stripe[].
Looking at the above code, I think
do_wakeup |= 1 << (size - 1);
should be
do_wakeup |= 1 << hash;
do you agree? Or am I missing something?
Thanks,
NeilBrown
pgpDXRFTl5uv3.pgp
Description: OpenPGP digital signature
[PATCH 1/1] Staging: xgifb: vb_setmode: Fixed spelling error
From: Colin Cronin Fixed spelling error in comment. Signed-off-by: Colin Cronin --- drivers/staging/xgifb/vb_setmode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/xgifb/vb_setmode.c b/drivers/staging/xgifb/vb_setmode.c index a47395e..3f7c10e 100644 --- a/drivers/staging/xgifb/vb_setmode.c +++ b/drivers/staging/xgifb/vb_setmode.c @@ -940,7 +940,7 @@ static void XGI_SetCRT1FIFO(struct xgi_hw_device_info *HwDeviceExtension, data = xgifb_reg_get(pVBInfo->P3c4, 0x3D); data &= 0xfe; - xgifb_reg_set(pVBInfo->P3c4, 0x3D, data); /* diable auto-threshold */ + xgifb_reg_set(pVBInfo->P3c4, 0x3D, data); /* disable auto-threshold */ xgifb_reg_set(pVBInfo->P3c4, 0x08, 0x34); data = xgifb_reg_get(pVBInfo->P3c4, 0x09); -- 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/
[PATCH 2/3] scripts/gdb: Fix PEP8 compliance
Signed-off-by: Thiébaud Weksteen
---
scripts/gdb/linux/dmesg.py | 1 -
scripts/gdb/linux/symbols.py | 9 -
scripts/gdb/linux/tasks.py | 2 ++
scripts/gdb/linux/utils.py | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
index 3c947f0..927d0d2 100644
--- a/scripts/gdb/linux/dmesg.py
+++ b/scripts/gdb/linux/dmesg.py
@@ -12,7 +12,6 @@
#
import gdb
-import string
from linux import utils
diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
index cd5bea9..627750c 100644
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -14,9 +14,8 @@
import gdb
import os
import re
-import string
-from linux import modules, utils
+from linux import modules
if hasattr(gdb, 'Breakpoint'):
@@ -97,7 +96,7 @@ lx-symbols command."""
return ""
attrs = sect_attrs['attrs']
section_name_to_address = {
-attrs[n]['name'].string() : attrs[n]['address']
+attrs[n]['name'].string(): attrs[n]['address']
for n in range(int(sect_attrs['nsections']))}
args = []
for section_name in [".data", ".data..read_mostly", ".rodata", ".bss"]:
@@ -124,7 +123,7 @@ lx-symbols command."""
addr=module_addr,
sections=self._section_arguments(module))
gdb.execute(cmdline, to_string=True)
-if not module_name in self.loaded_modules:
+if module_name not in self.loaded_modules:
self.loaded_modules.append(module_name)
else:
gdb.write("no module object found for '{0}'\n".format(module_name))
@@ -164,7 +163,7 @@ lx-symbols command."""
self.load_all_symbols()
if hasattr(gdb, 'Breakpoint'):
-if not self.breakpoint is None:
+if self.breakpoint is not None:
self.breakpoint.delete()
self.breakpoint = None
self.breakpoint = LoadModuleBreakpoint(
diff --git a/scripts/gdb/linux/tasks.py b/scripts/gdb/linux/tasks.py
index e2037d9..89d38e1 100644
--- a/scripts/gdb/linux/tasks.py
+++ b/scripts/gdb/linux/tasks.py
@@ -18,6 +18,7 @@ from linux import utils
task_type = utils.CachedType("struct task_struct")
+
def task_lists():
global task_type
task_ptr_type = task_type.get_type().pointer()
@@ -38,6 +39,7 @@ def task_lists():
if t == init_task:
return
+
def get_task_by_pid(pid):
for task in task_lists():
if int(task['pid']) == pid:
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index d7ff3a3..0893b32 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -151,6 +151,6 @@ def get_gdbserver_type():
gdbserver_type = GDBSERVER_QEMU
elif probe_kgdb():
gdbserver_type = GDBSERVER_KGDB
-if not gdbserver_type is None and hasattr(gdb, 'events'):
+if gdbserver_type is not None and hasattr(gdb, 'events'):
gdb.events.exited.connect(exit_handler)
return gdbserver_type
--
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 1/3] scripts/gdb: Fix typo in exception name
Signed-off-by: Thiébaud Weksteen
---
scripts/gdb/linux/utils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gdb/linux/utils.py b/scripts/gdb/linux/utils.py
index 128c306..d7ff3a3 100644
--- a/scripts/gdb/linux/utils.py
+++ b/scripts/gdb/linux/utils.py
@@ -83,7 +83,7 @@ def get_target_endianness():
elif "big endian" in endian:
target_endianness = BIG_ENDIAN
else:
-raise gdb.GdgError("unknown endianness '{0}'".format(str(endian)))
+raise gdb.GdbError("unknown endianness '{0}'".format(str(endian)))
return target_endianness
--
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 0/3] scripts/gdb: clean up
Set of patches to clean up scripts/gdb Thiébaud Weksteen (3): scripts/gdb: Fix typo in exception name scripts/gdb: Fix PEP8 compliance scripts/gdb: Remove useless global instruction scripts/gdb/linux/dmesg.py | 1 - scripts/gdb/linux/symbols.py | 9 - scripts/gdb/linux/tasks.py | 4 ++-- scripts/gdb/linux/utils.py | 4 ++-- 4 files changed, 8 insertions(+), 10 deletions(-) -- 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/
Re: [PATCH 2/6] clk: sunxi: Add H3 clocks support
On Tue, May 12, 2015 at 10:44 PM, Maxime Ripard
wrote:
> Hi,
>
> On Sun, May 10, 2015 at 12:54:50PM +0200, Jens Kuske wrote:
>> On 09/05/15 13:27, Maxime Ripard wrote:
>> > On Wed, May 06, 2015 at 11:31:29AM +0200, Jens Kuske wrote:
>> >> The H3 clock control unit is similar to the those of other sun8i family
>> >> members like the A23.
>> >>
>> >> The AHB1 gates got split up into AHB1 and AHB2, with AHB2 clock source
>> >> being muxable between AHB1 and PLL6/2, but still sharing gate registers.
>> >> The documentation isn't totally clear about which devices belong to
>> >> AHB2 now, especially USB EHIC/OHIC, so it is mostly based on Allwinner
>> >> kernel source code.
>> >>
>> >> Signed-off-by: Jens Kuske
>> >> ---
>> >> Documentation/devicetree/bindings/clock/sunxi.txt | 7
>> >> drivers/clk/sunxi/clk-sunxi.c | 46
>> >> ++-
>> >> 2 files changed, 52 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
>> >> b/Documentation/devicetree/bindings/clock/sunxi.txt
>> >> index 4fa11af..4eeb893 100644
>> >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> >> @@ -14,6 +14,8 @@ Required properties:
>> >>"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
>> >>"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
>> >>"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
>> >> + "allwinner,sun8i-h3-pll6-clk" - for the PLL6 clock on H3
>> >> + "allwinner,sun8i-h3-pll8-clk" - for the PLL8 clock on H3
>> >>"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
>> >>"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
>> >>"allwinner,sun4i-a10-axi-clk" - for the AXI clock
>> >> @@ -28,8 +30,11 @@ Required properties:
>> >>"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
>> >>"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
>> >>"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
>> >> + "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
>> >>"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
>> >>"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
>> >> + "allwinner,sun8i-h3-ahb1-gates-clk" - for the AHB1 gates on H3
>> >> + "allwinner,sun8i-h3-ahb2-gates-clk" - for the AHB2 gates on H3
>> >>"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
>> >>"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
>> >>"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
>> >> @@ -52,8 +57,10 @@ Required properties:
>> >>"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
>> >>"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
>> >>"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
>> >> + "allwinner,sun8i-h3-apb1-gates-clk" - for the APB1 gates on H3
>> >>"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
>> >>"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>> >> + "allwinner,sun8i-h3-apb2-gates-clk" - for the APB2 gates on H3
>> >>"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
>> >>"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
>> >>"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
>> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> >> index 7e1e2bd..152a1f7 100644
>> >> --- a/drivers/clk/sunxi/clk-sunxi.c
>> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> >> @@ -727,6 +727,12 @@ static const struct factors_data sun5i_a13_ahb_data
>> >> __initconst = {
>> >>.getter = sun5i_a13_get_ahb_factors,
>> >> };
>> >>
>> >> +static const struct factors_data sun8i_h3_pll8_data __initconst = {
>> >> + .enable = 31,
>> >> + .table = _a31_pll6_config,
>> >> + .getter = sun6i_a31_get_pll6_factors,
>> >> +};
>> >
>> > This looks like it's just another instance of the A31 pll6.
>> >
>> > In such a case, we don't need to declare a new driver, just reuse the
>> > same compatible.
>>
>> If I reuse pll6 for pll8 I get errors because of the .name = "pll6x2"
>> field, already existing clock or something like that.
>
> Damn. You're obviously right...
I think I have a solution for this.
The current divs clock setup just passes the factors_data directly to
sunxi_factors_register(). What if it did a copy, read the _correct_
name from the DT (since it knows the index) and put it in the copy.
How does that sound?
> Could you add a TODO comment on top then? just so that we know that we
> need to merge this clock with pll6?
>
>> (And pll8 doesn't even have a x2 version)
>
> Judging by the H3 datasheet, it does.
>
>> >> static const struct factors_data sun4i_apb1_data __initconst = {
>> >>.mux = 24,
>> >>.muxmask = BIT(1) | BIT(0),
>> >> @@ -777,6 +783,10 @@ static const struct mux_data sun6i_a31_ahb1_mux_data
>> >> __initconst = {
>> >>
Re: [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210platform
On 14-05-15, 13:07, Kukjin Kim wrote: > On 05/13/15 23:08, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > Hi Bart, > > > On Friday, April 03, 2015 06:43:43 PM Bartlomiej Zolnierkiewicz wrote: > >> Hi, > >> > >> This patch series removes the use of Exynos4210 specific support > >> from cpufreq-exynos driver and enables the use of cpufreq-dt driver > >> for this platform. > > > > Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant > > patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos > > mach/dts and patch #6 is for cpufreq subsystem)? Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now. > Yes, I totally agreed with this patches for arch side changes and this > approach when Thomas posted. > > > Also what is your > > preferred way to upstream them (patches are not independent so it would > > be best to merge them through one tree, otherwise synchronization of > > git pulls between different subsystem trees will be needed)? > > > I can provide topic branch for arch side changes even it is small. I > think once Viresh and Mike make each topic branch based on -rc or the > smallest changes from each subsystem then I could handle this series or > Viresh or Mike need to handle this series with merging each topic > branches in subsystem. I'm fine either way. > > Viresh and Mike, how do you think about that? For cpufreq subsystem changes, you can take them in your tree. > > I'm still hoping that this patchset will make it into v4.2 as there are > > no known issues with it (except minor coding nit for patch #5)... > > > Sure, why not :-) One thing that looked wrong to me is the email id of Thomas.. I believe he has already left Samsung and his id wouldn't exist anymore. Right ? Then I wouldn't recommend something that doesn't exist to get merged now. Probably use another email id of his. -- 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 5/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210
On 03-04-15, 18:43, Bartlomiej Zolnierkiewicz wrote: > From: Thomas Abraham > > The new CPU clock type allows the use of generic CPUfreq driver. > Switch Exynos4210 to using generic cpufreq driver. > > Changes by Bartlomiej: > - removed non-Exynos4210 support for now > > Cc: Tomasz Figa > Cc: Kukjin Kim > Cc: Javier Martinez Canillas > Signed-off-by: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/mach-exynos/exynos.c | 21 - > 1 file changed, 20 insertions(+), 1 deletion(-) Acked-by: Viresh 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/
Re: linux-next: manual merge of the tip tree with the kselftest-fixes tree
* Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in
> tools/testing/selftests/x86/run_x86_tests.sh between commit
> c1e6e5cb941b ("selftests, x86: Remove useless run_tests rule") from
> the kselftest-fixes tree and commit e22438f8e997 ("x86, selftests:
> Add a test for the "sysret_ss_attrs" bug") from the tip tree.
>
> I fixed it up (I removed the file) and can carry the fix as
> necessary (no action is required).
Thanks Stephen - I've dropped this and the other conflicting commit
from -tip, so both conflicts should go away in tomorrow's integration.
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 6/6] cpufreq: exynos: remove Exynos4210 specific cpufreq driver support
On 03-04-15, 18:43, Bartlomiej Zolnierkiewicz wrote: > From: Thomas Abraham > > Exynos4210 based platforms have switched over to use generic > cpufreq driver for cpufreq functionality. So the Exynos > specific cpufreq support for these platforms can be removed. > > Changes by Bartlomiej: > - dropped Exynos5250 support removal for now > - updated exynos-cpufreq.[c,h] > > Cc: Viresh Kumar > Cc: Javier Martinez Canillas > Signed-off-by: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/cpufreq/Kconfig.arm | 11 -- > drivers/cpufreq/Makefile |1 - > drivers/cpufreq/exynos-cpufreq.c |5 +- > drivers/cpufreq/exynos-cpufreq.h |9 -- > drivers/cpufreq/exynos4210-cpufreq.c | 184 > -- > 5 files changed, 1 insertion(+), 209 deletions(-) > delete mode 100644 drivers/cpufreq/exynos4210-cpufreq.c Acked-by: Viresh 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/
Re: [PATCH kernel v10 26/34] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
On Tue, May 12, 2015 at 01:39:15AM +1000, Alexey Kardashevskiy wrote:
>This is a part of moving DMA window programming to an iommu_ops
>callback. pnv_pci_ioda2_set_window() takes an iommu_table_group as
>a first parameter (not pnv_ioda_pe) as it is going to be used as
>a callback for VFIO DDW code.
>
>This adds pnv_pci_ioda2_tvt_invalidate() to invalidate TVT as it is
>a good thing to do. It does not have immediate effect now as the table
>is never recreated after reboot but it will in the following patches.
>
>This should cause no behavioural change.
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
>---
>Changes:
>v9:
>* initialize pe->table_group.tables[0] at the very end when
>tbl is fully initialized
>* moved pnv_pci_ioda2_tvt_invalidate() from earlier patch
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 47 +--
> 1 file changed, 38 insertions(+), 9 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 7d98d83..85f80b2 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -1983,6 +1983,43 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
>*phb,
> }
> }
>
>+static long pnv_pci_ioda2_set_window(struct iommu_table_group *table_group,
>+ int num, struct iommu_table *tbl)
>+{
>+ struct pnv_ioda_pe *pe = container_of(table_group, struct pnv_ioda_pe,
>+ table_group);
>+ struct pnv_phb *phb = pe->phb;
>+ int64_t rc;
>+ const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
>+ const __u64 win_size = tbl->it_size << tbl->it_page_shift;
s/__u64/u64 maybe :-)
>+
>+ pe_info(pe, "Setting up window %llx..%llx pg=%x\n",
>+ start_addr, start_addr + win_size - 1,
>+ 1UL << tbl->it_page_shift);
>+
>+ /*
>+ * Map TCE table through TVT. The TVE index is the PE number
>+ * shifted by 1 bit for 32-bits DMA space.
>+ */
>+ rc = opal_pci_map_pe_dma_window(phb->opal_id,
>+ pe->pe_number,
>+ pe->pe_number << 1,
>+ 1,
>+ __pa(tbl->it_base),
>+ tbl->it_size << 3,
>+ 1ULL << tbl->it_page_shift);
There is one macro for IOMMU page size: IOMMU_PAGE_SIZE(), which is defined in
arch/powerpc/include/asm/iommu.h as below:
#define IOMMU_PAGE_SIZE(tblptr) (ASM_CONST(1) << (tblptr)->it_page_shift)
>+ if (rc) {
>+ pe_err(pe, "Failed to configure TCE table, err %ld\n", rc);
>+ return rc;
>+ }
>+
>+ pnv_pci_link_table_and_group(phb->hose->node, num,
>+ tbl, >table_group);
>+ pnv_pci_ioda2_tvt_invalidate(pe);
>+
>+ return 0;
>+}
>+
> static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
> {
> uint16_t window_id = (pe->pe_number << 1 ) + 1;
>@@ -2127,21 +2164,13 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
>*phb,
> pe->table_group.ops = _pci_ioda2_ops;
> #endif
>
>- /*
>- * Map TCE table through TVT. The TVE index is the PE number
>- * shifted by 1 bit for 32-bits DMA space.
>- */
>- rc = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
>- pe->pe_number << 1, 1, __pa(tbl->it_base),
>- tbl->it_size << 3, 1ULL << tbl->it_page_shift);
>+ rc = pnv_pci_ioda2_set_window(>table_group, 0, tbl);
> if (rc) {
> pe_err(pe, "Failed to configure 32-bit TCE table,"
> " err %ld\n", rc);
> goto fail;
> }
>
>- pnv_pci_ioda2_tvt_invalidate(pe);
>-
> /* OPAL variant of PHB3 invalidated TCEs */
> if (pe->tce_inval_reg)
> tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
Thanks,
Gavin
>--
>2.4.0.rc3.8.gfb3e7d5
>
--
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,1/1] hv_netvsc: use per_cpu stats to calculate TX/RX data
From: six...@microsoft.com
Date: Tue, 12 May 2015 15:50:02 -0700
> From: Simon Xiao
>
> Current code does not lock anything when calculating the TX and RX stats.
> As a result, the RX and TX data reported by ifconfig are not accuracy in a
> system with high network throughput and multiple CPUs (in my test,
> RX/TX = 83% between 2 HyperV VM nodes which have 8 vCPUs and 40G Ethernet).
>
> This patch fixed the above issue by using per_cpu stats.
> netvsc_get_stats64() summarizes TX and RX data by iterating over all CPUs
> to get their respective stats.
>
> Signed-off-by: Simon Xiao
> Reviewed-by: K. Y. Srinivasan
> Reviewed-by: Haiyang Zhang
> ---
> drivers/net/hyperv/hyperv_net.h | 9 +
> drivers/net/hyperv/netvsc_drv.c | 80
> -
> 2 files changed, 81 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index 41071d3..5a92b36 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -611,6 +611,12 @@ struct multi_send_data {
> u32 count; /* counter of batched packets */
> };
>
> +struct netvsc_stats {
> + u64 packets;
> + u64 bytes;
> + struct u64_stats_sync s_sync;
> +};
> +
> /* The context of the netvsc device */
> struct net_device_context {
> /* point back to our device context */
> @@ -618,6 +624,9 @@ struct net_device_context {
> struct delayed_work dwork;
> struct work_struct work;
> u32 msg_enable; /* debug level */
> +
> + struct netvsc_stats __percpu *tx_stats;
> + struct netvsc_stats __percpu *rx_stats;
> };
>
> /* Per netvsc device */
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 5993c7e..310b902 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -391,7 +391,7 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct
> net_device *net)
> u32 skb_length;
> u32 pkt_sz;
> struct hv_page_buffer page_buf[MAX_PAGE_BUFFER_COUNT];
> -
> + struct netvsc_stats *tx_stats = this_cpu_ptr(net_device_ctx->tx_stats);
>
> /* We will atmost need two pages to describe the rndis
>* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
> @@ -580,8 +580,10 @@ do_send:
>
> drop:
> if (ret == 0) {
> - net->stats.tx_bytes += skb_length;
> - net->stats.tx_packets++;
> + u64_stats_update_begin(_stats->s_sync);
> + tx_stats->packets++;
> + tx_stats->bytes += skb_length;
> + u64_stats_update_end(_stats->s_sync);
> } else {
> if (ret != -EAGAIN) {
> dev_kfree_skb_any(skb);
> @@ -644,13 +646,17 @@ int netvsc_recv_callback(struct hv_device *device_obj,
> struct ndis_tcp_ip_checksum_info *csum_info)
> {
> struct net_device *net;
> + struct net_device_context *net_device_ctx;
> struct sk_buff *skb;
> + struct netvsc_stats *rx_stats;
>
> net = ((struct netvsc_device *)hv_get_drvdata(device_obj))->ndev;
> if (!net || net->reg_state != NETREG_REGISTERED) {
> packet->status = NVSP_STAT_FAIL;
> return 0;
> }
> + net_device_ctx = netdev_priv(net);
> + rx_stats = this_cpu_ptr(net_device_ctx->rx_stats);
>
> /* Allocate a skb - TODO direct I/O to pages? */
> skb = netdev_alloc_skb_ip_align(net, packet->total_data_buflen);
> @@ -686,8 +692,10 @@ int netvsc_recv_callback(struct hv_device *device_obj,
> skb_record_rx_queue(skb, packet->channel->
> offermsg.offer.sub_channel_index);
>
> - net->stats.rx_packets++;
> - net->stats.rx_bytes += packet->total_data_buflen;
> + u64_stats_update_begin(_stats->s_sync);
> + rx_stats->packets++;
> + rx_stats->bytes += packet->total_data_buflen;
> + u64_stats_update_end(_stats->s_sync);
>
> /*
>* Pass the skb back up. Network stack will deallocate the skb when it
> @@ -753,6 +761,46 @@ static int netvsc_change_mtu(struct net_device *ndev,
> int mtu)
> return 0;
> }
>
> +static struct rtnl_link_stats64 *netvsc_get_stats64(struct net_device *net,
> + struct rtnl_link_stats64 *t)
> +{
> + struct net_device_context *ndev_ctx = netdev_priv(net);
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + struct netvsc_stats *tx_stats = per_cpu_ptr(ndev_ctx->tx_stats,
> + cpu);
> + struct netvsc_stats *rx_stats = per_cpu_ptr(ndev_ctx->rx_stats,
> + cpu);
> + u64 tx_packets, tx_bytes, rx_packets, rx_bytes;
> + unsigned int start;
> +
> + do {
> + start = u64_stats_fetch_begin_irq(_stats->s_sync);
> +
Re: [RFC v2 5/7] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core
On 2015/5/14 12:05, Hanjun Guo wrote:
> On 2015年05月14日 09:09, Jiang Liu wrote:
>> On 2015/5/13 21:25, Hanjun Guo wrote:
>>> On 2015年05月13日 20:24, Jiang Liu wrote:
On 2015/5/13 17:29, Hanjun Guo wrote:
> Hi Jiang,
>
> On 2015年05月05日 10:46, Jiang Liu wrote:
>
> struct pci_controller {
> struct acpi_device *companion;
> void *iommu;
> int segment;
> int node; /* nearest node with memory or
> NUMA_NO_NODE for global allocation */
>
> void *platform_data;
> };
>
> except void *platform_data;
>
> On ARM64, the structure is almost the same, so how about
> introduce
>
> struct pci_controller {
> struct acpi_device *companion; /* ACPI companion device */
> void*iommu; /* IOMMU private data */
> int segment;/* PCI domain */
> int node; /* NUMA node */
> #ifdef CONFIG_IA64
> void *platform_data;
> #endif
> };
>
> in this file, then can be used for all architectures?
Current mode is that architecture defines its own version of
struct pci_controller. It would be better to keep this pattern.
>>>
>>> OK, thanks for the clarify :) So how about add my basic
>>> PCI support patch for ARM64 on top of you patch set to fix
>>> this problem?
>>
>> Sure, please send me the patches and I will send out v3 to
>> cover your review comments.
>
> OK, I need to rework my patches because my patch set is dependent
> on top of another MMCFG refactor patch set [1], so I need to remove
> MMCONFIG first then will speed up the upstream process of your patch
> set, will send you the patches soon.
Hi Hanjun,
I will send out v3 soon , so you could rebase onto v3.
There are changes which will affect your rebase.
Thanks!
Gerry
>
> [1]: https://lkml.org/lkml/2015/4/17/29
>
> Thanks
> Hanjun
--
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 4/4] netconsole: implement extended console support
From: Tejun Heo Date: Wed, 13 May 2015 11:46:20 -0400 > Hello, David. > > On Tue, May 12, 2015 at 07:23:22PM -0400, David Miller wrote: >> Second question, is there an upper bound on this header size? >> Because if there is, it seems to me that there is no reason why we >> can't just avoid the fragmentation support altogether. >> >> The current code limits to 1000 bytes, and that limit seems arbitrary. >> Obviously this code is meant to work on interfaces with an ethernet >> MTU or larger. So you could bump the limit enough to accomodate the >> new header size, yet still be within the real constraints. >> >> What do you think? > > Yeah, if we can bump the tx size enough to accomodate all messages, > it'd be great. It can get fairly large tho. The absolute maximum > right now is 8k. While regular prink message bodies are capped > slightly below 1k, the dictionary printed through vprintk_emit() > doesn't have such length limit. Another factor is that non-printables > are escaped using \xXX and vprintk_emit() is supposed to be useable > with transmitting binary data (like low level device error > descriptors) although I'm not sure anybody is doing that yet. Yeah, 8K is too much to handle, oh well. Ok I'm fine with this series from my end, and you can merge this wherever the extended console support bits go. Signed-off-by: David S. Miller Thanks. -- 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 v3 2/2] ARM: EXYNOS: Use of_machine_is_compatible instead ofsoc_is_exynos4
2015-05-14 11:41 GMT+09:00 Kukjin Kim :
> On 05/11/15 10:27, Krzysztof Kozlowski wrote:
>> of_machine_is_compatible() seems to be preferred over soc_is_exynos4().
>>
>> Signed-off-by: Krzysztof Kozlowski
>>
>> ---
>> Changes since v2:
>> 1. New patch, requested by Kukjin Kim.
>> ---
>> arch/arm/mach-exynos/exynos.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index c3bfbba3006d..5917a30eee33 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -179,7 +179,7 @@ static void __init exynos_init_io(void)
>> */
>> void exynos_set_delayed_reset_assertion(bool enable)
>> {
>> - if (soc_is_exynos4()) {
>> + if (of_machine_is_compatible("samsung,exynos4")) {
>> unsigned int tmp, core_id;
>>
>> for (core_id = 0; core_id < num_possible_cpus(); core_id++) {
>
> Maybe we need to change the compatible for exynos4415.dtsi? because no
> exynos4 in the compatible...Applied, anyway.
It could be quite significant change and each path checking for
compatibility with exynos4 should be tested. There is no board DTS for
Exynos4415 so I am not quite convinced that we should care about it.
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/
linux-next: manual merge of the tip tree with the kselftest-fixes tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
tools/testing/selftests/x86/run_x86_tests.sh between commit
c1e6e5cb941b ("selftests, x86: Remove useless run_tests rule") from the
kselftest-fixes tree and commit e22438f8e997 ("x86, selftests: Add a
test for the "sysret_ss_attrs" bug") from the tip tree.
I fixed it up (I removed the file) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpVXSPnEIRIB.pgp
Description: OpenPGP digital signature
Re: [PATCH kernel v10 25/34] powerpc/powernv/ioda2: Introduce helpers to allocate TCE pages
On Tue, May 12, 2015 at 01:39:14AM +1000, Alexey Kardashevskiy wrote:
>This is a part of moving TCE table allocation into an iommu_ops
>callback to support multiple IOMMU groups per one VFIO container.
>
>This moves the code which allocates the actual TCE tables to helpers:
>pnv_pci_ioda2_table_alloc_pages() and pnv_pci_ioda2_table_free_pages().
>These do not allocate/free the iommu_table struct.
>
>This enforces window size to be a power of two.
>
>This should cause no behavioural change.
>
>Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
>---
>Changes:
>v10:
>* removed @table_group parameter from pnv_pci_create_table as it was not used
>* removed *tce_table_allocated from pnv_alloc_tce_table_pages()
>* pnv_pci_create_table/pnv_pci_free_table renamed to
>pnv_pci_ioda2_table_alloc_pages/pnv_pci_ioda2_table_free_pages and moved
>back to pci-ioda.c as these only allocate pages for IODA2 and there is
>no chance they will be reused for IODA1/P5IOC2
>* shortened subject line
>
>v9:
>* moved helpers to the common powernv pci.c file from pci-ioda.c
>* moved bits from pnv_pci_create_table() to pnv_alloc_tce_table_pages()
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 82 +++
> 1 file changed, 62 insertions(+), 20 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 9b80b74..7d98d83 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -49,6 +49,8 @@
> /* 256M DMA window, 4K TCE pages, 8 bytes TCE */
> #define TCE32_TABLE_SIZE ((0x1000 / 0x1000) * 8)
>
>+static void pnv_pci_ioda2_table_free_pages(struct iommu_table *tbl);
>+
> static void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
> const char *fmt, ...)
> {
>@@ -1313,8 +1315,8 @@ static void pnv_pci_ioda2_release_dma_pe(struct pci_dev
>*dev, struct pnv_ioda_pe
> iommu_group_put(pe->table_group.group);
> BUG_ON(pe->table_group.group);
> }
>+ pnv_pci_ioda2_table_free_pages(tbl);
> iommu_free_table(tbl, of_node_full_name(dev->dev.of_node));
>- free_pages(addr, get_order(TCE32_TABLE_SIZE));
> }
>
> static void pnv_ioda_release_vf_PE(struct pci_dev *pdev, u16 num_vfs)
>@@ -2034,13 +2036,62 @@ static struct iommu_table_group_ops pnv_pci_ioda2_ops
>= {
> };
> #endif
>
>-static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
>- struct pnv_ioda_pe *pe)
>+static __be64 *pnv_pci_ioda2_table_do_alloc_pages(int nid, unsigned shift)
> {
> struct page *tce_mem = NULL;
>+ __be64 *addr;
>+ unsigned order = max_t(unsigned, shift, PAGE_SHIFT) - PAGE_SHIFT;
>+
>+ tce_mem = alloc_pages_node(nid, GFP_KERNEL, order);
>+ if (!tce_mem) {
>+ pr_err("Failed to allocate a TCE memory, order=%d\n", order);
>+ return NULL;
>+ }
>+ addr = page_address(tce_mem);
>+ memset(addr, 0, 1UL << (order + PAGE_SHIFT));
>+
>+ return addr;
>+}
>+
>+static long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
>+ __u32 page_shift, __u64 window_size, struct iommu_table *tbl)
>+{
It seems that pci-ioda.c has the convention to have u32/u64, instead of
__u32/__u64.
Thanks,
Gavin
> void *addr;
>+ const unsigned window_shift = ilog2(window_size);
>+ unsigned entries_shift = window_shift - page_shift;
>+ unsigned table_shift = max_t(unsigned, entries_shift + 3, PAGE_SHIFT);
>+ const unsigned long tce_table_size = 1UL << table_shift;
>+
>+ if ((window_size > memory_hotplug_max()) || !is_power_of_2(window_size))
>+ return -EINVAL;
>+
>+ /* Allocate TCE table */
>+ addr = pnv_pci_ioda2_table_do_alloc_pages(nid, table_shift);
>+ if (!addr)
>+ return -ENOMEM;
>+
>+ /* Setup linux iommu table */
>+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, bus_offset,
>+ page_shift);
>+
>+ pr_devel("Created TCE table: ws=%08llx ts=%lx @%08llx\n",
>+ window_size, tce_table_size, bus_offset);
>+
>+ return 0;
>+}
>+
>+static void pnv_pci_ioda2_table_free_pages(struct iommu_table *tbl)
>+{
>+ if (!tbl->it_size)
>+ return;
>+
>+ free_pages(tbl->it_base, get_order(tbl->it_size << 3));
>+}
>+
>+static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
>+ struct pnv_ioda_pe *pe)
>+{
> struct iommu_table *tbl;
>- unsigned int tce_table_size, end;
> int64_t rc;
>
> /* We shouldn't already have a 32-bit DMA associated */
>@@ -2059,24 +2110,16 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
>*phb,
>
> /* The PE will reserve all possible 32-bits space */
> pe->tce32_seg = 0;
>- end = (1 << ilog2(phb->ioda.m32_pci_base));
>- tce_table_size = (end / 0x1000) * 8;
> pe_info(pe,
linux-next: manual merge of the tip tree with the kselftest-fixes tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
tools/testing/selftests/x86/Makefile between commit e9886ace222e
("selftests, x86: Rework x86 target architecture detection") from the
kselftest-fixes tree and commit e22438f8e997 ("x86, selftests: Add a
test for the "sysret_ss_attrs" bug") from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc tools/testing/selftests/x86/Makefile
index 5bdb781163d1,9309097f58e8..
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@@ -1,10 -1,6 +1,10 @@@
-.PHONY: all all_32 all_64 check_build32 clean run_tests
+all:
+
+include ../lib.mk
+
+.PHONY: all all_32 all_64 warn_32bit_failure clean
- TARGETS_C_BOTHBITS := sigreturn single_step_syscall
+ TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
@@@ -38,20 -33,19 +38,23 @@@ $(TARGETS_C_BOTHBITS:%=%_32): %_32: %.
$(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c
$(CC) -m64 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
-check_build32:
- @if ! $(CC) -m32 -o /dev/null trivial_32bit_program.c; then \
-echo "Warning: you seem to have a broken 32-bit build" 2>&1; \
-echo "environment. If you are using a Debian-like"; \
-echo " distribution, try:"; \
-echo ""; \
-echo " apt-get install gcc-multilib libc6-i386 libc6-dev-i386"; \
-echo ""; \
-echo "If you are using a Fedora-like distribution, try:"; \
-echo ""; \
-echo " yum install glibc-devel.*i686"; \
-exit 1; \
- fi
+# x86_64 users should be encouraged to install 32-bit libraries
+ifeq ($(CAN_BUILD_I386)$(CAN_BUILD_X86_64),01)
+all: warn_32bit_failure
+
+warn_32bit_failure:
+ @echo "Warning: you seem to have a broken 32-bit build" 2>&1; \
+ echo "environment. This will reduce test coverage of 64-bit" 2>&1; \
+ echo "kernels. If you are using a Debian-like distribution," 2>&1; \
+ echo "try:"; 2>&1; \
+ echo "";\
+ echo " apt-get install gcc-multilib libc6-i386 libc6-dev-i386"; \
+ echo "";\
+ echo "If you are using a Fedora-like distribution, try:"; \
+ echo "";\
+ echo " yum install glibc-devel.*i686"; \
+ exit 0;
+endif
+
+ # Some tests have additional dependencies.
+ sysret_ss_attrs_64: thunks.S
pgpN83sVMNu68.pgp
Description: OpenPGP digital signature
Re: [PATCH kernel v10 24/34] powerpc/powernv/ioda2: Rework iommu_table creation
On Tue, May 12, 2015 at 01:39:13AM +1000, Alexey Kardashevskiy wrote:
>This moves iommu_table creation to the beginning to make following changes
>easier to review. This starts using table parameters from the iommu_table
>struct.
>
>This should cause no behavioural change.
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v9:
>* updated commit log and did minor cleanup
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index e3c784d..9b80b74 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -2074,13 +2074,23 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
>*phb,
> addr = page_address(tce_mem);
> memset(addr, 0, tce_table_size);
>
>+ /* Setup linux iommu table */
>+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
>+ IOMMU_PAGE_SHIFT_4K);
>+
>+ tbl->it_ops = _ioda2_iommu_ops;
>+ iommu_init_table(tbl, phb->hose->node);
>+#ifdef CONFIG_IOMMU_API
>+ pe->table_group.ops = _pci_ioda2_ops;
>+#endif
>+
> /*
>* Map TCE table through TVT. The TVE index is the PE number
>* shifted by 1 bit for 32-bits DMA space.
>*/
> rc = opal_pci_map_pe_dma_window(phb->opal_id, pe->pe_number,
>- pe->pe_number << 1, 1, __pa(addr),
>- tce_table_size, 0x1000);
>+ pe->pe_number << 1, 1, __pa(tbl->it_base),
>+ tbl->it_size << 3, 1ULL << tbl->it_page_shift);
> if (rc) {
> pe_err(pe, "Failed to configure 32-bit TCE table,"
> " err %ld\n", rc);
>@@ -2089,20 +2099,10 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
>*phb,
>
> pnv_pci_ioda2_tvt_invalidate(pe);
>
>- /* Setup linux iommu table */
>- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
>- IOMMU_PAGE_SHIFT_4K);
>-
> /* OPAL variant of PHB3 invalidated TCEs */
> if (pe->tce_inval_reg)
> tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
>
>- tbl->it_ops = _ioda2_iommu_ops;
>- iommu_init_table(tbl, phb->hose->node);
>-#ifdef CONFIG_IOMMU_API
>- pe->table_group.ops = _pci_ioda2_ops;
>-#endif
>-
> if (pe->flags & PNV_IODA_PE_DEV) {
> /*
>* Setting table base here only for carrying iommu_group
>--
>2.4.0.rc3.8.gfb3e7d5
>
--
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] cpufreq: use generic cpufreq drivers for Exynos4210platform
On 05/13/15 23:08, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
Hi Bart,
> On Friday, April 03, 2015 06:43:43 PM Bartlomiej Zolnierkiewicz wrote:
>> Hi,
>>
>> This patch series removes the use of Exynos4210 specific support
>> from cpufreq-exynos driver and enables the use of cpufreq-dt driver
>> for this platform.
>
> Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant
> patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos
> mach/dts and patch #6 is for cpufreq subsystem)?
Yes, I totally agreed with this patches for arch side changes and this
approach when Thomas posted.
> Also what is your
> preferred way to upstream them (patches are not independent so it would
> be best to merge them through one tree, otherwise synchronization of
> git pulls between different subsystem trees will be needed)?
>
I can provide topic branch for arch side changes even it is small. I
think once Viresh and Mike make each topic branch based on -rc or the
smallest changes from each subsystem then I could handle this series or
Viresh or Mike need to handle this series with merging each topic
branches in subsystem. I'm fine either way.
Viresh and Mike, how do you think about that?
> I'm still hoping that this patchset will make it into v4.2 as there are
> no known issues with it (except minor coding nit for patch #5)...
>
Sure, why not :-)
Thanks,
Kukjin
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
>> It consists of a modified "[PATCH v12 0/6] cpufreq: use generic
>> cpufreq drivers for exynos platforms" [1] patch series from Thomas
>> Abraham. As there have not been updates of this patchset since
>> November 2014 I decided to dust it off myself. I updated Thomas'
>> patchset to current kernels, fixed bugs that I noticed and removed
>> non-Exynos4210 support for now (to speed up inclusion in upstream
>> kernel). Since some modifications were not trivial I dropped all
>> Reviewed-by:, Tested-by: and Acked-by: tags. Please review/test
>> this patchset and reply with revelant tag (Thank You!). I also
>> plan to work on Exynos4x12 support next (which was missing in
>> the original patchset) and then on Exynos5250/Exynos5420 one.
>>
>> This patch series has been tested on Exynos4210 based Origen and
>> Trats boards.
>>
>> Depends on:
>> - next-20150330 branch of linux-next kernel tree
>> (mfd tree contains a crucial fix for MAX8997 PMIC support)
>> - "[PATCH] clk: samsung: exynos4: Disable ARMCLK down feature on
>> Exynos4210 SoC" [2]
>>
>> [1] https://www.marc.info/?l=linux-arm-kernel=141657611003803=2
>> [2] https://lkml.org/lkml/2015/3/27/568
>>
>> Changes over Thomas' code:
>> - fixed issue with wrong dividers being setup by Common Clock Framework
>> (by an addition of CLK_RECALC_NEW_RATES clock flag to mout_apll clock,
>> without this change cpufreq-dt driver showed ~10 mA larger energy
>> consumption when compared to cpufreq-exynos one when "performance"
>> cpufreq governor was used on Exynos4210 SoC based Origen board), this
>> was probably meant to be workarounded by use of CLK_GET_RATE_NOCACHE
>> and CLK_DIVIDER_READ_ONLY clock flags in the original patchset (in
>> "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and update
>> clock flags") but using these flags is not sufficient to fix the issue
>> observed
>> - fixed issue with setting lower dividers before the parent clock speed
>> was lowered (the issue resulted in lockup on Exynos4210 SoC based
>> Origen board when "ondemand" cpufreq governor was stress tested)
>> - fixed missing spin_unlock on error in exynos_cpuclk_post_rate_change()
>> problem by moving cfg_data search outside of the spin locked area
>> - removed leftover kfree() in exynos_register_cpu_clock() that could
>> result in dereferencing the NULL pointer on error
>> - moved spin_lock earlier in exynos_cpuclk_pre_rate_change() to cover
>> reading of E4210_SRC_CPU and E4210_DIV_CPU1 registers
>> - added missing "last chance" checks to wait_until_divider_stable() and
>> wait_until_mux_stable() (needed in case that IRQ handling took long
>> time to proceed and resulted in function printing incorrect error
>> message about timeout)
>> - moved E4210_CPU_DIV[0,1]() macros just before their only users,
>> this resulted in moving them from patch #2 to patch #3/6 ("clk:
>> samsung: exynos4: add cpu clock configuration data and instantiate
>> cpu clock")
>> - added my Copyrights to drivers/clk/samsung/clk-cpu.c
>> - updated exynos-cpufreq.[c,h]
>> - removed non-Exynos4210 support for now
>> - dropped "[PATCH v12 6/6] clk: samsung: remove unused clock aliases and
>> update clock flags" altogether for now
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R Institute Poland
>> Samsung Electronics
>>
>>
>> Bartlomiej Zolnierkiewicz (1):
>> clk: add CLK_RECALC_NEW_RATES clock flag for Exynos cpu clock support
>>
>> Thomas Abraham (5):
>>
Re: [RFC v2 5/7] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core
On 2015年05月14日 09:09, Jiang Liu wrote:
On 2015/5/13 21:25, Hanjun Guo wrote:
On 2015年05月13日 20:24, Jiang Liu wrote:
On 2015/5/13 17:29, Hanjun Guo wrote:
Hi Jiang,
On 2015年05月05日 10:46, Jiang Liu wrote:
struct pci_controller {
struct acpi_device *companion;
void *iommu;
int segment;
int node; /* nearest node with memory or
NUMA_NO_NODE for global allocation */
void *platform_data;
};
except void *platform_data;
On ARM64, the structure is almost the same, so how about
introduce
struct pci_controller {
struct acpi_device *companion; /* ACPI companion device */
void*iommu; /* IOMMU private data */
int segment;/* PCI domain */
int node; /* NUMA node */
#ifdef CONFIG_IA64
void *platform_data;
#endif
};
in this file, then can be used for all architectures?
Current mode is that architecture defines its own version of
struct pci_controller. It would be better to keep this pattern.
OK, thanks for the clarify :) So how about add my basic
PCI support patch for ARM64 on top of you patch set to fix
this problem?
Sure, please send me the patches and I will send out v3 to
cover your review comments.
OK, I need to rework my patches because my patch set is dependent
on top of another MMCFG refactor patch set [1], so I need to remove
MMCONFIG first then will speed up the upstream process of your patch
set, will send you the patches soon.
[1]: https://lkml.org/lkml/2015/4/17/29
Thanks
Hanjun
--
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/3] cpuidle: updates related to tick_broadcast_enter() failures
On 05/14/2015 04:29 AM, Kevin Hilman wrote: > "Rafael J. Wysocki" writes: > > [...] > >> Second, quite honestly, I don't see a connection to genpd here. > > The connection with genpd is because the *reason* the timer was > shutdown/stopped is because it shares power with the CPU, which is why > the timer stops when the CPU hits ceratin low power states. IOW, it's > in the same power domain as the CPU. > >> What you seem to be saying is "maybe we can eliminate the need to check the >> return value of tick_broadcast_enter() in the idle loop if we proactively >> disable the TIMER_STOP idle states of a CPU when we start to use that CPU's >> timer as a broadcast one". >> >> So this seems to be about the timekeeping rather than power domains, because >> that's where the broadcast thing is done. So the code setting up the CPU's >> timer for broadcast would pretty much need to pause cpuidle, go through the >> CPU's idle states and disable the TIMER_STOP ones. And do the reverse when >> the >> timer is not going the be used for broadcast any more. > > Or..., modify the timer subystem to use runtime PM on the timer devices, > create a genpd that includes the timer device, and use > pm_genpd_attach_cpuidle() to attach that genpd so that whenever that > timer is runtime PM active, the deeper C-states cannot be hit. I think you are missing a point here. If such a solution were possible, the tick broadcast framework would not have been designed to support deep cpu idle states. One reason we cannot go this way of course, is not all archs may support genpd as was pointed out. But the second reason IMO is that a timer is runtime PM active as long as there is some deferred work, either in the near or far future. The point behind the broadcast framework is let these CPUs go to deeper idle states when the timers are in the "far" future. We can potentially save power by doing so and don't need to keep the entire power domain active just because the timer is supposed to fire 5 minutes from now, which is precisely what happens if we go the genpd way. Hence I don't think we can trivially club timers with genpd unless we have a way to power the timer PM domain down, depending on when it is supposed to fire, in which case we will merely be replicating the cpuidle governor code. Regards Preeti U Murthy > >> So question is whether or not this is actually really more >> straightforward than checking the return value of >> tick_broadcast_enter() in the idle loop after all. > > Unfortunetly this problem doesn't only affect timers. > > Daniel's broader point is that $SUBJECT series only handles this for the > timer, but there's actually a more general problem to solve for *any* > device that shares a power domain with a CPU (e.g. CPU-local > timers, interrupt controllers, performance monitoring units, floating > point units, etc. etc.) > > If we keep adding checks to the idle loop for all those devices, we're > heading for a mess. (In fact, this is exactly what CPUidle drivers in > lots of vendor trees are doing, and it is indeed quite messy, and very > vendor specific.) > > Also, solving this more general problem was the primary motivation for > adding the gnpd _attach_cpuidle() feature in the first place, so why not > use that? > > Longer term, IMO, these dependencies between CPUs and all these "extras" > logic that share a power domain should be modeled by a genpd. If all > those devices are using runtime PM, including the CPUs, and they are > grouped into a genpd, then we we can very easily know at the genpd level > whether or not the CPU could be powered down, and to what level. This > longer-term solution is what I want to discuss at LPC this year in my > "Unifiy idle management of CPUs and IO devices" topic[1]. ( Also FYI, > using a genpd to model a CPU and connected logic is part of the > motivation behind the recent proposals to add support for multiple > states to genpd by Axel Haslam. ) > > Anyways I digress... > > In the short term, while your patches look fine to me, the objection I > have is that it's only a band-aid fix that handles timers, but none of > the other "extras" that might share a power rail with the CPU. So, > until we have the long-term stuff sorted out, the better > short-term solution IMO is the _attach_cpuidle() one above. > > Kevin > > [1] http://wiki.linuxplumbersconf.org/2015:energy-aware_scheduling > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- 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: [RFC PATCH v6] Documentation/arch: Add Documentation/arch-features.txt
On Wed, May 13, 2015 at 03:48:42PM +0200, Ingo Molnar wrote: > > Updated patch attached - I've added a few more features to the last > table, and restructured the explanations, now every feature > description also lists the Kconfig variable that it's tracking, e.g.: > > irq time acct: HAVE_IRQ_TIME_ACCOUNTING Regarding that one specifically, as far as I can see, HAVE_IRQ_TIME_ACCOUNTING is only relevant for tick-based time accounting. If you have CONFIG_VIRT_CPU_ACCOUNTING you get accurate irq time accounting with or without HAVE_IRQ_TIME_ACCOUNTING. So how about making this one: irq time acct: HAVE_IRQ_TIME_ACCOUNTING || VIRT_CPU_ACCOUNTING That would make the "irq time acct" entry for powerpc be "ok". Paul. -- 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 v10 23/34] powerpc/iommu/powernv: Release replaced TCE
On 05/14/2015 01:00 AM, Thomas Huth wrote:
On Tue, 12 May 2015 01:39:12 +1000
Alexey Kardashevskiy wrote:
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such as VFIO. The pool locks are to protect
DMA page allocator rather than entries and since the host kernel does
not control what pages are in use, there is no point in pool locks and
exchange()+put_page(oldtce) is sufficient to avoid possible races.
This adds an exchange() callback to iommu_table_ops which does the same
thing as set() plus it returns replaced TCE and DMA direction so
the caller can release the pages afterwards. The exchange() receives
a physical address unlike set() which receives linear mapping address;
and returns a physical address as the clear() does.
This implements exchange() for P5IOC2/IODA/IODA2. This adds a requirement
for a platform to have exchange() implemented in order to support VFIO.
This replaces iommu_tce_build() and iommu_clear_tce() with
a single iommu_tce_xchg().
This makes sure that TCE permission bits are not set in TCE passed to
IOMMU API as those are to be calculated by platform code from
DMA direction.
This moves SetPageDirty() to the IOMMU code to make it work for both
VFIO ioctl interface in in-kernel TCE acceleration (when it becomes
available later).
Signed-off-by: Alexey Kardashevskiy
[aw: for the vfio related changes]
Acked-by: Alex Williamson
[...]
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 6275164..1287d49 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -962,10 +962,7 @@ EXPORT_SYMBOL_GPL(iommu_tce_clear_param_check);
int iommu_tce_put_param_check(struct iommu_table *tbl,
unsigned long ioba, unsigned long tce)
{
- if (!(tce & (TCE_PCI_WRITE | TCE_PCI_READ)))
- return -EINVAL;
-
- if (tce & ~(IOMMU_PAGE_MASK(tbl) | TCE_PCI_WRITE | TCE_PCI_READ))
+ if (tce & ~IOMMU_PAGE_MASK(tbl))
return -EINVAL;
if (ioba & ~IOMMU_PAGE_MASK(tbl))
@@ -982,44 +979,16 @@ int iommu_tce_put_param_check(struct iommu_table *tbl,
}
EXPORT_SYMBOL_GPL(iommu_tce_put_param_check);
-unsigned long iommu_clear_tce(struct iommu_table *tbl, unsigned long entry)
+long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
+ unsigned long *hpa, enum dma_data_direction *direction)
{
- unsigned long oldtce;
- struct iommu_pool *pool = get_pool(tbl, entry);
+ long ret;
- spin_lock(&(pool->lock));
+ ret = tbl->it_ops->exchange(tbl, entry, hpa, direction);
- oldtce = tbl->it_ops->get(tbl, entry);
- if (oldtce & (TCE_PCI_WRITE | TCE_PCI_READ))
- tbl->it_ops->clear(tbl, entry, 1);
- else
- oldtce = 0;
-
- spin_unlock(&(pool->lock));
-
- return oldtce;
-}
-EXPORT_SYMBOL_GPL(iommu_clear_tce);
-
-/*
- * hwaddr is a kernel virtual address here (0xc... bazillion),
- * tce_build converts it to a physical address.
- */
-int iommu_tce_build(struct iommu_table *tbl, unsigned long entry,
- unsigned long hwaddr, enum dma_data_direction direction)
-{
- int ret = -EBUSY;
- unsigned long oldtce;
- struct iommu_pool *pool = get_pool(tbl, entry);
-
- spin_lock(&(pool->lock));
-
- oldtce = tbl->it_ops->get(tbl, entry);
- /* Add new entry if it is not busy */
- if (!(oldtce & (TCE_PCI_WRITE | TCE_PCI_READ)))
- ret = tbl->it_ops->set(tbl, entry, 1, hwaddr, direction, NULL);
-
- spin_unlock(&(pool->lock));
+ if (!ret && ((*direction == DMA_FROM_DEVICE) ||
+ (*direction == DMA_BIDIRECTIONAL)))
You could drop some of the parentheses:
if (!ret && (*direction == DMA_FROM_DEVICE ||
*direction == DMA_BIDIRECTIONAL))
I really (really) like braces. Is there any kernel code design rule against it?
+ SetPageDirty(pfn_to_page(*hpa >> PAGE_SHIFT));
/* if (unlikely(ret))
pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx
ret=%d\n",
[...]
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 2ead291..0724ec8 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -236,18 +236,11 @@ static void tce_iommu_release(void *iommu_data)
[...]
@@ -405,19 +410,26 @@ static long tce_iommu_ioctl(void *iommu_data,
return -EINVAL;
/* iova is checked by the IOMMU API */
- tce = param.vaddr;
if (param.flags & VFIO_DMA_MAP_FLAG_READ)
- tce |= TCE_PCI_READ;
- if (param.flags & VFIO_DMA_MAP_FLAG_WRITE)
-
Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks
On Wed, May 13, 2015 at 8:30 PM, Al Viro wrote: > > Maybe... I'd like to see the profiles, TBH - especially getxattr() and > access() frequency on various loads. Sure, make(1) and cc(1) really care > about stat() very much, but I wouldn't be surprised if something like > httpd or samba would be hitting getxattr() a lot... So I haven't seen samba profiles in ages, but iirc we have more serious problems than trying to speed up basic filename lookup. At least long long ago, inode semaphore contention was a big deal, largely due to readdir(). And readdir() itself, for that matter - we have no good vfs-level readdir caching, so it all ends up serialized on the inode semaphore, and it all goes all the way into the filesystem to get the readdir data. And at least for ext4, readdir() is slow anyway, because it doesn't use the page cache, it uses that good old buffer cache, because of how ext4 does metadata journaling etc. Having readdir() caching at the VFS layer would likely be a really good thing, but it's hard. It *might* be worth looking at the nfs4 code to see if we could possibly move some of that code into the vfs layer, but the answer is likely "no", or at least "that's incredibly painful". Also, I *think* samba ends up basically doing most of the pathname lookups from its own user-level cache, because of how it needs to avoid symlinks and do the whole crazy case insensitive pathname thing. I have this very dim memory that that's one reason samba ends up being so readdir-intensive. But I might be wrong, it's been many years since I talked to anybody about samba, and I don't run it myself. But yes, that would likely be a very worthy profile target. I suspect we've beaten the "make does lots of stat() calls" horse pretty much to death. Linus -- 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 v10 21/34] powerpc/powernv/ioda2: Add TCE invalidation for all attached groups
On 05/14/2015 12:22 PM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:10AM +1000, Alexey Kardashevskiy wrote:
The iommu_table struct keeps a list of IOMMU groups it is used for.
At the moment there is just a single group attached but further
patches will add TCE table sharing. When sharing is enabled, TCE cache
in each PE needs to be invalidated so does the patch.
This does not change pnv_pci_ioda1_tce_invalidate() as there is no plan
to enable TCE table sharing on PHBs older than IODA2.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v10:
* new to the series
---
arch/powerpc/platforms/powernv/pci-ioda.c | 35 ---
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f972e40..8e4987d 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1763,23 +1764,15 @@ static inline void pnv_pci_ioda2_tvt_invalidate(struct
pnv_ioda_pe *pe)
__raw_writeq(cpu_to_be64(val), pe->tce_inval_reg);
}
-static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
- unsigned long index, unsigned long npages, bool rm)
+static void pnv_pci_ioda2_tce_do_invalidate(unsigned pe_number, bool rm,
+ __be64 __iomem *invalidate, unsigned shift,
+ unsigned long index, unsigned long npages)
{
- struct iommu_table_group_link *tgl = list_first_entry_or_null(
- >it_group_list, struct iommu_table_group_link,
- next);
- struct pnv_ioda_pe *pe = container_of(tgl->table_group,
- struct pnv_ioda_pe, table_group);
unsigned long start, end, inc;
- __be64 __iomem *invalidate = rm ?
- (__be64 __iomem *)pe->tce_inval_reg_phys :
- pe->tce_inval_reg;
- const unsigned shift = tbl->it_page_shift;
/* We'll invalidate DMA address in PE scope */
start = 0x2ull << 60;
- start |= (pe->pe_number & 0xFF);
+ start |= (pe_number & 0xFF);
end = start;
/* Figure out the start, end and step */
@@ -1797,6 +1790,24 @@ static void pnv_pci_ioda2_tce_invalidate(struct
iommu_table *tbl,
}
}
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
+{
+ struct iommu_table_group_link *tgl;
+
+ list_for_each_entry_rcu(tgl, >it_group_list, next) {
+ struct pnv_ioda_pe *pe = container_of(tgl->table_group,
+ struct pnv_ioda_pe, table_group);
+ __be64 __iomem *invalidate = rm ?
+ (__be64 __iomem *)pe->tce_inval_reg_phys :
+ pe->tce_inval_reg;
+
+ pnv_pci_ioda2_tce_do_invalidate(pe->pe_number, rm,
+ invalidate, tbl->it_page_shift,
+ index, npages);
+ }
+}
+
I don't understand this well and need a teaching session: One IOMMU
table can be connected with multiple IOMMU table groups, each of them
can be regarded as being equal to one PE. It means one IOMMU table
can be shared by two PEs. There must be something I missed.
No, this is correct.
Could you give a teaching session with an example about the IOMMU
table sharing? :-)
If you do not share tables and you have multiple IOMMU groups passed to
QEMU, and all actual devices are capable of 64bit DMA, and you have
multiple PHBs in QEMU (each backed with a 64bit TCE table which is updated
once at the boot time and never changes) - all these tables will have
exactly the same content.
Another thing is if you do not want to have multiple PHBs in QEMU, and you
do not have tables sharing, every H_PUT_TCE request would have to update
each group's TCE table, not just one. Not very fast approach.
So it seems a useful thing. If you do not want sharing, just add another
virtual PHB and put vfio-pci devices onto it.
--
Alexey
--
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 v6 0/6] arm64: Add kernel probes (kprobes) support
On Thu, May 14, 2015 at 09:01:03AM +0900, Masami Hiramatsu wrote: > On 2015/05/14 0:41, William Cohen wrote: > > On 05/13/2015 05:22 AM, Masami Hiramatsu wrote: > >> On 2015/05/12 21:48, William Cohen wrote: > > > >>> Hi Dave, > >>> > >>> In some of the previous diagnostic output it looked like things would go > >>> wrong > >>> in the entry.S when the D bit was cleared and the debug interrupts were > >>> unmasksed. I wonder if some of the issue might be due to the starting > >>> the > >>> kprobe for the trampoline, but leaving things in an odd state when another > >>> set of krpobe/kretporbes are hit when the trampoline is running. > >> > >> Hmm, does this mean we have a trouble if a user kprobe handler calls the > >> function which is probed by other kprobe? Or, is this just a problem > >> only for kretprobes? > > > > Hi Masami, > > > > I wrote an example based off of sample/kprobes/kprobes_sample.c to force > > the reentry issue for kprobes (the attached kprobe_rentry_example.c). That > > seemed to run fine. I think the reason that the trampoline handler got > > into trouble is because of the reset_current_kprobe() before the possible > > call to kfree, but I haven't verified it. > > I still doubt about kfree() reentrant call, since kretprobe handler only > calls recycle_rp_inst() which doesn't free the instance but just push it back > to the unused instance list. > > > It seems like that should be at the end of trampoline handler just before > > the return. Other architectures have similar trampoline handlers, > > so I am surprised that the other architectures haven't encountered this > > issue with kretprobes. Maybe this is due to specific of arm64 exception > > handling. > > Ah, indeed the reset_current_kprobe() here seems not good since some > interruption or some other reason, another kprobes can be hit before > returning. > > If kprobes can handle reentered probes correctly, I think your patch > (directly branch from trampoline) looks good to fix this problem. > Actually, arm32 and x86 already has same method. > > It seems that powerpc will have similar issue, does someone checked > that? Ananth? Yes, there is a window where this can happen on powerpc. I haven't however been able to trigger it thus far -- will try with a different sample and test. Thanks for the heads-up. Ananth -- 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 Resend] sparc64: Resolve conflict between sparc v9 and M7 on usage of bit 9 of TTE
From: Khalid Aziz
Date: Mon, 27 Apr 2015 16:19:49 -0600
> @@ -342,9 +356,15 @@ static inline pgprot_t pgprot_noncached(pgprot_t prot)
> " andn%0, %4, %0\n"
> " or %0, %5, %0\n"
> " .previous\n"
> + " .section.sun_m7_2insn_patch, \"ax\"\n"
> + " .word 661b\n"
> + " andn%0, %6, %0\n"
> + " or %0, %5, %0\n"
> + " .previous\n"
> : "=r" (val)
> : "0" (val), "i" (_PAGE_CP_4U | _PAGE_CV_4U), "i" (_PAGE_E_4U),
> - "i" (_PAGE_CP_4V | _PAGE_CV_4V), "i" (_PAGE_E_4V));
> + "i" (_PAGE_CP_4V | _PAGE_CV_4V), "i" (_PAGE_E_4V),
> + "i" (_PAGE_CP_4V));
Please don't change the indentation of the "i" arguments.
> @@ -2446,18 +2471,35 @@ static void __init sun4u_pgprot_init(void)
> static void __init sun4v_pgprot_init(void)
> {
> unsigned long page_none, page_shared, page_copy, page_readonly;
> - unsigned long page_exec_bit;
> + unsigned long page_exec_bit, page_cache4v_flag;
> int i;
...
> + switch (sun4v_chip_type) {
> + case SUN4V_CHIP_SPARC_M7:
> + page_cache4v_flag = _PAGE_CP_4V;
> + break;
> + default:
> + page_cache4v_flag = _PAGE_CACHE_4V;
> + break;
> + }
Ok you've computed what cacheability bits to use in page_cache4v_flag.
> - kern_linear_pte_xor[0] |= (_PAGE_CP_4V | _PAGE_CV_4V |
> + switch (sun4v_chip_type) {
> + case SUN4V_CHIP_SPARC_M7:
> + kern_linear_pte_xor[0] |= (_PAGE_CP_4V | _PAGE_P_4V |
> +_PAGE_W_4V);
> + break;
> + default:
> + kern_linear_pte_xor[0] |= (_PAGE_CP_4V | _PAGE_CV_4V |
> _PAGE_P_4V | _PAGE_W_4V);
> + break;
> + }
>
Then needlessly compute this all over again, just use the
value you have already in page_cache4v_flag.
> @@ -2541,9 +2591,18 @@ static unsigned long kern_large_tte(unsigned long
> paddr)
> _PAGE_CP_4U | _PAGE_CV_4U | _PAGE_P_4U |
> _PAGE_EXEC_4U | _PAGE_L_4U | _PAGE_W_4U);
> if (tlb_type == hypervisor)
> - val = (_PAGE_VALID | _PAGE_SZ4MB_4V |
> -_PAGE_CP_4V | _PAGE_CV_4V | _PAGE_P_4V |
> -_PAGE_EXEC_4V | _PAGE_W_4V);
> + switch (sun4v_chip_type) {
> + case SUN4V_CHIP_SPARC_M7:
> + val = (_PAGE_VALID | _PAGE_SZ4MB_4V |
> +_PAGE_CP_4V | _PAGE_P_4V |
> +_PAGE_EXEC_4V | _PAGE_W_4V);
> + break;
> + default:
> + val = (_PAGE_VALID | _PAGE_SZ4MB_4V |
> +_PAGE_CP_4V | _PAGE_CV_4V | _PAGE_P_4V |
> +_PAGE_EXEC_4V | _PAGE_W_4V);
> + break;
> + }
Although in another function, we seem to compute it here yet again.
Perhaps early on put this into a "static unsigned long
page_cache4v_flag" and just use that everywhere.
If you do it early enough in paging_init() you should be fine.
--
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 v10 20/34] powerpc/powernv/ioda2: Move TCE kill register address to PE
On 05/14/2015 12:10 PM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:09AM +1000, Alexey Kardashevskiy wrote:
At the moment the DMA setup code looks for the "ibm,opal-tce-kill" property
which contains the TCE kill register address. Writes to this register
invalidates TCE cache on IODA/IODA2 hub.
This moves the register address from iommu_table to pnv_ioda_pe as:
1) When we get 2 tables per PE, this register will be used for both tables;
2) When we get TCE tables sharing, we will need to invalidate every
IOMMU group (i.e. PE) which is using this table and each PE has
its own invalidate register.
Actually, it's the virtual address of IO remapped PHB hardware register.
So it would be a property of PHB (struct pnv_phb). As the PE is connecting
with IOMMU table group. The virtual address can be retrieved by the path:
iommu_table -> iommu_table_group -> pnv_ioda_pe -> pnv_phb. However, I
don't insist and you have the best judge on it :-)
Are you suggesting moving pe->tce_inval_reg from pnv_ioda_pe to pnv_phb?
This moves the property reading/remapping code to a helper to reduce
code duplication. Although this change is not required for IODA1, this
changes it as well to reduce code duplication.
This adds a new pnv_pci_ioda2_tvt_invalidate() helper which invalidates
the entire table. It should be called after every call to
opal_pci_map_pe_dma_window(). It was not required before because
there is just a single TCE table and 64bit DMA is handled via bypass
window (which has no table so no chache is used) but this is going
to change with Dynamic DMA windows (DDW).
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
Thanks,
Gavin
---
Changes:
v10:
* fixed error from checkpatch.pl
* removed comment at "ibm,opal-tce-kill" parsing as irrelevant
* s/addr/val/ in pnv_pci_ioda2_tvt_invalidate() as it was not a kernel address
v9:
* new in the series
---
arch/powerpc/platforms/powernv/pci-ioda.c | 64 ++-
arch/powerpc/platforms/powernv/pci.h | 1 +
2 files changed, 39 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 35ab19c8..f972e40 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1680,7 +1680,7 @@ static void pnv_pci_ioda1_tce_invalidate(struct
iommu_table *tbl,
struct pnv_ioda_pe, table_group);
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe->tce_inval_reg_phys :
- (__be64 __iomem *)tbl->it_index;
+ pe->tce_inval_reg;
unsigned long start, end, inc;
const unsigned shift = tbl->it_page_shift;
@@ -1751,6 +1751,18 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
.get = pnv_tce_get,
};
+static inline void pnv_pci_ioda2_tvt_invalidate(struct pnv_ioda_pe *pe)
+{
+ /* 01xb - invalidate TCEs that match the specified PE# */
+ unsigned long val = (0x4ull << 60) | (pe->pe_number & 0xFF);
+
+ if (!pe->tce_inval_reg)
+ return;
+
+ mb(); /* Ensure above stores are visible */
+ __raw_writeq(cpu_to_be64(val), pe->tce_inval_reg);
+}
+
The function name sounds it's to invalidate TVE cache. Actually, it's
invalidting
TCE cache. So I guess the function name pnv_pci_ioda2_tce_invalidate() would be
more accurate.
TVT vs. TVE distinction is not clear for me, sorry :)
There is a function with exactly the same name as you proposed, below in
this mail, it invalidates cache.
May be s/pnv_pci_ioda2_tvt_invalidate/pnv_pci_ioda2_invalidate_entire_cache/ ?
--
Alexey
--
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 v10 19/34] powerpc/iommu: Fix IOMMU ownership control functions
On Tue, May 12, 2015 at 01:39:08AM +1000, Alexey Kardashevskiy wrote:
>This adds missing locks in iommu_take_ownership()/
>iommu_release_ownership().
>
>This marks all pages busy in iommu_table::it_map in order to catch
>errors if there is an attempt to use this table while ownership over it
>is taken.
>
>This only clears TCE content if there is no page marked busy in it_map.
>Clearing must be done outside of the table locks as iommu_clear_tce()
>called from iommu_clear_tces_and_put_pages() does this.
>
>In order to use bitmap_empty(), the existing code clears bit#0 which
>is set even in an empty table if it is bus-mapped at 0 as
>iommu_init_table() reserves page#0 to prevent buggy drivers
>from crashing when allocated page is bus-mapped at zero
>(which is correct). This restores the bit in the case of failure
>to bring the it_map to the state it was in when we called
>iommu_take_ownership().
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v9:
>* iommu_table_take_ownership() did not return @ret (and ignored EBUSY),
>now it does return correct error.
>* updated commit log about setting bit#0 in the case of failure
>
>v5:
>* do not store bit#0 value, it has to be set for zero-based table
>anyway
>* removed test_and_clear_bit
>---
> arch/powerpc/kernel/iommu.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>index 7e54714..6275164 100644
>--- a/arch/powerpc/kernel/iommu.c
>+++ b/arch/powerpc/kernel/iommu.c
>@@ -1032,31 +1032,51 @@ EXPORT_SYMBOL_GPL(iommu_tce_build);
>
> int iommu_take_ownership(struct iommu_table *tbl)
> {
>- unsigned long sz = (tbl->it_size + 7) >> 3;
>+ unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
>+ int ret = 0;
>+
>+ spin_lock_irqsave(>large_pool.lock, flags);
>+ for (i = 0; i < tbl->nr_pools; i++)
>+ spin_lock(>pools[i].lock);
>
> if (tbl->it_offset == 0)
> clear_bit(0, tbl->it_map);
>
> if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
> pr_err("iommu_tce: it_map is not empty");
>- return -EBUSY;
>+ ret = -EBUSY;
>+ /* Restore bit#0 set by iommu_init_table() */
>+ if (tbl->it_offset == 0)
>+ set_bit(0, tbl->it_map);
>+ } else {
>+ memset(tbl->it_map, 0xff, sz);
> }
>
>- memset(tbl->it_map, 0xff, sz);
>+ for (i = 0; i < tbl->nr_pools; i++)
>+ spin_unlock(>pools[i].lock);
>+ spin_unlock_irqrestore(>large_pool.lock, flags);
>
>- return 0;
>+ return ret;
> }
> EXPORT_SYMBOL_GPL(iommu_take_ownership);
>
> void iommu_release_ownership(struct iommu_table *tbl)
> {
>- unsigned long sz = (tbl->it_size + 7) >> 3;
>+ unsigned long flags, i, sz = (tbl->it_size + 7) >> 3;
>+
>+ spin_lock_irqsave(>large_pool.lock, flags);
>+ for (i = 0; i < tbl->nr_pools; i++)
>+ spin_lock(>pools[i].lock);
>
> memset(tbl->it_map, 0, sz);
>
> /* Restore bit#0 set by iommu_init_table() */
> if (tbl->it_offset == 0)
> set_bit(0, tbl->it_map);
>+
>+ for (i = 0; i < tbl->nr_pools; i++)
>+ spin_unlock(>pools[i].lock);
>+ spin_unlock_irqrestore(>large_pool.lock, flags);
> }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
>
>--
>2.4.0.rc3.8.gfb3e7d5
>
--
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 v10 16/34] powerpc/spapr: vfio: Replace iommu_table with iommu_table_group
On 05/14/2015 11:21 AM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:05AM +1000, Alexey Kardashevskiy wrote:
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table is supported.
This defines iommu_table_group struct which stores pointers to
iommu_group and iommu_table(s). This replaces iommu_table with
iommu_table_group where iommu_table was used to identify a group:
- iommu_register_group();
- iommudata of generic iommu_group;
This removes @data from iommu_table as it_table_group provides
same access to pnv_ioda_pe.
For IODA, instead of embedding iommu_table, the new iommu_table_group
keeps pointers to those. The iommu_table structs are allocated
dynamically.
For P5IOC2, both iommu_table_group and iommu_table are embedded into
PE struct. As there is no EEH and SRIOV support for P5IOC2,
iommu_free_table() should not be called on iommu_table struct pointers
so we can keep it embedded in pnv_phb::p5ioc2.
For pSeries, this replaces multiple calls of kzalloc_node() with a new
iommu_pseries_alloc_group() helper and stores the table group struct
pointer into the pci_dn struct. For release, a iommu_table_free_group()
helper is added.
This moves iommu_table struct allocation from SR-IOV code to
the generic DMA initialization code in pnv_pci_ioda_setup_dma_pe and
pnv_pci_ioda2_setup_dma_pe as this is where DMA is actually initialized.
This change is here because those lines had to be changed anyway.
This should cause no behavioural change.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
---
Changes:
v10:
* new to the series, separated from
"powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group"
* iommu_table is not embedded into iommu_table_group but allocated
dynamically in most cases
* iommu_table allocation is moved to a single place for IODA2's
pnv_pci_ioda_setup_dma_pe where it belongs to
* added list of groups into iommu_table; most of the code just looks at
the first item to keep the patch simpler
---
arch/powerpc/include/asm/iommu.h| 17 +++--
arch/powerpc/include/asm/pci-bridge.h | 2 +-
arch/powerpc/kernel/iommu.c | 17 ++---
arch/powerpc/platforms/powernv/pci-ioda.c | 55 +++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 18 +++--
arch/powerpc/platforms/powernv/pci.h| 3 +-
arch/powerpc/platforms/pseries/iommu.c | 107 +++-
drivers/vfio/vfio_iommu_spapr_tce.c | 23 +++---
8 files changed, 152 insertions(+), 90 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index e2a45c3..61bde1a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -92,13 +92,10 @@ struct iommu_table {
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
#ifdef CONFIG_IOMMU_API
- struct iommu_group *it_group;
+ struct iommu_table_group *it_table_group;
#endif
struct iommu_table_ops *it_ops;
void (*set_bypass)(struct iommu_table *tbl, bool enable);
-#ifdef CONFIG_PPC_POWERNV
- void *data;
-#endif
};
/* Pure 2^n version of get_order */
@@ -130,13 +127,21 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
#ifdef CONFIG_IOMMU_API
-extern void iommu_register_group(struct iommu_table *tbl,
+
+#define IOMMU_TABLE_GROUP_MAX_TABLES 1
+
+struct iommu_table_group {
+ struct iommu_group *group;
+ struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
+};
+
+extern void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
extern int __init tce_iommu_bus_notifier_init(void);
#else
-static inline void iommu_register_group(struct iommu_table *tbl,
+static inline void iommu_register_group(struct iommu_table_group *table_group,
int pci_domain_number,
unsigned long pe_num)
{
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 1811c44..e2d7479 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -185,7 +185,7 @@ struct pci_dn {
struct pci_dn *parent;
struct pci_controller *phb;/* for pci devices */
- struct iommu_table *iommu_table; /* for phb's or bridges */
+ struct iommu_table_group *table_group; /* for phb's or bridges */
struct device_node *node; /* back-pointer to the device_node */
int
Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks
On Wed, May 13, 2015 at 06:39:53PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2015 at 3:25 PM, Al Viro wrote: > > More on top of the current vfs.git#for-next (== the posted patchset > > with a couple of fixes): more fs/namei.c reorganization and stack footprint > > reduction (below 1Kb now). One interesting piece of that is that we don't > > touch current->fs->lock anymore - unlazy_walk() used to, but now we can > > get rid of that. > > Ok. I don't see anything wrong here, but I have to admit that I'm also > at the point where I go "maybe this area should calm down a bit", and > where I'd prefer to not see more long patch-series. Even if most of > the patches seem to be fairly mechanical code movement and cleanup and > preparation, mistakes happen, and I just get worried. > > So I think the series is good, but in particular if you're planning on > some more core changes (ie your "act on filename" callback thing), I > would really prefer that we stop at this point for the 4.2 window, and > make sure it's all stable. *nod* It had been a fun three weeks, but at that point all low-hanging fruits are gone. There is more stuff visible there (lazy stat(), offloading automounts via schedule_work(), perhaps RCU handling of non-fast symlinks), but that'll take a lot more serious plotting[1] before it gets to the stage when it can be implemented. In particular, automounts will require discussing what exactly in the process' state is used for those - both with autofs/NFS/AFS/CIFS folks and with Eric (what netns should be used when we are crossing an NFSv4 referral point? Should it come from the NFS mount we'd found the referral on, or from the process that has run across it? There'd been a series from Ian around the interplay of autofs with namespaces, and IIRC it stepped into similar-sounding areas; it'll need to be looked into, etc.) I doubt that we'll get it sorted out before 4.2, and this kind of stuff *does* need exposure in -testing, as well as public review, so such continuations are clear 4.3 fodder. I hope to get it figured out by the time 4.3-rc1 comes, so that it could be dealt with early in the next cycle, but for now I'm planning to pull the current #link_path_walk into #for-next and let it soak there. Especially since there are other pending piles of joy elsewhere - handling of d_move()-messed vfsmounts, for starters ;-/ > And then your callback thing could be for 4.3. > > That said, I'm not entirely convinced about a callback approach for > stat() and friends. I suspect only stat() is really critical enough to > warrant the whole "let's do it all in RCU mode", and if there's only > one case, then there's no need for the (*act) indirection - might as > well hardcode it. Maybe... I'd like to see the profiles, TBH - especially getxattr() and access() frequency on various loads. Sure, make(1) and cc(1) really care about stat() very much, but I wouldn't be surprised if something like httpd or samba would be hitting getxattr() a lot... > But feel free to convince me. Again, I'd really prefer that to be > after the current work has been in a stable release and a well tested > base, though. No arguments here... [1] as in "which shitpiles are we likely to step into on the way there and how far would detours take us" -- 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/4] edac, altera: Generalize driver to use DT Memory size
On 5/13/15 4:49 PM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer
>
> The Arria10 SOC uses a completely different SDRAM controller from the
> earlier CycloneV and ArriaV SoCs. The memory size is calculated in
> the bootloader and passed via the device tree. Using this device
> tree size is more generic than using the register fields to
> calculate the memory size for different SDRAM controllers.
>
> Signed-off-by: Thor Thayer
> ---
> drivers/edac/altera_edac.c | 53
> ++--
> 1 file changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
> index 3c4929f..e18a205 100644
> --- a/drivers/edac/altera_edac.c
> +++ b/drivers/edac/altera_edac.c
> @@ -219,36 +219,35 @@ static void altr_sdr_mc_create_debugfs_nodes(struct
> mem_ctl_info *mci)
> {}
> #endif
>
> -/* Get total memory size in bytes */
> -static u32 altr_sdram_get_total_mem_size(struct regmap *mc_vbase)
> +/* Get total memory size from Open Firmware DTB */
> +static unsigned long get_total_mem(void)
> {
> - u32 size, read_reg, row, bank, col, cs, width;
> + struct device_node *np = NULL;
> + const unsigned int *reg, *reg_end;
> + int len, sw, aw;
> + unsigned long start, size, total_mem;
>
> - if (regmap_read(mc_vbase, DRAMADDRW_OFST, _reg) < 0)
> + np = of_find_node_by_type(NULL, "memory");
> + if (!np)
> return 0;
>
> - if (regmap_read(mc_vbase, DRAMIFWIDTH_OFST, ) < 0)
> - return 0;
> -
> - col = (read_reg & DRAMADDRW_COLBIT_MASK) >>
> - DRAMADDRW_COLBIT_SHIFT;
> - row = (read_reg & DRAMADDRW_ROWBIT_MASK) >>
> - DRAMADDRW_ROWBIT_SHIFT;
> - bank = (read_reg & DRAMADDRW_BANKBIT_MASK) >>
> - DRAMADDRW_BANKBIT_SHIFT;
> - cs = (read_reg & DRAMADDRW_CSBIT_MASK) >>
> - DRAMADDRW_CSBIT_SHIFT;
> -
> - /* Correct for ECC as its not addressible */
> - if (width == DRAMIFWIDTH_32B_ECC)
> - width = 32;
> - if (width == DRAMIFWIDTH_16B_ECC)
> - width = 16;
> -
> - /* calculate the SDRAM size base on this info */
> - size = 1 << (row + bank + col);
> - size = size * cs * (width / 8);
> - return size;
> + aw = of_n_addr_cells(np);
> + sw = of_n_size_cells(np);
> + reg = (const unsigned int *)of_get_property(np, "reg", );
> + reg_end = reg + (len / sizeof(u32));
> +
> + total_mem = 0;
> + do {
> + start = of_read_number(reg, aw);
> + reg += aw;
> + size = of_read_number(reg, sw);
> + reg += sw;
> + total_mem += size;
> + } while (reg < reg_end);
> +
> + of_node_put(np);
> + edac_printk(KERN_ERR, EDAC_MC, "total_mem 0x%lx\n", total_mem);
Use edac_dbg() here.
Dinh
--
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: [BUG/REGRESSION] Screen flickering
On Tue, May 12, 2015 at 09:54:07PM +0200, Thomas Gummerer wrote:
>
> Hi,
>
> I noticed that on my machine the screen starts to flicker after I
> suspend and resume my machine, on the main laptop display if an external
> display is attached with kernel v4.1-rc1. I tracked the regression down
> to commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)"), and sent a patch that fixes that
> behavior at [1] about two weeks ago, although I'm not sure it's the
> right thing to do, as I'm not very familiar with the code. The same bug
> still exists in vv4.1-rc3.
>
> Jan Niehusmann confirmed the behavior, but there has been no further
> discussion on the topic. I also forgot to cc the people that were
> involved in the patch that caused the regression (sorry about that).
>
> Is there anything else that I can do to help fixing this issue?
>
> Thanks,
> Thomas
>
> [1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/065494.html
Sorry, I missed your patch when you first sent it. That type of fix
looks like an okay workaround while we do a more in-depth rework of the
watermark system. However I think your patch could cause a crash if we
disable the primary plane via the universal plane interface; if we do
that, p->pri.bytes_per_pixel is set to 0, but since we're now pretending
the primary plane is always enabled, ilk_wm_fbc() can eventually get
called and use that 0 in the denominator of a division operation.
If you just squash the following change into your patch, I think it should be
safe:
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index eb97cbe..99fa8ee 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2076,7 +2076,7 @@ static void ilk_compute_wm_parameters(struct
drm_crtc *crtc,
p->pri.bytes_per_pixel =
crtc->primary->state->fb->bits_per_pixel / 8;
else
- p->pri.bytes_per_pixel = 0;
+ p->pri.bytes_per_pixel = 4;
p->cur.bytes_per_pixel = 4;
/*
Matt
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
--
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 v10 15/34] powerpc/powernv/ioda/ioda2: Rework TCE invalidation in tce_build()/tce_free()
On 05/14/2015 10:48 AM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:04AM +1000, Alexey Kardashevskiy wrote:
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table.
IODA2 actually needs PCI addresses to invalidate the cache. Those
can be calculated from host addresses but since we are going
to implement multi-level TCE tables, calculating PCI address from
a host address might get either tricky or ugly as TCE table remains flat
on PCI bus but not in RAM.
This moves pnv_pci_ioda_tce_invalidate() from generic pnv_tce_build/
pnt_tce_free and defines IODA1/2-specific callbacks which call generic
ones and do PHB-model-specific TCE cache invalidation. P5IOC2 keeps
using generic callbacks as before.
This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
number of pages which are PCI addresses shifted by IOMMU page shift.
No change in behaviour is expected.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
---
Changes:
v10:
* moved before "Switch from iommu_table to new iommu_table_group" as it adds
list of groups to iommu_table and tce invalidation depends on it
v9:
* removed confusing comment from commit log about unintentional calling of
pnv_pci_ioda_tce_invalidate()
* moved mechanical changes away to "powerpc/iommu: Move tce_xxx callbacks from
ppc_md to iommu_table"
* fixed bug with broken invalidation in pnv_pci_ioda2_tce_invalidate -
@index includes @tbl->it_offset but old code added it anyway which later broke
DDW
---
arch/powerpc/platforms/powernv/pci-ioda.c | 81 ++-
arch/powerpc/platforms/powernv/pci.c | 17 ++-
2 files changed, 61 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 2924abe..1b43e25 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1678,18 +1678,19 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe,
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
{
+ struct pnv_ioda_pe *pe = tbl->data;
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe->tce_inval_reg_phys :
(__be64 __iomem *)tbl->it_index;
unsigned long start, end, inc;
const unsigned shift = tbl->it_page_shift;
- start = __pa(startp);
- end = __pa(endp);
+ start = __pa(((__be64 *)tbl->it_base) + index - tbl->it_offset);
+ end = __pa(((__be64 *)tbl->it_base) + index - tbl->it_offset +
+ npages - 1);
Platform is the only one knowing the TCE table layout and iommu_table_ops->get()
helps to retrieve TCE entry for the given index. If iommu_table_ops->get() had
returned the address of the TCE entry, not the content. Here,
iommu_table_ops->get()
can be reused and we hide the platform specific TCE table layout in
iommu_table_ops->get()
backend. However, it's not a big deal and it probably introduces more changes
than expected. You judge it's worthy to do it or improve it later :-)
This will require a separate patch to convert tce_get() from returning
value to returning address. I could do that, yes. Furthermore there is even
pnv_tce() helper added later in this patchset which can be used for this in
this patch (if I moved that patch earlier). But this would be a bigger
change which is not very much related to what the patch does -
cut-n-pasting invalidate() bits. May be later. The patchset is way too big
already :(
/* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
if (tbl->it_busno) {
@@ -1725,16 +1726,39 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
*/
}
+static int pnv_ioda1_tce_build(struct iommu_table *tbl, long index,
+ long npages, unsigned long uaddr,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ long ret = pnv_tce_build(tbl, index, npages, uaddr, direction,
+ attrs);
The return value from pnv_tce_build() is "int" :-)
Oops.
+
+ if (!ret && (tbl->it_type & TCE_PCI_SWINV_CREATE))
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+
+ return ret;
+}
+
+static void pnv_ioda1_tce_free(struct iommu_table *tbl, long index,
+ long npages)
+{
+ pnv_tce_free(tbl, index, npages);
+
+ if (tbl->it_type & TCE_PCI_SWINV_FREE)
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+}
+
static
[PATCH] vf610: dt: Nomenclature fixup for PTC12 pin used in RMII mode.
This commit includes a minor nomenclature fixup for boards based on the Freescale VF610 SoC and which make use of the alternate "RMII1_RXD1" functionality for pin PTC12. This brings the macro name in-line with both the datasheet and other similar macros. Signed-off-by: Cory Tusar --- arch/arm/boot/dts/vf-colibri.dtsi | 2 +- arch/arm/boot/dts/vf610-cosmic.dts | 2 +- arch/arm/boot/dts/vf610-pinfunc.h | 2 +- arch/arm/boot/dts/vf610-twr.dts| 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi index fbef082..68ca125 100644 --- a/arch/arm/boot/dts/vf-colibri.dtsi +++ b/arch/arm/boot/dts/vf-colibri.dtsi @@ -140,7 +140,7 @@ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2 VF610_PAD_PTC10__ENET_RMII1_MDIO0x30d3 VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1 - VF610_PAD_PTC12__ENET_RMII_RXD1 0x30d1 + VF610_PAD_PTC12__ENET_RMII1_RXD10x30d1 VF610_PAD_PTC13__ENET_RMII1_RXD00x30d1 VF610_PAD_PTC14__ENET_RMII1_RXER0x30d1 VF610_PAD_PTC15__ENET_RMII1_TXD10x30d2 diff --git a/arch/arm/boot/dts/vf610-cosmic.dts b/arch/arm/boot/dts/vf610-cosmic.dts index fd8758b..5447f25 100644 --- a/arch/arm/boot/dts/vf610-cosmic.dts +++ b/arch/arm/boot/dts/vf610-cosmic.dts @@ -68,7 +68,7 @@ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2 VF610_PAD_PTC10__ENET_RMII1_MDIO0x30d3 VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1 - VF610_PAD_PTC12__ENET_RMII_RXD1 0x30d1 + VF610_PAD_PTC12__ENET_RMII1_RXD10x30d1 VF610_PAD_PTC13__ENET_RMII1_RXD00x30d1 VF610_PAD_PTC14__ENET_RMII1_RXER0x30d1 VF610_PAD_PTC15__ENET_RMII1_TXD10x30d2 diff --git a/arch/arm/boot/dts/vf610-pinfunc.h b/arch/arm/boot/dts/vf610-pinfunc.h index 1ee681f..fcad713 100644 --- a/arch/arm/boot/dts/vf610-pinfunc.h +++ b/arch/arm/boot/dts/vf610-pinfunc.h @@ -369,7 +369,7 @@ #define VF610_PAD_PTC11__MLB_DATA 0x0E0 0x358 ALT6 0x1 #define VF610_PAD_PTC11__DEBUG_OUT 0x0E0 0x000 ALT7 0x0 #define VF610_PAD_PTC12__GPIO_57 0x0E4 0x000 ALT0 0x0 -#define VF610_PAD_PTC12__ENET_RMII_RXD10x0E4 0x000 ALT1 0x0 +#define VF610_PAD_PTC12__ENET_RMII1_RXD1 0x0E4 0x000 ALT1 0x0 #define VF610_PAD_PTC12__ESAI_SDO1 0x0E4 0x318 ALT3 0x1 #define VF610_PAD_PTC12__SAI2_TX_BCLK 0x0E4 0x370 ALT5 0x1 #define VF610_PAD_PTC12__DEBUG_OUT30x0E4 0x000 ALT7 0x0 diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts index f64fddc..375ab23 100644 --- a/arch/arm/boot/dts/vf610-twr.dts +++ b/arch/arm/boot/dts/vf610-twr.dts @@ -221,7 +221,7 @@ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2 VF610_PAD_PTC10__ENET_RMII1_MDIO0x30d3 VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1 - VF610_PAD_PTC12__ENET_RMII_RXD1 0x30d1 + VF610_PAD_PTC12__ENET_RMII1_RXD10x30d1 VF610_PAD_PTC13__ENET_RMII1_RXD00x30d1 VF610_PAD_PTC14__ENET_RMII1_RXER0x30d1 VF610_PAD_PTC15__ENET_RMII1_TXD10x30d2 -- 2.3.6 -- 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 v3] imx27: dt: only map 4 Kbyte for fec registers
On Wed, May 13, 2015 at 12:18:26AM +0200, Philippe Reynes wrote: > According to the imx27 documentation, fec has a 4 Kbyte > memory space map. Moreover, the actual 16 Kbyte mapping > overlaps the SCC (Security Controller) memory register > space. So, we reduce the memory register space to 4 Kbyte. > > Signed-off-by: Philippe Reynes Updated the patch prefix as "ARM: dts: imx27: ", and applied. Thanks. Shawn -- 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 v10 14/34] powerpc/iommu: Move tce_xxx callbacks from ppc_md to iommu_table
On 05/14/2015 10:23 AM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:03AM +1000, Alexey Kardashevskiy wrote:
This adds a iommu_table_ops struct and puts pointer to it into
the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
callbacks from ppc_md to the new struct where they really belong to.
This adds the requirement for @it_ops to be initialized before calling
iommu_init_table() to make sure that we do not leave any IOMMU table
with iommu_table_ops uninitialized. This is not a parameter of
iommu_init_table() though as there will be cases when iommu_init_table()
will not be called on TCE tables, for example - VFIO.
This does s/tce_build/set/, s/tce_free/clear/ and removes "tce_"
redundand prefixes.
s/redundand/redundant I might be wrong because of my bad English.
No, you're right ;)
This removes tce_xxx_rm handlers from ppc_md but does not add
them to iommu_table_ops as this will be done later if we decide to
support TCE hypercalls in real mode. This removes _vm callbacks as
only virtual mode is supported by now so this also removes @rm parameter.
For pSeries, this always uses tce_buildmulti_pSeriesLP/
tce_buildmulti_pSeriesLP. This changes multi callback to fall back to
tce_build_pSeriesLP/tce_free_pSeriesLP if FW_FEATURE_MULTITCE is not
present. The reason for this is we still have to support "multitce=off"
boot parameter in disable_multitce() and we do not want to walk through
all IOMMU tables in the system and replace "multi" callbacks with single
ones.
For powernv, this defines _ops per PHB type which are P5IOC2/IODA1/IODA2.
This makes the callbacks for them public. Later patches will extend
callbacks for IODA1/2.
No change in behaviour is expected.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
---
Changes:
v9:
* pnv_tce_build/pnv_tce_free/pnv_tce_get have been made public and lost
"rm" parameters to make following patches simpler (realmode is not
supported here anyway)
* got rid of _vm versions of callbacks
---
arch/powerpc/include/asm/iommu.h| 17 +++
arch/powerpc/include/asm/machdep.h | 25 ---
arch/powerpc/kernel/iommu.c | 46 ++--
arch/powerpc/kernel/vio.c | 5 +++
arch/powerpc/platforms/cell/iommu.c | 8 +++--
arch/powerpc/platforms/pasemi/iommu.c | 7 +++--
arch/powerpc/platforms/powernv/pci-ioda.c | 14 +
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 7 +
arch/powerpc/platforms/powernv/pci.c| 47 +
arch/powerpc/platforms/powernv/pci.h| 5 +++
arch/powerpc/platforms/pseries/iommu.c | 34 -
arch/powerpc/sysdev/dart_iommu.c| 12 +---
12 files changed, 116 insertions(+), 111 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index d91bd69..e2a45c3 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -44,6 +44,22 @@
extern int iommu_is_off;
extern int iommu_force_on;
+struct iommu_table_ops {
+ int (*set)(struct iommu_table *tbl,
+ long index, long npages,
+ unsigned long uaddr,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs);
+ void (*clear)(struct iommu_table *tbl,
+ long index, long npages);
+ unsigned long (*get)(struct iommu_table *tbl, long index);
+ void (*flush)(struct iommu_table *tbl);
Currently, there isn't flush backend on PowerNV platform. I'm not sure
if we have to implement it for PowerNV if we really need it. Maybe you
will have it to support DDW in subsequent patches which I didn't look
into it, but I will :-)
I am not adding new callbacks here, I am moving them. DART uses flush() so
it has to be here.
+};
+
+/* These are used by VIO */
+extern struct iommu_table_ops iommu_table_lpar_multi_ops;
+extern struct iommu_table_ops iommu_table_pseries_ops;
+
It might be reasonable to add "struct iommu_table_ops *ops" to function
vio_register_device_node() where the specified "ops" can be hooked to
the newly created IOMMU table. In that way, the platform (pSeries) specific
IOMMU table operations doesn't have to be exposed to PowerPC subsystem.
I am not exposing anything new here - I am just replacing references to
ppc_md with references to iommu_table_ops.
vio_register_device_node() is called from VIO code. So I'll have to have a
copy of iommu_table_pseries_ops and iommu_table_lpar_multi_ops in VIO code.
If I do this, I'll have to export
tce_build_pSeries()/tce_free_pSeries()/tce_get_pseries() to initialize
those structs. Either way I need to expose some symbols and do deeper
rework but not in this patchset.
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [PATCH] lib: fix 842 build on 32-bit architectures
On Wed, May 13, 2015 at 10:56:39PM +0200, Arnd Bergmann wrote: > Building the 842 code on 32-bit ARM currently results in this link > error: > > ERROR: "__aeabi_uldivmod" [lib/842/842_decompress.ko] undefined! > > The reason is that the __do_index function performs a 64-bit > division by a power-of-two number, but it has no insight into > the function arguments. > > By marking that function inline, the fsize argument is always > known at the time that do_index is called, and the compiler is > able to replace the extremely expensive 64-bit division with > a cheap constant shift operation. > > Aside from fixing that link error, this approach should also improve > both code size and performance on 32-bit architectures significantly. > > Signed-off-by: Arnd Bergmann > --- > Found while building arm32 allmodconfig with gcc-5.0 > > diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c > index 6b2b45aecde3..285bf6b6959c 100644 > --- a/lib/842/842_decompress.c > +++ b/lib/842/842_decompress.c > @@ -169,7 +169,7 @@ static int do_data(struct sw842_param *p, u8 n) > return 0; > } > > -static int __do_index(struct sw842_param *p, u8 size, u8 bits, u64 fsize) > +static inline int __do_index(struct sw842_param *p, u8 size, u8 bits, u64 > fsize) Ugh, relying on inlining to work is fragile. I'm not against making this inline but please make it work even when it is out- of-line. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: [RFC v2 3/6] crypto: qat - address recursive dependency when fw signing is enabled
On Wed, May 13, 2015 at 11:23:53AM -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > We're going to add firmware module signing support, but when we do > this we end up with the following recursive dependency. Fix this by > just depending on FW_LOADER, which is typically always enabled > anyway. We do this as a compromise for now as FW_LOADER is only > selectable when EXPERT is enabled and the recursive dependency issue > below is actually real and valid, its proper fix however requires > a bit of work. > > This technically means this change is likely welcomed for other > parts of the kernel but this is really only needed for now here. Nack. Either fix kbuild or make every user of FW_LOADER use a dependency. Singling out a single crypto device makes zero sense. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 RFC v2 1/2] crypto: add PKE API
On Wed, May 13, 2015 at 04:03:55PM +0100, David Howells wrote: > > So what if we want to use a key that's stored in a TPM? I presume then we > can't use the crypto interface, but must rather use the *key* as the primary > interface somehow. Then it has nothing to do with what we're trying to do here. The crypto API is providing a generic algorithmic interface for operations that can then be accelerated by hardware devices. So anything that cannot be done purely in software does not fall under our purview. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 v10 05/34] powerpc/iommu: Always release iommu_table in iommu_free_table()
On Thu, 2015-05-14 at 12:34 +1000, Alexey Kardashevskiy wrote:
> On 05/14/2015 09:27 AM, Gavin Shan wrote:
> > On Wed, May 13, 2015 at 02:51:36PM +0200, Thomas Huth wrote:
> >> On Wed, 13 May 2015 16:30:16 +1000
> >> Alexey Kardashevskiy wrote:
> >>
> >>> On 05/13/2015 03:33 PM, Gavin Shan wrote:
> On Tue, May 12, 2015 at 01:38:54AM +1000, Alexey Kardashevskiy wrote:
> > At the moment iommu_free_table() only releases memory if
> > the table was initialized for the platform code use, i.e. it had
> > it_map initialized (which purpose is to track DMA memory space use).
> >
> > With dynamic DMA windows, we will need to be able to release
> > iommu_table even if it was used for VFIO in which case it_map is NULL
> > so does the patch.
> >
> > Signed-off-by: Alexey Kardashevskiy
>
> Reviewed-by: Gavin Shan
>
> > ---
> > arch/powerpc/kernel/iommu.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> > index 3d47eb3..2c02d4c 100644
> > --- a/arch/powerpc/kernel/iommu.c
> > +++ b/arch/powerpc/kernel/iommu.c
> > @@ -714,8 +714,7 @@ void iommu_free_table(struct iommu_table *tbl,
> > const char *node_name)
> > unsigned int order;
> >
> > if (!tbl || !tbl->it_map) {
> > - printk(KERN_ERR "%s: expected TCE map for %s\n",
> > __func__,
> > - node_name);
> > + kfree(tbl);
>
> I'm not sure if the "tbl" needs to be checked against NULL as kfree()
> already
> has the check. But it looks a bit strange to free NULL "tbl" from the
> code
> itself.
> >>>
> >>> Yeah, looks a bit weird, agree, I'll change but in general kfree/vfree/...
> >>> - they all check the passed pointer for NULL.
> >>
> >> But if tbl is NULL, the tbl->it_map check will fail, won't it? So in
> >> this case, I think you have to keep it.
> >>
> >
> > If I understood your question correctly, "tbl->it_map" won't be checked
> > when "tbl" is NULL because the connection ("||") for the two conditions.
> > The code can be changed to something like below if Alexey want:
> >
> > if (!tbl)
> > return;
> > if (!tbl->itmap)
> > kfree(tbl);
>
> To be precise ;)
>
> if (!tbl->itmap) {
> kfree(tbl);
> return;
> }
I hope that's not your solution, it clearly segfaults with a null
pointer de-ref if !tbl, which is apparently a concern down this path.
--
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 3/3] max7359_keypad: implement DT bindings
max7359_keypad: implement DT bindings
Signed-off-by: Evgeniy A. Dushistov
---
.../devicetree/bindings/input/max7359-keypad.txt | 33
drivers/input/keyboard/max7359_keypad.c| 60 --
2 files changed, 90 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/max7359-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/max7359-keypad.txt
b/Documentation/devicetree/bindings/input/max7359-keypad.txt
new file mode 100644
index 000..0a3c381
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/max7359-keypad.txt
@@ -0,0 +1,33 @@
+* MAX7359 keypda device tree bindings
+
+Required Properties:
+- compatible: Should be "maxim,max7359"
+- linux,keymap:The definition can be found at
+ bindings/input/matrix-keymap.txt
+
+Optional Properties:
+- maxim,debounce_reg: u8, in short allow control debounce,
+see max7359 datasheet for details
+- maxim,ports_reg: u8, in short allow control what pin used,
+and what pins should be configured as GPIO
+
+Example:
+ max7359_keypad@38 {
+ compatible = "maxim,max7359";
+ reg = <0x38>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;/*gpio_156*/
+ interrupt-parent = <>;
+ maxim,debounce_reg = /bits/ 8 <0x5F>;
+ maxim,ports_reg = /bits/ 8 <0xFF>;
+ linux,keymap = <
+ MATRIX_KEY(0, 0, KEY_RESERVED) /*row 0 not used*/
+ MATRIX_KEY(0, 1, KEY_RESERVED)
+ MATRIX_KEY(0, 2, KEY_RESERVED)
+ MATRIX_KEY(0, 3, KEY_RESERVED)
+ MATRIX_KEY(0, 4, KEY_RESERVED)
+ MATRIX_KEY(0, 5, KEY_RESERVED)
+ MATRIX_KEY(0, 6, KEY_RESERVED)
+ MATRIX_KEY(0, 7, KEY_RESERVED)
+ ...
+ >;
+ };
diff --git a/drivers/input/keyboard/max7359_keypad.c
b/drivers/input/keyboard/max7359_keypad.c
index 5091133..0164f2e 100644
--- a/drivers/input/keyboard/max7359_keypad.c
+++ b/drivers/input/keyboard/max7359_keypad.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#define MAX7359_MAX_KEY_ROWS 8
#define MAX7359_MAX_KEY_COLS 8
@@ -64,6 +65,11 @@ struct max7359_keypad {
struct i2c_client *client;
};
+struct max7359_initial_state {
+ u8 debounce_val;
+ u8 ports_val;
+};
+
static int max7359_write_reg(struct i2c_client *client, u8 reg, u8 val)
{
int ret = i2c_smbus_write_byte_data(client, reg, val);
@@ -143,24 +149,54 @@ static void max7359_close(struct input_dev *dev)
max7359_fall_deepsleep(keypad->client);
}
-static void max7359_initialize(struct i2c_client *client)
+static void max7359_initialize(struct i2c_client *client,
+ const struct max7359_initial_state *init_state)
{
max7359_write_reg(client, MAX7359_REG_CONFIG,
MAX7359_CFG_KEY_RELEASE | /* Key release enable */
MAX7359_CFG_WAKEUP); /* Key press wakeup enable */
/* Full key-scan functionality */
- max7359_write_reg(client, MAX7359_REG_DEBOUNCE, 0x1F);
+ max7359_write_reg(client, MAX7359_REG_DEBOUNCE,
+ init_state->debounce_val);
/* nINT asserts every debounce cycles */
max7359_write_reg(client, MAX7359_REG_INTERRUPT, 0x01);
+ max7359_write_reg(client, MAX7359_REG_PORTS, init_state->ports_val);
max7359_fall_deepsleep(client);
}
+#ifdef CONFIG_OF
+static int max7359_parse_dt(struct device *dev,
+ struct max7359_initial_state *init_state)
+{
+ struct device_node *np = dev->of_node;
+ u8 prop;
+
+ if (!of_property_read_u8(np, "maxim,debounce_reg", ))
+ init_state->debounce_val = prop;
+
+ if (!of_property_read_u8(np, "maxim,ports_reg", ))
+ init_state->ports_val = prop;
+
+ return 0;
+}
+#else
+static inline int max7359_parse_dt(struct device *dev,
+ struct max7359_initial_state *init_state)
+{
+ return -EINVAL;
+}
+#endif
+
static int max7359_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct max7359_initial_state init_state = {
+ .debounce_val = 0x1F,
+ .ports_val = 0xFE,
+ };
const struct matrix_keymap_data *keymap_data =
dev_get_platdata(>dev);
struct max7359_keypad *keypad;
@@ -181,6 +217,15 @@ static int max7359_probe(struct i2c_client *client,
}
dev_dbg(>dev, "keys FIFO is 0x%02x\n", ret);
+ if (!keymap_data) {
+ error = max7359_parse_dt(>dev, _state);
+ if (error) {
+ dev_err(>dev, "platform data null, and no DT
data\n");
+ return error;
+ }
+ dev_dbg(>dev, "Init vals: debounce %X,
Re: [PATCH kernel v10 13/34] powerpc/powernv: Do not set "read" flag if direction==DMA_NONE
On 05/14/2015 10:00 AM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:39:02AM +1000, Alexey Kardashevskiy wrote:
Normally a bitmap from the iommu_table is used to track what TCE entry
is in use. Since we are going to use iommu_table without its locks and
do xchg() instead, it becomes essential not to put bits which are not
implied in the direction flag as the old TCE value (more precisely -
the permission bits) will be used to decide whether to put the page or not.
This adds iommu_direction_to_tce_perm() (its counterpart is there already)
and uses it for powernv's pnv_tce_build().
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
---
Changes:
v9:
* added comment why we must put only valid permission bits
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 15 +++
arch/powerpc/platforms/powernv/pci.c | 7 +--
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index e94a5e3..d91bd69 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -200,6 +200,7 @@ extern int iommu_take_ownership(struct iommu_table *tbl);
extern void iommu_release_ownership(struct iommu_table *tbl);
extern enum dma_data_direction iommu_tce_direction(unsigned long tce);
+extern unsigned long iommu_direction_to_tce_perm(enum dma_data_direction dir);
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 8673c94..31319f8 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -863,6 +863,21 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t
size,
}
}
+unsigned long iommu_direction_to_tce_perm(enum dma_data_direction dir)
+{
+ switch (dir) {
+ case DMA_BIDIRECTIONAL:
+ return TCE_PCI_READ | TCE_PCI_WRITE;
+ case DMA_FROM_DEVICE:
+ return TCE_PCI_WRITE;
+ case DMA_TO_DEVICE:
+ return TCE_PCI_READ;
+ default:
+ return 0;
It might be nice to have a WARN_ON() or log for the default case. If the TCE
entry is going to be updated without permission bits by ppc_md.tce_build().
If this is happening in pnv_tce_build() (which is for the host DMA only) -
it is quite late to trace anything, we are totally screwed by then.
If you are talking about VFIO (pnv_tce_xchg()), we calculate
enum_dma_data_direction from the VFIO permission bits so wrong value won't
be passed here at all.
The DMA operation covered by this TCE entry will cause EEH error. More
logs would be helpful to locate the root cause of the EEH error :-)
+ }
+}
+EXPORT_SYMBOL_GPL(iommu_direction_to_tce_perm);
+
The function converts generic permission flags to PCI specific flags as
the names (TCE_PCI_{READ,WRITE}) indicates. I'm not sure if it's reasonable
to have function name iommu_direction_to_pci_tce_perm(). Platform devices
who have DMA capability might have different flags other than
TCE_PCI_{READ,WRITE}
and possibly use iommu.c to manage platform specific TCE table. We might
not have the use case for now, so I'm not sure it makes sense to have a
more specific function name.
"tce" is for SPAPR TCE protocol so the function does pretty certain thing.
It might not be the best place for this function (powernv/pci.c seems to be
better) but I use this function from POWERNV and KVM and I have either
duplicate these helpers in POWERNV and KVM or put in some common place and
where it is now is this place.
And its counterpart - iommu_tce_direction - is there already. We may move
these somewhere else later if we want.
Thanks,
Gavin
#ifdef CONFIG_IOMMU_API
/*
* SPAPR TCE API
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index bca2aeb..b7ea245 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -576,15 +576,10 @@ static int pnv_tce_build(struct iommu_table *tbl, long
index, long npages,
unsigned long uaddr, enum dma_data_direction direction,
struct dma_attrs *attrs, bool rm)
{
- u64 proto_tce;
+ u64 proto_tce = iommu_direction_to_tce_perm(direction);
__be64 *tcep, *tces;
u64 rpn;
- proto_tce = TCE_PCI_READ; // Read allowed
-
- if (direction != DMA_TO_DEVICE)
- proto_tce |= TCE_PCI_WRITE;
-
tces = tcep = ((__be64 *)tbl->it_base) + index - tbl->it_offset;
rpn = __pa(uaddr) >> tbl->it_page_shift;
--
2.4.0.rc3.8.gfb3e7d5
--
Alexey
--
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: Flush cache after DMA_FROM_DEVICE for agressively speculative CPUs
On Wed, May 13, 2015 at 6:49 PM, Leonid Yegoshin
wrote:
> Some MIPS CPUs have an aggressive speculative load and may erroneuosly load
> some cache line in the middle of DMA transaction. CPU discards result but
> cache
> doesn't. If DMA happens from device then additional cache invalidation is
> needed
> on that CPU's after DMA.
>
> Found in test.
>
> Signed-off-by: Leonid Yegoshin
> ---
> arch/mips/mm/dma-default.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
> index 609d1241b0c4..ccf49ecfbf8c 100644
> --- a/arch/mips/mm/dma-default.c
> +++ b/arch/mips/mm/dma-default.c
> @@ -67,11 +67,13 @@ static inline struct page *dma_addr_to_page(struct device
> *dev,
> * systems and only the R1 and R12000 are used in such systems, the
> * SGI IP28 Indigo² rsp. SGI IP32 aka O2.
> */
> -static inline int cpu_needs_post_dma_flush(struct device *dev)
> +static inline int cpu_needs_post_dma_flush(struct device *dev,
> + enum dma_data_direction direction)
> {
> return !plat_device_is_coherent(dev) &&
>(boot_cpu_type() == CPU_R1 ||
> boot_cpu_type() == CPU_R12000 ||
> + (cpu_has_maar && (direction != DMA_TO_DEVICE)) ||
> boot_cpu_type() == CPU_BMIPS5000);
Can all of these CPUs safely skip the post_dma_flush on DMA_TO_DEVICE
(not just maar)?
--
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] atmel: fix an error handle in mxt_probe
HI, Dmitry
thanks for your reply :)
On 2015年05月14日 01:41, Dmitry Torokhov wrote:
Hi,
On Wed, Apr 22, 2015 at 06:46:58PM +0800, Pan Xinhui wrote:
mxt_probe() may fail at last step, and the queue_work scheduled by
request_firmware_nowait
may run later and then access some data which is freed.
To handle this error, add one mutex_lock to cover such case. It may cause
module load delay only when the probe fails.
here is the detail.
module load:
worker_thread:
mxt_probe -> mxt_initialize -> request_firmware_nowait (schedule_work)
|
sysfs_create_group (fails)
mxt_config_cb -> mxt_configure_objects (may access data freed)
|
err_free_object: some cleanup work, like free(data).
Signed-off-by: xinhuix.pan
---
drivers/input/touchscreen/atmel_mxt_ts.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 2875ddf..af057c0 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1978,10 +1978,19 @@ err_free_mem:
static int mxt_configure_objects(struct mxt_data *data,
const struct firmware *cfg);
+static DEFINE_MUTEX(err_probe_lock);
+static int err_probe;
While you are right that bad things will happen if we let
request_firmware_nowait() run after driver fails to bind to the device
using statics to indicate success or failure is not good idea since you
may have several such devices in your unit. Also it still doe snot help
if you decide to unbind the device quickly or unlock the module.
I guess the best way is to signal a completion from callback and wait
for it in error path and in remove().
Thanks.
yes, statics is not good.
It's also a good point that do some work both in err patch and in_remove().
thanks for your nice advices. I will work out patch V2.
thanks
xinhui
+
static void mxt_config_cb(const struct firmware *cfg, void *ctx)
{
+ mutex_lock(_probe_lock);
+ if (err_probe) {
+ mutex_unlock(_probe_lock);
+ return;
+ }
mxt_configure_objects(ctx, cfg);
release_firmware(cfg);
+ mutex_unlock(_probe_lock);
}
static int mxt_initialize(struct mxt_data *data)
@@ -2423,6 +2432,8 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
const struct mxt_platform_data *pdata;
int error;
+ err_probe = 0;
+
pdata = dev_get_platdata(>dev);
if (!pdata) {
pdata = mxt_parse_dt(client);
@@ -2472,6 +2483,9 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return 0;
err_free_object:
+ mutex_lock(_probe_lock);
+ err_probe = -1;
+ mutex_unlock(_probe_lock);
mxt_free_input_device(data);
mxt_free_object_table(data);
err_free_irq:
--
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 v3 2/2] ARM: EXYNOS: Use of_machine_is_compatible instead ofsoc_is_exynos4
On 05/11/15 10:27, Krzysztof Kozlowski wrote:
> of_machine_is_compatible() seems to be preferred over soc_is_exynos4().
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
> Changes since v2:
> 1. New patch, requested by Kukjin Kim.
> ---
> arch/arm/mach-exynos/exynos.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index c3bfbba3006d..5917a30eee33 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -179,7 +179,7 @@ static void __init exynos_init_io(void)
> */
> void exynos_set_delayed_reset_assertion(bool enable)
> {
> - if (soc_is_exynos4()) {
> + if (of_machine_is_compatible("samsung,exynos4")) {
> unsigned int tmp, core_id;
>
> for (core_id = 0; core_id < num_possible_cpus(); core_id++) {
Maybe we need to change the compatible for exynos4415.dtsi? because no
exynos4 in the compatible...Applied, anyway.
Thanks,
Kukjin
--
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 2/3] max7359_keypad: remove code duplication
max7359_keypad: remove code duplication,
max7359_build_keycode do the same thing as matrix_keypad_build_keymap, but
matrix_keypad_build_keymap can also handle DT bindings, so remove
max7359_build_keycode and use matrix_keypad_build_keymap instead. Tested on
beagleboard-xm.
Signed-off-by: Evgeniy A. Dushistov
---
drivers/input/keyboard/Kconfig | 1 +
drivers/input/keyboard/max7359_keypad.c | 30 +-
2 files changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 106fbac..4d75062 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -367,6 +367,7 @@ config KEYBOARD_MAPLE
config KEYBOARD_MAX7359
tristate "Maxim MAX7359 Key Switch Controller"
+ select INPUT_MATRIXKMAP
depends on I2C
help
If you say yes here you get support for the Maxim MAX7359 Key
diff --git a/drivers/input/keyboard/max7359_keypad.c
b/drivers/input/keyboard/max7359_keypad.c
index 4e35904..5091133 100644
--- a/drivers/input/keyboard/max7359_keypad.c
+++ b/drivers/input/keyboard/max7359_keypad.c
@@ -84,26 +84,6 @@ static int max7359_read_reg(struct i2c_client *client, int
reg)
return ret;
}
-static void max7359_build_keycode(struct max7359_keypad *keypad,
- const struct matrix_keymap_data *keymap_data)
-{
- struct input_dev *input_dev = keypad->input_dev;
- int i;
-
- for (i = 0; i < keymap_data->keymap_size; i++) {
- unsigned int key = keymap_data->keymap[i];
- unsigned int row = KEY_ROW(key);
- unsigned int col = KEY_COL(key);
- unsigned int scancode = MATRIX_SCAN_CODE(row, col,
- MAX7359_ROW_SHIFT);
- unsigned short keycode = KEY_VAL(key);
-
- keypad->keycodes[scancode] = keycode;
- __set_bit(keycode, input_dev->keybit);
- }
- __clear_bit(KEY_RESERVED, input_dev->keybit);
-}
-
/* runs in an IRQ thread -- can (and will!) sleep */
static irqreturn_t max7359_interrupt(int irq, void *dev_id)
{
@@ -232,7 +212,15 @@ static int max7359_probe(struct i2c_client *client,
input_set_capability(input_dev, EV_MSC, MSC_SCAN);
input_set_drvdata(input_dev, keypad);
- max7359_build_keycode(keypad, keymap_data);
+ error = matrix_keypad_build_keymap(keymap_data, NULL,
+ MAX7359_MAX_KEY_ROWS,
+ MAX7359_MAX_KEY_COLS,
+ keypad->keycodes,
+ input_dev);
+ if (error) {
+ dev_err(>dev, "failed to build keymap\n");
+ return error;
+ }
error = devm_request_threaded_irq(>dev, client->irq, NULL,
max7359_interrupt,
--
2.3.6
--
/Evgeniy
--
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 1/3] max7359_keypad: Do not set MAX7359_CFG_INTERRUPT flag
max7359_keypad: Do not set MAX7359_CFG_INTERRUPT flag.
In datasheet of max7359, there is description of this flag:
0 - INT cleared when FIFO empty,
1 - INT cleared after host read. In this mode, I2C should read
FIFO until interrupt condition removed, or further INT may be lost.
So, if we set this flag, we have to read FIFO until it become
empty. But in interrupt we read FIFO just once.
This lead to "keyboard" hang until reboot, if we press
several keys, because of interrupt handler read just one
"press" from FIFO and clear interrupt.
Signed-off-by: Evgeniy A. Dushistov
---
drivers/input/keyboard/max7359_keypad.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/input/keyboard/max7359_keypad.c
b/drivers/input/keyboard/max7359_keypad.c
index faa6da5..4e35904 100644
--- a/drivers/input/keyboard/max7359_keypad.c
+++ b/drivers/input/keyboard/max7359_keypad.c
@@ -166,7 +166,6 @@ static void max7359_close(struct input_dev *dev)
static void max7359_initialize(struct i2c_client *client)
{
max7359_write_reg(client, MAX7359_REG_CONFIG,
- MAX7359_CFG_INTERRUPT | /* Irq clears after host read */
MAX7359_CFG_KEY_RELEASE | /* Key release enable */
MAX7359_CFG_WAKEUP); /* Key press wakeup enable */
--
2.3.6
--
/Evgeniy
--
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 v10 22/34] powerpc/powernv: Implement accessor to TCE entry
On Tue, May 12, 2015 at 01:39:11AM +1000, Alexey Kardashevskiy wrote:
>This replaces direct accesses to TCE table with a helper which
>returns an TCE entry address. This does not make difference now but will
>when multi-level TCE tables get introduces.
>
>No change in behavior is expected.
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v9:
>* new patch in the series to separate this mechanical change from
>functional changes; this is not right before
>"powerpc/powernv: Implement multilevel TCE tables" but here in order
>to let the next patch - "powerpc/iommu/powernv: Release replaced TCE" -
>use pnv_tce() and avoid changing the same code twice
>---
> arch/powerpc/platforms/powernv/pci.c | 34 +-
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci.c
>b/arch/powerpc/platforms/powernv/pci.c
>index ed7de7b..cc82f05 100644
>--- a/arch/powerpc/platforms/powernv/pci.c
>+++ b/arch/powerpc/platforms/powernv/pci.c
>@@ -572,38 +572,46 @@ struct pci_ops pnv_pci_ops = {
> .write = pnv_pci_write_config,
> };
>
>+static __be64 *pnv_tce(struct iommu_table *tbl, long idx)
>+{
>+ __be64 *tmp = ((__be64 *)tbl->it_base);
>+
>+ return tmp + idx;
>+}
>+
> int pnv_tce_build(struct iommu_table *tbl, long index, long npages,
> unsigned long uaddr, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> u64 proto_tce = iommu_direction_to_tce_perm(direction);
>- __be64 *tcep;
>- u64 rpn;
>+ u64 rpn = __pa(uaddr) >> tbl->it_page_shift;
>+ long i;
>
>- tcep = ((__be64 *)tbl->it_base) + index - tbl->it_offset;
>- rpn = __pa(uaddr) >> tbl->it_page_shift;
>-
>- while (npages--)
>- *(tcep++) = cpu_to_be64(proto_tce |
>- (rpn++ << tbl->it_page_shift));
>+ for (i = 0; i < npages; i++) {
>+ unsigned long newtce = proto_tce |
>+ ((rpn + i) << tbl->it_page_shift);
>+ unsigned long idx = index - tbl->it_offset + i;
>
>+ *(pnv_tce(tbl, idx)) = cpu_to_be64(newtce);
>+ }
>
> return 0;
> }
>
> void pnv_tce_free(struct iommu_table *tbl, long index, long npages)
> {
>- __be64 *tcep;
>+ long i;
>
>- tcep = ((__be64 *)tbl->it_base) + index - tbl->it_offset;
>+ for (i = 0; i < npages; i++) {
>+ unsigned long idx = index - tbl->it_offset + i;
>
>- while (npages--)
>- *(tcep++) = cpu_to_be64(0);
>+ *(pnv_tce(tbl, idx)) = cpu_to_be64(0);
>+ }
> }
>
> unsigned long pnv_tce_get(struct iommu_table *tbl, long index)
> {
>- return ((u64 *)tbl->it_base)[index - tbl->it_offset];
>+ return *(pnv_tce(tbl, index - tbl->it_offset));
> }
>
> struct iommu_table *pnv_pci_table_alloc(int nid)
>--
>2.4.0.rc3.8.gfb3e7d5
>
--
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 v10 05/34] powerpc/iommu: Always release iommu_table in iommu_free_table()
On 05/14/2015 09:27 AM, Gavin Shan wrote:
On Wed, May 13, 2015 at 02:51:36PM +0200, Thomas Huth wrote:
On Wed, 13 May 2015 16:30:16 +1000
Alexey Kardashevskiy wrote:
On 05/13/2015 03:33 PM, Gavin Shan wrote:
On Tue, May 12, 2015 at 01:38:54AM +1000, Alexey Kardashevskiy wrote:
At the moment iommu_free_table() only releases memory if
the table was initialized for the platform code use, i.e. it had
it_map initialized (which purpose is to track DMA memory space use).
With dynamic DMA windows, we will need to be able to release
iommu_table even if it was used for VFIO in which case it_map is NULL
so does the patch.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
---
arch/powerpc/kernel/iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 3d47eb3..2c02d4c 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -714,8 +714,7 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
unsigned int order;
if (!tbl || !tbl->it_map) {
- printk(KERN_ERR "%s: expected TCE map for %s\n", __func__,
- node_name);
+ kfree(tbl);
I'm not sure if the "tbl" needs to be checked against NULL as kfree() already
has the check. But it looks a bit strange to free NULL "tbl" from the code
itself.
Yeah, looks a bit weird, agree, I'll change but in general kfree/vfree/...
- they all check the passed pointer for NULL.
But if tbl is NULL, the tbl->it_map check will fail, won't it? So in
this case, I think you have to keep it.
If I understood your question correctly, "tbl->it_map" won't be checked
when "tbl" is NULL because the connection ("||") for the two conditions.
The code can be changed to something like below if Alexey want:
if (!tbl)
return;
if (!tbl->itmap)
kfree(tbl);
To be precise ;)
if (!tbl->itmap) {
kfree(tbl);
return;
}
Thanks,
Gavin
--
Alexey
--
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 v9.5.1 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
This patch adds a helper to get bits per pixel value of MIPI DSI pixel format.
The helper takes a parameter in the type 'enum mipi_dsi_pixel_format' and
returns it's bits per pixel value if the parameter is valid, otherwise, it
returns -EINVAL. The helper makes users' life easier to do the conversion
from a specific MIPI DSI pixel format to it's bits per pixel value.
Signed-off-by: Liu Ying
---
v9.5->v9.5.1:
* To address Thierry Reding's comments, add a commit message to describe why
the helper is useful and when to use it and fix typo in kernel-doc from
'mipi dsi' to 'MIPI DSI'.
v9->v9.5:
* Add kernel-doc for the new helper function to address Daniel Vetter's
comment.
v8->v9:
* Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.
v7->v8:
* None.
v6->v7:
* None.
v5->v6:
* Address the over 80 characters in one line warning reported by the
checkpatch.pl script.
v4->v5:
* None.
v3->v4:
* None.
v2->v3:
* None.
v1->v2:
* Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
could be placed at the common DRM MIPI DSI driver.
This patch is newly added.
include/drm/drm_mipi_dsi.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..186b15b 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,28 @@ static inline struct mipi_dsi_device
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
}
+/**
+ * mipi_dsi_pixel_format_to_bpp() - get bits per pixel for a MIPI DSI
+ *pixel format
+ * @fmt: MIPI DSI pixel format
+ *
+ * Return: The bits per pixel value for the MIPI DSI pixel format on success or
+ *a negative error code on failure.
+ */
+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case MIPI_DSI_FMT_RGB888:
+ case MIPI_DSI_FMT_RGB666:
+ return 24;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return 18;
+ case MIPI_DSI_FMT_RGB565:
+ return 16;
+ }
+ return -EINVAL;
+}
+
struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node
*np);
int mipi_dsi_attach(struct mipi_dsi_device *dsi);
int mipi_dsi_detach(struct mipi_dsi_device *dsi);
--
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 1/4] ASoC: rockchip: add rockchip machine driver
On 2015年05月14日 07:11, Dylan Reid wrote: On Wed, May 13, 2015 at 10:21 AM, Dylan Reid wrote: On Wed, May 13, 2015 at 9:42 AM, Mark Brown wrote: On Wed, May 13, 2015 at 09:23:01PM +0800, zhengxing wrote: On 2015年05月13日 03:22, Mark Brown wrote: Is it not possible to extend simple card to handle your use cases? Given the very generic naming and the fact that things like jack detection and so on should depend on the CODEC and board usually rather than on the SoC it doesn't sound like this is Rockchip specific. This also looks like you're reimplementing some device model enumeration stuff which probably shouldn't be happening but let's understand the problem you're trying to solve here before going too far into the code. Because we are trying to bring rt5650 in the project, so we intend to describe supported codecs with DTS via only a rockchip machine driver file, others remain pre-implement(like max98090 / rt5645 that vendor machine driver). I don't undertand what you're saying here, sorry - why is this not just a case of writing multiple machine drivers? I don't understand this either. I'd think the best solution is simple-card, configured through DTS for each device. Hi Mark, Dylan, I tried to use simple-card and had some trouble that jack detection. So my idea is simply: /-- rockchip_max98090 (to configure max98090, and no need to via DTS) rockchip_machine_driver |-- rockchip_rt5645 (to configure rt5650/rt5645, and no need to via DTS) (supported codecs via DTS) \-- rockchip_(maybe other codecs) It is right that it is base on original rockchip_max98090, but the old rockchip_max98090 used DTS. I tried to explain my ideas. Your kind suggestions will be highly appreciated. Thanks. -- 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 v10 21/34] powerpc/powernv/ioda2: Add TCE invalidation for all attached groups
On Tue, May 12, 2015 at 01:39:10AM +1000, Alexey Kardashevskiy wrote:
>The iommu_table struct keeps a list of IOMMU groups it is used for.
>At the moment there is just a single group attached but further
>patches will add TCE table sharing. When sharing is enabled, TCE cache
>in each PE needs to be invalidated so does the patch.
>
>This does not change pnv_pci_ioda1_tce_invalidate() as there is no plan
>to enable TCE table sharing on PHBs older than IODA2.
>
>Signed-off-by: Alexey Kardashevskiy
>---
>Changes:
>v10:
>* new to the series
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 35 ---
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index f972e40..8e4987d 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -24,6 +24,7 @@
> #include
> #include
> #include
>+#include
>
> #include
> #include
>@@ -1763,23 +1764,15 @@ static inline void pnv_pci_ioda2_tvt_invalidate(struct
>pnv_ioda_pe *pe)
> __raw_writeq(cpu_to_be64(val), pe->tce_inval_reg);
> }
>
>-static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
>- unsigned long index, unsigned long npages, bool rm)
>+static void pnv_pci_ioda2_tce_do_invalidate(unsigned pe_number, bool rm,
>+ __be64 __iomem *invalidate, unsigned shift,
>+ unsigned long index, unsigned long npages)
> {
>- struct iommu_table_group_link *tgl = list_first_entry_or_null(
>- >it_group_list, struct iommu_table_group_link,
>- next);
>- struct pnv_ioda_pe *pe = container_of(tgl->table_group,
>- struct pnv_ioda_pe, table_group);
> unsigned long start, end, inc;
>- __be64 __iomem *invalidate = rm ?
>- (__be64 __iomem *)pe->tce_inval_reg_phys :
>- pe->tce_inval_reg;
>- const unsigned shift = tbl->it_page_shift;
>
> /* We'll invalidate DMA address in PE scope */
> start = 0x2ull << 60;
>- start |= (pe->pe_number & 0xFF);
>+ start |= (pe_number & 0xFF);
> end = start;
>
> /* Figure out the start, end and step */
>@@ -1797,6 +1790,24 @@ static void pnv_pci_ioda2_tce_invalidate(struct
>iommu_table *tbl,
> }
> }
>
>+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
>+ unsigned long index, unsigned long npages, bool rm)
>+{
>+ struct iommu_table_group_link *tgl;
>+
>+ list_for_each_entry_rcu(tgl, >it_group_list, next) {
>+ struct pnv_ioda_pe *pe = container_of(tgl->table_group,
>+ struct pnv_ioda_pe, table_group);
>+ __be64 __iomem *invalidate = rm ?
>+ (__be64 __iomem *)pe->tce_inval_reg_phys :
>+ pe->tce_inval_reg;
>+
>+ pnv_pci_ioda2_tce_do_invalidate(pe->pe_number, rm,
>+ invalidate, tbl->it_page_shift,
>+ index, npages);
>+ }
>+}
>+
I don't understand this well and need a teaching session: One IOMMU
table can be connected with multiple IOMMU table groups, each of them
can be regarded as being equal to one PE. It means one IOMMU table
can be shared by two PEs. There must be something I missed.
Could you give a teaching session with an example about the IOMMU
table sharing? :-)
Thanks,
Gavin
> static int pnv_ioda2_tce_build(struct iommu_table *tbl, long index,
> long npages, unsigned long uaddr,
> enum dma_data_direction direction,
>--
>2.4.0.rc3.8.gfb3e7d5
>
--
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 v10 20/34] powerpc/powernv/ioda2: Move TCE kill register address to PE
On Tue, May 12, 2015 at 01:39:09AM +1000, Alexey Kardashevskiy wrote:
>At the moment the DMA setup code looks for the "ibm,opal-tce-kill" property
>which contains the TCE kill register address. Writes to this register
>invalidates TCE cache on IODA/IODA2 hub.
>
>This moves the register address from iommu_table to pnv_ioda_pe as:
>1) When we get 2 tables per PE, this register will be used for both tables;
>2) When we get TCE tables sharing, we will need to invalidate every
>IOMMU group (i.e. PE) which is using this table and each PE has
>its own invalidate register.
>
Actually, it's the virtual address of IO remapped PHB hardware register.
So it would be a property of PHB (struct pnv_phb). As the PE is connecting
with IOMMU table group. The virtual address can be retrieved by the path:
iommu_table -> iommu_table_group -> pnv_ioda_pe -> pnv_phb. However, I
don't insist and you have the best judge on it :-)
>This moves the property reading/remapping code to a helper to reduce
>code duplication. Although this change is not required for IODA1, this
>changes it as well to reduce code duplication.
>
>This adds a new pnv_pci_ioda2_tvt_invalidate() helper which invalidates
>the entire table. It should be called after every call to
>opal_pci_map_pe_dma_window(). It was not required before because
>there is just a single TCE table and 64bit DMA is handled via bypass
>window (which has no table so no chache is used) but this is going
>to change with Dynamic DMA windows (DDW).
>
>Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v10:
>* fixed error from checkpatch.pl
>* removed comment at "ibm,opal-tce-kill" parsing as irrelevant
>* s/addr/val/ in pnv_pci_ioda2_tvt_invalidate() as it was not a kernel address
>
>v9:
>* new in the series
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 64 ++-
> arch/powerpc/platforms/powernv/pci.h | 1 +
> 2 files changed, 39 insertions(+), 26 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 35ab19c8..f972e40 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -1680,7 +1680,7 @@ static void pnv_pci_ioda1_tce_invalidate(struct
>iommu_table *tbl,
> struct pnv_ioda_pe, table_group);
> __be64 __iomem *invalidate = rm ?
> (__be64 __iomem *)pe->tce_inval_reg_phys :
>- (__be64 __iomem *)tbl->it_index;
>+ pe->tce_inval_reg;
> unsigned long start, end, inc;
> const unsigned shift = tbl->it_page_shift;
>
>@@ -1751,6 +1751,18 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
> .get = pnv_tce_get,
> };
>
>+static inline void pnv_pci_ioda2_tvt_invalidate(struct pnv_ioda_pe *pe)
>+{
>+ /* 01xb - invalidate TCEs that match the specified PE# */
>+ unsigned long val = (0x4ull << 60) | (pe->pe_number & 0xFF);
>+
>+ if (!pe->tce_inval_reg)
>+ return;
>+
>+ mb(); /* Ensure above stores are visible */
>+ __raw_writeq(cpu_to_be64(val), pe->tce_inval_reg);
>+}
>+
The function name sounds it's to invalidate TVE cache. Actually, it's
invalidting
TCE cache. So I guess the function name pnv_pci_ioda2_tce_invalidate() would be
more accurate.
> static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
> unsigned long index, unsigned long npages, bool rm)
> {
>@@ -1762,7 +1774,7 @@ static void pnv_pci_ioda2_tce_invalidate(struct
>iommu_table *tbl,
> unsigned long start, end, inc;
> __be64 __iomem *invalidate = rm ?
> (__be64 __iomem *)pe->tce_inval_reg_phys :
>- (__be64 __iomem *)tbl->it_index;
>+ pe->tce_inval_reg;
> const unsigned shift = tbl->it_page_shift;
>
> /* We'll invalidate DMA address in PE scope */
>@@ -1814,13 +1826,26 @@ static struct iommu_table_ops pnv_ioda2_iommu_ops = {
> .get = pnv_tce_get,
> };
>
>+static void pnv_pci_ioda_setup_opal_tce_kill(struct pnv_phb *phb,
>+ struct pnv_ioda_pe *pe)
>+{
>+ const __be64 *swinvp;
>+
>+ /* OPAL variant of PHB3 invalidated TCEs */
>+ swinvp = of_get_property(phb->hose->dn, "ibm,opal-tce-kill", NULL);
>+ if (!swinvp)
>+ return;
>+
>+ pe->tce_inval_reg_phys = be64_to_cpup(swinvp);
>+ pe->tce_inval_reg = ioremap(pe->tce_inval_reg_phys, 8);
>+}
>+
Yeah, nice to have the helper function to initialize it :)
> static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
> struct pnv_ioda_pe *pe, unsigned int base,
> unsigned int segs)
> {
>
> struct page *tce_mem = NULL;
>- const __be64 *swinvp;
> struct iommu_table *tbl;
> unsigned int i;
> int64_t rc;
>@@ -1839,6 +1864,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
>*phb,
> pe->pe_number);
>
Re: [PATCH RFC v9.5 09/20] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
2015-05-12 21:36 GMT+08:00 Thierry Reding : > On Fri, Feb 13, 2015 at 01:25:19PM +0800, Liu Ying wrote: >> Signed-off-by: Liu Ying > > This could use a commit message. Describe for example why this is useful > or when to use it. Ok, I'll add it in the next version. > >> --- >> v9->v9.5: >> * Add kernel-doc for the new helper function to address Daniel Vetter's >>comment. >> >> v8->v9: >> * Rebase onto the imx-drm/next branch of Philipp Zabel's open git >> repository. >> >> v7->v8: >> * None. >> >> v6->v7: >> * None. >> >> v5->v6: >> * Address the over 80 characters in one line warning reported by the >>checkpatch.pl script. >> >> v4->v5: >> * None. >> >> v3->v4: >> * None. >> >> v2->v3: >> * None. >> >> v1->v2: >> * Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function >>could be placed at the common DRM MIPI DSI driver. >>This patch is newly added. >> >> include/drm/drm_mipi_dsi.h | 22 ++ >> 1 file changed, 22 insertions(+) >> >> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h >> index f1d8d0d..cabc910 100644 >> --- a/include/drm/drm_mipi_dsi.h >> +++ b/include/drm/drm_mipi_dsi.h >> @@ -163,6 +163,28 @@ static inline struct mipi_dsi_device >> *to_mipi_dsi_device(struct device *dev) >> return container_of(dev, struct mipi_dsi_device, dev); >> } >> >> +/** >> + * mipi_dsi_pixel_format_to_bpp() - get bits per pixel for a mipi dsi >> + *pixel format >> + * @fmt: mipi dsi pixel format >> + * >> + * Return: The bits per pixel value for the mipi dsi pixel format on >> success or >> + *a negative error code on failure. >> + */ > > s/mipi dsi/MIPI DSI/, please. Ok. Thanks, Liu Ying > > Thierry > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Best Regards, Liu Ying -- 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/5] PM / Wakeirq: Add automated device wake IRQ handling
Hi,
On Wed, May 13, 2015 at 04:36:33PM -0700, Tony Lindgren wrote:
> Turns out we can automate the handling for the device_may_wakeup()
> quite a bit by using the kernel wakeup source list.
>
> And as some hardware has separate dedicated wake-up interrupt
> in addition to the IO interrupt, we can automate the handling by
> adding a generic threaded interrupt handler that just calls the
> device PM runtime to wake up the device.
>
> This allows dropping code from device drivers as we currently
> are doing it in multiple ways, and often wrong.
>
> For most drivers, we should be able to drop the following
> boilerplate code from runtime_suspend and runtime_resume
> functions:
>
> ...
> if (device_may_wakeup(dev)
> enable_irq_wake(irq);
> ...
> if (device_may_wakeup(dev)
> enable_irq_wake(irq);
> ...
>
> We can replace it with just the following init and exit
> time code:
>
> ...
> device_init_wakeup(dev, true);
> dev_pm_set_wake_irq(dev, irq);
> ...
> dev_pm_clear_wake_irq(dev);
> device_init_wakeup(dev, false);
> ...
>
> And for hardware with dedicated wake-up interrupts:
>
> ...
> device_init_wakeup(dev, true);
> dev_pm_request_wake_irq(dev, wakeirq, NULL, 0, NULL);
> ...
> dev_pm_enable_wake_irq(dev);
> ...
> dev_pm_disable_wake_irq(dev);
> ...
> dev_pm_free_wake_irq(dev);
> device_init_wakeup(dev, false);
> ...
>
> For now, let's only enable it for select PM_WAKEIRQ.
>
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/Kconfig | 1 +
> drivers/base/power/Makefile | 1 +
> drivers/base/power/main.c| 2 +
> drivers/base/power/power.h | 38 ++
> drivers/base/power/wakeirq.c | 316
> +++
> drivers/base/power/wakeup.c | 96 +
> include/linux/pm.h | 2 +
> include/linux/pm_wakeirq.h | 72 ++
> include/linux/pm_wakeup.h| 7 +
> kernel/power/Kconfig | 4 +
> 10 files changed, 539 insertions(+)
> create mode 100644 drivers/base/power/wakeirq.c
> create mode 100644 include/linux/pm_wakeirq.h
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 6468f15..ac7b570 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -85,6 +85,7 @@ config ARCH_OMAP2PLUS
> select OMAP_DM_TIMER
> select OMAP_GPMC
> select PINCTRL
> + select PM_WAKEIRQ if PM_SLEEP
> select SOC_BUS
> select TI_PRIV_EDMA
> select OMAP_IRQCHIP
seems like enabling this for OMAP should be a patch of its own.
> diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
> index 1cb8544..527546e 100644
> --- a/drivers/base/power/Makefile
> +++ b/drivers/base/power/Makefile
> @@ -4,5 +4,6 @@ obj-$(CONFIG_PM_TRACE_RTC)+= trace.o
> obj-$(CONFIG_PM_OPP) += opp.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o
> obj-$(CONFIG_HAVE_CLK) += clock_ops.o
> +obj-$(CONFIG_PM_WAKEIRQ) += wakeirq.o
>
> ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 3d874ec..24515e7 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -587,6 +587,7 @@ void dpm_resume_noirq(pm_message_t state)
> async_synchronize_full();
> dpm_show_time(starttime, state, "noirq");
> resume_device_irqs();
> + device_wakeup_disarm_wakeirqs();
> cpuidle_resume();
> trace_suspend_resume(TPS("dpm_resume_noirq"), state.event, false);
> }
> @@ -1104,6 +1105,7 @@ int dpm_suspend_noirq(pm_message_t state)
>
> trace_suspend_resume(TPS("dpm_suspend_noirq"), state.event, true);
> cpuidle_pause();
> + device_wakeup_arm_wakeirqs();
> suspend_device_irqs();
> mutex_lock(_list_mtx);
> pm_transition = state;
> diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> index b6b8a27..6183c5d 100644
> --- a/drivers/base/power/power.h
> +++ b/drivers/base/power/power.h
> @@ -20,6 +20,44 @@ static inline void pm_runtime_early_init(struct device
> *dev)
> extern void pm_runtime_init(struct device *dev);
> extern void pm_runtime_remove(struct device *dev);
>
> +#ifdef CONFIG_PM_WAKEIRQ
> +
> +extern int device_wakeup_attach_irq(struct device *dev,
> + struct wake_irq *wakeirq);
> +extern void device_wakeup_detach_irq(struct device *dev);
> +extern void device_wakeup_arm_wakeirqs(void);
> +extern void device_wakeup_disarm_wakeirqs(void);
> +
> +extern void dev_pm_arm_wake_irq(struct wake_irq *wirq);
> +extern void dev_pm_disarm_wake_irq(struct wake_irq *wirq);
> +
> +#else
> +
> +static inline int
> +device_wakeup_attach_irq(struct device *dev,
> + struct wake_irq *wakeirq)
> +{
> + return 0;
> +}
> +
> +static inline void
Re: [PATCH kernel v10 18/34] vfio: powerpc/spapr/iommu/powernv/ioda2: Rework IOMMU ownership control
On Tue, May 12, 2015 at 01:39:07AM +1000, Alexey Kardashevskiy wrote:
>This adds tce_iommu_take_ownership() and tce_iommu_release_ownership
>which call in a loop iommu_take_ownership()/iommu_release_ownership()
>for every table on the group. As there is just one now, no change in
>behaviour is expected.
>
>At the moment the iommu_table struct has a set_bypass() which enables/
>disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
>which calls this callback when external IOMMU users such as VFIO are
>about to get over a PHB.
>
>The set_bypass() callback is not really an iommu_table function but
>IOMMU/PE function. This introduces a iommu_table_group_ops struct and
>adds take_ownership()/release_ownership() callbacks to it which are
>called when an external user takes/releases control over the IOMMU.
>
>This replaces set_bypass() with ownership callbacks as it is not
>necessarily just bypass enabling, it can be something else/more
>so let's give it more generic name.
>
>The callbacks is implemented for IODA2 only. Other platforms (P5IOC2,
>IODA1) will use the old iommu_take_ownership/iommu_release_ownership API.
>The following patches will replace iommu_take_ownership/
>iommu_release_ownership calls in IODA2 with full IOMMU table release/
>create.
>
>As we here and touching bypass control, this removes
>pnv_pci_ioda2_setup_bypass_pe() as it does not do much
>more compared to pnv_pci_ioda2_set_bypass. This moves tce_bypass_base
>initialization to pnv_pci_ioda2_setup_dma_pe.
>
>Signed-off-by: Alexey Kardashevskiy
>[aw: for the vfio related changes]
>Acked-by: Alex Williamson
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v10:
>* fixed comments around take_ownership/release_ownership in
>iommu_table_group_ops
>
>v9:
>* squashed "vfio: powerpc/spapr: powerpc/iommu: Rework IOMMU ownership control"
>and "vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework IOMMU ownership
>control"
>into a single patch
>* moved helpers with a loop through tables in a group
>to vfio_iommu_spapr_tce.c to keep the platform code free of IOMMU table
>groups as much as possible
>* added missing tce_iommu_clear() to tce_iommu_release_ownership()
>* replaced the set_ownership(enable) callback with take_ownership() and
>release_ownership()
>---
> arch/powerpc/include/asm/iommu.h | 11 -
> arch/powerpc/kernel/iommu.c | 12 -
> arch/powerpc/platforms/powernv/pci-ioda.c | 73 ++-
> drivers/vfio/vfio_iommu_spapr_tce.c | 70 ++---
> 4 files changed, 116 insertions(+), 50 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/iommu.h
>b/arch/powerpc/include/asm/iommu.h
>index 664beeb..c5375c5 100644
>--- a/arch/powerpc/include/asm/iommu.h
>+++ b/arch/powerpc/include/asm/iommu.h
>@@ -95,7 +95,6 @@ struct iommu_table {
> struct list_head it_group_list;/* List of iommu_table_group_link */
> #endif
> struct iommu_table_ops *it_ops;
>- void (*set_bypass)(struct iommu_table *tbl, bool enable);
> };
>
> /* Pure 2^n version of get_order */
>@@ -130,6 +129,15 @@ extern struct iommu_table *iommu_init_table(struct
>iommu_table * tbl,
>
> #define IOMMU_TABLE_GROUP_MAX_TABLES 1
>
>+struct iommu_table_group;
>+
>+struct iommu_table_group_ops {
>+ /* Switch ownership from platform code to external user (e.g. VFIO) */
>+ void (*take_ownership)(struct iommu_table_group *table_group);
>+ /* Switch ownership from external user (e.g. VFIO) back to core */
>+ void (*release_ownership)(struct iommu_table_group *table_group);
>+};
>+
> struct iommu_table_group_link {
> struct list_head next;
> struct rcu_head rcu;
>@@ -139,6 +147,7 @@ struct iommu_table_group_link {
> struct iommu_table_group {
> struct iommu_group *group;
> struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
>+ struct iommu_table_group_ops *ops;
> };
>
> extern void iommu_register_group(struct iommu_table_group *table_group,
>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>index bdf19c6..7e54714 100644
>--- a/arch/powerpc/kernel/iommu.c
>+++ b/arch/powerpc/kernel/iommu.c
>@@ -1044,14 +1044,6 @@ int iommu_take_ownership(struct iommu_table *tbl)
>
> memset(tbl->it_map, 0xff, sz);
>
>- /*
>- * Disable iommu bypass, otherwise the user can DMA to all of
>- * our physical memory via the bypass window instead of just
>- * the pages that has been explicitly mapped into the iommu
>- */
>- if (tbl->set_bypass)
>- tbl->set_bypass(tbl, false);
>-
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_take_ownership);
>@@ -1065,10 +1057,6 @@ void iommu_release_ownership(struct iommu_table *tbl)
> /* Restore bit#0 set by iommu_init_table() */
> if (tbl->it_offset == 0)
> set_bit(0, tbl->it_map);
>-
>- /* The kernel owns the device now, we can restore the iommu bypass */
>- if (tbl->set_bypass)
>-
Re: [PATCH 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Thu, May 14, 2015 at 10:37:21AM +1000, Dave Chinner wrote: > On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: > > On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > > > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > > > > This definitions will be used by inode and superblock for encyption. > > > > > > How much of this crypto stuff is common with or only slightly > > > modified from the ext4 code? Is the behaviour and features the > > > same? Is the user API and management tools the same? > > > > > > IMO, if there is any amount of overlap, then we should be > > > implementing this stuff as generic code, not propagating the same > > > code through multiple filesystems via copy-n-paste-n-modify. This > > > will simply end up with diverging code, different bugs and feature > > > sets, and none of the implementations will get the review and > > > maintenance they really require... > > > > > > And, FWIW, this is the reason why I originally asked for the ext4 > > > encryption code to be pulled up to the VFS: precisely so we didn't > > > end up with a rapid proliferation of individual in-filesystem > > > encryption implementations that are all slightly different... > > > > Totally agreed! > > > > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so > > I believe most part of crypto codes are common. > > Can I suggest fs/crypto/ if there are going to be multiple files? No problem at all. I'll do. > > > But, in order to realize that quickly, Ted implemented the feature to > > finalize > > on-disk and in-memory design in EXT4 as a first step. > > Then, I've been catching up and validating its design by implementing it in > > F2FS, which also intends to figure out what crypto codes can be exactly > > common. > > Excellent. That will make it easier and less error prone for other > filesystems to implement it, too! > > > As Ted mentioned before, since next android version tries to use per-file > > encryption, F2FS also needs to support it as quick as possible likewise > > EXT4. > > Fair enough. > > > Meanwhile, surely I've been working on writing patches to push them into > > fs/; > > currenlty, I did for cryto.c and will do for crypto_key.c and > > crypto_fname.c. > > But, it needs to think about crypto_policy.c differently, since it may > > depend > > on how each filesystem stores the policy information respectively; we cannot > > push all the filesystems should use xattrs, right? > > All filesystems likely to implement per-file crypto support xattrs, > and this is exactly what xattrs are designed for. e.g. we already > require xattrs for generic security labels, ACLs, etc. Hence > per-file crypto information should also use a common, shared xattr > format. That way it only needs to be implemented once in the generic > code and there's very little (hopefully nothing!) each filesystem > has to customise to store the crypto information for each file. Ok, I see. Let me take a look at that too. Thank you for sharing your thoughts. :) > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.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: [PATCH kernel v10 17/34] powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group
On Tue, May 12, 2015 at 01:39:06AM +1000, Alexey Kardashevskiy wrote:
>Modern IBM POWERPC systems support multiple (currently two) TCE tables
>per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
>for TCE tables. Right now just one table is supported.
>
>For IODA, instead of embedding iommu_table, the new iommu_table_group
>keeps pointers to those. The iommu_table structs are allocated
>dynamically now by a pnv_pci_table_alloc() helper as PCI hotplug
>code (for EEH recovery) and SRIOV are supported there.
>
>For P5IOC2, both iommu_table_group and iommu_table are embedded into
>PE struct. As there is no EEH and SRIOV support for P5IOC2,
>iommu_free_table() should not be called on iommu_table struct pointers
>so we can keep it embedded in pnv_phb::p5ioc2.
>
>For pSeries, this replaces multiple calls of kzalloc_node() with a new
>iommu_pseries_group_alloc() helper and stores the table group struct
>pointer into the pci_dn struct. For release, a iommu_table_group_free()
>helper is added.
>
>This moves iommu_table struct allocation from SR-IOV code to
>the generic DMA initialization code in pnv_pci_ioda2_setup_dma_pe.
>
>This replaces a single pointer to iommu_group with a list of
>iommu_table_group structs. For now it is just a single iommu_table_group
>in this list but later with TCE table sharing enabled, the list will
>keep all the IOMMU groups which use the particular table. The list
>uses iommu_table_group_link structs rather than iommu_table_group::next
>as a VFIO container may have 2 IOMMU tables, each will have its own list
>head pointer as it is mainly for TCE invalidation code which should
>walk through all attached groups and invalidate TCE cache so
>the table has to keep the list head pointer. The other option would
>be storing list head in a VFIO container but it would not work as
>the platform code (which does TCE table update and invalidation) has
>no idea about VFIO.
>
>This should cause no behavioural change.
>
>Signed-off-by: Alexey Kardashevskiy
>[aw: for the vfio related changes]
>Acked-by: Alex Williamson
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
Thanks,
Gavin
>---
>Changes:
>v10:
>* iommu_table is not embedded into iommu_table_group but allocated
>dynamically
>* iommu_table allocation is moved to a single place for IODA2's
>pnv_pci_ioda_setup_dma_pe where it belongs to
>* added list of groups into iommu_table; most of the code just looks at
>the first item to keep the patch simpler
>
>v9:
>* s/it_group/it_table_group/
>* added and used iommu_table_group_free(), from now iommu_free_table()
>is only used for VIO
>* added iommu_pseries_group_alloc()
>* squashed "powerpc/iommu: Introduce iommu_table_alloc() helper" into this
>---
> arch/powerpc/include/asm/iommu.h| 8 +-
> arch/powerpc/kernel/iommu.c | 9 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 45 ++
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 +
> arch/powerpc/platforms/powernv/pci.c| 73 +
> arch/powerpc/platforms/powernv/pci.h| 7 ++
> arch/powerpc/platforms/pseries/iommu.c | 36 ++--
> drivers/vfio/vfio_iommu_spapr_tce.c | 122
> 8 files changed, 241 insertions(+), 62 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/iommu.h
>b/arch/powerpc/include/asm/iommu.h
>index 61bde1a..664beeb 100644
>--- a/arch/powerpc/include/asm/iommu.h
>+++ b/arch/powerpc/include/asm/iommu.h
>@@ -92,7 +92,7 @@ struct iommu_table {
> unsigned long *it_map; /* A simple allocation bitmap for now */
> unsigned long it_page_shift;/* table iommu page size */
> #ifdef CONFIG_IOMMU_API
>- struct iommu_table_group *it_table_group;
>+ struct list_head it_group_list;/* List of iommu_table_group_link */
> #endif
> struct iommu_table_ops *it_ops;
> void (*set_bypass)(struct iommu_table *tbl, bool enable);
>@@ -130,6 +130,12 @@ extern struct iommu_table *iommu_init_table(struct
>iommu_table * tbl,
>
> #define IOMMU_TABLE_GROUP_MAX_TABLES 1
>
>+struct iommu_table_group_link {
>+ struct list_head next;
>+ struct rcu_head rcu;
>+ struct iommu_table_group *table_group;
>+};
>+
> struct iommu_table_group {
> struct iommu_group *group;
> struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
>diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>index 79e8b43..bdf19c6 100644
>--- a/arch/powerpc/kernel/iommu.c
>+++ b/arch/powerpc/kernel/iommu.c
>@@ -1075,6 +1075,7 @@ EXPORT_SYMBOL_GPL(iommu_release_ownership);
> int iommu_add_device(struct device *dev)
> {
> struct iommu_table *tbl;
>+ struct iommu_table_group_link *tgl;
>
> /*
>* The sysfs entries should be populated before
>@@ -1092,15 +1093,17 @@ int iommu_add_device(struct device *dev)
> }
>
> tbl = get_iommu_table_base(dev);
>- if (!tbl || !tbl->it_table_group || !tbl->it_table_group->group) {
>+ if (!tbl ||
[PATCH v4] livepatch: Prevent to apply the patch once coming module notifier fails
The previous patches can be applied, once the corresponding module is
loaded. In general, the patch will do relocation (if necessary) and
obtain/verify function address before we start to enable patch.
There are three different situations in which the coming module notifier
can fail:
1) relocations are not applied for some reason. In this case kallsyms
for module symbol is not called at all. The patch is not applied to the
module. If the user disable and enable patch again, there is possible
bug in klp_enable_func. If the user specified func->old_addr for some
function in the module (and he shouldn't do that, but nevertheless) our
warning would not catch it, there will be something wrong with the
ftrace.
2) relocations are applied successfully, but kallsyms lookup fails. In
this case func->old_addr can be correct for all previous lookups, 0 for
current failed one, and "unspecified" for the rest. If we undergo the
same scenario as in 1, the behaviour differs for three cases, but the
patch is not enable anyway.
3) the object is initialized, but klp_enable_object fails in the
notifier due to possible ftrace error. Since it is improbable that
ftrace would heal itself in the future, we would get those errors
everytime the patch is enabled.
In order to fix above situations, we can make obj->mod to NULL, if the
coming modified notifier fails.
Signed-off-by: Minfei Huang
---
v3:
- modify the code style
v2:
- add the error message to make it more friendly
- modify the commit log, base on the mbe...@suse.cz suggesting
v1:
- modify the commit log, describe the issue more details
---
kernel/livepatch/core.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 284e269..d4603e7 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch)
}
EXPORT_SYMBOL_GPL(klp_register_patch);
-static void klp_module_notify_coming(struct klp_patch *patch,
+static int klp_module_notify_coming(struct klp_patch *patch,
struct klp_object *obj)
{
struct module *pmod = patch->mod;
@@ -891,22 +891,24 @@ static void klp_module_notify_coming(struct klp_patch
*patch,
int ret;
ret = klp_init_object_loaded(patch, obj);
- if (ret)
- goto err;
+ if (ret) {
+ pr_warn("failed to initialize patch '%s' for module '%s'
(%d)\n",
+ pmod->name, mod->name, ret);
+ goto out;
+ }
if (patch->state == KLP_DISABLED)
- return;
+ goto out;
pr_notice("applying patch '%s' to loading module '%s'\n",
pmod->name, mod->name);
ret = klp_enable_object(obj);
- if (!ret)
- return;
-
-err:
- pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
- pmod->name, mod->name, ret);
+ if (ret)
+ pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
+ pmod->name, mod->name, ret);
+out:
+ return ret;
}
static void klp_module_notify_going(struct klp_patch *patch,
@@ -930,6 +932,7 @@ disabled:
static int klp_module_notify(struct notifier_block *nb, unsigned long action,
void *data)
{
+ int ret;
struct module *mod = data;
struct klp_patch *patch;
struct klp_object *obj;
@@ -955,7 +958,12 @@ static int klp_module_notify(struct notifier_block *nb,
unsigned long action,
if (action == MODULE_STATE_COMING) {
obj->mod = mod;
- klp_module_notify_coming(patch, obj);
+ ret = klp_module_notify_coming(patch, obj);
+ if (ret) {
+ obj->mod = NULL;
+ pr_warn("patch '%s' is in an
inconsistent state!\n",
+ patch->mod->name);
+ }
} else /* MODULE_STATE_GOING */
klp_module_notify_going(patch, obj);
--
2.2.2
--
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] MIPS: Flush cache after DMA_FROM_DEVICE for agressively speculative CPUs
Some MIPS CPUs have an aggressive speculative load and may erroneuosly load
some cache line in the middle of DMA transaction. CPU discards result but cache
doesn't. If DMA happens from device then additional cache invalidation is needed
on that CPU's after DMA.
Found in test.
Signed-off-by: Leonid Yegoshin
---
arch/mips/mm/dma-default.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index 609d1241b0c4..ccf49ecfbf8c 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -67,11 +67,13 @@ static inline struct page *dma_addr_to_page(struct device
*dev,
* systems and only the R1 and R12000 are used in such systems, the
* SGI IP28 Indigo² rsp. SGI IP32 aka O2.
*/
-static inline int cpu_needs_post_dma_flush(struct device *dev)
+static inline int cpu_needs_post_dma_flush(struct device *dev,
+ enum dma_data_direction direction)
{
return !plat_device_is_coherent(dev) &&
(boot_cpu_type() == CPU_R1 ||
boot_cpu_type() == CPU_R12000 ||
+ (cpu_has_maar && (direction != DMA_TO_DEVICE)) ||
boot_cpu_type() == CPU_BMIPS5000);
}
@@ -255,7 +257,7 @@ static inline void __dma_sync(struct page *page,
static void mips_dma_unmap_page(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction direction, struct dma_attrs *attrs)
{
- if (cpu_needs_post_dma_flush(dev))
+ if (cpu_needs_post_dma_flush(dev, direction))
__dma_sync(dma_addr_to_page(dev, dma_addr),
dma_addr & ~PAGE_MASK, size, direction);
plat_post_dma_flush(dev);
@@ -309,7 +311,7 @@ static void mips_dma_unmap_sg(struct device *dev, struct
scatterlist *sg,
static void mips_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction direction)
{
- if (cpu_needs_post_dma_flush(dev))
+ if (cpu_needs_post_dma_flush(dev, direction))
__dma_sync(dma_addr_to_page(dev, dma_handle),
dma_handle & ~PAGE_MASK, size, direction);
plat_post_dma_flush(dev);
@@ -328,7 +330,7 @@ static void mips_dma_sync_sg_for_cpu(struct device *dev,
{
int i;
- if (cpu_needs_post_dma_flush(dev))
+ if (cpu_needs_post_dma_flush(dev, direction))
for (i = 0; i < nelems; i++, sg++)
__dma_sync(sg_page(sg), sg->offset, sg->length,
direction);
--
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: [net-next PATCH] net: Reserve skb headroom and set skb->dev even if using __alloc_skb
On Wed, May 13, 2015 at 02:35:51PM -0700, Kevin Hilman wrote:
> Alexander Duyck writes:
>
> > When I had inlined __alloc_rx_skb into __netdev_alloc_skb and
> > __napi_alloc_skb I had overlooked the fact that there was a return in the
> > __alloc_rx_skb. As a result we weren't reserving headroom or setting the
> > skb->dev in certain cases. This change corrects that by adding a couple of
> > jump labels to jump to depending on __alloc_skb either succeeding or
> > failing.
> >
> > Fixes: 9451980a6646 ("net: Use cached copy of pfmemalloc to avoid accessing
> > page")
> > Reported-by: Felipe Balbi
> > Signed-off-by: Alexander Duyck
>
> Tested this on top of next-20150513 on an ARM/OMAP
> (am335x-boneblack.dts) an it fixes the boot problem for me.
>
> Tested-by: Kevin Hilman
Yeah, I know it's too late, but I also tested on my AM437x SK.
Tested-by: Felipe Balbi
--
balbi
signature.asc
Description: Digital signature
[PATCH] perf record: Fix zomible status of child process
If the child process exited between the following code,
the child process will keep zomible status and perf process
will keep "poll" forever
if (done || draining)
break;
---//child process exit, done to 1
err = perf_evlist__poll(rec->evlist,-1);
so, change timeout to 1 second.
---
tools/perf/builtin-record.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c3efdfb..0b242eb 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -486,7 +486,9 @@ static int __cmd_record(struct record *rec, int argc, const
char **argv)
if (hits == rec->samples) {
if (done || draining)
break;
- err = perf_evlist__poll(rec->evlist, -1);
+ do{
+ err = perf_evlist__poll(rec->evlist, 1000);
+ }while((0 == err) && !done);
/*
* Propagate error, only if there's any. Ignore positive
* number of returned events and interrupt error.
--
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] perf record: Fix zomible status of child process
If the child process exited between the following code,
the child process will keep zomible status and perf process
will keep "poll" forever
if (done || draining)
break;
---//child process exit, done to 1
err = perf_evlist__poll(rec->evlist,-1);
so, change timeout to 1 second.
---
tools/perf/builtin-record.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c3efdfb..0b242eb 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -486,7 +486,9 @@ static int __cmd_record(struct record *rec, int argc, const
char **argv)
if (hits == rec->samples) {
if (done || draining)
break;
- err = perf_evlist__poll(rec->evlist, -1);
+ do{
+ err = perf_evlist__poll(rec->evlist, 1000);
+ }while((0 == err) && !done);
/*
* Propagate error, only if there's any. Ignore positive
* number of returned events and interrupt error.
--
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: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks
On Wed, May 13, 2015 at 3:25 PM, Al Viro wrote: > More on top of the current vfs.git#for-next (== the posted patchset > with a couple of fixes): more fs/namei.c reorganization and stack footprint > reduction (below 1Kb now). One interesting piece of that is that we don't > touch current->fs->lock anymore - unlazy_walk() used to, but now we can > get rid of that. Ok. I don't see anything wrong here, but I have to admit that I'm also at the point where I go "maybe this area should calm down a bit", and where I'd prefer to not see more long patch-series. Even if most of the patches seem to be fairly mechanical code movement and cleanup and preparation, mistakes happen, and I just get worried. So I think the series is good, but in particular if you're planning on some more core changes (ie your "act on filename" callback thing), I would really prefer that we stop at this point for the 4.2 window, and make sure it's all stable. And then your callback thing could be for 4.3. That said, I'm not entirely convinced about a callback approach for stat() and friends. I suspect only stat() is really critical enough to warrant the whole "let's do it all in RCU mode", and if there's only one case, then there's no need for the (*act) indirection - might as well hardcode it. But feel free to convince me. Again, I'd really prefer that to be after the current work has been in a stable release and a well tested base, though. Linus -- 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: [RFC v2 6/6] firmware: add firmware signature checking support
On Thu, May 14, 2015 at 10:31:52AM +1000, Julian Calaby wrote: > On Thu, May 14, 2015 at 4:23 AM, Luis R. Rodriguez > wrote: > > +"Require all firmware to be validly signed", under the same menu. > > You reference the relevant Kconfig symbols above, do you want to add > it here too? Sure, amended, thanks. Luis -- 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 v3] livepatch: Prevent to apply the patch once coming module notifier fails
On 05/13/15 at 09:14P, Josh Poimboeuf wrote:
> On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
> > @@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch)
> > }
> > EXPORT_SYMBOL_GPL(klp_register_patch);
> >
> > -static void klp_module_notify_coming(struct klp_patch *patch,
> > +static int klp_module_notify_coming(struct klp_patch *patch,
> > struct klp_object *obj)
> > {
> > struct module *pmod = patch->mod;
> > @@ -891,22 +891,24 @@ static void klp_module_notify_coming(struct klp_patch
> > *patch,
> > int ret;
> >
> > ret = klp_init_object_loaded(patch, obj);
> > - if (ret)
> > - goto err;
> > + if (ret) {
> > + pr_warn("failed to initialize the patch '%s' (%d)\n",
> > + pmod->name, ret);
> > + goto out;
> > + }
>
> Can you change it to:
>
> "failed to initialize the patch '%s' for module '%s' (%d)\n" ?
>
> That would make it more consistent with the other error message and
> identify the failing module.
>
> Also, the indentation should be fixed on the second pr_warn() line.
>
Will modify.
> >
> > if (patch->state == KLP_DISABLED)
> > - return;
> > + goto out;
> >
> > pr_notice("applying patch '%s' to loading module '%s'\n",
> > pmod->name, mod->name);
> >
> > ret = klp_enable_object(obj);
> > - if (!ret)
> > - return;
> > -
> > -err:
> > - pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
> > - pmod->name, mod->name, ret);
> > + if (ret)
> > + pr_warn("failed to apply patch '%s' to module '%s' (%d)\n",
> > + pmod->name, mod->name, ret);
>
> Bad indentation here too.
>
> > @@ -930,6 +932,7 @@ disabled:
> > static int klp_module_notify(struct notifier_block *nb, unsigned long
> > action,
> > void *data)
> > {
> > + int ret;
> > struct module *mod = data;
> > struct klp_patch *patch;
> > struct klp_object *obj;
> > @@ -955,7 +958,13 @@ static int klp_module_notify(struct notifier_block
> > *nb, unsigned long action,
> >
> > if (action == MODULE_STATE_COMING) {
> > obj->mod = mod;
> > - klp_module_notify_coming(patch, obj);
> > + ret = klp_module_notify_coming(patch, obj);
> > + if (ret) {
> > + obj->mod = NULL;
> > + pr_warn("patch '%s' is dead, remove it "
> > + "or re-install the module
> > '%s'\n",
> > + patch->mod->name, obj->name);
> > + }
>
> The patch isn't necessarily dead, since it might also include previously
> enabled changes for vmlinux or other modules. It can actually be a
> dangerous condition if there's a mismatch between old code in the module
> and new code elsewhere. How about something like:
>
> "patch '%s' is in an inconsistent state!\n"
>
> Also, there's no need to split up the string literal into two lines.
> It's ok for a line to have more than 80 columns in that case.
>
Thanks for your reviewing. Will modify the patch.
Thanks
Minfei
> --
> Josh
--
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 v10 16/34] powerpc/spapr: vfio: Replace iommu_table with iommu_table_group
On Tue, May 12, 2015 at 01:39:05AM +1000, Alexey Kardashevskiy wrote:
>Modern IBM POWERPC systems support multiple (currently two) TCE tables
>per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
>for TCE tables. Right now just one table is supported.
>
>This defines iommu_table_group struct which stores pointers to
>iommu_group and iommu_table(s). This replaces iommu_table with
>iommu_table_group where iommu_table was used to identify a group:
>- iommu_register_group();
>- iommudata of generic iommu_group;
>
>This removes @data from iommu_table as it_table_group provides
>same access to pnv_ioda_pe.
>
>For IODA, instead of embedding iommu_table, the new iommu_table_group
>keeps pointers to those. The iommu_table structs are allocated
>dynamically.
>
>For P5IOC2, both iommu_table_group and iommu_table are embedded into
>PE struct. As there is no EEH and SRIOV support for P5IOC2,
>iommu_free_table() should not be called on iommu_table struct pointers
>so we can keep it embedded in pnv_phb::p5ioc2.
>
>For pSeries, this replaces multiple calls of kzalloc_node() with a new
>iommu_pseries_alloc_group() helper and stores the table group struct
>pointer into the pci_dn struct. For release, a iommu_table_free_group()
>helper is added.
>
>This moves iommu_table struct allocation from SR-IOV code to
>the generic DMA initialization code in pnv_pci_ioda_setup_dma_pe and
>pnv_pci_ioda2_setup_dma_pe as this is where DMA is actually initialized.
>This change is here because those lines had to be changed anyway.
>
>This should cause no behavioural change.
>
>Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Gavin Shan
>---
>Changes:
>v10:
>* new to the series, separated from
>"powerpc/spapr: vfio: Switch from iommu_table to new iommu_table_group"
>* iommu_table is not embedded into iommu_table_group but allocated
>dynamically in most cases
>* iommu_table allocation is moved to a single place for IODA2's
>pnv_pci_ioda_setup_dma_pe where it belongs to
>* added list of groups into iommu_table; most of the code just looks at
>the first item to keep the patch simpler
>---
> arch/powerpc/include/asm/iommu.h| 17 +++--
> arch/powerpc/include/asm/pci-bridge.h | 2 +-
> arch/powerpc/kernel/iommu.c | 17 ++---
> arch/powerpc/platforms/powernv/pci-ioda.c | 55 +++---
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 18 +++--
> arch/powerpc/platforms/powernv/pci.h| 3 +-
> arch/powerpc/platforms/pseries/iommu.c | 107 +++-
> drivers/vfio/vfio_iommu_spapr_tce.c | 23 +++---
> 8 files changed, 152 insertions(+), 90 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/iommu.h
>b/arch/powerpc/include/asm/iommu.h
>index e2a45c3..61bde1a 100644
>--- a/arch/powerpc/include/asm/iommu.h
>+++ b/arch/powerpc/include/asm/iommu.h
>@@ -92,13 +92,10 @@ struct iommu_table {
> unsigned long *it_map; /* A simple allocation bitmap for now */
> unsigned long it_page_shift;/* table iommu page size */
> #ifdef CONFIG_IOMMU_API
>- struct iommu_group *it_group;
>+ struct iommu_table_group *it_table_group;
> #endif
> struct iommu_table_ops *it_ops;
> void (*set_bypass)(struct iommu_table *tbl, bool enable);
>-#ifdef CONFIG_PPC_POWERNV
>- void *data;
>-#endif
> };
>
> /* Pure 2^n version of get_order */
>@@ -130,13 +127,21 @@ extern void iommu_free_table(struct iommu_table *tbl,
>const char *node_name);
> extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
> int nid);
> #ifdef CONFIG_IOMMU_API
>-extern void iommu_register_group(struct iommu_table *tbl,
>+
>+#define IOMMU_TABLE_GROUP_MAX_TABLES 1
>+
>+struct iommu_table_group {
>+ struct iommu_group *group;
>+ struct iommu_table *tables[IOMMU_TABLE_GROUP_MAX_TABLES];
>+};
>+
>+extern void iommu_register_group(struct iommu_table_group *table_group,
>int pci_domain_number, unsigned long pe_num);
> extern int iommu_add_device(struct device *dev);
> extern void iommu_del_device(struct device *dev);
> extern int __init tce_iommu_bus_notifier_init(void);
> #else
>-static inline void iommu_register_group(struct iommu_table *tbl,
>+static inline void iommu_register_group(struct iommu_table_group *table_group,
> int pci_domain_number,
> unsigned long pe_num)
> {
>diff --git a/arch/powerpc/include/asm/pci-bridge.h
>b/arch/powerpc/include/asm/pci-bridge.h
>index 1811c44..e2d7479 100644
>--- a/arch/powerpc/include/asm/pci-bridge.h
>+++ b/arch/powerpc/include/asm/pci-bridge.h
>@@ -185,7 +185,7 @@ struct pci_dn {
>
> struct pci_dn *parent;
> struct pci_controller *phb;/* for pci devices */
>- struct iommu_table *iommu_table; /* for phb's or bridges */
>+ struct iommu_table_group *table_group; /* for phb's or bridges */
> struct device_node
Re: [RFC v2 5/7] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core
On 2015/5/13 21:25, Hanjun Guo wrote:
> On 2015年05月13日 20:24, Jiang Liu wrote:
>> On 2015/5/13 17:29, Hanjun Guo wrote:
>>> Hi Jiang,
>>>
>>> On 2015年05月05日 10:46, Jiang Liu wrote:
>>>
>>> struct pci_controller {
>>> struct acpi_device *companion;
>>> void *iommu;
>>> int segment;
>>> int node; /* nearest node with memory or
>>> NUMA_NO_NODE for global allocation */
>>>
>>> void *platform_data;
>>> };
>>>
>>> except void *platform_data;
>>>
>>> On ARM64, the structure is almost the same, so how about
>>> introduce
>>>
>>> struct pci_controller {
>>> struct acpi_device *companion; /* ACPI companion device */
>>> void*iommu; /* IOMMU private data */
>>> int segment;/* PCI domain */
>>> int node; /* NUMA node */
>>> #ifdef CONFIG_IA64
>>> void *platform_data;
>>> #endif
>>> };
>>>
>>> in this file, then can be used for all architectures?
>> Current mode is that architecture defines its own version of
>> struct pci_controller. It would be better to keep this pattern.
>
> OK, thanks for the clarify :) So how about add my basic
> PCI support patch for ARM64 on top of you patch set to fix
> this problem?
Sure, please send me the patches and I will send out v3 to
cover your review comments.
Thanks!
>
> Thanks
> Hanjun
>
>
--
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/3] sched, cgroup: reorganize threadgroup locking
Hello,
On (05/13/15 16:35), Tejun Heo wrote:
[..]
> -static inline void threadgroup_lock(struct task_struct *tsk)
> +static inline void threadgroup_change_begin(struct task_struct *tsk)
> {
> - down_write(>signal->group_rwsem);
> + might_sleep();
I think cgroup_threadgroup_change_begin()->down_read() already does
might_sleep() check.
-ss
> + cgroup_threadgroup_change_begin(tsk);
> }
>
> /**
> - * threadgroup_unlock - unlock threadgroup
> - * @tsk: member task of the threadgroup to unlock
> + * threadgroup_change_end - mark the end of changes to a threadgroup
> + * @tsk: task causing the changes
> *
> - * Reverse threadgroup_lock().
> + * See threadgroup_change_begin().
> */
> -static inline void threadgroup_unlock(struct task_struct *tsk)
> +static inline void threadgroup_change_end(struct task_struct *tsk)
> {
> - up_write(>signal->group_rwsem);
> + cgroup_threadgroup_change_end(tsk);
> }
> -#else
> -static inline void threadgroup_change_begin(struct task_struct *tsk) {}
> -static inline void threadgroup_change_end(struct task_struct *tsk) {}
> -static inline void threadgroup_lock(struct task_struct *tsk) {}
> -static inline void threadgroup_unlock(struct task_struct *tsk) {}
> -#endif
>
> #ifndef __HAVE_THREAD_FUNCTIONS
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index cfa27f9..9309452 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -848,6 +848,48 @@ static struct css_set *find_css_set(struct css_set
> *old_cset,
> return cset;
> }
>
> +void cgroup_threadgroup_change_begin(struct task_struct *tsk)
> +{
> + down_read(>signal->group_rwsem);
> +}
> +
> +void cgroup_threadgroup_change_end(struct task_struct *tsk)
> +{
> + up_read(>signal->group_rwsem);
> +}
> +
> +/**
> + * threadgroup_lock - lock threadgroup
> + * @tsk: member task of the threadgroup to lock
> + *
> + * Lock the threadgroup @tsk belongs to. No new task is allowed to enter
> + * and member tasks aren't allowed to exit (as indicated by PF_EXITING) or
> + * change ->group_leader/pid. This is useful for cases where the threadgroup
> + * needs to stay stable across blockable operations.
> + *
> + * fork and exit explicitly call threadgroup_change_{begin|end}() for
> + * synchronization. While held, no new task will be added to threadgroup
> + * and no existing live task will have its PF_EXITING set.
> + *
> + * de_thread() does threadgroup_change_{begin|end}() when a non-leader
> + * sub-thread becomes a new leader.
> + */
> +static void threadgroup_lock(struct task_struct *tsk)
> +{
> + down_write(>signal->group_rwsem);
> +}
> +
> +/**
> + * threadgroup_unlock - unlock threadgroup
> + * @tsk: member task of the threadgroup to unlock
> + *
> + * Reverse threadgroup_lock().
> + */
> +static inline void threadgroup_unlock(struct task_struct *tsk)
> +{
> + up_write(>signal->group_rwsem);
> +}
> +
> static struct cgroup_root *cgroup_root_from_kf(struct kernfs_root *kf_root)
> {
> struct cgroup *root_cgrp = kf_root->kn->priv;
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" 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/
[PATCH 2/2] Drivers: staging: skein: skein_api: Fixed spelling errors
Fixed a few spelling errors in comments.
Signed-off-by: Colin Cronin
---
drivers/staging/skein/skein_api.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/skein/skein_api.h
b/drivers/staging/skein/skein_api.h
index 171b875..7da8b38 100644
--- a/drivers/staging/skein/skein_api.h
+++ b/drivers/staging/skein/skein_api.h
@@ -121,7 +121,7 @@ struct skein_ctx {
* @param size
* Which Skein size to use.
* @return
- * SKEIN_SUCESS of SKEIN_FAIL
+ * SKEIN_SUCCESS of SKEIN_FAIL
*/
int skein_ctx_prepare(struct skein_ctx *ctx, enum skein_size size);
@@ -136,7 +136,7 @@ int skein_ctx_prepare(struct skein_ctx *ctx, enum
skein_size size);
* @param hash_bit_len
* Number of MAC hash bits to compute
* @return
- * SKEIN_SUCESS of SKEIN_FAIL
+ * SKEIN_SUCCESS of SKEIN_FAIL
* @see skein_reset
*/
int skein_init(struct skein_ctx *ctx, size_t hash_bit_len);
@@ -171,7 +171,7 @@ void skein_reset(struct skein_ctx *ctx);
* @param hash_bit_len
* Number of MAC hash bits to compute
* @return
- * SKEIN_SUCESS of SKEIN_FAIL
+ * SKEIN_SUCCESS of SKEIN_FAIL
*/
int skein_mac_init(struct skein_ctx *ctx, const u8 *key, size_t key_len,
size_t hash_bit_len);
--
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/
[PATCH 1/2] Drivers: staging: comedi: comedi: Fixed comment spelling error
Fixed a spelling error in a comment. Signed-off-by: Colin Cronin --- drivers/staging/comedi/comedi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedi.h b/drivers/staging/comedi/comedi.h index 7455740..66edda1 100644 --- a/drivers/staging/comedi/comedi.h +++ b/drivers/staging/comedi/comedi.h @@ -217,7 +217,7 @@ #define SDF_RUNNING0x0800 /* subdevice is acquiring data */ #define SDF_LSAMPL 0x1000 /* subdevice uses 32-bit samples */ #define SDF_PACKED 0x2000 /* subdevice can do packed DIO */ -/* re recyle these flags for PWM */ +/* re recycle these flags for PWM */ #define SDF_PWM_COUNTER SDF_MODE0 /* PWM can automatically switch off */ #define SDF_PWM_HBRIDGE SDF_MODE1 /* PWM is signed (H-bridge) */ -- 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: [v4 1/3] genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU
> -Original Message- > From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Thursday, May 14, 2015 5:04 AM > To: Jiang Liu > Cc: Wu, Feng; mi...@redhat.com; h...@zytor.com; > linux-kernel@vger.kernel.org > Subject: Re: [v4 1/3] genirq: Introduce irq_set_vcpu_affinity() to target an > interrupt to a VCPU > > > On Wed, 13 May 2015, Jiang Liu wrote: > > > On 2015/4/30 15:06, Feng Wu wrote: > > > With Posted-Interrupts support in Intel CPU and IOMMU, an external > > > interrupt from assigned-devices could be directly delivered to a > > > virtual CPU in a virtual machine. Instead of hacking KVM and Intel > > > IOMMU drivers, we propose a platform independent interface to target > > > an interrupt to a specific virtual CPU in a virtual machine, or set > > > virtual CPU affinity for an interrupt. > > > > > > By adopting this new interface and the hierarchy irqdomain, we could > > > easily support posted-interrupts on Intel platforms, and also provide > > > flexible enough interfaces for other platforms to support similar > > > features. > > > > > > Here is the usage scenario for this interface: > > > Guest update MSI/MSI-X interrupt configuration > > > -->QEMU and KVM handle this > > > -->KVM call this interface (passing posted interrupts descriptor > > >and guest vector) > > > -->irq core will transfer the control to IOMMU > > > -->IOMMU will do the real work of updating IRTE (IRTE has new > > >format for VT-d Posted-Interrupts) > > > > Hi Thomas, > > Any comments or suggestions about this abstraction interface? > > It's on my review list... Thanks a lot, Thomas! Thanks, Feng -- 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] regulator: Add SPMI regulator driver
On 05/13/15 04:41, Mark Brown wrote:
> On Tue, May 12, 2015 at 02:39:47PM -0700, Stephen Boyd wrote:
>
> Lots of things with the DT bindings here. In general if you're
> introducing lots of custom properties I'd recommend doing a patch series
> which starts off with the generic, bog standard driver and then adds on
> the fancy bells and whistles later. That way the simple stuff can get
> merged easily which cuts down on review effort.
Ok. I went for almost everything we had in the downstream kernel so we
can work through the binding. I'll split off all these custom properties
into a different patch.
>
>> +- qcom,system-load:
>> +Usage: optional
>> +Value type:
>> +Description: Load in uA present on regulator that is not captured by
>> + any consumer request.
> This doesn't seem at all specific to this hardware - please add it as a
> generic property.
Ok.
>
>> +- qcom,auto-mode-enable:
>> +Usage: optional
>> +Value type:
>> +Description: 1 = Enable automatic hardware selection of regulator
>> + mode (HPM vs LPM); not available on boost type
>> + regulators. 0 = Disable auto mode selection.
> Can we come up with a different name for this - IIRC (I'm working
> offline as I reply to this) this is not about pulse skipping enabling
> type automatic mode selection but rather about allowing other processors
> to control things. The current name makes me think of the former thing.
> Perhaps just hpm-enable or something, or key it off specifying the
> signal to be used?
This is about configuring the regulator to switch mode between HPM and
LPM automatically based on current. You're right that it's not about
pulse skipping, but it isn't about letting other processors control
things either. I think you're thinking about pin control?
The register field is called AUTO_MODE, so I'm finding it hard to come
up with a better name. Perhaps qcom,auto-efficient-mode-enable?
qcom,auto-current-mode-enable?
>
>> +- qcom,bypass-mode-enable:
>> +Usage: optional
>> +Value type:
>> +Description: 1 = Enable bypass mode for an LDO type regulator so that
>> + it acts like a switch and simply outputs its input
>> + voltage. 0 = Do not enable bypass mode.
> We have generic regulator API support for this, we should have a generic
> DT binding for it.
Given that regulator_allow_bypass() is a consumer facing API should I
just change this to regulator-allow-bypass and then add a set_bypass() op?
>
>> +- qcom,pull-down-enable:
>> +Usage: optional
>> +Value type:
>> +Description: 1 = Enable output pull down resistor when the regulator
>> + is disabled. 0 = Disable pull down resistor
In qcom_rpm-regulator.c I think this is called bias-pull-down.
>> +
>> +- qcom,soft-start-enable:
>> +Usage: optional
>> +Value type:
>> +Description: 1 = Enable soft start for LDO and voltage switch type
>> + regulators so that output voltage slowly ramps up when the
>> + regulator is enabled. 0 = Disable soft start
>
> These also seem like generic properties (we don't currently have generic
> APIs for them but these are by no means the only regulators I've seen
> with these features).
So for these sorts of generic properties how do I get them all the way
into the driver? Are you suggesting adding new ops for setting pull-down
and soft-start-enable and then parsing DT properties, setting those in
the regulation_constraints structure, and then calling the ops when we
apply constraints in set_machine_constraints()?
>
>> +- qcom,boost-current-limit:
>> +Usage: optional
>> +Value type:
>> +Description: This property sets the current limit of boost type
>> + regulators; supported values are:
>> +0 = 300 mA
>> +1 = 600 mA
>> +2 = 900 mA
>> +3 = 1200 mA
>> +4 = 1500 mA
>> +5 = 1800 mA
>> +6 = 2100 mA
>> +7 = 2400 mA
> Again seems generic - there seems like overlap with your own OCP
> properties further above.
Yes it's generic. This property only applies to boost regulators on this
PMIC whereas OCP is only used for voltage switch type regulators. I
wonder if this should be done via regulator-min-microamp and
regulator-max-microamp being set to the same value and then implementing
a .set_current_limit() function?
>
>> +#define VOLTAGE_RANGE(_range_sel, _min_uV, _set_point_min_uV, \
>> +_set_point_max_uV, _max_uV, _step_uV) \
>> +{ \
>> +.min_uV = _min_uV, \
>> +.max_uV = _max_uV, \
>> +.set_point_min_uV = _set_point_min_uV, \
>> +
[PATCH] platform/chrome: cros_ec_dev - Add a platform device ID table
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
Signed-off-by: Javier Martinez Canillas
---
drivers/platform/chrome/cros_ec_dev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_dev.c
b/drivers/platform/chrome/cros_ec_dev.c
index 6090d0b2826f..4232c8136939 100644
--- a/drivers/platform/chrome/cros_ec_dev.c
+++ b/drivers/platform/chrome/cros_ec_dev.c
@@ -216,6 +216,12 @@ static int ec_device_remove(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id cros_ec_id[] = {
+ { "cros-ec-ctl", 0 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, cros_ec_id);
+
static struct platform_driver cros_ec_dev_driver = {
.driver = {
.name = "cros-ec-ctl",
--
2.1.4
--
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] percpu_counter: batch size aware __percpu_counter_compare()
On Wed, May 13, 2015 at 09:59:19AM -0400, Tejun Heo wrote:
> Hello, Dave.
>
> On Wed, May 13, 2015 at 09:52:33AM +1000, Dave Chinner wrote:
> > @@ -116,6 +121,12 @@ static inline int percpu_counter_compare(struct
> > percpu_counter *fbc, s64 rhs)
> > return 0;
> > }
> >
> > +static inline int
> > +percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
> > +{
> > + return percpu_counter_compare(fbc, rhs);
> > +}
>
> I don't think this is right. Looks fine to me otherwise.
Ah, no, it's not. My bad, stale patch. Corrected version below.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
percpu_counter: batch size aware __percpu_counter_compare()
From: Dave Chinner
XFS uses non-stanard batch sizes for avoiding frequent global
counter updates on it's allocated inode counters, as they increment
or decrement in batches of 64 inodes. Hence the standard percpu
counter batch of 32 means that the counter is effectively a global
counter. Currently Xfs uses a batch size of 128 so that it doesn't
take the global lock on every single modification.
However, Xfs also needs to compare accurately against zero, which
means we need to use percpu_counter_compare(), and that has a
hard-coded batch size of 32, and hence will spuriously fail to
detect when it is supposed to use precise comparisons and hence
the accounting goes wrong.
Add __percpu_counter_compare() to take a custom batch size so we can
use it sanely in XFS and factor percpu_counter_compare() to use it.
Signed-off-by: Dave Chinner
---
include/linux/percpu_counter.h | 13 -
lib/percpu_counter.c | 6 +++---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 50e5009..84a1094 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -41,7 +41,12 @@ void percpu_counter_destroy(struct percpu_counter *fbc);
void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch);
s64 __percpu_counter_sum(struct percpu_counter *fbc);
-int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs);
+int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch);
+
+static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
+{
+ return __percpu_counter_compare(fbc, rhs, percpu_counter_batch);
+}
static inline void percpu_counter_add(struct percpu_counter *fbc, s64 amount)
{
@@ -116,6 +121,12 @@ static inline int percpu_counter_compare(struct
percpu_counter *fbc, s64 rhs)
return 0;
}
+static inline int
+__percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
+{
+ return percpu_counter_compare(fbc, rhs);
+}
+
static inline void
percpu_counter_add(struct percpu_counter *fbc, s64 amount)
{
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index 48144cd..f051d69 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -197,13 +197,13 @@ static int percpu_counter_hotcpu_callback(struct
notifier_block *nb,
* Compare counter against given value.
* Return 1 if greater, 0 if equal and -1 if less
*/
-int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
+int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
{
s64 count;
count = percpu_counter_read(fbc);
/* Check to see if rough count will be sufficient for comparison */
- if (abs(count - rhs) > (percpu_counter_batch*num_online_cpus())) {
+ if (abs(count - rhs) > (batch * num_online_cpus())) {
if (count > rhs)
return 1;
else
@@ -218,7 +218,7 @@ int percpu_counter_compare(struct percpu_counter *fbc, s64
rhs)
else
return 0;
}
-EXPORT_SYMBOL(percpu_counter_compare);
+EXPORT_SYMBOL(__percpu_counter_compare);
static int __init percpu_counter_startup(void)
{
--
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/4] powerpc32: memset(0): use cacheable_memzero
On Tue, 2015-05-12 at 15:32 +0200, Christophe Leroy wrote: > cacheable_memzero uses dcbz instruction and is more efficient than > memset(0) when the destination is in RAM > > This patch renames memset as generic_memset, and defines memset > as a prolog to cacheable_memzero. This prolog checks if the byte > to set is 0 and if the buffer is in RAM. If not, it falls back to > generic_memcpy() > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/lib/copy_32.S | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S > index cbca76c..d8a9a86 100644 > --- a/arch/powerpc/lib/copy_32.S > +++ b/arch/powerpc/lib/copy_32.S > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > > #define COPY_16_BYTES\ > lwz r7,4(r4); \ > @@ -74,6 +75,18 @@ CACHELINE_MASK = (L1_CACHE_BYTES-1) > * to set them to zero. This requires that the destination > * area is cacheable. -- paulus > */ > +_GLOBAL(memset) > + cmplwi r4,0 > + bne-generic_memset > + cmplwi r5,L1_CACHE_BYTES > + blt-generic_memset > + lis r8,max_pfn@ha > + lwz r8,max_pfn@l(r8) > + tophys (r9,r3) > + srwir9,r9,PAGE_SHIFT > + cmplw r9,r8 > + bge-generic_memset > + mr r4,r5 max_pfn includes highmem, and tophys only works on normal kernel addresses. If we were to point memset_io, memcpy_toio, etc. at noncacheable versions, are there any other callers left that can reasonably point at uncacheable memory? -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 1/4] Partially revert "powerpc: Remove duplicate cacheable_memcpy/memzero functions"
On Tue, 2015-05-12 at 15:32 +0200, Christophe Leroy wrote:
> This partially reverts
> commit 'powerpc: Remove duplicate cacheable_memcpy/memzero functions
> ("f909a35bdfb7cb350d078a2cf888162eeb20381c")'
I don't have that SHA. Do you mean
b05ae4ee602b7dc90771408ccf0972e1b3801a35?
> Functions cacheable_memcpy/memzero are more efficient than
> memcpy/memset as they use the dcbz instruction which avoids refill
> of the cacheline with the data that we will overwrite.
I don't see anything in this patchset that addresses the "NOTE: The old
routines are just flat buggy on kernels that support hardware with
different cacheline sizes" comment.
-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 kernel v10 15/34] powerpc/powernv/ioda/ioda2: Rework TCE invalidation in tce_build()/tce_free()
On Tue, May 12, 2015 at 01:39:04AM +1000, Alexey Kardashevskiy wrote:
>The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
>supposed to be called on IODA1/2 and not called on p5ioc2. It receives
>start and end host addresses of TCE table.
>
>IODA2 actually needs PCI addresses to invalidate the cache. Those
>can be calculated from host addresses but since we are going
>to implement multi-level TCE tables, calculating PCI address from
>a host address might get either tricky or ugly as TCE table remains flat
>on PCI bus but not in RAM.
>
>This moves pnv_pci_ioda_tce_invalidate() from generic pnv_tce_build/
>pnt_tce_free and defines IODA1/2-specific callbacks which call generic
>ones and do PHB-model-specific TCE cache invalidation. P5IOC2 keeps
>using generic callbacks as before.
>
>This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
>number of pages which are PCI addresses shifted by IOMMU page shift.
>
>No change in behaviour is expected.
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
>---
>Changes:
>v10:
>* moved before "Switch from iommu_table to new iommu_table_group" as it adds
>list of groups to iommu_table and tce invalidation depends on it
>
>v9:
>* removed confusing comment from commit log about unintentional calling of
>pnv_pci_ioda_tce_invalidate()
>* moved mechanical changes away to "powerpc/iommu: Move tce_xxx callbacks from
>ppc_md to iommu_table"
>* fixed bug with broken invalidation in pnv_pci_ioda2_tce_invalidate -
>@index includes @tbl->it_offset but old code added it anyway which later broke
>DDW
>---
> arch/powerpc/platforms/powernv/pci-ioda.c | 81 ++-
> arch/powerpc/platforms/powernv/pci.c | 17 ++-
> 2 files changed, 61 insertions(+), 37 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>b/arch/powerpc/platforms/powernv/pci-ioda.c
>index 2924abe..1b43e25 100644
>--- a/arch/powerpc/platforms/powernv/pci-ioda.c
>+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>@@ -1678,18 +1678,19 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
>*pe,
> }
> }
>
>-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
>- struct iommu_table *tbl,
>- __be64 *startp, __be64 *endp, bool rm)
>+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
>+ unsigned long index, unsigned long npages, bool rm)
> {
>+ struct pnv_ioda_pe *pe = tbl->data;
> __be64 __iomem *invalidate = rm ?
> (__be64 __iomem *)pe->tce_inval_reg_phys :
> (__be64 __iomem *)tbl->it_index;
> unsigned long start, end, inc;
> const unsigned shift = tbl->it_page_shift;
>
>- start = __pa(startp);
>- end = __pa(endp);
>+ start = __pa(((__be64 *)tbl->it_base) + index - tbl->it_offset);
>+ end = __pa(((__be64 *)tbl->it_base) + index - tbl->it_offset +
>+ npages - 1);
Platform is the only one knowing the TCE table layout and iommu_table_ops->get()
helps to retrieve TCE entry for the given index. If iommu_table_ops->get() had
returned the address of the TCE entry, not the content. Here,
iommu_table_ops->get()
can be reused and we hide the platform specific TCE table layout in
iommu_table_ops->get()
backend. However, it's not a big deal and it probably introduces more changes
than expected. You judge it's worthy to do it or improve it later :-)
>
> /* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
> if (tbl->it_busno) {
>@@ -1725,16 +1726,39 @@ static void pnv_pci_ioda1_tce_invalidate(struct
>pnv_ioda_pe *pe,
>*/
> }
>
>+static int pnv_ioda1_tce_build(struct iommu_table *tbl, long index,
>+ long npages, unsigned long uaddr,
>+ enum dma_data_direction direction,
>+ struct dma_attrs *attrs)
>+{
>+ long ret = pnv_tce_build(tbl, index, npages, uaddr, direction,
>+ attrs);
The return value from pnv_tce_build() is "int" :-)
>+
>+ if (!ret && (tbl->it_type & TCE_PCI_SWINV_CREATE))
>+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
>+
>+ return ret;
>+}
>+
>+static void pnv_ioda1_tce_free(struct iommu_table *tbl, long index,
>+ long npages)
>+{
>+ pnv_tce_free(tbl, index, npages);
>+
>+ if (tbl->it_type & TCE_PCI_SWINV_FREE)
>+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
>+}
>+
> static struct iommu_table_ops pnv_ioda1_iommu_ops = {
>- .set = pnv_tce_build,
>- .clear = pnv_tce_free,
>+ .set = pnv_ioda1_tce_build,
>+ .clear = pnv_ioda1_tce_free,
> .get = pnv_tce_get,
> };
>
>-static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
>- struct iommu_table *tbl,
>- __be64 *startp, __be64 *endp, bool rm)
>+static
Re: [PATCH] pwm: samsung: Use MODULE_DEVICE_TABLE() to include OF modalias
Hello Krzysztof, On 05/14/2015 02:37 AM, Krzysztof Kozlowski wrote: > On 14.05.2015 09:32, Javier Martinez Canillas wrote: >> If the pwm-samsung driver is built as a module, modalias information is >> not filled so the module is not autoloaded. Use the MODULE_DEVICE_TABLE() >> macro to export the OF device ID so the module contains that information. >> >> Signed-off-by: Javier Martinez Canillas > > Reviewed-by: Krzysztof Kozlowski > > I think many other Maxim/S[25]M drivers for Samsung boards may also be > affected... Probably they should also be updated. > Yeah, I detected these since I'm preparing a series to reduce the delta between exynos_defconfig and multi_v7_defconfig. And found these issues since current multi_v7 policy is to build as much as possible as a module. I think is unfortunate how many drivers are not providing proper module aliases information and so building them as a module is less useful since user-space can't associate the module with the modalias uevents to autoload. Anyway, I'll take a look for other drivers and see if I can post similar patches but now at least all the peripherals in the Exynos5 Chromebooks are working when their drivers are built as a module. > Best regards, > Krzysztof > Best regards, Javier -- 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: [Y2038] [PATCH] aoe: Use 64-bit timestamp in frame
On 05/13/2015 04:04 AM, Arnd Bergmann wrote: ... Shall we do the ktime_get_us() approach then? It still requires a 32-bit division like do_gettimeofday(), so it will not be as efficient as the shifted nanoseconds. It's no worse, though, right? So I think it's a good transition. Further optimization could be attempted in an experimental branch at some point for easy testing. As for the aoe_deadsecs computation, converting the aoe_deadsec module parameter into scaled nanoseconds can be done at module load time, and that way you also save the integer division you currently do for each frame in rexmit_timer() to turn the microseconds into seconds. Arnd That's true, but the "secs" in the identifier stands for "seconds". It would be misleading to have something called seconds be scaled nanoseconds. And we could just use another variable if it weren't for the fact that this module parameter is exposed through sysfs and can be changed through that mechanism at any time. -- Ed -- 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 0/6] selftests: Add futex functional tests
On 05/13/2015 05:34 PM, Darren Hart wrote: > On 5/13/15, 4:22 PM, "Shuah Khan" wrote: > >> On 05/12/2015 10:07 PM, Darren Hart wrote: >>> Hi Shuah, >>> >>> This series begins the process of migrating my futextest tests into >>> kselftest. >>> I've started with only the functional tests, as the performance and >>> stress may >>> not be appropriate for kselftest as they stand. >>> >>> I cleaned up various complaints from checkpatch, but I ignored others >>> that would >>> require significant rework of the testcases, such as not using volatile >>> and not >>> creating new typedefs. >>> >> >> Daren, >> >> This patch series is good. kselftest run and install >> are good. I see the following results. Something you >> would expect?? > > Yes, that is all expected behavior if you don't run as root and your user > doesn't have the necessary capabilities added - similar to other tests > with privileged operations. > >> No Issues and I am going to get them >> into 4.2 - should show up in linux-kselftest next. > > Great, thanks. Perhaps some explicit capabilities tests and clearer error > messages would make sense as a follow-on patch. > > Thanks for working with me to get these into the kernel, I think it will > improve futex test exposure and hopefully encourage people to write more > tests to fill some of the gaps. > Applied to linux-kselftest next for 4.2 thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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/3] A few small fixups to the alarmtimer-suspend test
On 05/13/2015 05:16 PM, John Stultz wrote: > On Wed, May 13, 2015 at 4:04 PM, Shuah Khan wrote: >> On 05/13/2015 04:13 PM, John Stultz wrote: >>> Hey Shuah, >>> Wanted to send along a few small fixups to the alarmtimer-suspend >>> test that I had pending. >>> >>> Let me know if you have any objections or feedback. >>> >> >> Hi John, >> >> No issues with these. We are tweaking sleep and suspend >> times. The nature of the beast I am guessing. I gave it >> test run and looks good. I would like to get these into >> rc5. Patches 1 and 3 look like critical fixes to >> me. I will wait a couple of days for any reviews comments >> before I apply them to linux-kselftest fixes. > > I'd not claim any of them are actually urgent. So if you'd rather > queue these for 4.2 I'm fine with it. > Applied to linux-kselftest next for 4.2 thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] Drivers: staging: comedi: comedi: Fixed comment spelling error
On Wed, May 13, 2015 at 05:01:40PM -0700, colincronin wrote: > Fixed a spelling error in a comment. > > Signed-off-by: Colin Cronin This name doesn't match the "From:" line in your email header, please fix it up to match properly. thanks, greg k-h -- 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] pwm: samsung: Use MODULE_DEVICE_TABLE() to include OF modalias
On 14.05.2015 09:32, Javier Martinez Canillas wrote: > If the pwm-samsung driver is built as a module, modalias information is > not filled so the module is not autoloaded. Use the MODULE_DEVICE_TABLE() > macro to export the OF device ID so the module contains that information. > > Signed-off-by: Javier Martinez Canillas Reviewed-by: Krzysztof Kozlowski I think many other Maxim/S[25]M drivers for Samsung boards may also be affected... Probably they should also be updated. 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: [PATCH 2/2] Drivers: staging: skein: skein_api: Fixed spelling errors
On Wed, May 13, 2015 at 05:03:04PM -0700, colincronin wrote: > Fixed a few spelling errors in comments. > > Signed-off-by: Colin Cronin > --- > drivers/staging/skein/skein_api.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Same problem with the From: line. Can you fix your email client and try this again? thanks, greg k-h -- 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 03/18] f2fs crypto: declare some definitions for f2fs encryption feature
On Tue, May 12, 2015 at 11:48:02PM -0700, Jaegeuk Kim wrote: > On Wed, May 13, 2015 at 12:02:08PM +1000, Dave Chinner wrote: > > On Fri, May 08, 2015 at 09:20:38PM -0700, Jaegeuk Kim wrote: > > > This definitions will be used by inode and superblock for encyption. > > > > How much of this crypto stuff is common with or only slightly > > modified from the ext4 code? Is the behaviour and features the > > same? Is the user API and management tools the same? > > > > IMO, if there is any amount of overlap, then we should be > > implementing this stuff as generic code, not propagating the same > > code through multiple filesystems via copy-n-paste-n-modify. This > > will simply end up with diverging code, different bugs and feature > > sets, and none of the implementations will get the review and > > maintenance they really require... > > > > And, FWIW, this is the reason why I originally asked for the ext4 > > encryption code to be pulled up to the VFS: precisely so we didn't > > end up with a rapid proliferation of individual in-filesystem > > encryption implementations that are all slightly different... > > Totally agreed! > > AFAIK, Ted wants to push the codes as a crypto library into fs/ finally, so > I believe most part of crypto codes are common. Can I suggest fs/crypto/ if there are going to be multiple files? > But, in order to realize that quickly, Ted implemented the feature to finalize > on-disk and in-memory design in EXT4 as a first step. > Then, I've been catching up and validating its design by implementing it in > F2FS, which also intends to figure out what crypto codes can be exactly > common. Excellent. That will make it easier and less error prone for other filesystems to implement it, too! > As Ted mentioned before, since next android version tries to use per-file > encryption, F2FS also needs to support it as quick as possible likewise EXT4. Fair enough. > Meanwhile, surely I've been working on writing patches to push them into fs/; > currenlty, I did for cryto.c and will do for crypto_key.c and crypto_fname.c. > But, it needs to think about crypto_policy.c differently, since it may depend > on how each filesystem stores the policy information respectively; we cannot > push all the filesystems should use xattrs, right? All filesystems likely to implement per-file crypto support xattrs, and this is exactly what xattrs are designed for. e.g. we already require xattrs for generic security labels, ACLs, etc. Hence per-file crypto information should also use a common, shared xattr format. That way it only needs to be implemented once in the generic code and there's very little (hopefully nothing!) each filesystem has to customise to store the crypto information for each file. Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [PATCH v3 09/10] KVM: MMU: fix MTRR update
On Wed, May 13, 2015 at 04:10:08PM +0200, Paolo Bonzini wrote: > > >On 13/05/2015 10:43, Wanpeng Li wrote: >> kvm_mmu_reset_context >> kvm_mmu_unload >> mmu_free_roots >> >> The original root shadow page will be freed in mmu_free_roots, where I >> miss? >> >> Another question maybe not related to this patch: >> >> If kvm_mmu_reset_context is just called to destroy the original root >> shadow page and all the sptes will remain valid? > >SPTEs are kept around and cached. The "role" field is used as the hash >key; if the role doesn't change, SPTEs are reused, so you have to zap >the SPTEs explicitly. Thanks for your explanation. :) Btw, why the patch changelog mentioned that the root shadow page will be reused, I think it will be zapped in mmu_free_roots. Regards, Wanpeng Li > >Paolo -- 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] pwm: samsung: Use MODULE_DEVICE_TABLE() to include OF modalias
If the pwm-samsung driver is built as a module, modalias information is
not filled so the module is not autoloaded. Use the MODULE_DEVICE_TABLE()
macro to export the OF device ID so the module contains that information.
Signed-off-by: Javier Martinez Canillas
---
drivers/pwm/pwm-samsung.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index ff201e1b9219..ada2d326dc3e 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -456,6 +456,7 @@ static const struct of_device_id samsung_pwm_matches[] = {
{ .compatible = "samsung,exynos4210-pwm", .data = _variant },
{},
};
+MODULE_DEVICE_TABLE(of, samsung_pwm_matches);
static int pwm_samsung_parse_dt(struct samsung_pwm_chip *chip)
{
--
2.1.4
--
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: kernel >= 4.0: crashes when using traceroute6 with isatap
Am Dienstag, 12. Mai 2015, 16:18:54 schrieb Vlad Yasevich: > On 05/06/2015 06:11 PM, Wolfgang Walter wrote: > > Am Mittwoch, 6. Mai 2015, 11:15:18 schrieben Sie: > >> (Cc'ing netdev.) > >> > >> On Sat, May 2, 2015 at 5:29 AM, Wolfgang Walter wrote: > >>> Am Samstag, 2. Mai 2015, 02:16:36 schrieb Wolfgang Walter: > Hello, > > kernel 4.0 (and 4.0.1) crashes immediately when I use traceroute6 with > an > isatap-tunnel. > >>> > >>> I did some further tests. To trigger the crash you need > >>> > >>> * isatap-tunnel (probably any sit-tunnel will do it) > >>> * raw-socket > >>> * udp > >>> > >>> Using icmpv6 or tcp i.e. does not trigger it. > >> > >> Do you have a script to reproduce it? > >> > >> > >> Thanks for the bug report! > > > > You need a isatap-server with say ipv4-address $X > > > > Then, on host with 4.0, start isatapd: isatapd --mtu 1280 $X > > > > then do > > > > traceroute6 www.google.de > > > > Regards, > > Hi Walter > > Could you try this patch. Looks like raw passes transhdrlen > of 0 on the first packet and that makes IPv4 behave correctly, > but not IPv6. > > > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > index 7fde1f2..fd9c079 100644 > --- a/net/ipv6/ip6_output.c > +++ b/net/ipv6/ip6_output.c > @@ -1278,7 +1278,7 @@ emsgsize: > /* If this is the first and only packet and device >* supports checksum offloading, let's use it. >*/ > - if (!skb && sk->sk_protocol == IPPROTO_UDP && > + if (transhdrlen && sk->sk_protocol == IPPROTO_UDP && > length + fragheaderlen < mtu && > rt->dst.dev->features & NETIF_F_V6_CSUM && > !exthdrlen) Ok, that works as fix. No crash and checksums are ok. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- 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: [RFC v2 6/6] firmware: add firmware signature checking support
Hi Luis, On Thu, May 14, 2015 at 4:23 AM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Systems that have module signing currently enabled may > wish to extend vetting of firmware passed to the kernel > as well. We can re-use most of the code for module signing > for firmware signature verification and signing. This will > also later enable re-use of this same code for subsystems > that wish to provide their own cryptographic verification > mechanisms on userspace data needed. > > As with module signing, we do a very simple search for a > particular string appended to the firmware. There's both a > config option and a boot parameter which control whether we > accept or fail with unsigned firmware and firmware that are > signed with an unknown key. > > If firmware signing is enabled, the kernel will be tainted > if a firmware is loaded that is unsigned or has a signature > for which we don't have the key. > > Cc: Rusty Russell > Cc: David Howells > Cc: Ming Lei > Cc: Seth Forshee > Cc: Kyle McMartin > Signed-off-by: Luis R. Rodriguez > --- > Documentation/firmware_class/signing.txt | 88 + > drivers/base/Kconfig | 18 ++ > drivers/base/firmware_class.c | 214 > - > .../sysdata-internal.h => include/linux/sysdata.h | 0 > kernel/module.c| 2 +- > kernel/sysdata_signing.c | 3 +- > kernel/system_keyring.c| 2 +- > 7 files changed, 317 insertions(+), 10 deletions(-) > create mode 100644 Documentation/firmware_class/signing.txt > rename kernel/sysdata-internal.h => include/linux/sysdata.h (100%) > > diff --git a/Documentation/firmware_class/signing.txt > b/Documentation/firmware_class/signing.txt > new file mode 100644 > index 000..6e1ce3c > --- /dev/null > +++ b/Documentation/firmware_class/signing.txt > @@ -0,0 +1,88 @@ > + > + KERNEL FIRMWARE SIGNING FACILITY > + > + > +CONTENTS > + > + - Overview. > + - Configuring firmware signing. > + - Using signing keys. > + - Signing firmware files. > + > + > + > +OVERVIEW > + > + > +Device drivers which require a firmware to be uploaded onto a device as its > own > +device's microcode use any of the following APIs: > + > + * request_firmware() > + * request_firmware_direct() > + * request_firmware_nowait() > + > +The kernel firmware signing facility enables to cryptographically sign > +firmware files on a system using the same keys used for module signing. > +Firmware files's signatures consist of PKCS#7 messages of the respective > +firmware file. A firmware file named foo.bin, would have its respective > +signature on the filesystem as foo.bin.pkcs7. When firmware signature > +checking is enabled (FIRMWARE_SIG) when one of the above APIs is used > +against foo.bin, the file foo.bin.pkcs7 will also be looked for. If > +FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to > +be returned to callers of the above APIs if and only if the foo.bin.pkcs7 > +file is confirmed to be a valid signature of the foo.bin file. If > +FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the > +kernel will be permissive and enabled unsiged firmware files, or firmware > +files with incorrect signatures. If FIRMWARE_SIG is not enabled the > +signature file is ignored completely. > + > +Firmware signing increases security by making it harder to load a malicious > +firmware into the kernel. The firmware signature checking is done by the > +kernel so that it is not necessary to have trusted userspace bits. > + > + > +CONFIGURING FIRMWARE SIGNING > + > + > +The firmware signing facility is enabled by going to the section: > + > +-> Device Drivers > + -> Generic Driver Options > +-> Userspace firmware loading support (FW_LOADER [=y]) > + -> Firmware signature verification (FIRMWARE_SIG [=y]) > + > +If you want to not allow unsigned firmware to be loaded you should > +enable: > + > +"Require all firmware to be validly signed", under the same menu. You reference the relevant Kconfig symbols above, do you want to add it here too? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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/3] cpuidle: updates related to tick_broadcast_enter() failures
"Rafael J. Wysocki" writes: > On Wednesday, May 13, 2015 05:13:27 PM Kevin Hilman wrote: >> On Wed, May 13, 2015 at 5:16 PM, Rafael J. Wysocki >> wrote: >> > On Wednesday, May 13, 2015 03:59:55 PM Kevin Hilman wrote: >> >> "Rafael J. Wysocki" writes: >> >> >> >> [...] >> >> >> >> > Second, quite honestly, I don't see a connection to genpd here. >> >> >> >> The connection with genpd is because the *reason* the timer was >> >> shutdown/stopped is because it shares power with the CPU, which is why >> >> the timer stops when the CPU hits ceratin low power states. IOW, it's >> >> in the same power domain as the CPU. >> > >> > Well, what if you don't have genpd on that system? Is the problem at hand >> > not >> > relevant then magically? >> >> Well, if you're not using genpd to model hardware power domain >> dependencies, then yes you'll definitely need a different solution. >> >> And, as we discussed on IRC. If you only care about timers, and genpd >> is not in use, then $SUBJECT series is a fine approach, and I have no >> objections. But for SoCs where there are several other things that >> share power with CPU, we need a more generic, genpd based solution, >> which it seems we're in agreement on. And since the two approaches >> are not mutually exclusive, then I have real objections to applying >> this series. > > I guess a "no" is missing in the last sentence. ;-) Correct. I have *no* real objections to applying this series. 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 v5 18/21] clk: tegra: pll: Fix _pll_ramp_calc_pll logic and _calc_dynamic_ramp_rate
On Tue, May 12, 2015 at 10:24 AM, Rhyland Klein wrote: > This removes the conversion from pdiv to hw, which is already taken > care of by _get_table_rate before this code is run. This avoids > incorrectly converting pdiv to hw twice and getting the wrong hw value. > > Also set the input_rate in the freq cfg in _calc_dynamic_ramp_rate while > setting all the other fields. > > Signed-off-by: Rhyland Klein Reviewed-by: Benson Leung -- Benson Leung Software Engineer, Chrom* OS ble...@chromium.org -- 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 tip/core/rcu 15/24] rcu: Directly drive RCU_USER_QS from Kconfig
On Wed, May 13, 2015 at 10:45:05AM -0700, Paul E. McKenney wrote:
> On Wed, May 13, 2015 at 02:37:52AM +0200, Frederic Weisbecker wrote:
> > On Tue, May 12, 2015 at 03:30:45PM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Currently, Kconfig will ask the user whether RCU_USER_QS should be set.
> > > This is silly because Kconfig already has all the information that it
> > > needs to set this parameter. This commit therefore directly drives
> > > the value of RCU_USER_QS via NO_HZ_FULL's "select" statement.
> > >
> > > Reported-by: Ingo Molnar
> > > Signed-off-by: Paul E. McKenney
> > > Cc: Frederic Weisbecker
> >
> > ACK. And we should remove it completely and use NO_HZ_FULL instead.
> > There won't seem to be more users.
>
> Good point! I have queued the patch shown below for 4.3.
>
> Thanx, Paul
>
>
>
> rcu: Drop RCU_USER_QS in favor of NO_HZ_FULL
>
> The RCU_USER_QS Kconfig parameter is now just a synonym for NO_HZ_FULL,
> so this commit eliminates RCU_USER_QS, replacing all uses with NO_HZ_FULL.
>
> Reported-by: Frederic Weisbecker
> Signed-off-by: Paul E. McKenney
Excellent! ACK+!
Thanks.
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 03a899aabd17..18e377b92875 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -307,7 +307,7 @@ static inline void rcu_sysrq_end(void)
> }
> #endif /* #else #ifdef CONFIG_RCU_STALL_COMMON */
>
> -#ifdef CONFIG_RCU_USER_QS
> +#ifdef CONFIG_NO_HZ_FULL
> void rcu_user_enter(void);
> void rcu_user_exit(void);
> #else
> @@ -315,7 +315,7 @@ static inline void rcu_user_enter(void) { }
> static inline void rcu_user_exit(void) { }
> static inline void rcu_user_hooks_switch(struct task_struct *prev,
>struct task_struct *next) { }
> -#endif /* CONFIG_RCU_USER_QS */
> +#endif /* CONFIG_NO_HZ_FULL */
>
> #ifdef CONFIG_RCU_NOCB_CPU
> void rcu_init_nohz(void);
> diff --git a/init/Kconfig b/init/Kconfig
> index 4c08197044f1..5b8726c10685 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -537,15 +537,6 @@ config RCU_STALL_COMMON
> config CONTEXT_TRACKING
> bool
>
> -config RCU_USER_QS
> - bool
> - help
> - This option sets hooks on kernel / userspace boundaries and
> - puts RCU in extended quiescent state when the CPU runs in
> - userspace. It means that when a CPU runs in userspace, it is
> - excluded from the global RCU state machine and thus doesn't
> - try to keep the timer tick on for RCU.
> -
> config CONTEXT_TRACKING_FORCE
> bool "Force context tracking"
> depends on CONTEXT_TRACKING
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 7651d7dd982c..012cbee9d354 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -696,7 +696,7 @@ void rcu_idle_enter(void)
> }
> EXPORT_SYMBOL_GPL(rcu_idle_enter);
>
> -#ifdef CONFIG_RCU_USER_QS
> +#ifdef CONFIG_NO_HZ_FULL
> /**
> * rcu_user_enter - inform RCU that we are resuming userspace.
> *
> @@ -709,7 +709,7 @@ void rcu_user_enter(void)
> {
> rcu_eqs_enter(1);
> }
> -#endif /* CONFIG_RCU_USER_QS */
> +#endif /* CONFIG_NO_HZ_FULL */
>
> /**
> * rcu_irq_exit - inform RCU that current CPU is exiting irq towards idle
> @@ -823,7 +823,7 @@ void rcu_idle_exit(void)
> }
> EXPORT_SYMBOL_GPL(rcu_idle_exit);
>
> -#ifdef CONFIG_RCU_USER_QS
> +#ifdef CONFIG_NO_HZ_FULL
> /**
> * rcu_user_exit - inform RCU that we are exiting userspace.
> *
> @@ -834,7 +834,7 @@ void rcu_user_exit(void)
> {
> rcu_eqs_exit(1);
> }
> -#endif /* CONFIG_RCU_USER_QS */
> +#endif /* CONFIG_NO_HZ_FULL */
>
> /**
> * rcu_irq_enter - inform RCU that current CPU is entering irq away from idle
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 579ce1b929af..4008d9f95dd7 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -92,12 +92,10 @@ config NO_HZ_FULL
> depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
> # We need at least one periodic CPU for timekeeping
> depends on SMP
> - # RCU_USER_QS dependency
> depends on HAVE_CONTEXT_TRACKING
> # VIRT_CPU_ACCOUNTING_GEN dependency
> depends on HAVE_VIRT_CPU_ACCOUNTING_GEN
> select NO_HZ_COMMON
> - select RCU_USER_QS
> select RCU_NOCB_CPU
> select VIRT_CPU_ACCOUNTING_GEN
> select IRQ_WORK
>
--
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-next: Tree for May 13 (avr32 build error due to switchdev patch)
On Wed, May 13, 2015 at 06:09:27PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150512:
>
> New tree: h8300
>
> The net-next tree gained a conflict against the net tree.
>
> The security tree gained conflicts against the vfs tree.
>
> The spi tree lost its build failure.
>
> The target-updates tree still had its build failure so I used the version
> from next-20150511.
>
> The gpio tree gained a build failure so I used the version from
> next-20150512.
>
> Non-merge commits (relative to Linus' tree): 3825
> 3592 files changed, 173394 insertions(+), 76013 deletions(-)
>
>
>
avr32:defconfig:
net/bridge/br_stp.c: In function 'br_set_state':
net/bridge/br_stp.c:44: error: unknown field 'stp_state' specified in
initializer
The problem is most likely that the variable is part of an unnamed union, and
it looks like gcc 4.2.4 doesn't understand that. avr32 is not supported by more
recent versions of gcc, so I can not update the toolchain to work around the
problem.
Introduced by commit 3563606258cf3 ("switchdev: convert STP update to switchdev
attr set").
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/
Re: [PATCH kernel v10 14/34] powerpc/iommu: Move tce_xxx callbacks from ppc_md to iommu_table
On Tue, May 12, 2015 at 01:39:03AM +1000, Alexey Kardashevskiy wrote:
>This adds a iommu_table_ops struct and puts pointer to it into
>the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
>callbacks from ppc_md to the new struct where they really belong to.
>
>This adds the requirement for @it_ops to be initialized before calling
>iommu_init_table() to make sure that we do not leave any IOMMU table
>with iommu_table_ops uninitialized. This is not a parameter of
>iommu_init_table() though as there will be cases when iommu_init_table()
>will not be called on TCE tables, for example - VFIO.
>
>This does s/tce_build/set/, s/tce_free/clear/ and removes "tce_"
>redundand prefixes.
>
s/redundand/redundant I might be wrong because of my bad English.
>This removes tce_xxx_rm handlers from ppc_md but does not add
>them to iommu_table_ops as this will be done later if we decide to
>support TCE hypercalls in real mode. This removes _vm callbacks as
>only virtual mode is supported by now so this also removes @rm parameter.
>
>For pSeries, this always uses tce_buildmulti_pSeriesLP/
>tce_buildmulti_pSeriesLP. This changes multi callback to fall back to
>tce_build_pSeriesLP/tce_free_pSeriesLP if FW_FEATURE_MULTITCE is not
>present. The reason for this is we still have to support "multitce=off"
>boot parameter in disable_multitce() and we do not want to walk through
>all IOMMU tables in the system and replace "multi" callbacks with single
>ones.
>
>For powernv, this defines _ops per PHB type which are P5IOC2/IODA1/IODA2.
>This makes the callbacks for them public. Later patches will extend
>callbacks for IODA1/2.
>
>No change in behaviour is expected.
>
>Signed-off-by: Alexey Kardashevskiy
>Reviewed-by: David Gibson
Reviewed-by: Gavin Shan
>---
>Changes:
>v9:
>* pnv_tce_build/pnv_tce_free/pnv_tce_get have been made public and lost
>"rm" parameters to make following patches simpler (realmode is not
>supported here anyway)
>* got rid of _vm versions of callbacks
>---
> arch/powerpc/include/asm/iommu.h| 17 +++
> arch/powerpc/include/asm/machdep.h | 25 ---
> arch/powerpc/kernel/iommu.c | 46 ++--
> arch/powerpc/kernel/vio.c | 5 +++
> arch/powerpc/platforms/cell/iommu.c | 8 +++--
> arch/powerpc/platforms/pasemi/iommu.c | 7 +++--
> arch/powerpc/platforms/powernv/pci-ioda.c | 14 +
> arch/powerpc/platforms/powernv/pci-p5ioc2.c | 7 +
> arch/powerpc/platforms/powernv/pci.c| 47 +
> arch/powerpc/platforms/powernv/pci.h| 5 +++
> arch/powerpc/platforms/pseries/iommu.c | 34 -
> arch/powerpc/sysdev/dart_iommu.c| 12 +---
> 12 files changed, 116 insertions(+), 111 deletions(-)
>
>diff --git a/arch/powerpc/include/asm/iommu.h
>b/arch/powerpc/include/asm/iommu.h
>index d91bd69..e2a45c3 100644
>--- a/arch/powerpc/include/asm/iommu.h
>+++ b/arch/powerpc/include/asm/iommu.h
>@@ -44,6 +44,22 @@
> extern int iommu_is_off;
> extern int iommu_force_on;
>
>+struct iommu_table_ops {
>+ int (*set)(struct iommu_table *tbl,
>+ long index, long npages,
>+ unsigned long uaddr,
>+ enum dma_data_direction direction,
>+ struct dma_attrs *attrs);
>+ void (*clear)(struct iommu_table *tbl,
>+ long index, long npages);
>+ unsigned long (*get)(struct iommu_table *tbl, long index);
>+ void (*flush)(struct iommu_table *tbl);
Currently, there isn't flush backend on PowerNV platform. I'm not sure
if we have to implement it for PowerNV if we really need it. Maybe you
will have it to support DDW in subsequent patches which I didn't look
into it, but I will :-)
>+};
>+
>+/* These are used by VIO */
>+extern struct iommu_table_ops iommu_table_lpar_multi_ops;
>+extern struct iommu_table_ops iommu_table_pseries_ops;
>+
It might be reasonable to add "struct iommu_table_ops *ops" to function
vio_register_device_node() where the specified "ops" can be hooked to
the newly created IOMMU table. In that way, the platform (pSeries) specific
IOMMU table operations doesn't have to be exposed to PowerPC subsystem.
Thanks,
Gavin
> /*
> * IOMAP_MAX_ORDER defines the largest contiguous block
> * of dma space we can get. IOMAP_MAX_ORDER = 13
>@@ -78,6 +94,7 @@ struct iommu_table {
> #ifdef CONFIG_IOMMU_API
> struct iommu_group *it_group;
> #endif
>+ struct iommu_table_ops *it_ops;
> void (*set_bypass)(struct iommu_table *tbl, bool enable);
> #ifdef CONFIG_PPC_POWERNV
> void *data;
>diff --git a/arch/powerpc/include/asm/machdep.h
>b/arch/powerpc/include/asm/machdep.h
>index ef889943..ab721b4 100644
>--- a/arch/powerpc/include/asm/machdep.h
>+++ b/arch/powerpc/include/asm/machdep.h
>@@ -65,31 +65,6 @@ struct machdep_calls {
>* destroyed as well */
> void
Re: [PATCH v5 17/21] clk: tegra: pll: Add logic for SS
On Tue, May 12, 2015 at 10:24 AM, Rhyland Klein wrote:
> +static void pll_clk_start_ss(struct tegra_clk_pll *pll)
> +{
> + if (pll->params->defaults_set && pll->params->ssc_ctrl_en_mask) {
Is there any reason you're checking for the existence of
ssc_ctrl_en_mask rather than ssc_ctrl_reg?
> + u32 val = pll_readl(pll->params->ssc_ctrl_reg, pll);
> +
> + val |= pll->params->ssc_ctrl_en_mask;
> + pll_writel(val, pll->params->ssc_ctrl_reg, pll);
> + }
> +}
> +
> +static void pll_clk_stop_ss(struct tegra_clk_pll *pll)
> +{
> + if (pll->params->defaults_set && pll->params->ssc_ctrl_en_mask) {
> + u32 val = pll_readl(pll->params->ssc_ctrl_reg, pll);
> +
> + val &= ~pll->params->ssc_ctrl_en_mask;
> + pll_writel(val, pll->params->ssc_ctrl_reg, pll);
> + }
> +}
> +
--
Benson Leung
Software Engineer, Chrom* OS
ble...@chromium.org
--
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/
