ammini
ATTENZIONE; La cassetta postale ha superato il limite di archiviazione, che è 5 GB come definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti informazioni qui di seguito: nome: Nome utente: Password: Conferma Password: E-mail: telefono: Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi posta sarà disabilitato! Ci dispiace per l'inconvenienza. Codice di verifica: en:0085362LK.ft6789000.2017 Mail Technical Support ©2017 grazie Sistemi amministratore
Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS
On Thursday 13 April 2017 12:22 PM, Bhupesh Sharma wrote: Hi Aneesh, On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V wrote: Bhupesh Sharma writes: powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset for the mmap base address for a ASLR ELF. This patch makes sure that powerpc mmap arch_mmap_rnd() implementation is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits and helpers to generate the mmap address randomization. The maximum and minimum randomization range values represent a compromise between increased ASLR effectiveness and avoiding address-space fragmentation. Using the Kconfig option and suitable /proc tunable, platform developers may choose where to place this compromise. Also this patch keeps the default values as new minimums. Signed-off-by: Bhupesh Sharma Reviewed-by: Kees Cook --- * Changes since v2: v2 can be seen here (https://patchwork.kernel.org/patch/9551509/) - Changed a few minimum and maximum randomization ranges as per Michael's suggestion. - Corrected Kees's email address in the Reviewed-by line. - Added further comments in kconfig to explain how the address ranges were worked out. * Changes since v1: v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html) - No functional change in this patch. - Dropped PATCH 2/2 from v1 as recommended by Kees Cook. arch/powerpc/Kconfig | 44 arch/powerpc/mm/mmap.c | 7 --- 2 files changed, 48 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 97a8bc8..84aae67 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -22,6 +22,48 @@ config MMU bool default y +# min bits determined by the following formula: +# VA_BITS - PAGE_SHIFT - CONSTANT +# where, +#VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT Where did we derive that 46 bits from ? is that based on TASK_SIZE ? Yes. It was derived from TASK_SIZE : http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105 That is getting update to 128TB by default and conditionally to 512TB -aneesh
Re: [PATCH v5 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
On 12.04.2017 18:53, Peter Rosin wrote: On 2017-04-12 10:26, Linus Walleij wrote: On Tue, Apr 11, 2017 at 2:16 PM, wrote: From: Michael Hennerich This patch adds support for the Analog Devices / Linear Technology LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches. The LTC4306 optionally provides two general purpose input/output pins (GPIOs) that can be configured as logic inputs, opendrain outputs or push-pull outputs via the generic GPIOLIB framework. Great, thanks for your contribution Michael! Both patches pushed to the for-next branch of the i2c-mux tree. Signed-off-by: Michael Hennerich (...) Changes since v4: Reviewed-by: Linus Walleij Please go ahead and merge to the i2c tree if you like. Yup, thanks for the review! (But not merged directly to the i2c tree, although they will get there eventually...) Cheers, peda Peter and Linus, Thanks for your precious time - really appreciated! -- Greetings, Michael -- Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München Sitz der Gesellschaft München, Registergericht München HRB 40368, Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
Re: [PATCH 2/3] powernv:idle: Decouple TB restore & Per-core SPRs restore
On Wed, 2017-04-12 at 17:16 +0530, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > The idle-exit code assumes that if Timebase is not lost, then neither > are the per-core hypervisor resources lost. Double negative! How about: The idle-exit code assumes that if the timebase is restored, then the per-core hypervisor resources are also restored. > This was true on POWER8 > where fast-sleep lost only TB but not per-core resources, and winkle > lost both. > > This assumption is not true for POWER9 however, since there can be > states which do not lose timebase but can lose per-core SPRs. > > Hence check if we need to restore the per-core hypervisor state even > if timebase is not lost. I think I understand what you're doing, just seems awkwardly worded. Is this actually what the patch is doing? It seem to be just changing one branch. Mikey > > Signed-off-by: Gautham R. Shenoy > --- > arch/powerpc/kernel/idle_book3s.S | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/kernel/idle_book3s.S > b/arch/powerpc/kernel/idle_book3s.S > index 9b747e9..6a9bd28 100644 > --- a/arch/powerpc/kernel/idle_book3s.S > +++ b/arch/powerpc/kernel/idle_book3s.S > @@ -723,13 +723,14 @@ timebase_resync: > * Use cr3 which indicates that we are waking up with atleast partial > * hypervisor state loss to determine if TIMEBASE RESYNC is needed. > */ > - ble cr3,clear_lock > + ble cr3,.Ltb_resynced > /* Time base re-sync */ > bl opal_resync_timebase; > /* > - * If waking up from sleep, per core state is not lost, skip to > - * clear_lock. > + * If waking up from sleep (POWER8), per core state > + * is not lost, skip to clear_lock. > */ > +.Ltb_resynced: > blt cr4,clear_lock > > /*
Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS
Hi Aneesh, On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V wrote: > Bhupesh Sharma writes: > >> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) >> for >> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset >> for the mmap base address for a ASLR ELF. >> >> This patch makes sure that powerpc mmap arch_mmap_rnd() implementation >> is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits >> and helpers to generate the mmap address randomization. >> >> The maximum and minimum randomization range values represent >> a compromise between increased ASLR effectiveness and avoiding >> address-space fragmentation. >> >> Using the Kconfig option and suitable /proc tunable, platform >> developers may choose where to place this compromise. >> >> Also this patch keeps the default values as new minimums. >> >> Signed-off-by: Bhupesh Sharma >> Reviewed-by: Kees Cook >> --- >> * Changes since v2: >> v2 can be seen here (https://patchwork.kernel.org/patch/9551509/) >> - Changed a few minimum and maximum randomization ranges as per >> Michael's suggestion. >> - Corrected Kees's email address in the Reviewed-by line. >> - Added further comments in kconfig to explain how the address ranges >> were worked out. >> >> * Changes since v1: >> v1 can be seen here >> (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html) >> - No functional change in this patch. >> - Dropped PATCH 2/2 from v1 as recommended by Kees Cook. >> >> arch/powerpc/Kconfig | 44 >> arch/powerpc/mm/mmap.c | 7 --- >> 2 files changed, 48 insertions(+), 3 deletions(-) >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 97a8bc8..84aae67 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -22,6 +22,48 @@ config MMU >> bool >> default y >> >> +# min bits determined by the following formula: >> +# VA_BITS - PAGE_SHIFT - CONSTANT >> +# where, >> +#VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT > > > Where did we derive that 46 bits from ? is that based on TASK_SIZE ? Yes. It was derived from TASK_SIZE : http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105 Regards, Bhupesh > >> +#CONSTANT = 16 for 64BIT and 8 for 32BIT >> +config ARCH_MMAP_RND_BITS_MIN >> + default 5 if PPC_256K_PAGES && 32BIT # 31 - 18 - 8 = 5 >> + default 7 if PPC_64K_PAGES && 32BIT # 31 - 16 - 8 = 7 >> + default 9 if PPC_16K_PAGES && 32BIT # 31 - 14 - 8 = 9 >> + default 11 if PPC_4K_PAGES && 32BIT # 31 - 12 - 8 = 11 >> + default 12 if PPC_256K_PAGES && 64BIT # 46 - 18 - 16 = 12 >> + default 14 if PPC_64K_PAGES && 64BIT # 46 - 16 - 16 = 14 >> + default 16 if PPC_16K_PAGES && 64BIT # 46 - 14 - 16 = 16 >> + default 18 if PPC_4K_PAGES && 64BIT # 46 - 12 - 16 = 18 >> + >> +# max bits determined by the following formula: > > > -aneesh >
Re: [PATCH 0/6] fujitsu-laptop: LED cleanup
On Fri, Apr 07, 2017 at 03:07:07PM +0200, Micha?? K??pie?? wrote: > This patch series cleans up parts of fujitsu-laptop responsible for > handling LED class devices. It was tested on a Lifebook E744. It > depends on the previous patch series I submitted for fujitsu-laptop and > should be applied on top of the backlight cleanup series. > > drivers/platform/x86/Kconfig | 2 +- > drivers/platform/x86/fujitsu-laptop.c | 402 > +++--- > 2 files changed, 176 insertions(+), 228 deletions(-) FYI I should be able to complete my review of this series over the Easter weekend. This week has been hectic to say the least. Apologies for the delay. Regards jonathan
Re: [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
Reviewed-by: Wu-Cheng Li
On Thu, Apr 13, 2017 at 12:18 PM, Minghsiu Tsai
wrote:
> From: Daniel Kurtz
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Minghsiu Tsai
>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 13afe48..8ab7ca0 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file,
> void *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (mtk_mdp_is_target_compose(s->target))
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (mtk_mdp_is_target_crop(s->target))
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (mtk_mdp_is_target_compose(s->target))
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file,
> void *fh,
> int ret;
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (s->target == V4L2_SEL_TGT_COMPOSE)
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (s->target == V4L2_SEL_TGT_CROP)
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (s->target == V4L2_SEL_TGT_COMPOSE)
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file,
> void *fh,
> if (ret)
> return ret;
>
> - if (mtk_mdp_is_target_crop(s->target))
> + if (mtk_mdp_is_target_compose(s->target))
> frame = &ctx->s_frame;
> else
> frame = &ctx->d_frame;
> --
> 1.9.1
>
[PATCH] dma-debug: Make locking to work for RT
Interrupt enable/disabled with spinlock is not a valid
implementation for RT as it can make executing task to
sleep from a non-sleepable context. So, converting it
to spin_lock_irq[save, restore].
Signed-off-by: Pankaj Gupta
---
lib/dma-debug.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index b157b46..fe4d50c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -942,21 +942,17 @@ static int device_dma_allocations(struct device *dev,
struct dma_debug_entry **o
unsigned long flags;
int count = 0, i;
- local_irq_save(flags);
-
for (i = 0; i < HASH_SIZE; ++i) {
- spin_lock(&dma_entry_hash[i].lock);
+ spin_lock_irqsave(&dma_entry_hash[i].lock, flags);
list_for_each_entry(entry, &dma_entry_hash[i].list, list) {
if (entry->dev == dev) {
count += 1;
*out_entry = entry;
}
}
- spin_unlock(&dma_entry_hash[i].lock);
+ spin_unlock_irqrestore(&dma_entry_hash[i].lock, flags);
}
- local_irq_restore(flags);
-
return count;
}
--
2.7.4
Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020
On 2017-04-12 17:40, Dmitry Torokhov wrote:
> Hi Martin,
>
> On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote:
>> ar1021_i2c simply also supports the ar1020 device we use. This is tested.
>> They also share the same datasheet:
>>
>>http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf
>>
>> We differentiate not only to make it obvious that we support both devices,
>> but also to be able to implement the few model specific things in the
>> future.
>>
>> Signed-off-by: Martin Kepplinger
>> ---
>> drivers/input/touchscreen/Kconfig | 4 ++--
>> drivers/input/touchscreen/ar1021_i2c.c | 13 ++---
>> 2 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/Kconfig
>> b/drivers/input/touchscreen/Kconfig
>> index 33c62e5..535b91a 100644
>> --- a/drivers/input/touchscreen/Kconfig
>> +++ b/drivers/input/touchscreen/Kconfig
>> @@ -96,8 +96,8 @@ config TOUCHSCREEN_AR1021_I2C
>> tristate "Microchip AR1021 i2c touchscreen"
>> depends on I2C && OF
>> help
>> - Say Y here if you have the Microchip AR1021 touchscreen controller
>> - chip in your system.
>> + Say Y here if you have the Microchip AR1020 or AR1021 touchscreen
>> + controller chip in your system.
>>
>>If unsure, say N.
>>
>> diff --git a/drivers/input/touchscreen/ar1021_i2c.c
>> b/drivers/input/touchscreen/ar1021_i2c.c
>> index 6562b17..1767257 100644
>> --- a/drivers/input/touchscreen/ar1021_i2c.c
>> +++ b/drivers/input/touchscreen/ar1021_i2c.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Microchip AR1021 driver for I2C
>> + * Microchip AR1020 and AR1021 driver for I2C
>> *
>> * Author: Christian Gmeiner
>> *
>> @@ -24,6 +24,11 @@ struct ar1021_i2c {
>> u8 data[AR1021_TOCUH_PKG_SIZE];
>> };
>>
>> +enum {
>> +ar1021,
>> +ar1020,
>> +};
>> +
>> static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
>> {
>> struct ar1021_i2c *ar1021 = dev_id;
>> @@ -151,13 +156,15 @@ static int __maybe_unused ar1021_i2c_resume(struct
>> device *dev)
>> static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend,
>> ar1021_i2c_resume);
>>
>> static const struct i2c_device_id ar1021_i2c_id[] = {
>> -{ "MICROCHIP_AR1021_I2C", 0 },
>> +{ "MICROCHIP_AR1021_I2C", ar1021 },
>> +{ "MICROCHIP_AR1020_I2C", ar1020 },
>> { },
>> };
>> MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
>>
>> static const struct of_device_id ar1021_i2c_of_match[] = {
>> { .compatible = "microchip,ar1021-i2c", },
>> +{ .compatible = "microchip,ar1020-i2c", },
>> { }
>> };
>> MODULE_DEVICE_TABLE(of, ar1021_i2c_of_match);
>> @@ -175,5 +182,5 @@ static struct i2c_driver ar1021_i2c_driver = {
>> module_i2c_driver(ar1021_i2c_driver);
>>
>> MODULE_AUTHOR("Christian Gmeiner ");
>> -MODULE_DESCRIPTION("Microchip AR1021 I2C Driver");
>> +MODULE_DESCRIPTION("Microchip AR1020 and AR1021 I2C Driver");
>> MODULE_LICENSE("GPL");
>> --
>> 2.1.4
>>
>
> I do not see where you handle ar1020 differently from ar1021. If devices
> are compatible, you do not need to add a new compatible to the driver,
> simply use it in the binding:
>
> compatible = "microchip,ar1020-i2c", "microchip,ar1021-i2c";
>
> Thanks.
>
Why would you use "microchip,ar1020-i2c" in the dts if it's not
available? people don't obviously see, by grepping or reading,
that they have a compatible driver. ... or did I get you wrong?
I don't handle anything differently now. Factory reset has to be done
differntly though, as one example. So it'd be nice to have the option
to add data.
thanks
martin
Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS
Bhupesh Sharma writes: > powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for > 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset > for the mmap base address for a ASLR ELF. > > This patch makes sure that powerpc mmap arch_mmap_rnd() implementation > is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits > and helpers to generate the mmap address randomization. > > The maximum and minimum randomization range values represent > a compromise between increased ASLR effectiveness and avoiding > address-space fragmentation. > > Using the Kconfig option and suitable /proc tunable, platform > developers may choose where to place this compromise. > > Also this patch keeps the default values as new minimums. > > Signed-off-by: Bhupesh Sharma > Reviewed-by: Kees Cook > --- > * Changes since v2: > v2 can be seen here (https://patchwork.kernel.org/patch/9551509/) > - Changed a few minimum and maximum randomization ranges as per Michael's > suggestion. > - Corrected Kees's email address in the Reviewed-by line. > - Added further comments in kconfig to explain how the address ranges > were worked out. > > * Changes since v1: > v1 can be seen here > (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html) > - No functional change in this patch. > - Dropped PATCH 2/2 from v1 as recommended by Kees Cook. > > arch/powerpc/Kconfig | 44 > arch/powerpc/mm/mmap.c | 7 --- > 2 files changed, 48 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 97a8bc8..84aae67 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -22,6 +22,48 @@ config MMU > bool > default y > > +# min bits determined by the following formula: > +# VA_BITS - PAGE_SHIFT - CONSTANT > +# where, > +#VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT Where did we derive that 46 bits from ? is that based on TASK_SIZE ? > +#CONSTANT = 16 for 64BIT and 8 for 32BIT > +config ARCH_MMAP_RND_BITS_MIN > + default 5 if PPC_256K_PAGES && 32BIT # 31 - 18 - 8 = 5 > + default 7 if PPC_64K_PAGES && 32BIT # 31 - 16 - 8 = 7 > + default 9 if PPC_16K_PAGES && 32BIT # 31 - 14 - 8 = 9 > + default 11 if PPC_4K_PAGES && 32BIT # 31 - 12 - 8 = 11 > + default 12 if PPC_256K_PAGES && 64BIT # 46 - 18 - 16 = 12 > + default 14 if PPC_64K_PAGES && 64BIT # 46 - 16 - 16 = 14 > + default 16 if PPC_16K_PAGES && 64BIT # 46 - 14 - 16 = 16 > + default 18 if PPC_4K_PAGES && 64BIT # 46 - 12 - 16 = 18 > + > +# max bits determined by the following formula: -aneesh
Re: [PATCH 1/3] powernv:idle: Use correct IDLE_THREAD_BITS in POWER8/9
On Wed, 2017-04-12 at 17:16 +0530, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > This patch ensures that POWER8 and POWER9 processors use the correct > value of IDLE_THREAD_BITS as POWER8 has 8 threads per core and hence > the IDLE_THREAD_BITS should be 0xFF while POWER9 has only 4 threads > per core and hence the IDLE_THREAD_BITS should be 0xF. Why don't we derive this from the device tree rather than hard wiring it per cpu type? Mikey > > Signed-off-by: Gautham R. Shenoy > --- > arch/powerpc/include/asm/cpuidle.h| 3 ++- > arch/powerpc/kernel/idle_book3s.S | 9 ++--- > arch/powerpc/platforms/powernv/idle.c | 5 - > 3 files changed, 12 insertions(+), 5 deletions(-) > > diff --git a/arch/powerpc/include/asm/cpuidle.h > b/arch/powerpc/include/asm/cpuidle.h > index 52586f9..fece6ca 100644 > --- a/arch/powerpc/include/asm/cpuidle.h > +++ b/arch/powerpc/include/asm/cpuidle.h > @@ -34,7 +34,8 @@ > #define PNV_CORE_IDLE_THREAD_WINKLE_BITS_SHIFT 8 > #define PNV_CORE_IDLE_THREAD_WINKLE_BITS 0xFF00 > > -#define PNV_CORE_IDLE_THREAD_BITS 0x00FF > +#define PNV_CORE_IDLE_4THREAD_BITS 0x000F > +#define PNV_CORE_IDLE_8THREAD_BITS 0x00FF > > /* > * NOTE = > diff --git a/arch/powerpc/kernel/idle_book3s.S > b/arch/powerpc/kernel/idle_book3s.S > index 2b13fe2..9b747e9 100644 > --- a/arch/powerpc/kernel/idle_book3s.S > +++ b/arch/powerpc/kernel/idle_book3s.S > @@ -223,7 +223,7 @@ lwarx_loop1: > add r15,r15,r5 /* Add if winkle */ > andcr15,r15,r7 /* Clear thread bit */ > > - andi. r9,r15,PNV_CORE_IDLE_THREAD_BITS > + andi. r9,r15,PNV_CORE_IDLE_8THREAD_BITS > > /* > * If cr0 = 0, then current thread is the last thread of the core entering > @@ -582,8 +582,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE) > stwcx. r15,0,r14 > bne-1b > isync > - > - andi. r9,r15,PNV_CORE_IDLE_THREAD_BITS > +BEGIN_FTR_SECTION > + andi. r9,r15,PNV_CORE_IDLE_4THREAD_BITS > +FTR_SECTION_ELSE > + andi. r9,r15,PNV_CORE_IDLE_8THREAD_BITS > +ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_300) > cmpwi cr2,r9,0 > > /* > diff --git a/arch/powerpc/platforms/powernv/idle.c > b/arch/powerpc/platforms/powernv/idle.c > index 445f30a..d46920b 100644 > --- a/arch/powerpc/platforms/powernv/idle.c > +++ b/arch/powerpc/platforms/powernv/idle.c > @@ -112,7 +112,10 @@ static void pnv_alloc_idle_core_states(void) > size_t paca_ptr_array_size; > > core_idle_state = kmalloc_node(sizeof(u32), GFP_KERNEL, > node); > - *core_idle_state = PNV_CORE_IDLE_THREAD_BITS; > + if (cpu_has_feature(CPU_FTR_ARCH_300)) > + *core_idle_state = PNV_CORE_IDLE_4THREAD_BITS; > + else > + *core_idle_state = PNV_CORE_IDLE_8THREAD_BITS; > paca_ptr_array_size = (threads_per_core * > sizeof(struct paca_struct *)); >
Re: [PATCH] ALSA: line6: constify snd_kcontrol_new structures
On Wed, Apr 12, 2017 at 7:15 PM, Takashi Sakamoto
wrote:
> Hi,
>
>
> On Apr 12 2017 22:10, Bhumika Goyal wrote:
>>
>> Declare snd_kcontrol_new strcutures as const as they are only passed as
>> an argument to the function snd_ctl_new1. This argument is of type const,
>> so snd_kcontrol_new structures having this property can be made const too.
>> Done using Coccinelle:
>>
>> @r disable optional_qualifier@
>> identifier x;
>> position p;
>> @@
>> static struct snd_kcontrol_new x@p={...};
>>
>> @ok@
>> identifier r.x;
>> position p;
>> @@
>> snd_ctl_new1(&x@p,...)
>>
>> @bad@
>> position p != {r.p,ok.p};
>> identifier r.x;
>> @@
>> x@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r.x;
>> @@
>> +const
>> struct snd_kcontrol_new x;
>>
>> Signed-off-by: Bhumika Goyal
>> ---
>> sound/usb/line6/pod.c | 2 +-
>> sound/usb/line6/toneport.c | 4 ++--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>
> Reviewed-by: Takashi Sakamoto
>
> I have interests in your way to detect this kind of issue, because below
> 'struct snd_kcontrol_new' array seems not to be detected. I think there's a
> space to improve it.
>
Thanks for pointing it out. The logic that I use currently for my
scripts doesn't take into account the arrays. I will extend the script
for arrays too.
Thanks,
Bhumika
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/usb/line6/pcm.c#n432
>
> 432 /* control definition */
> 433 static struct snd_kcontrol_new line6_controls[] = {
> 434 {
> 435 .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>
> Later, I'll post for the above line.
>
>
>> diff --git a/sound/usb/line6/pod.c b/sound/usb/line6/pod.c
>> index 17aa616..358224c 100644
>> --- a/sound/usb/line6/pod.c
>> +++ b/sound/usb/line6/pod.c
>> @@ -380,7 +380,7 @@ static int snd_pod_control_monitor_put(struct
>> snd_kcontrol *kcontrol,
>> }
>>
>> /* control definition */
>> -static struct snd_kcontrol_new pod_control_monitor = {
>> +static const struct snd_kcontrol_new pod_control_monitor = {
>> .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>> .name = "Monitor Playback Volume",
>> .index = 0,
>> diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
>> index 8e22f43..ba7975c 100644
>> --- a/sound/usb/line6/toneport.c
>> +++ b/sound/usb/line6/toneport.c
>> @@ -250,7 +250,7 @@ static void toneport_start_pcm(unsigned long arg)
>> }
>>
>> /* control definition */
>> -static struct snd_kcontrol_new toneport_control_monitor = {
>> +static const struct snd_kcontrol_new toneport_control_monitor = {
>> .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>> .name = "Monitor Playback Volume",
>> .index = 0,
>> @@ -261,7 +261,7 @@ static struct snd_kcontrol_new
>> toneport_control_monitor = {
>> };
>>
>> /* source selector definition */
>> -static struct snd_kcontrol_new toneport_control_source = {
>> +static const struct snd_kcontrol_new toneport_control_source = {
>> .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
>> .name = "PCM Capture Source",
>> .index = 0,
>
>
>
> Regards
>
> Takashi Sakamoto
Re: [PATCH 0/2] hp-wmi: Fix dock status and tablet mode reporting
On Sun, Apr 9, 2017 at 3:56 PM, Carlo Caione wrote: > From: Carlo Caione > > Several HP laptops cannot be put to sleep using the LID since systemd > complains > that the system is docked even though the laptop is not even dockable (see > [1]). > > This is due to a bug in hp-wmi where the driver is failing to check for errors > before creating the input switches. > > [1]: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1574120 > > Carlo Caione (2): > hp-wmi: Fix error value for hp_wmi_tablet_state > hp-wmi: Fix detection for dock and tablet mode Gentle ping. -- Carlo Caione | +39.340.80.30.096 | Endless
Re: [PATCH v2] mac80211: Fix clang warning about constant operand in logical operation
On Thu, 2017-04-06 at 16:31 -0700, Matthias Kaehlcke wrote: > When clang detects a non-boolean constant in a logical operation it > generates a 'constant-logical-operand' warning. In > ieee80211_try_rate_control_ops_get() the result of strlen( str>) > is used in a logical operation, clang resolves the expression to an > (integer) constant at compile time when clang's builtin strlen > function > is used. > > Change the condition to check for strlen() > 0 to make the constant > operand boolean and thus avoid the warning. > Applied. johannes
Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop
On Thu, 2017-04-13 at 14:12 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > > > #endif > > > mtctr r12 > > > bctrl > > > +/* > > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > > + * sane value that is set at early boot time, > > > + * thereby clearing LPCR_UPRT. > > > + * LPCR_UPRT is required if we are running in Radix mode. > > > + * Set it here if that be the case. > > > + */ > > > +BEGIN_MMU_FTR_SECTION > > > + mfspr r3, SPRN_LPCR > > > + LOAD_REG_IMMEDIATE(r4, LPCR_UPRT) > > > + or r3, r3, r4 > > > + mtspr SPRN_LPCR, r3 > > > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX) > > We are probably better off saving the value somewhere during boot > and just "blasting" it whole back. We seem to touch LPCR in a bunch of places these days. Not sure when "sometimes during boot" should actually be. Mikey
Re: [REGRESSION next-20170410] Commit a6ff6cbf1fab ("usb: xhci: Add helper function xhci_set_power_on().") breaks armada-385
On 12.04.2017 10:47, Ralph Sennhauser wrote:
Hi Guoqing Zhang,
Commit a6ff6cbf1fabe7500d8ac25e133e3346db0a0fca ("usb: xhci: Add helper
function xhci_set_power_on().") causes a null pointer dereference on an
armada-385. Below the kernel as well as the bisect log.
Seems Guoqing Zhang is not currently reachable
I'll send a fix for this, adding you to cc.
Can you check if it solves the issue on armada-385?
Thanks
-Mathias
Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
On 04/12/2017 11:25 PM, Christoph Lameter wrote: > On Tue, 11 Apr 2017, Vlastimil Babka wrote: > >>> The fallback was only intended for a cpuset on which boundaries are not >>> enforced >>> in critical conditions (softwall). A hardwall cpuset (CS_MEM_HARDWALL) >>> should fail the allocation. >> >> Hmm just to clarify - I'm talking about ignoring the *mempolicy's* nodemask >> on >> the basis of cpuset having higher priority, while you seem to be talking >> about >> ignoring a (softwall) cpuset nodemask, right? man set_mempolicy says "... if >> required nodemask contains no nodes that are allowed by the process's current >> cpuset context, the memory policy reverts to local allocation" which does >> come >> down to ignoring mempolicy's nodemask. > > I am talking of allocating outside of the current allowed nodes > (determined by mempolicy -- MPOL_BIND is the only concern as far as I can > tell -- as well as the current cpuset). One can violate the cpuset if its not > a hardwall but the MPOL_MBIND node restriction cannot be violated. > > Those allocations are also not allowed if the allocation was for a user > space page even if this is a softwall cpuset. > This patch fixes the issue by having __alloc_pages_slowpath() check for empty intersection of cpuset and ac->nodemask before OOM or allocation failure. If it's indeed empty, the nodemask is ignored and allocation retried, which mimics node_zonelist(). This works fine, because almost all callers of >>> >>> Well that would need to be subject to the hardwall flag. Allocation needs >>> to fail for a hardwall cpuset. >> >> They still do, if no hardwall cpuset node can satisfy the allocation with >> mempolicy ignored. > > If the memory policy is MPOL_MBIND then allocations outside of the given > nodes should fail. They can violate the cpuset boundaries only if they are > kernel allocations and we are not in a hardwall cpuset. > > That was at least my understand when working on this code years ago. Hmm, I see policy_nodemask() (I wrongly mentioned node_zonelist() before) ignores BIND mempolicy nodemask when it doesn't overlap with cpuset allowed nodes since initial git commit 1da177e4c3f4 (back then it was zonelist_policy()). But AFAIU this couldn't actually happen (outside of races), because 1) one is not allowed to create such effectively empty BIND mempolicy in the first place and 2) an existing mempolicy is rebound on cpuset changes to maintain the overlap. The point 2) does not apply to MPOL_F_STATIC_NODES mempolicies introduced in 2008 by DavidR, but it's documented in Documentation/vm/numa_memory_policy.txt and manpages that when they don't overlap with cpuset allowed nodes, the default mempolicy is used instead. I doubt we can change that now, because that can break existing programs. It also makes some sense at least to me, because a task can control its own mempolicy (for performance reasons), but cpuset changes are admin decisions that the task cannot even anticipate. I think it's better to continue working with suboptimal performance than start failing allocations? > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org >
[tip:efi/urgent] x86/efi: Don't try to reserve runtime regions
Commit-ID: 6f6266a561306e206e0e31a5038f029b6a7b1d89
Gitweb: http://git.kernel.org/tip/6f6266a561306e206e0e31a5038f029b6a7b1d89
Author: Omar Sandoval
AuthorDate: Wed, 12 Apr 2017 16:27:19 +0100
Committer: Ingo Molnar
CommitDate: Thu, 13 Apr 2017 08:09:27 +0200
x86/efi: Don't try to reserve runtime regions
Reserving a runtime region results in splitting the EFI memory
descriptors for the runtime region. This results in runtime region
descriptors with bogus memory mappings, leading to interesting crashes
like the following during a kexec:
general protection fault: [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
RIP: 0010:virt_efi_set_variable()
...
Call Trace:
efi_delete_dummy_variable()
efi_enter_virtual_mode()
start_kernel()
? set_init_arg()
x86_64_start_reservations()
x86_64_start_kernel()
start_cpu()
...
Kernel panic - not syncing: Fatal exception
Runtime regions will not be freed and do not need to be reserved, so
skip the memmap modification in this case.
Signed-off-by: Omar Sandoval
Signed-off-by: Matt Fleming
Cc: # v4.9+
Cc: Ard Biesheuvel
Cc: Dave Young
Cc: Linus Torvalds
Cc: Peter Jones
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-...@vger.kernel.org
Fixes: 8e80632fb23f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Link: http://lkml.kernel.org/r/20170412152719.9779-2-m...@codeblueprint.co.uk
Signed-off-by: Ingo Molnar
---
arch/x86/platform/efi/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 30031d5..cdfe8c6 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -201,6 +201,10 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64
size)
return;
}
+ /* No need to reserve regions that will never be freed. */
+ if (md.attribute & EFI_MEMORY_RUNTIME)
+ return;
+
size += addr % EFI_PAGE_SIZE;
size = round_up(size, EFI_PAGE_SIZE);
addr = round_down(addr, EFI_PAGE_SIZE);
''Goodness''
Dear Beneficiary, This is to inform you that you are among the lucky beneficiary selected to receive a donation award sum of Eur1,950,000 each as charity donations/aid from the Qatar Foundation to promote your business and personal Interest. For collection of fund, Kindly get back to us for more information. On behalf of the foundation, we say congratulations to you. Yours Sincerely, Dr. Sheikha Moza bint Nasser. President Qatar Foundation. 5825 Al Luqta Street Education City, Doha, Qatar Email: sheikh.nas...@yandex.com
Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
On 04/13/2017 08:06 AM, Vlastimil Babka wrote: >> Did you really mean node_zonelist() in both the instances above. Because >> that function just picks up either FALLBACK_ZONELIST or NOFALLBACK_ZONELIST >> depending upon the passed GFP flags in the allocation request and does not >> deal with ignoring the passed nodemask. > > Oops, I meant policy_zonelist(), thanks for noticing. Nah, policy_nodemask()... I need coffee.
Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
On 04/13/2017 07:42 AM, Anshuman Khandual wrote:
> On 04/11/2017 07:36 PM, Vlastimil Babka wrote:
>> Commit e47483bca2cc ("mm, page_alloc: fix premature OOM when racing with
>> cpuset
>> mems update") has fixed known recent regressions found by LTP's cpuset01
>> testcase. I have however found that by modifying the testcase to use per-vma
>> mempolicies via bind(2) instead of per-task mempolicies via set_mempolicy(2),
>> the premature OOM still happens and the issue is much older.
>
> Meanwhile while we are discussing this RFC, will it be better to WARN
> out these situations where we dont have node in the intersection,
> hence no usable zone during allocation. That might actually give
> a hint to the user before a premature OOM/allocation failure comes.
Well, the bug is very old and nobody reported it so far, AFAIK. So it's
not that urgent.
>>
>> The root of the problem is that the cpuset's mems_allowed and mempolicy's
>> nodemask can temporarily have no intersection, thus get_page_from_freelist()
>> cannot find any usable zone. The current semantic for empty intersection is
>> to
>> ignore mempolicy's nodemask and honour cpuset restrictions. This is checked
>> in
>> node_zonelist(), but the racy update can happen after we already passed the
>> check. Such races should be protected by the seqlock task->mems_allowed_seq,
>> but it doesn't work here, because 1) mpol_rebind_mm() does not happen under
>> seqlock for write, and doing so would lead to deadlock, as it takes mmap_sem
>> for write, while the allocation can have mmap_sem for read when it's taking
>> the
>> seqlock for read. And 2) the seqlock cookie of callers of node_zonelist()
>> (alloc_pages_vma() and alloc_pages_current()) is different than the one of
>> __alloc_pages_slowpath(), so there's still a potential race window.
>>
>> This patch fixes the issue by having __alloc_pages_slowpath() check for empty
>> intersection of cpuset and ac->nodemask before OOM or allocation failure. If
>> it's indeed empty, the nodemask is ignored and allocation retried, which
>> mimics
>> node_zonelist(). This works fine, because almost all callers of
>> __alloc_pages_nodemask are obtaining the nodemask via node_zonelist(). The
>> only
>> exception is new_node_page() from hotplug, where the potential violation of
>> nodemask isn't an issue, as there's already a fallback allocation attempt
>> without any nodemask. If there's a future caller that needs to have its
>> specific
>> nodemask honoured over task's cpuset restrictions, we'll have to e.g. add a
>> gfp
>> flag for that.
>
> Did you really mean node_zonelist() in both the instances above. Because
> that function just picks up either FALLBACK_ZONELIST or NOFALLBACK_ZONELIST
> depending upon the passed GFP flags in the allocation request and does not
> deal with ignoring the passed nodemask.
Oops, I meant policy_zonelist(), thanks for noticing.
Re: [PATCH V4 2/9] PM / Domains: Use OPP tables for power-domains
On 12-04-17, 17:58, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> > The OPP table bindings contains all the necessary fields to support
> > power-domains now. Update the power-domain bindings to allow
> > "operating-points-v2" to be present within the power-domain node.
> >
> > Also allow consumer devices, that don't use OPP tables, to specify the
> > parent power-domain's performance level using the
> > "domain-performance-state" property.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > .../devicetree/bindings/power/power_domain.txt | 42
> > ++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> > b/Documentation/devicetree/bindings/power/power_domain.txt
> > index 723e1ad937da..5db112fa5d7c 100644
> > --- a/Documentation/devicetree/bindings/power/power_domain.txt
> > +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> > @@ -38,6 +38,9 @@ phandle arguments (so called PM domain specifiers) of
> > length specified by the
> >domain's idle states. In the absence of this property, the domain would
> > be
> >considered as capable of being powered-on or powered-off.
> >
> > +- operating-points-v2 : This describes the performance states of a PM
> > domain.
> > + Refer to ../opp/opp.txt for more information.
> > +
> > Example:
> >
> > power: power-controller@1234 {
> > @@ -118,4 +121,43 @@ The node above defines a typical PM domain consumer
> > device, which is located
> > inside a PM domain with index 0 of a power controller represented by a node
> > with the label "power".
> >
> > +Optional properties:
> > +- domain-performance-state: A positive integer value representing the
> > minimum
> > + power-domain performance level required by the consumer device. The
> > integer
> > + value '0' represents the lowest performance level and the higher values
> > + represent higher performance levels. The value of
> > "domain-performance-state"
> > + field should match the "domain-performance-state" field of one of the OPP
> > + nodes in the parent power-domain's OPP table.
> > +
> > +
> > +
> > +Example:
> > +
> > + domain_opp_table: opp_table {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 97 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 100 1085000>;
> > + };
> > + };
> > +
> > + parent: power-controller@1234 {
> > + compatible = "foo,power-controller";
> > + reg = <0x1234 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
>
> As mentioned in the other email, it would be good to consider
> scalability with multiple power domains in a PM domain provider.
> i.e case of #power-domain-cells = <1> or more
Yeah, but that isn't supported for devices today. So no point
considering that today.
--
viresh
[PATCH] perf trace: Add usage of --no-syscalls in man page
perf trace supports --no-syscalls option but it's not listed in the man page. (Though, I see an example using --no-syscalls in EXAMPLES section.) Signed-off-by: Ravi Bangoria --- tools/perf/Documentation/perf-trace.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/Documentation/perf-trace.txt b/tools/perf/Documentation/perf-trace.txt index afd7286..c1e3288 100644 --- a/tools/perf/Documentation/perf-trace.txt +++ b/tools/perf/Documentation/perf-trace.txt @@ -123,7 +123,8 @@ the thread executes on the designated CPUs. Default is to monitor all CPUs. major or all pagefaults. Default value is maj. --syscalls:: - Trace system calls. This options is enabled by default. + Trace system calls. This options is enabled by default, disable with + --no-syscalls. --call-graph [mode,type,min[,limit],order[,key][,branch]]:: Setup and enable call-graph (stack chain/backtrace) recording. -- 2.1.4
Re: [PATCH] mm,hugetlb: compute page_size_log properly
Matthew Wilcox writes:
> On Tue, Mar 28, 2017 at 09:55:13AM -0700, Davidlohr Bueso wrote:
>> Do we have any consensus here? Keeping SHM_HUGE_* is currently
>> winning 2-1. If there are in fact users out there computing the
>> value manually, then I am ok with keeping it and properly exporting
>> it. Michal?
>
> Well, let's see what it looks like to do that. I went down the rabbit
> hole trying to understand why some of the SHM_ flags had the same value
> as each other until I realised some of them were internal flags, some
> were flags to shmat() and others were flags to shmget(). Hopefully I
> disambiguated them nicely in this patch. I also added 8MB and 16GB sizes.
> Any more architectures with a pet favourite huge/giant page size we
> should add convenience defines for?
>
> diff --git a/include/linux/shm.h b/include/linux/shm.h
> index 04e881829625..cd95243efd1a 100644
> --- a/include/linux/shm.h
> +++ b/include/linux/shm.h
> @@ -24,26 +24,13 @@ struct shmid_kernel /* private to the kernel */
> struct list_headshm_clist; /* list by creator */
> };
>
> -/* shm_mode upper byte flags */
> -#define SHM_DEST01000 /* segment will be destroyed on last
> detach */
> -#define SHM_LOCKED 02000 /* segment will not be swapped */
> -#define SHM_HUGETLB 04000 /* segment will use huge TLB pages */
> -#define SHM_NORESERVE 01 /* don't check for reservations */
> -
> -/* Bits [26:31] are reserved */
> -
> /*
> - * When SHM_HUGETLB is set bits [26:31] encode the log2 of the huge page
> size.
> - * This gives us 6 bits, which is enough until someone invents 128 bit
> address
> - * spaces.
> - *
> - * Assume these are all power of twos.
> - * When 0 use the default page size.
> + * These flags are used internally; they cannot be specified by the user.
> + * They are masked off in newseg(). These values are used by IPC_CREAT
> + * and IPC_EXCL when calling shmget().
> */
> -#define SHM_HUGE_SHIFT 26
> -#define SHM_HUGE_MASK 0x3f
> -#define SHM_HUGE_2MB(21 << SHM_HUGE_SHIFT)
> -#define SHM_HUGE_1GB(30 << SHM_HUGE_SHIFT)
> +#define SHM_DEST01000 /* segment will be destroyed on last
> detach */
> +#define SHM_LOCKED 02000 /* segment will not be swapped */
>
> #ifdef CONFIG_SYSVIPC
> struct sysv_shm {
> diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
> index 1fbf24ea37fd..44b36cb228d7 100644
> --- a/include/uapi/linux/shm.h
> +++ b/include/uapi/linux/shm.h
> @@ -40,15 +40,34 @@ struct shmid_ds {
> /* Include the definition of shmid64_ds and shminfo64 */
> #include
>
> -/* permission flag for shmget */
> +/* shmget() shmflg values. */
> +/* The bottom nine bits are the same as open(2) mode flags */
> #define SHM_R0400/* or S_IRUGO from */
> #define SHM_W0200/* or S_IWUGO from */
> +/* Bits 9 & 10 are IPC_CREAT and IPC_EXCL */
> +#define SHM_HUGETLB (1 << 11) /* segment will use huge TLB pages */
> +#define SHM_NORESERVE (1 << 12) /* don't check for reservations */
>
> -/* mode for attach */
> -#define SHM_RDONLY 01 /* read-only access */
> -#define SHM_RND 02 /* round attach address to SHMLBA
> boundary */
> -#define SHM_REMAP 04 /* take-over region on attach */
> -#define SHM_EXEC010 /* execution access */
> +/*
> + * When SHM_HUGETLB is set bits [26:31] encode the log2 of the huge page
> size.
> + * This gives us 6 bits, which is enough until someone invents 128 bit
> address
> + * spaces. These match MAP_HUGE_SHIFT and MAP_HUGE_MASK.
> + *
> + * Assume these are all powers of two.
> + * When 0 use the default page size.
> + */
> +#define SHM_HUGE_SHIFT 26
> +#define SHM_HUGE_MASK0x3f
> +#define SHM_HUGE_2MB (21 << SHM_HUGE_SHIFT)
> +#define SHM_HUGE_8MB (23 << SHM_HUGE_SHIFT)
> +#define SHM_HUGE_1GB (30 << SHM_HUGE_SHIFT)
> +#define SHM_HUGE_16GB(34 << SHM_HUGE_SHIFT)
This should be in arch/uapi like MAP_HUGE_2M ? That will let arch add
#defines based on the hugepae size supported by them.
> +
> +/* shmat() shmflg values */
> +#define SHM_RDONLY (1 << 12) /* read-only access */
> +#define SHM_RND (1 << 13) /* round attach address to SHMLBA
> boundary */
> +#define SHM_REMAP (1 << 14) /* take-over region on attach */
> +#define SHM_EXEC(1 << 15) /* execution access */
>
-aneesh
Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry
On 2017/04/13 01:37PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:28 +0530 > "Naveen N. Rao" wrote: > > > On kprobe handler re-entry, try to emulate the instruction rather than > > single stepping always. > > > > > As a related change, remove the duplicate saving of msr as that is > > already done in set_current_kprobe() > > If so, this part might be separated as a cleanup patch... Sure, thanks for the review! - Naveen
Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper
On 2017/04/13 01:34PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:27 +0530 > "Naveen N. Rao" wrote: > > > This helper will be used in a subsequent patch to emulate instructions > > on re-entering the kprobe handler. No functional change. > > In this case, please merge this patch into the next patch which > actually uses the factored out function unless that changes > too much. Ok, will do. Thanks, Naveen
Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points
On 2017/04/13 01:32PM, Masami Hiramatsu wrote: > On Wed, 12 Apr 2017 16:28:26 +0530 > "Naveen N. Rao" wrote: > > > kprobe_lookup_name() is specific to the kprobe subsystem and may not > > always return the function entry point (in a subsequent patch for > > KPROBES_ON_FTRACE). > > If so, please move this patch into that series. It is hard to review > patches which requires for other series. :-) This patch was originally the first in this series to try avoiding the need for converting kprobe_lookup_name() in optprobes.c. But, with the re-shuffle, this is more suitable in the other series. I will move it. Thanks, Naveen
Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
On 12-04-17, 18:05, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> [...]
>
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require
> > state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 97 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 100 1085000>;
> > + };
> > + };
> > +
> > + foo_domain: power-controller@1234 {
> > + compatible = "foo,power-controller";
> > + reg = <0x1234 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
> > + }
> > +
> > + cpu0_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp@10 {
> > + opp-hz = /bits/ 64 <10>;
> > + domain-performance-state = <1>;
> > + };
> > + opp@11 {
> > + opp-hz = /bits/ 64 <11>;
> > + domain-performance-state = <2>;
> > + };
> > + opp@12 {
> > + opp-hz = /bits/ 64 <12>;
> > + domain-performance-state = <2>;
> > + };
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> > + compatible = "arm,cortex-a9";
> > + reg = <0>;
> > + clocks = <&clk_controller 0>;
> > + clock-names = "cpu";
> > + operating-points-v2 = <&cpu0_opp_table>;
> > + power-domains = <&foo_domain>;
> > + };
> > + };
> > +};
>
>
> Thinking more about this above example, I think you need more
> explanation. So in the above case you have cpu with clock controller,
> power-domain and the OPP table info, I can think of few things that need
> to be explicit:
>
> 1. How does the precedence look like ?
Just think of the power-domain as a regulator here. If we are
increasing frequency of the device, power-domain needs to be
programmed first followed by the clock.
> 2. Since power-domains with OPP table control the performance state, do
They control performance state of the domains, not the devices.
>we ignore clock and operating-points-v2 in the above case completely?
No. They are separate.
>
> 3. Will the power-domain drive the OPP ?
power-domain will driver its own state using its own OPP table.
Devices may fine tune within those states.
--
viresh
Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring
On 2017/04/13 12:02PM, Masami Hiramatsu wrote: > Hi Naveen, Hi Masami, > > BTW, I saw you sent 3 different series, are there any > conflict each other? or can we pick those independently? Yes, all these three patch series are based off powerpc/next and they do depend on each other, as they are all about powerpc kprobes. Patches 1 and 2 in this series touch generic kprobes bits and Michael was planning on putting those in a topic branch so that -tip can pull them too. Apart from those two, your optprobes patch 3/5 (https://patchwork.ozlabs.org/patch/749934/) also touches generic code, but it is needed for KPROBES_ON_FTRACE on powerpc. So, I've posted that as part of my series. We could probably also put that in the topic branch. Thanks, Naveen
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage
On (04/12/17 01:19), Sergey Senozhatsky wrote: [..] > it does offloading after X printed lines by the same process. > if we reschedule, then the counter resets. which is probably OK, > we don't really want any process, except for printk_kthread, to > stay in console_unlock() forever. may be this can be changed. we don't want even printk_kthread to keep console_sem locked for too long, because other process that might want to lock console_sem have to sleep in TASK_UNINTERRUPTIBLE as long as printing thread has pending messages to print. so may be the rule can be "every process prints up to `atomic_print_limit' lines and then offloads printing - wake_up()s printk_kthread and up()s console_sem". some other process (printk_kthread or a process from console_sem wait list, let them compete for console_sem) will eventually down() console_sem and print the next `atomic_print_limit' lines, while current process will have a chance to return from console_unlock() and do something else. [..] > the next question will be -- do we even need printk_emergency_begin/end > or we can leave without it. what I meant here -- drop sysrq and kexec printk_emergency_begin/end patches, but keep printk_emergency_begin/end API and do printk_emergency_begin/end in console_suspend()/resume(). PM already calls console_suspend()/resume(). something like that... -ss
Re: [patch 05/13] powerpc/smp: Replace open coded task affinity logic
Thomas Gleixner writes: > Init task invokes smp_ops->setup_cpu() from smp_cpus_done(). Init task can > run on any online CPU at this point, but the setup_cpu() callback requires > to be invoked on the boot CPU. This is achieved by temporarily setting the > affinity of the calling user space thread to the requested CPU and reset it > to the original affinity afterwards. > > That's racy vs. CPU hotplug and concurrent affinity settings for that > thread resulting in code executing on the wrong CPU and overwriting the > new affinity setting. > > That's actually not a problem in this context as neither CPU hotplug nor > affinity settings can happen, but the access to task_struct::cpus_allowed > is about to restricted. > > Replace it with a call to work_on_cpu_safe() which achieves the same result. > > Signed-off-by: Thomas Gleixner > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: linuxppc-...@lists.ozlabs.org > --- > arch/powerpc/kernel/smp.c | 26 +++--- > 1 file changed, 11 insertions(+), 15 deletions(-) LGTM. Acked-by: Michael Ellerman (powerpc) cheers
Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update
On 04/11/2017 07:36 PM, Vlastimil Babka wrote:
> Commit e47483bca2cc ("mm, page_alloc: fix premature OOM when racing with
> cpuset
> mems update") has fixed known recent regressions found by LTP's cpuset01
> testcase. I have however found that by modifying the testcase to use per-vma
> mempolicies via bind(2) instead of per-task mempolicies via set_mempolicy(2),
> the premature OOM still happens and the issue is much older.
Meanwhile while we are discussing this RFC, will it be better to WARN
out these situations where we dont have node in the intersection,
hence no usable zone during allocation. That might actually give
a hint to the user before a premature OOM/allocation failure comes.
>
> The root of the problem is that the cpuset's mems_allowed and mempolicy's
> nodemask can temporarily have no intersection, thus get_page_from_freelist()
> cannot find any usable zone. The current semantic for empty intersection is to
> ignore mempolicy's nodemask and honour cpuset restrictions. This is checked in
> node_zonelist(), but the racy update can happen after we already passed the
> check. Such races should be protected by the seqlock task->mems_allowed_seq,
> but it doesn't work here, because 1) mpol_rebind_mm() does not happen under
> seqlock for write, and doing so would lead to deadlock, as it takes mmap_sem
> for write, while the allocation can have mmap_sem for read when it's taking
> the
> seqlock for read. And 2) the seqlock cookie of callers of node_zonelist()
> (alloc_pages_vma() and alloc_pages_current()) is different than the one of
> __alloc_pages_slowpath(), so there's still a potential race window.
>
> This patch fixes the issue by having __alloc_pages_slowpath() check for empty
> intersection of cpuset and ac->nodemask before OOM or allocation failure. If
> it's indeed empty, the nodemask is ignored and allocation retried, which
> mimics
> node_zonelist(). This works fine, because almost all callers of
> __alloc_pages_nodemask are obtaining the nodemask via node_zonelist(). The
> only
> exception is new_node_page() from hotplug, where the potential violation of
> nodemask isn't an issue, as there's already a fallback allocation attempt
> without any nodemask. If there's a future caller that needs to have its
> specific
> nodemask honoured over task's cpuset restrictions, we'll have to e.g. add a
> gfp
> flag for that.
Did you really mean node_zonelist() in both the instances above. Because
that function just picks up either FALLBACK_ZONELIST or NOFALLBACK_ZONELIST
depending upon the passed GFP flags in the allocation request and does not
deal with ignoring the passed nodemask.
linux-next: Tree for Apr 13
Hi all, News: There will be no linux-next releases until next Tuesday (next-20170418). Changes since 20170412: New trees: imx-drm, etnaviv The kvm-ppc tree lost its build failure. The tty tree gained conflicts against the bluetooth tree. The rtc tree still had its build failure for which I applied a supplied patch. Non-merge commits (relative to Linus' tree): 9166 8893 files changed, 1085189 insertions(+), 182104 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 258 trees (counting Linus' and 37 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b9b3322f13f3 Merge branch 'stable-4.11' of git://git.infradead.org/users/pcmoore/audit) Merging fixes/master (97da3854c526 Linux 4.11-rc3) Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading parentheses around a condition) Merging arc-current/for-curr (83c67bb382fb ARC: [plat-eznps] Fix build error) Merging arm-current/fixes (3872fe83a2fb Merge branch 'kprobe-fixes' of https://git.linaro.org/people/tixy/kernel into fixes) Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (4749228f0228 powerpc/crypto/crc32c-vpmsum: Fix missing preempt_disable()) Merging sparc/master (78d91a75b40f Merge branch 'for-linus' of git://git.kernel.dk/linux-block) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (a2d6cbb0670d ipv6: Fix idev->addr_list corruption) Merging ipsec/master (89e357d83c06 af_key: Add lock to key dump) Merging netfilter/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO check) Merging ipvs/master (0b9aefea8600 tcp: minimize false-positives on TCP/GRO check) Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype avoiding use-after-free of virtual interface) Merging mac80211/master (75514b665485 net: ethernet: ti: cpsw: wake tx queues on ndo_tx_timeout) Merging sound-current/for-linus (3d016d57fdc5 ALSA: oxfw: fix regression to handle Stanton SCS.1m/1d) Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding (hisi-pcie-almost-ecam)) Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6) Merging tty.current/tty-linus (a71c9a1c779f Linux 4.11-rc5) Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5) Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held) Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move the lock initialization to core file) Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON) Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6) Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4) Merging input-current/for-linus (537636688625 Input: xpad - add support for Razer Wildcat gamepad) Merging crypto-current/master (e6534aebb26e crypto: algif_aead - Fix bogus request dereference in completion function) Merging ide/master (96297aee8bce ide: palm_bk3710: add __initdata to palm_bk3710_port_info) Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6) Merging kselftest-fix
Re: [patch 13/13] crypto: n2 - Replace racy task affinity logic
On Wed, Apr 12, 2017 at 10:07:39PM +0200, Thomas Gleixner wrote: > spu_queue_register() needs to invoke setup functions on a particular > CPU. This is achieved by temporarily setting the affinity of the > calling user space thread to the requested CPU and reset it to the original > affinity afterwards. > > That's racy vs. CPU hotplug and concurrent affinity settings for that > thread resulting in code executing on the wrong CPU and overwriting the > new affinity setting. > > Replace it by using work_on_cpu_safe() which guarantees to run the code on > the requested CPU or to fail in case the CPU is offline. > > Signed-off-by: Thomas Gleixner > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: linux-cry...@vger.kernel.org Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
On 12-04-17, 17:49, Sudeep Holla wrote:
> On 20/03/17 09:32, Viresh Kumar wrote:
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> > b/Documentation/devicetree/bindings/opp/opp.txt
> > index 63725498bd20..d0b95c9e1011 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -76,10 +76,9 @@ This describes the OPPs belonging to a device. This node
> > can have following
> > This defines voltage-current-frequency combinations along with other
> > related
> > properties.
> >
> > -Required properties:
> > +Optional properties:
> > - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer.
> >
> > -Optional properties:
> > - opp-microvolt: voltage in micro Volts.
> >
> >A single regulator's voltage is specified with an array of size one or
> > three.
> > @@ -154,6 +153,19 @@ properties.
> >
> > - status: Marks the node enabled/disabled.
> >
> > +- domain-performance-state: A positive integer value representing the
> > minimum
> > + power-domain performance level required by the device for the OPP node.
> > The
>
> So the above definition is when this field in in the device node rather
> than the OPP table entry, right ?
No. We are updating the opp.txt file here and so it is not about the
device node. The OPP node entries will contain this field for two
cases:
- The OPP table belongs to a power domain
- The OPP table belongs to a device whose power domain supports
performance-states.
> For simplicity why not have the
> properties named slightly different or just use phandle to an entry in
> the device node for this purpose.
We really need a value here. For example, in case where the OPP table
defines the states of the power-domain itself, we don't have any
phandles to point to.
> > + The integer value '0' represents the lowest performance level and the
> > higher
> > + values represent higher performance levels.
>
> needs to be changed as OPP table entry.
Not sure I understood what change you are looking for :(
> > When present in the OPP table of a
> > + power-domain, it represents the performance level of the domain. When
> > present
>
> again "performance level of the domain corresponding to that OPP entry"
> on something similar
Ok.
> > + in the OPP table of a normal device, it represents the performance level
> > of
>
> what do you mean by normal device ? needs description as that's
> something new introduced here.
It should be non-power-domain node.
> > + the parent power-domain. The OPP table can contain the
> > + "domain-performance-state" property, only if the device node contains the
> > + "power-domains" or "#power-domain-cells" property.
>
> Why such a restriction ?
Why would we use it for non-power-domain cases? That's not what we
are looking for..
> > The OPP nodes aren't
> > + allowed to contain the "domain-performance-state" property partially,
> > i.e.
> > + Either all OPP nodes in the OPP table have the "domain-performance-state"
> > + property or none of them have it.
> > +
> > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states
> > together.
> >
> > / {
> > @@ -528,3 +540,60 @@ Example 5: opp-supported-hw
> > };
> > };
> > };
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require
> > state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 97 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 100 1085000>;
> > + };
> > + };
> > +
> > + foo_domain: power-controller@1234 {
> > + compatible = "foo,power-controller";
> > + reg = <0x1234 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
>
> How does it scale with power domain providers with multiple power domain ?
Devices can't have multiple power domains today. Will see this when
that support is added.
Note that only the power domains can have multiple parent power
domains today.
> > + }
> > +
> > + cpu0_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp@10 {
> > + opp-hz = /bits/ 64 <10>;
> > + domain-performance-state = <1>;
> > + };
> > + opp@11 {
> > + opp-hz = /bits/ 64 <11>;
> > + domain-performance-state = <2>;
> > + };
> > + opp@12 {
> > + opp-hz = /bits/ 64 <12>;
> > + domain-performance-state = <2>
Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64
On 2017/4/7 23:57, Gabriele Paoloni wrote: > Hi Robin and all > >> -Original Message- >> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- >> ow...@vger.kernel.org] On Behalf Of Robin Murphy >> Sent: 20 March 2017 14:00 >> To: Dingtianhong; Catalin Marinas; Will Deacon; linux-arm- >> ker...@lists.infradead.org; linux-kernel@vger.kernel.org >> Cc: alexander.du...@gmail.com; maowenan >> Subject: Re: [PATCH] arm64: enable ARCH_WANT_RELAX_ORDER for aarch64 >> >> On 14/03/17 14:06, Ding Tianhong wrote: >>> Hi Robin： >>> >>> On 2017/3/13 21:31, Robin Murphy wrote: On 13/03/17 12:03, Ding Tianhong wrote: > The ARCH_WANT_RELAX_ORDER will enable Relaxed Ordering (RO) which >> allows > transactions that do not have any order of completion requirements >> to > complete more efficiently compare to the Stricted Ordering (SO) for >> ixbge > nic card. Which ixgbe NIC? As far as I can see we have an arch-level config >> option here which applies to one single driver, and doesn't even cover all >> the hardware supported by that driver (82598, for example, still has the #ifndef CONFIG_SPARC in the equivalent place). Looking at the >> history, I'd prefer to at least know what the "various issues with certain chipsets" were, and why they wouldn't affect ARM systems, before >> making any judgement about whether this could be considered universally >> safe for arm64. >>> >>> Indeed, in fact if the chipsets didn't support RO mode or has some >> errata for RO mode, it may >>> occur some issues, but it looks no such aarch64 chips, maybe I miss >> something. >>> >>> There are several intel nic card could support enable relax order, so >> need another patch to rename the SPARC >>> to ARCH_WANT_RELAX_ORDER, the universal name looks more better. >> >> I'm sure I'm not alone in disagreeing outright that it looks better, >> because ARCH_ is hardly the appropriate namespace for a driver option >> unrelated to an architecture port's interaction with core kernel code; >> plus it's further confounded by a name which both doesn't imply any >> relationship with said driver, and does overlap with the kind of CPU >> memory model terminology which *is* the purview of architecture ports. >> >> As an equivalent example, consider how equally misleading it would be >> from the ARM maintainer perspective if CONFIG_IOMMU_IO_PGTABLE_LPAE was >> just called CONFIG_ARCH_WANT_LPAE and implemented in this manner. >> >> Having looked into it, I see that "Relaxed Order" does actually turn >> out >> to be a specific PCIe term, but even in that context it doesn't apply >> at >> the arch level - that's going to be a matter for particular endpoints >> and particular host controllers and all the quirks in between. > > I fully agree on this and to be honest I don't understand how > < to support relax ordering">> has landed into mainline... > > >> > The system will see high write-to-memory performance when RO is > enabled on the data transactions just like the SPARC did. > > The aarch64 pcie controller could both support Relaxed Ordering >> (RO) What is "the AArch64 PCIe controller", exactly? Disregarding that talking of PCIe in terms of the CPU ISA makes little sense, I can >> barely name two ARMv8-based systems which nominally use the same PCIe IP, >> and the amount of various quirks and incompatibilities I'm aware of >> leaves me with the default assumption that any such unqualified blanket statement is probably wrong. I think we need some much more >> considered reasoning here. >>> >>> Agree, till now I could only test on hip06/hip07 board and get the >> better performance, >>> maybe I could test on other aarch64 platform. >>> > and Stricted Ordering (SO), so enable ARCH_WANT_RELAX_ORDER for >> ixgbe > nic card to get much more better performance, and didn't see any > adverse effects. > > Nic Card(Ixgbe) Disable RO | Enable RO > Performance(Per thread) 8.4Gb/s | 9.4Gb/s > > Tested by Iperf on Hip06/Hip07 Soc Board. > > Signed-off-by: Ding Tianhong > --- > arch/arm64/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 8c7c244..36249a3 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -115,6 +115,7 @@ config ARM64 > select SPARSE_IRQ > select SYSCTL_EXCEPTION_TRACE > select THREAD_INFO_IN_TASK > + select ARCH_WANT_RELAX_ORDER I'd say the first order of business is to rename this config option >> to IXBGE_82599_WANT_RELAXED_ORDER so that it's not entirely misleading >> and >>> >>> not only for 82599, including 82598, 82576 >> >> So why does ixgbe_start_hw_82598() still have the original #ifndef >> CONFIG_SPARC from 887012e80aea? >> >> It was pretty clear from the
Re: [v3] PCI: Add an option to control probing of VFs before enabling SR-IOV
On Wed, Apr 12, 2017 at 08:56:14PM -0600, Alex Williamson wrote: >On Thu, 13 Apr 2017 01:51:40 +0300 >bod...@mellanox.com wrote: > >> From: Bodong Wang >> >> Sometimes it is not desirable to probe the virtual functions after >> SRIOV is enabled. This can save host side resource usage by VF >> instances which would be eventually probed to VMs. >> >> Add a new PCI sysfs interface "sriov_drivers_autoprobe" to control >> that from the PF, all current callers still retain the same >> functionality. To modify it, echo 0/n/N (disable probe) or 1/y/Y >> (enable probe) to: >> >> /sys/bus/pci/devices//sriov_drivers_autoprobe >> >> Note that, the choice must be made before enabling VFs. The change >> will not take effect if VFs are already enabled. Simply, one can set >> sriov_numvfs to 0, choose whether to probe or not, and then resume >> sriov_numvfs. >> >> Signed-off-by: Bodong Wang >> Signed-off-by: Eli Cohen >> Reviewed-by: Gavin Shan >> Reviewed-by: Alex Williamson > >Whoa, I reviewed the last version, that's different than providing a >Reviewed-by, and I've certainly never seen this version until now, so I >can't possibly have endorsed it in any way. It's also changed since >Gavin saw it and I think Bjorn is in the same boat. Probably a good >idea to cc the people you're claiming reviewed this too (cc +Gavin). > Thanks, Alex. I usually keep an eye on the patches that I ever reviewed and follow them until they are merged or rejected. More comments would be given if I have. Otherwise, everthing is fine. Yes, it's always nice to copy those who reviewed the patch. For this one, my reviewed-by is still valid. Thanks, Gavin
[PATCH v2] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig
Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- v2: add missing hunk --- arch/x86/Kconfig | 1 + mm/Kconfig | 6 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c43f47622440..535b4d514792 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -59,6 +59,7 @@ config X86 select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_ZONE_DEVICE if X86_64 select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI select ARCH_MIGHT_HAVE_PC_PARPORT diff --git a/mm/Kconfig b/mm/Kconfig index c89f472b658c..392bf8d7574c 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -684,12 +684,16 @@ config IDLE_PAGE_TRACKING See Documentation/vm/idle_page_tracking.txt for more details. +# arch_add_memory() comprehends device memory +config ARCH_HAS_ZONE_DEVICE + bool + config ZONE_DEVICE bool "Device memory (pmem, etc...) hotplug support" depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE depends on SPARSEMEM_VMEMMAP - depends on X86_64 #arch_add_memory() comprehends device memory + depends on ARCH_HAS_ZONE_DEVICE help Device memory hotplug support allows for establishing pmem, -- 2.9.3
Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once
On Thursday 13 April 2017 10:36 AM, Eduardo Valentin wrote:
> Hey,
>
> On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote:
>> thermal_zone_device_check --> thermal_zone_device_update -->
>> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
>>
>> The above sequence happens every 250/500 mS based on the configuration.
>> The orderly_poweroff function is getting called every 250/500 mS.
>> With a full fledged file system it takes at least 5-10 Seconds to
>> power off gracefully.
>>
>> In that period due to the thermal_zone_device_check triggering
>> periodically the thermal work queues bombard with
>> orderly_poweroff calls multiple times eventually leading to
>> failures in gracefully powering off the system.
>>
>> Make sure that orderly_poweroff is called only once.
>>
>> Fixes: 0c01ebbfd3caf1d ("Thermal: Remove throttling logic out of
>> thermal_sys.c")
>
> Why? how the above commit introduced this issue?
git blame showed me that. I can remove this. Let me know if you have the
right commit that introduced this.
>
>> Reported-by: Nishanth Menon
>> Signed-off-by: Keerthy
>> ---
>> drivers/thermal/thermal_core.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 11f0675..4e68ce0 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -326,6 +326,7 @@ static void handle_critical_trips(struct
>> thermal_zone_device *tz,
>>int trip, enum thermal_trip_type trip_type)
>> {
>> int trip_temp;
>> +static bool power_off_triggered;
>>
>
> I am not convinced this change does what you say it does..
>
>> tz->ops->get_trip_temp(tz, trip, &trip_temp);
>>
>> @@ -338,11 +339,12 @@ static void handle_critical_trips(struct
>> thermal_zone_device *tz,
>> if (tz->ops->notify)
>> tz->ops->notify(tz, trip, trip_type);
>>
>> -if (trip_type == THERMAL_TRIP_CRITICAL) {
>> +if (trip_type == THERMAL_TRIP_CRITICAL && !power_off_triggered) {
>> dev_emerg(&tz->device,
>>"critical temperature reached(%d C),shutting down\n",
>>tz->temperature / 1000);
>> orderly_poweroff(true);
>
> Imagine you have two zones about to enter critical path. thermal zone 0
> first gets into critical, and at this line (btween orderly_poweroff()
> and you set your flag), it gets preempted. Then thermal zone 1 also
> enters the critical path, then happens to be scheduled, you essentially
> end up still calling orderly_poweroff() twice, which is what this patch
> is supposed to avoid.
>
> You better simply use a lock to serialize code execution.
Okay understood. Will do it in the next version.
>
> BR,
>
>> +power_off_triggered = true;
>> }
>> }
>>
>> --
>> 1.9.1
>>
Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.
Stephen Rothwell writes: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: >> >> Since ia64 and ppc64 don't set CONFIG_64BIT, they were already >> excluded by the original dependency. > > My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... > > $ grep CONFIG_64BIT ~/next/powerpc_ppc64_defconfig/.config > CONFIG_64BIT=y Yeah, arch/powerpc/Kconfig: config 64BIT bool default y if PPC64 cheers
Re: [PATCH] thermal: core: Allow orderly_poweroff to be called only once
Hey,
On Wed, Apr 12, 2017 at 02:42:12PM +0530, Keerthy wrote:
> thermal_zone_device_check --> thermal_zone_device_update -->
> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
>
> The above sequence happens every 250/500 mS based on the configuration.
> The orderly_poweroff function is getting called every 250/500 mS.
> With a full fledged file system it takes at least 5-10 Seconds to
> power off gracefully.
>
> In that period due to the thermal_zone_device_check triggering
> periodically the thermal work queues bombard with
> orderly_poweroff calls multiple times eventually leading to
> failures in gracefully powering off the system.
>
> Make sure that orderly_poweroff is called only once.
>
> Fixes: 0c01ebbfd3caf1d ("Thermal: Remove throttling logic out of
> thermal_sys.c")
Why? how the above commit introduced this issue?
> Reported-by: Nishanth Menon
> Signed-off-by: Keerthy
> ---
> drivers/thermal/thermal_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 11f0675..4e68ce0 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -326,6 +326,7 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> int trip, enum thermal_trip_type trip_type)
> {
> int trip_temp;
> + static bool power_off_triggered;
>
I am not convinced this change does what you say it does..
> tz->ops->get_trip_temp(tz, trip, &trip_temp);
>
> @@ -338,11 +339,12 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> if (tz->ops->notify)
> tz->ops->notify(tz, trip, trip_type);
>
> - if (trip_type == THERMAL_TRIP_CRITICAL) {
> + if (trip_type == THERMAL_TRIP_CRITICAL && !power_off_triggered) {
> dev_emerg(&tz->device,
> "critical temperature reached(%d C),shutting down\n",
> tz->temperature / 1000);
> orderly_poweroff(true);
Imagine you have two zones about to enter critical path. thermal zone 0
first gets into critical, and at this line (btween orderly_poweroff()
and you set your flag), it gets preempted. Then thermal zone 1 also
enters the critical path, then happens to be scheduled, you essentially
end up still calling orderly_poweroff() twice, which is what this patch
is supposed to avoid.
You better simply use a lock to serialize code execution.
BR,
> + power_off_triggered = true;
> }
> }
>
> --
> 1.9.1
>
signature.asc
Description: Digital signature
[PATCH] ARM: dts: dra7: Add power hold and power controller properties to palmas
Add power hold and power controller properties to palmas node.
This is needed to shutdown pmic correctly on boards with
powerhold set.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/dra7-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4bc4b57..31a9e06 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -204,6 +204,8 @@
tps659038: tps659038@58 {
compatible = "ti,tps659038";
reg = <0x58>;
+ ti,palmas-override-powerhold;
+ ti,system-power-controller;
tps659038_pmic {
compatible = "ti,tps659038-pmic";
--
1.9.1
Re: [PATCH v2 5/5] powerpc: kprobes: emulate instructions on kprobe handler re-entry
On Wed, 12 Apr 2017 16:28:28 +0530
"Naveen N. Rao" wrote:
> On kprobe handler re-entry, try to emulate the instruction rather than
> single stepping always.
>
> As a related change, remove the duplicate saving of msr as that is
> already done in set_current_kprobe()
If so, this part might be separated as a cleanup patch...
Thanks,
>
> Acked-by: Ananth N Mavinakayanahalli
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerpc/kernel/kprobes.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 8b48f7d046bd..005bd4a75902 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -273,10 +273,17 @@ int __kprobes kprobe_handler(struct pt_regs *regs)
>*/
> save_previous_kprobe(kcb);
> set_current_kprobe(p, regs, kcb);
> - kcb->kprobe_saved_msr = regs->msr;
> kprobes_inc_nmissed_count(p);
> prepare_singlestep(p, regs);
> kcb->kprobe_status = KPROBE_REENTER;
> + if (p->ainsn.boostable >= 0) {
> + ret = try_to_emulate(p, regs);
> +
> + if (ret > 0) {
> + restore_previous_kprobe(kcb);
> + return 1;
> + }
> + }
> return 1;
> } else {
> if (*addr != BREAKPOINT_INSTRUCTION) {
> --
> 2.12.1
>
--
Masami Hiramatsu
Re: [PATCH v2 4/5] powerpc: kprobes: factor out code to emulate instruction into a helper
On Wed, 12 Apr 2017 16:28:27 +0530
"Naveen N. Rao" wrote:
> This helper will be used in a subsequent patch to emulate instructions
> on re-entering the kprobe handler. No functional change.
In this case, please merge this patch into the next patch which
actually uses the factored out function unless that changes
too much.
Thank you,
>
> Acked-by: Ananth N Mavinakayanahalli
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerpc/kernel/kprobes.c | 52
> ++-
> 1 file changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 0732a0291ace..8b48f7d046bd 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -207,6 +207,35 @@ void __kprobes arch_prepare_kretprobe(struct
> kretprobe_instance *ri,
> regs->link = (unsigned long)kretprobe_trampoline;
> }
>
> +int __kprobes try_to_emulate(struct kprobe *p, struct pt_regs *regs)
> +{
> + int ret;
> + unsigned int insn = *p->ainsn.insn;
> +
> + /* regs->nip is also adjusted if emulate_step returns 1 */
> + ret = emulate_step(regs, insn);
> + if (ret > 0) {
> + /*
> + * Once this instruction has been boosted
> + * successfully, set the boostable flag
> + */
> + if (unlikely(p->ainsn.boostable == 0))
> + p->ainsn.boostable = 1;
> + } else if (ret < 0) {
> + /*
> + * We don't allow kprobes on mtmsr(d)/rfi(d), etc.
> + * So, we should never get here... but, its still
> + * good to catch them, just in case...
> + */
> + printk("Can't step on instruction %x\n", insn);
> + BUG();
> + } else if (ret == 0)
> + /* This instruction can't be boosted */
> + p->ainsn.boostable = -1;
> +
> + return ret;
> +}
> +
> int __kprobes kprobe_handler(struct pt_regs *regs)
> {
> struct kprobe *p;
> @@ -302,18 +331,9 @@ int __kprobes kprobe_handler(struct pt_regs *regs)
>
> ss_probe:
> if (p->ainsn.boostable >= 0) {
> - unsigned int insn = *p->ainsn.insn;
> + ret = try_to_emulate(p, regs);
>
> - /* regs->nip is also adjusted if emulate_step returns 1 */
> - ret = emulate_step(regs, insn);
> if (ret > 0) {
> - /*
> - * Once this instruction has been boosted
> - * successfully, set the boostable flag
> - */
> - if (unlikely(p->ainsn.boostable == 0))
> - p->ainsn.boostable = 1;
> -
> if (p->post_handler)
> p->post_handler(p, regs, 0);
>
> @@ -321,17 +341,7 @@ int __kprobes kprobe_handler(struct pt_regs *regs)
> reset_current_kprobe();
> preempt_enable_no_resched();
> return 1;
> - } else if (ret < 0) {
> - /*
> - * We don't allow kprobes on mtmsr(d)/rfi(d), etc.
> - * So, we should never get here... but, its still
> - * good to catch them, just in case...
> - */
> - printk("Can't step on instruction %x\n", insn);
> - BUG();
> - } else if (ret == 0)
> - /* This instruction can't be boosted */
> - p->ainsn.boostable = -1;
> + }
> }
> prepare_singlestep(p, regs);
> kcb->kprobe_status = KPROBE_HIT_SS;
> --
> 2.12.1
>
--
Masami Hiramatsu
Re: [printk] fbc14616f4: BUG:kernel_reboot-without-warning_in_test_stage
On (04/12/17 20:43), Pavel Machek wrote: [..] > > when the limit of "number of lines printed" is 0, then no > > offloading takes place. > > And with "number of lines printed" set to 99, it will get us > previous behaviour, right? `atomic_print_limit' set to zero disables offloading explicitly. at the same time, an unreasonably high `atomic_print_limit' value makes offloading less possible and starting from some value, basically, disables it implicitly. -ss
Re: [PATCH v2 3/5] powerpc: introduce a new helper to obtain function entry points
On Wed, 12 Apr 2017 16:28:26 +0530
"Naveen N. Rao" wrote:
> kprobe_lookup_name() is specific to the kprobe subsystem and may not
> always return the function entry point (in a subsequent patch for
> KPROBES_ON_FTRACE).
If so, please move this patch into that series. It is hard to review
patches which requires for other series.
Thank you,
> For looking up function entry points, introduce a
> separate helper and use the same in optprobes.c
>
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerpc/include/asm/code-patching.h | 37
>
> arch/powerpc/kernel/optprobes.c | 6 +++---
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/code-patching.h
> b/arch/powerpc/include/asm/code-patching.h
> index 8ab937771068..3e994f404434 100644
> --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -12,6 +12,8 @@
>
> #include
> #include
> +#include
> +#include
>
> /* Flags for create_branch:
> * "b" == create_branch(addr, target, 0);
> @@ -99,6 +101,41 @@ static inline unsigned long
> ppc_global_function_entry(void *func)
> #endif
> }
>
> +/*
> + * Wrapper around kallsyms_lookup() to return function entry address:
> + * - For ABIv1, we lookup the dot variant.
> + * - For ABIv2, we return the local entry point.
> + */
> +static inline unsigned long ppc_kallsyms_lookup_name(const char *name)
> +{
> + unsigned long addr;
> +#ifdef PPC64_ELF_ABI_v1
> + /* check for dot variant */
> + char dot_name[1 + KSYM_NAME_LEN];
> + bool dot_appended = false;
> + if (name[0] != '.') {
> + dot_name[0] = '.';
> + dot_name[1] = '\0';
> + strncat(dot_name, name, KSYM_NAME_LEN - 2);
> + dot_appended = true;
> + } else {
> + dot_name[0] = '\0';
> + strncat(dot_name, name, KSYM_NAME_LEN - 1);
> + }
> + addr = kallsyms_lookup_name(dot_name);
> + if (!addr && dot_appended)
> + /* Let's try the original non-dot symbol lookup */
> + addr = kallsyms_lookup_name(name);
> +#elif defined(PPC64_ELF_ABI_v2)
> + addr = kallsyms_lookup_name(name);
> + if (addr)
> + addr = ppc_function_entry((void *)addr);
> +#else
> + addr = kallsyms_lookup_name(name);
> +#endif
> + return addr;
> +}
> +
> #ifdef CONFIG_PPC64
> /*
> * Some instruction encodings commonly used in dynamic ftracing
> diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
> index ce81a322251c..ec60ed0d4aad 100644
> --- a/arch/powerpc/kernel/optprobes.c
> +++ b/arch/powerpc/kernel/optprobes.c
> @@ -243,10 +243,10 @@ int arch_prepare_optimized_kprobe(struct
> optimized_kprobe *op, struct kprobe *p)
> /*
>* 2. branch to optimized_callback() and emulate_step()
>*/
> - op_callback_addr = kprobe_lookup_name("optimized_callback", 0);
> - emulate_step_addr = kprobe_lookup_name("emulate_step", 0);
> + op_callback_addr = (kprobe_opcode_t
> *)ppc_kallsyms_lookup_name("optimized_callback");
> + emulate_step_addr = (kprobe_opcode_t
> *)ppc_kallsyms_lookup_name("emulate_step");
> if (!op_callback_addr || !emulate_step_addr) {
> - WARN(1, "kprobe_lookup_name() failed\n");
> + WARN(1, "Unable to lookup
> optimized_callback()/emulate_step()\n");
> goto error;
> }
>
> --
> 2.12.1
>
--
Masami Hiramatsu
Re: [BUG nohz]: wrong user and system time accounting
2017-04-12 22:57 GMT+08:00 Thomas Gleixner :
> On Wed, 12 Apr 2017, Frederic Weisbecker wrote:
>> On Tue, Apr 11, 2017 at 04:22:48PM +0200, Thomas Gleixner wrote:
>> > It's not different from the current jiffies based stuff at all. Same
>> > failure mode.
>>
>> Yes you're right, I got confused again. So to fix this we could do our
>> snapshots
>> at a frequency lower than HZ but still high enough to avoid overhead.
>>
>> Something like TICK_NSEC / 2 ?
>
> If you are using TSC anyway then you can do proper accumulation for both
> system and user and only account the data when the accumulation is more
> than a jiffie.
So I implement it as below:
- HZ=1000.
1) two cpu hogs on cpu in nohz_full mode, 100% user time
2) Luzi's testcase, ~95% user time, ~5% idle time (as we expected)
- HZ=250
1) two cpu hogs on cpu in nohz_full mode, 100% user time
2) Luzi's testcase, 100% idle
So the codes below still not work correctly for HZ=250, any suggestions?
-->8-
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d67eee8..6a11771 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -668,6 +668,8 @@ struct task_struct {
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
seqcount_tvtime_seqcount;
unsigned long longvtime_snap;
+u64vtime_acct_utime;
+u64vtime_acct_stime;
enum {
/* Task is sleeping or running in a CPU with VTIME inactive: */
VTIME_INACTIVE = 0,
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index f3778e2b..f8e54ba 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -674,20 +674,41 @@ void thread_group_cputime_adjusted(struct
task_struct *p, u64 *ut, u64 *st)
#endif /* !CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
-static u64 vtime_delta(struct task_struct *tsk)
+static u64 vtime_delta(struct task_struct *tsk, bool user)
{
-unsigned long now = READ_ONCE(jiffies);
+u64 delta, ret = 0;
-if (time_before(now, (unsigned long)tsk->vtime_snap))
-return 0;
+delta = sched_clock() - tsk->vtime_snap;
-return jiffies_to_nsecs(now - tsk->vtime_snap);
+if (is_idle_task(tsk)) {
+if (delta >= TICK_NSEC)
+ret = delta;
+} else {
+if (user) {
+tsk->vtime_acct_utime += delta;
+if (tsk->vtime_acct_utime >= TICK_NSEC)
+ret = tsk->vtime_acct_utime;
+} else {
+tsk->vtime_acct_stime += delta;
+if (tsk->vtime_acct_utime >= TICK_NSEC)
+ret = tsk->vtime_acct_stime;
+}
+}
+
+return ret;
}
-static u64 get_vtime_delta(struct task_struct *tsk)
+static u64 get_vtime_delta(struct task_struct *tsk, bool user)
{
-unsigned long now = READ_ONCE(jiffies);
-u64 delta, other;
+u64 delta = vtime_delta(tsk, user);
+u64 other;
+
+if (!is_idle_task(tsk)) {
+if (user)
+tsk->vtime_acct_utime = 0;
+else
+tsk->vtime_acct_stime = 0;
+}
/*
* Unlike tick based timing, vtime based timing never has lost
@@ -696,22 +717,21 @@ static u64 get_vtime_delta(struct task_struct *tsk)
* elapsed time. Limit account_other_time to prevent rounding
* errors from causing elapsed vtime to go negative.
*/
-delta = jiffies_to_nsecs(now - tsk->vtime_snap);
other = account_other_time(delta);
WARN_ON_ONCE(tsk->vtime_snap_whence == VTIME_INACTIVE);
-tsk->vtime_snap = now;
+tsk->vtime_snap += delta;
return delta - other;
}
static void __vtime_account_system(struct task_struct *tsk)
{
-account_system_time(tsk, irq_count(), get_vtime_delta(tsk));
+account_system_time(tsk, irq_count(), get_vtime_delta(tsk, false));
}
void vtime_account_system(struct task_struct *tsk)
{
-if (!vtime_delta(tsk))
+if (!vtime_delta(tsk, false))
return;
write_seqcount_begin(&tsk->vtime_seqcount);
@@ -723,15 +743,15 @@ void vtime_account_user(struct task_struct *tsk)
{
write_seqcount_begin(&tsk->vtime_seqcount);
tsk->vtime_snap_whence = VTIME_SYS;
-if (vtime_delta(tsk))
-account_user_time(tsk, get_vtime_delta(tsk));
+if (vtime_delta(tsk, true))
+account_user_time(tsk, get_vtime_delta(tsk, true));
write_seqcount_end(&tsk->vtime_seqcount);
}
void vtime_user_enter(struct task_struct *tsk)
{
write_seqcount_begin(&tsk->vtime_seqcount);
-if (vtime_delta(tsk))
+if (vtime_delta(tsk, false))
__vtime_account_system(tsk);
tsk->vtime_snap_whence = VTIME_USER;
write_seqcount_end(&tsk->vtime_seqcount);
@@ -747,7 +767,7 @@ void vtime_guest_enter(struct task_struct *tsk)
* that can thus safely catch up with a tickless delta.
*/
write_seqcount_begin(&tsk->vtime_seqcount);
-if (vtime_delta(tsk))
+if (vtime_delta(tsk, false))
Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup
On Thu, Mar 30, 2017 at 12:40:32PM -0700, Tim Murray wrote: > On Thu, Mar 30, 2017 at 8:51 AM, Johannes Weiner wrote: > > In cgroup2, we've added a memory.low knob, where groups within their > > memory.low setting are not reclaimed. > > > > You can set that knob on foreground groups to the amount of memory > > they need to function properly, and set it to 0 on background groups. > > > > Have you tried doing that? > > I have not, but I'm trying to get that working now to evaluate it on Android. > > However, based on other experiences, I don't think it will work well. > We've experimented a lot with different limits in different places > (Java heap limits, hard_reclaim, soft_reclaim) at different times in > the process lifecycle, and the problem has always been that there's no > way for us to know what limit is reasonable. memory.low will have the > same problem. If memory.low is higher than the actual working set of a > foreground process, the system wastes memory (eg, file pages loaded > during app startup that are never used again won't be reclaimed under > pressure). If memory.low is less than the actual working set, > foreground processes will still get hit by thrashing. > > Another issue is that the working set varies tremendously from app to > app. An email client's working set may be 1/10 or 1/20 of a camera > running a computational photography pipeline with multiple captures in > flight. I can imagine a case where it makes sense for a foreground > application to take 50-75% of a device's physical memory (the camera > case or something similar), but I hope that's an extreme outlier > compared to most apps on the system. However, high-memory apps are > often the most performance-sensitive, so reclaim is more likely to > cause problems. > > As a result, I think there's still a need for relative priority > between mem cgroups, not just an absolute limit. > > Does that make sense? I agree with it. Recently, embedded platform's workload for smart things would be much diverse(from game to alarm) so it's hard to handle the absolute limit proactively and userspace has more hints about what workloads are more important(ie, greedy) compared to others although it would be harmful for something(e.g., it's not visible effect to user) As a such point of view, I support this idea as basic approach. And with thrashing detector from Johannes, we can do fine-tune of LRU balancing and vmpressure shooting time better. Johannes, Do you have any concern about this memcg prority idea? Or Do you think the patchset you are preparing solve this situation? > > > Both vmpressure and priority levels are based on reclaim efficiency, > > which is problematic on solid state storage because page reads have > > very low latency. It's rare that pages are still locked from the > > read-in by the time reclaim gets to them on the LRU, so efficiency > > tends to stay at 100%, until the system is essentially livelocked. > > > > On solid state storage, the bigger problem when you don't have enough > > memory is that you can reclaim just fine but wait a significant amount > > of time to refault the recently evicted pages, i.e. on thrashing. > > > > A more useful metric for memory pressure at this point is quantifying > > that time you spend thrashing: time the job spends in direct reclaim > > and on the flipside time the job waits for recently evicted pages to > > come back. Combined, that gives you a good measure of overhead from > > memory pressure; putting that in relation to a useful baseline of > > meaningful work done gives you a portable scale of how effictively > > your job is running. > > This sounds fantastic, and it matches the behavior I've seen around > pagecache thrashing on Android. > > On Android, I think there are three different times where userspace > would do something useful for memory: > > 1. scan priority is creeping up, scanned/reclaim ratio is getting > worse, system is exhibiting signs of approaching severe memory > pressure. userspace should probably kill something if it's got > something it can kill cheaply. > 2. direct reclaim is happening, system is thrashing, things are bad. > userspace should aggressively kill non-critical processes because > performance has already gotten worse. > 3. something's gone horribly wrong, oom_killer is imminent: userspace > should kill everything it possibly can to keep the system stable. > > My vmpressure experiments have focused on #1 because it integrates > nicely with memcg priorities. However, it doesn't seem like a good > approach for #2 or #3. Time spent thrashing sounds ideal for #2. I'm > not sure what to do for #3. The current critical vmpressure event > hasn't been that successful in avoiding oom-killer (on 3.18, at > least)--I've been able to get oom-killer to trigger without a > vmpressure event. > > Assuming that memcg priorities are reasonable, would you be open to > using scan priority info as a vmpressure signal for a low amount of > memory press
Re: [PATCH v2 2/5] powerpc: kprobes: fix handling of function offsets on ABIv2
On Wed, 12 Apr 2017 16:28:25 +0530
"Naveen N. Rao" wrote:
> commit 239aeba76409 ("perf powerpc: Fix kprobe and kretprobe handling
> with kallsyms on ppc64le") changed how we use the offset field in struct
> kprobe on ABIv2. perf now offsets from the GEP (Global entry point) if an
> offset is specified and otherwise chooses the LEP (Local entry point).
>
> Fix the same in kernel for kprobe API users. We do this by extending
> kprobe_lookup_name() to accept an additional parameter to indicate the
> offset specified with the kprobe registration. If offset is 0, we return
> the local function entry and return the global entry point otherwise.
>
> With:
> # cd /sys/kernel/debug/tracing/
> # echo "p _do_fork" >> kprobe_events
> # echo "p _do_fork+0x10" >> kprobe_events
>
> before this patch:
> # cat ../kprobes/list
> c00d0748 k _do_fork+0x8[DISABLED]
> c00d0758 k _do_fork+0x18[DISABLED]
> c00412b0 k kretprobe_trampoline+0x0[OPTIMIZED]
>
> and after:
> # cat ../kprobes/list
> c00d04c8 k _do_fork+0x8[DISABLED]
> c00d04d0 k _do_fork+0x10[DISABLED]
> c00412b0 k kretprobe_trampoline+0x0[OPTIMIZED]
>
> Acked-by: Ananth N Mavinakayanahalli
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerpc/kernel/kprobes.c | 4 ++--
> arch/powerpc/kernel/optprobes.c | 4 ++--
> include/linux/kprobes.h | 2 +-
> kernel/kprobes.c| 7 ---
> 4 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index a7aa7394954d..0732a0291ace 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -42,14 +42,14 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>
> struct kretprobe_blackpoint kretprobe_blacklist[] = {{NULL, NULL}};
>
> -kprobe_opcode_t *kprobe_lookup_name(const char *name)
> +kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
Hmm, if we do this change, it is natural that kprobe_lookup_name()
returns the address + offset.
Thank you,
--
Masami Hiramatsu
Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error
On Wed, Apr 12, 2017 at 7:21 AM, Wolfgang Bumiller
wrote:
> If memory allocation for nla_memdup_cookie() fails
> module_put has to be guarded by the same condition as it was
> before the TCA_ACT_COOKIE has been added as stated in the
> comment afterwards:
>
> /* module count goes up only when brand new policy is created
> * if it exists and is only bound to in a_o->init() then
> * ACT_P_CREATED is not returned (a zero is).
> */
Yeah, this patch makes sense for me too. Just one comment below.
>
> Signed-off-by: Wolfgang Bumiller
> ---
>
> Note that I'm unsure about this patch. The hangups weren't very reliable
> and I couldn't actually reproduce them when building from git/master (as
> I can only test a fraction of my usual workload with it as a lot of my
> data (VMs & containers utilizing veths and tap devices) is on ZFS...).
> In any case it can't harm to take another look at the error handling
> here.
>
> net/sched/act_api.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index 8cc883c063f0..795ac092b723 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -608,15 +608,19 @@ struct tc_action *tcf_action_init_1(struct net *net,
> struct nlattr *nla,
> int cklen = nla_len(tb[TCA_ACT_COOKIE]);
>
> if (cklen > TC_COOKIE_MAX_SIZE) {
> - err = -EINVAL;
> tcf_hash_release(a, bind);
> - goto err_mod;
> + if (err != ACT_P_CREATED)
> + module_put(a_o->owner);
> + err = -EINVAL;
> + goto err_out;
> }
>
> if (nla_memdup_cookie(a, tb) < 0) {
> - err = -ENOMEM;
> tcf_hash_release(a, bind);
> - goto err_mod;
> + if (err != ACT_P_CREATED)
> + module_put(a_o->owner);
> + err = -ENOMEM;
> + goto err_out;
Instead of duplicating code, you can add the check
to the module_put() next to err_mod label? I mean:
@@ -630,7 +630,8 @@ struct tc_action *tcf_action_init_1(struct net
*net, struct nlattr *nla,
return a;
err_mod:
- module_put(a_o->owner);
+ if (err != ACT_P_CREATED)
+ module_put(a_o->owner);
err_out:
return ERR_PTR(err);
}
[tip:WIP.sched/cpusallowed 13/13] drivers/crypto/n2_core.c:1659:31: error: passing argument 2 of 'work_on_cpu_safe' from incompatible pointer type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.sched/cpusallowed
head: 4ba98c7ec4094a9123d0d6aabb4497290207b518
commit: 4ba98c7ec4094a9123d0d6aabb4497290207b518 [13/13] crypto: n2 - Use
work_on_cpu() instead of affinity games
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ba98c7ec4094a9123d0d6aabb4497290207b518
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All error/warnings (new ones prefixed by >>):
drivers/crypto/n2_core.c: In function 'spu_queue_register':
>> drivers/crypto/n2_core.c:1659:31: error: passing argument 2 of
>> 'work_on_cpu_safe' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
return work_on_cpu_safe(cpu, &qr);
^
In file included from include/linux/srcu.h:34:0,
from include/linux/notifier.h:15,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:749,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/crypto/n2_core.c:9:
include/linux/workqueue.h:617:6: note: expected 'long int (*)(void *)' but
argument is of type 'struct spu_qreg *'
long work_on_cpu_safe(int cpu, long (*fn)(void *), void *arg);
^~~~
>> drivers/crypto/n2_core.c:1659:9: error: too few arguments to function
>> 'work_on_cpu_safe'
return work_on_cpu_safe(cpu, &qr);
^~~~
In file included from include/linux/srcu.h:34:0,
from include/linux/notifier.h:15,
from include/linux/memory_hotplug.h:6,
from include/linux/mmzone.h:749,
from include/linux/gfp.h:5,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/crypto/n2_core.c:9:
include/linux/workqueue.h:617:6: note: declared here
long work_on_cpu_safe(int cpu, long (*fn)(void *), void *arg);
^~~~
>> drivers/crypto/n2_core.c:1660:1: warning: control reaches end of non-void
>> function [-Wreturn-type]
}
^
At top level:
drivers/crypto/n2_core.c:1639:13: warning: 'spu_queue_register_workfn'
defined but not used [-Wunused-function]
static long spu_queue_register_workfn(void *arg)
^
cc1: some warnings being treated as errors
vim +/work_on_cpu_safe +1659 drivers/crypto/n2_core.c
1653
1654 static int spu_queue_register(struct spu_queue *p, unsigned long q_type)
1655 {
1656 int cpu = cpumask_any_and(&p->sharing, cpu_online_mask);
1657 struct spu_qreg qr = { .queue = p, .type = q_type };
1658
> 1659 return work_on_cpu_safe(cpu, &qr);
> 1660 }
1661
1662 static int spu_queue_setup(struct spu_queue *p)
1663 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Daniel Kurtz
Experiments show that the:
(1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
(2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
Signed-off-by: Daniel Kurtz
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 13afe48..8ab7ca0 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file,
void *fh,
struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (mtk_mdp_is_target_compose(s->target))
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (mtk_mdp_is_target_crop(s->target))
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (mtk_mdp_is_target_compose(s->target))
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file,
void *fh,
int ret;
bool valid = false;
- if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (s->target == V4L2_SEL_TGT_COMPOSE)
- valid = true;
- } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
if (s->target == V4L2_SEL_TGT_CROP)
valid = true;
+ } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ if (s->target == V4L2_SEL_TGT_COMPOSE)
+ valid = true;
}
if (!valid) {
mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
@@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void
*fh,
if (ret)
return ret;
- if (mtk_mdp_is_target_crop(s->target))
+ if (mtk_mdp_is_target_compose(s->target))
frame = &ctx->s_frame;
else
frame = &ctx->d_frame;
--
1.9.1
Re: [PATCH] mm: add VM_STATIC flag to vmalloc and prevent from removing the areas
On 04/12/2017 10:31 AM, Hoeun Ryu wrote:
> vm_area_add_early/vm_area_register_early() are used to reserve vmalloc area
> during boot process and those virtually mapped areas are never unmapped.
> So `OR` VM_STATIC flag to the areas in vmalloc_init() when importing
> existing vmlist entries and prevent those areas from being removed from the
> rbtree by accident.
I am wondering whether protection against accidental deletion
of any vmap area should be done in remove_vm_area() function
or the callers should take care of it. But I guess either way
it works.
>
> Signed-off-by: Hoeun Ryu
> ---
> include/linux/vmalloc.h | 1 +
> mm/vmalloc.c| 9 ++---
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 46991ad..3df53fc 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -19,6 +19,7 @@ struct notifier_block; /* in notifier.h */
> #define VM_UNINITIALIZED 0x0020 /* vm_struct is not fully
> initialized */
> #define VM_NO_GUARD 0x0040 /* don't add guard page */
> #define VM_KASAN 0x0080 /* has allocated kasan shadow
> memory */
> +#define VM_STATIC0x0200
You might want to add some description in the comment saying
its a sticky VM area which will never go away or something.
> /* bits [20..32] reserved for arch specific ioremap internals */
>
> /*
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 8ef8ea1..fb5049a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1262,7 +1262,7 @@ void __init vmalloc_init(void)
> /* Import existing vmlist entries. */
> for (tmp = vmlist; tmp; tmp = tmp->next) {
> va = kzalloc(sizeof(struct vmap_area), GFP_NOWAIT);
> - va->flags = VM_VM_AREA;
> + va->flags = VM_VM_AREA | VM_STATIC;
> va->va_start = (unsigned long)tmp->addr;
> va->va_end = va->va_start + tmp->size;
> va->vm = tmp;
> @@ -1480,7 +1480,7 @@ struct vm_struct *remove_vm_area(const void *addr)
> might_sleep();
>
> va = find_vmap_area((unsigned long)addr);
> - if (va && va->flags & VM_VM_AREA) {
> + if (va && va->flags & VM_VM_AREA && likely(!(va->flags & VM_STATIC))) {
You might want to move the VM_STATIC check before the VM_VM_AREA
check so in cases where the former is set we can save one more
conditional check.
RE: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.
> On Wed, Apr 5, 2017 at 6:58 AM, Wu Hao wrote:
> > On Mon, Apr 03, 2017 at 04:44:15PM -0500, Alan Tull wrote:
> >> On Thu, Mar 30, 2017 at 7:08 AM, Wu Hao wrote:
> >> > From: Xiao Guangrong
> >> >
> >> > Device Featuer List structure creates a link list of feature headers
> >> > within the MMIO space to provide an extensiable way of adding features.
> >> >
> >> > The Intel FPGA PCIe driver walks through the feature headers to enumerate
> >> > feature devices, FPGA Management Engine (FME) and FPGA Port for
> Accelerated
> >> > Function Unit (AFU), and their private sub features. For feature devices,
> >> > it creates the platform devices and linked the private sub features into
> >> > their platform data.
> >> >
> >> > Signed-off-by: Tim Whisonant
> >> > Signed-off-by: Enno Luebbers
> >> > Signed-off-by: Shiva Rao
> >> > Signed-off-by: Christopher Rauer
> >> > Signed-off-by: Kang Luwei
> >> > Signed-off-by: Zhang Yi
> >> > Signed-off-by: Xiao Guangrong
> >> > Signed-off-by: Wu Hao
> >> > ---
> >> > drivers/fpga/intel/Makefile | 2 +-
> >> > drivers/fpga/intel/feature-dev.c | 139 +++
> >> > drivers/fpga/intel/feature-dev.h | 342
> >> > drivers/fpga/intel/pcie.c| 841
> ++-
> >> > 4 files changed, 1321 insertions(+), 3 deletions(-)
> >> > create mode 100644 drivers/fpga/intel/feature-dev.c
> >> > create mode 100644 drivers/fpga/intel/feature-dev.h
> >> >
> >> > diff --git a/drivers/fpga/intel/Makefile b/drivers/fpga/intel/Makefile
> >> > index 61fd8ea..c029940 100644
> >> > --- a/drivers/fpga/intel/Makefile
> >> > +++ b/drivers/fpga/intel/Makefile
> >> > @@ -1,3 +1,3 @@
> >> > obj-$(CONFIG_INTEL_FPGA_PCI) += intel-fpga-pci.o
> >> >
> >> > -intel-fpga-pci-objs := pcie.o
> >> > +intel-fpga-pci-objs := pcie.o feature-dev.o
> >> > diff --git a/drivers/fpga/intel/feature-dev.c
> >> > b/drivers/fpga/intel/feature-
> dev.c
> >> > new file mode 100644
> >> > index 000..6952566
> >> > --- /dev/null
> >> > +++ b/drivers/fpga/intel/feature-dev.c
> >> > @@ -0,0 +1,139 @@
> >> > +/*
> >> > + * Intel FPGA Feature Device Driver
> >> > + *
> >> > + * Copyright (C) 2017 Intel Corporation, Inc.
> >> > + *
> >> > + * Authors:
> >> > + * Kang Luwei
> >> > + * Zhang Yi
> >> > + * Wu Hao
> >> > + * Xiao Guangrong
> >> > + *
> >> > + * This work is licensed under a dual BSD/GPLv2 license. When using or
> >> > + * redistributing this file, you may do so under either license. See the
> >> > + * LICENSE.BSD file under this directory for the BSD license and see
> >> > + * the COPYING file in the top-level directory for the GPLv2 license.
> >> > + */
> >> > +
> >> > +#include "feature-dev.h"
> >> > +
> >> > +void feature_platform_data_add(struct feature_platform_data *pdata,
> >> > + int index, const char *name,
> >> > + int resource_index, void __iomem *ioaddr)
> >> > +{
> >> > + WARN_ON(index >= pdata->num);
> >> > +
> >> > + pdata->features[index].name = name;
> >> > + pdata->features[index].resource_index = resource_index;
> >> > + pdata->features[index].ioaddr = ioaddr;
> >> > +}
> >> > +
> >> > +int feature_platform_data_size(int num)
> >> > +{
> >> > + return sizeof(struct feature_platform_data) +
> >> > + num * sizeof(struct feature);
> >> > +}
> >> > +
> >> > +struct feature_platform_data *
> >> > +feature_platform_data_alloc_and_init(struct platform_device *dev, int
> num)
> >> > +{
> >> > + struct feature_platform_data *pdata;
> >> > +
> >> > + pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> >> > + if (pdata) {
> >> > + pdata->dev = dev;
> >> > + pdata->num = num;
> >> > + mutex_init(&pdata->lock);
> >> > + }
> >> > +
> >> > + return pdata;
> >> > +}
> >> > +
> >> > +int fme_feature_num(void)
> >> > +{
> >> > + return FME_FEATURE_ID_MAX;
> >> > +}
> >> > +
> >> > +int port_feature_num(void)
> >> > +{
> >> > + return PORT_FEATURE_ID_MAX;
> >> > +}
> >> > +
> >> > +int fpga_port_id(struct platform_device *pdev)
> >> > +{
> >> > + struct feature_port_header *port_hdr;
> >> > + struct feature_port_capability capability;
> >> > +
> >> > + port_hdr = get_feature_ioaddr_by_index(&pdev->dev,
> >> > + PORT_FEATURE_ID_HEADER);
> >> > + WARN_ON(!port_hdr);
> >> > +
> >> > + capability.csr = readq(&port_hdr->capability);
> >> > + return capability.port_number;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(fpga_port_id);
> >> > +
> >> > +/*
> >> > + * Enable Port by clear the port soft reset bit, which is set by
> >> > default.
> >> > + * The User AFU is unable to respond to any MMIO access while in reset.
> >> > + * __fpga_port_enable function should only be used after
> __fpga_port_disable
> >> > + * function.
> >> > + */
> >> > +void __fpga_port_enable(struct pl
Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop
On Thu, 2017-04-13 at 09:28 +0530, Aneesh Kumar K.V wrote: > > #endif > > mtctr r12 > > bctrl > > +/* > > + * cur_cpu_spec->cpu_restore would restore LPCR to a > > + * sane value that is set at early boot time, > > + * thereby clearing LPCR_UPRT. > > + * LPCR_UPRT is required if we are running in Radix mode. > > + * Set it here if that be the case. > > + */ > > +BEGIN_MMU_FTR_SECTION > > + mfspr r3, SPRN_LPCR > > + LOAD_REG_IMMEDIATE(r4, LPCR_UPRT) > > + or r3, r3, r4 > > + mtspr SPRN_LPCR, r3 > > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX) We are probably better off saving the value somewhere during boot and just "blasting" it whole back. Cheers Ben.
Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board
Hi Heiko, On 04/12/2017 09:29 PM, Heiko Stuebner wrote: Hi Kever, Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang: Firefly-rk3399 is a bord from T-Firefly, you can find detail about it here: http://en.t-firefly.com/en/firenow/Firefly_RK3399/ This patch add basic node for the board and make it able to bring up. Peripheral works: - usb hub which connect to ehci controller; - UART2 debug - eMMC - PCIe Not work: - USB 3.0 HOST, type-C port - sdio, sd-card Not test for other peripheral: - HDMI - Ethernet - OPTICAL - WiFi/BT - MIPI CSI/DSI - IR - EDP/DP Signed-off-by: Kever Yang applied for 4.13, as we're a bit late for 4.12, with the following changes: Thanks for your help, I'm not familiar with the devices status on upstream because not working on kernel upstream for a long time. - commit subject - dropped status from backlight (as there is no disabled common node and it's specific to the firefly itself) - quite some reordering of properties - reordered regulator nodes per their addresses: 0x1b < 0x40 - dropped obsolete regulator-compatible properties - fixed gpio-irq on the mpu6500 - dropped out-of-tree orientation properties of mpu6500 --> please provide the optional "mount-matrix" in a follow-up patch see bindings/iio/imu/inv_mpu6050.txt Maybe we can drop this mpu6050 node first? I can't find binding file for it. - dropped rockchip,i2s-broken-burst-len; That change never made it into the mainline kernel - fixed pcie pinctrl indentation - dropped wireless-bluetooth uart-gpios pinctrl - dropped supports-emmc property Please try to be a bit more careful when porting stuff from device kernels with respect to properties not found in the mainline kernel and please also double-check in [0] that I didn't break anything. I have test this patch on my firefly-rk3399, it works fine with pwm2 regulator init in U-Boot. Thanks, - Kever Thanks Heiko [0] https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=495a3c891a696b62465d71b1a125e3424352028b
[PATCH v2] efi: Config options to assign versions in the PE-COFF header
This commit adds the new config options to allow the user to modify the following fields in the PE-COFF header. UINT16 MajorOperatingSystemVersion UINT16 MinorOperatingSystemVersion UINT16 MajorImageVersion UINT16 MinorImageVersion Those fields are mainly for the executables or libraries in Windows NT or higher to specify the minimum supported Windows version and the version of the image itself. Given the fact that those fields are ignored in UEFI, we can safely reuse those fields for other purposes, e.g. Security Version(*). (*) https://github.com/lcp/shim/wiki/Security-Version v2 changes: - Modify the header direct instead of using an external script as suggested by Ard Biesheuvel - Include arm and arm64 Cc: Russell King Cc: Matt Fleming Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Will Deacon Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Joey Lee Cc: Vojtech Pavlik Signed-off-by: Gary Lin --- arch/arm/Kconfig | 24 arch/arm/boot/compressed/efi-header.S | 8 arch/arm64/Kconfig| 24 arch/arm64/kernel/head.S | 8 arch/x86/Kconfig | 24 arch/x86/boot/header.S| 8 6 files changed, 84 insertions(+), 12 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0d4e71b42c77..4965ad2ccc23 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2090,6 +2090,30 @@ config EFI is only useful for kernels that may run on systems that have UEFI firmware. +config EFI_MAJOR_OS + hex "EFI Major OS Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MINOR_OS + hex "EFI Minor OS Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MAJOR_IMAGE + hex "EFI Major Image Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MINOR_IMAGE + hex "EFI Minor Image Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + endmenu menu "CPU Power Management" diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S index 9d5dc4fda3c1..67715472a76f 100644 --- a/arch/arm/boot/compressed/efi-header.S +++ b/arch/arm/boot/compressed/efi-header.S @@ -69,10 +69,10 @@ extra_header_fields: .long 0 @ ImageBase .long 0x200 @ SectionAlignment .long 0x200 @ FileAlignment - .short 0 @ MajorOperatingSystemVersion - .short 0 @ MinorOperatingSystemVersion - .short 0 @ MajorImageVersion - .short 0 @ MinorImageVersion + .short CONFIG_EFI_MAJOR_OS @ MajorOperatingSystemVersion + .short CONFIG_EFI_MINOR_OS @ MinorOperatingSystemVersion + .short CONFIG_EFI_MAJOR_IMAGE @ MajorImageVersion + .short CONFIG_EFI_MINOR_IMAGE @ MinorImageVersion .short 0 @ MajorSubsystemVersion .short 0 @ MinorSubsystemVersion .long 0 @ Win32VersionValue diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3741859765cf..c782c422e58c 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1033,6 +1033,30 @@ config EFI allow the kernel to be booted as an EFI application. This is only useful on systems that have UEFI firmware. +config EFI_MAJOR_OS + hex "EFI Major OS Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MINOR_OS + hex "EFI Minor OS Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MAJOR_IMAGE + hex "EFI Major Image Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + +config EFI_MINOR_IMAGE + hex "EFI Minor Image Version" + range 0x0 0x + default "0x0" + depends on EFI_STUB + config DMI bool "Enable support for SMBIOS (DMI) tables" depends on EFI diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index 4fb6ccd886d1..9faa4b04d0ef 100644 --- a/arch/arm64/kernel/head.S +++ b/arch/arm64/kernel/head.S @@ -129,10 +129,10 @@ extra_header_fields: .quad 0 // ImageBase .long 0x1000 // SectionAlignment .long PECOFF_FILE_ALIGNMENT // FileAlignment - .short 0 // MajorOperatingSystemVersion - .short 0 // MinorOperatingSystemVersion - .short 0
Re: [PATCH 3/3] powernv:idle: Set LPCR_UPRT on wakeup from deep-stop
"Gautham R. Shenoy" writes: > From: "Gautham R. Shenoy" > > On wakeup from a deep-stop used for CPU-Hotplug, we invoke > cur_cpu_spec->cpu_restore() which would set sane default values to > various SPRs including LPCR. > > On POWER9, the cpu_restore_power9() call would would restore LPCR to a > sane value that is set at early boot time, thereby clearing LPCR_UPRT. > > However, LPCR_UPRT is required to be set if we are running in Radix > mode. If this is not set we will end up with a crash when we enable > IR,DR. > > To fix this, after returning from cur_cpu_spec->cpu_restore() in the > idle exit path, set LPCR_UPRT if we are running in Radix mode. > > Cc: Aneesh Kumar K.V > Signed-off-by: Gautham R. Shenoy > --- > arch/powerpc/kernel/idle_book3s.S | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/arch/powerpc/kernel/idle_book3s.S > b/arch/powerpc/kernel/idle_book3s.S > index 6a9bd28..39a9b63 100644 > --- a/arch/powerpc/kernel/idle_book3s.S > +++ b/arch/powerpc/kernel/idle_book3s.S > @@ -804,6 +804,19 @@ no_segments: > #endif > mtctr r12 > bctrl > +/* > + * cur_cpu_spec->cpu_restore would restore LPCR to a > + * sane value that is set at early boot time, > + * thereby clearing LPCR_UPRT. > + * LPCR_UPRT is required if we are running in Radix mode. > + * Set it here if that be the case. > + */ > +BEGIN_MMU_FTR_SECTION > + mfspr r3, SPRN_LPCR > + LOAD_REG_IMMEDIATE(r4, LPCR_UPRT) > + or r3, r3, r4 > + mtspr SPRN_LPCR, r3 > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_RADIX) What about LPCR_HR ? > > hypervisor_state_restored: > > -- > 1.9.4 -aneesh
Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.
[Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.] On 13/04/2017 (Thu 13:27) Stephen Rothwell wrote: > Hi Paul, > > On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker > wrote: > > > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were already > > excluded by the original dependency. > > My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... > > $ grep CONFIG_64BIT ~/next/powerpc_ppc64_defconfig/.config > CONFIG_64BIT=y I must have fat fingered the grep; I was using the PA Semi defconfig since I knew that was 64 bit. I probably searched for 64_BIT or something stupid. The underscore ARM64 vs. X86_64 always gets me. In the end, it doesn't change the commit itself, since the driver still only builds on X86_64, S390 and ARM64(but only after my patch). The ppc64 was also never compile tested it seems. I can tweak the commit log of this patch in a v2 once there has been a chance for others to put in their feedback as well. Here is the spew I got when I tried to compile hmm on next/master ppc64. Paul. -- CC mm/hmm.o mm/hmm.c: In function 'hmm_devmem_radix_release': mm/hmm.c:784:30: error: 'PA_SECTION_SHIFT' undeclared (first use in this function) #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) ^ mm/hmm.c:790:36: note: in expansion of macro 'SECTION_SIZE' align_start = resource->start & ~(SECTION_SIZE - 1); ^ mm/hmm.c:784:30: note: each undeclared identifier is reported only once for each function it appears in #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) ^ mm/hmm.c:790:36: note: in expansion of macro 'SECTION_SIZE' align_start = resource->start & ~(SECTION_SIZE - 1); ^ mm/hmm.c: In function 'hmm_devmem_release': mm/hmm.c:784:30: error: 'PA_SECTION_SHIFT' undeclared (first use in this function) #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) ^ mm/hmm.c:812:36: note: in expansion of macro 'SECTION_SIZE' align_start = resource->start & ~(SECTION_SIZE - 1); ^ mm/hmm.c:816:2: error: implicit declaration of function 'arch_remove_memory' [-Werror=implicit-function-declaration] arch_remove_memory(align_start, align_size, devmem->pagemap.type); ^ mm/hmm.c: In function 'hmm_devmem_find': mm/hmm.c:827:54: error: 'PA_SECTION_SHIFT' undeclared (first use in this function) return radix_tree_lookup(&hmm_devmem_radix, phys >> PA_SECTION_SHIFT); ^ mm/hmm.c: In function 'hmm_devmem_pages_create': mm/hmm.c:784:30: error: 'PA_SECTION_SHIFT' undeclared (first use in this function) #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) ^ mm/hmm.c:838:44: note: in expansion of macro 'SECTION_SIZE' align_start = devmem->resource->start & ~(SECTION_SIZE - 1); ^ In file included from include/linux/cache.h:4:0, from include/linux/printk.h:8, from include/linux/kernel.h:13, from include/asm-generic/bug.h:15, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/mmdebug.h:4, from include/linux/mm.h:8, from mm/hmm.c:20: mm/hmm.c: In function 'hmm_devmem_add': mm/hmm.c:784:30: error: 'PA_SECTION_SHIFT' undeclared (first use in this function) #define SECTION_SIZE (1UL << PA_SECTION_SHIFT) ^ include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK' #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask)) ^ include/linux/kernel.h:49:22: note: in expansion of macro '__ALIGN_KERNEL' #define ALIGN(x, a) __ALIGN_KERNEL((x), (a)) ^ mm/hmm.c:982:9: note: in expansion of macro 'ALIGN' size = ALIGN(size, SECTION_SIZE); ^ mm/hmm.c:982:21: note: in expansion of macro 'SECTION_SIZE' size = ALIGN(size, SECTION_SIZE); ^ mm/hmm.c: In function 'hmm_devmem_find': mm/hmm.c:828:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ cc1: some warnings being treated as errors scripts/Makefile.build:294: recipe for target 'mm/hmm.o' failed make[2]: *** [mm/hmm.o] Error 1 make[2]: *** Waiting for unfinished jobs Makefile:1663: recipe for target 'mm/' failed make[1]: *** [mm/] Error 2 make[1]: Leaving directory '/home/paul/git/ppc-build' Makefile:152: recipe for target 'sub-make' failed make: *** [sub-make] Error 2
Re: [PATCH] thermal: core: Add a back up thermal shutdown mechanism
On Thursday 13 April 2017 12:13 AM, Tero Kristo wrote:
> On 12/04/17 20:24, Eduardo Valentin wrote:
>> On Wed, Apr 12, 2017 at 10:41:00PM +0530, Keerthy wrote:
>>>
>>>
>>> On Wednesday 12 April 2017 10:38 PM, Grygorii Strashko wrote:
On 04/12/2017 11:44 AM, Keerthy wrote:
>
>
> On Wednesday 12 April 2017 10:01 PM, Grygorii Strashko wrote:
>>
>>
>> On 04/12/2017 10:44 AM, Eduardo Valentin wrote:
>>> Hello,
>>>
>> ...
>>
>>>
>>> I agree. But there it nothing that says it is not reenterable. If
>>> you
>>> saw something in this line, can you please share?
>>>
>> will you generate a patch to do this?
> Sure. I will generate a patch to take care of 1) To make sure that
> orderly_poweroff is called only once right away. I have already
> tested.
>
> for 2) Cancel all the scheduled work queues to monitor the
> temperature.
> I will take some more time to make it and test.
>
> Is that okay? Or you want me to send both together?
>
I think you can send patch for step 1 first.
>>>
>>> I am happy to see that Keerthy found the problem with his setup
>>> and a
>>> possible solution. But I have a few concerns here.
>>>
>>> 1. If regular shutdown process takes 10seconds, that is a
>>> ballpark that
>>> thermal should never wait. orderly_poweroff() calls run_cmd()
>>> with wait
>>> flag set. That means, if regular userland shutdown takes 10s, we are
>>> waiting for it. Obviously this not acceptable. Specially if you
>>> setup
>>> critical trip to be 125C. Now, if you properly size the critical
>>> trip to
>>> fire before hotspot really reach 125C, for 10s (or the time it
>>> takes to
>>> shutdown), then fine. But based on what was described in this
>>> thread,
>>> his system is waiting 10s on regular shutdown, and his silicon is on
>>> out-of-spec temperature for 10s, which is wrong.
>>>
>>> 2. The above scenario is not acceptable in a long run, specially
>>> from a
>>> reliability perspective. If orderly_poweroff() has a possibility to
>>> simply never return (or take too long), I would say the thermal
>>> subsystem is using the wrong API.
^ this question just repeat everything which was already discussed in
previous versions of this patch - orderly_poweroff() is not good for
critical shutdown/poweroff,
but what to use instead?
>>
>> It is still useful on a properly sized system. The point is the thermal
>> subsystem still wants to give one opportunity to gracefully shutdown the
>> running system on a thermal scenario, as I explained in the other email.
>> But, you have to do this accounting the down time, and your reliability
>> concerns.
>>
>>>
>>
>>
>> Hh, I do not see that orderly_poweroff() will wait for anything now:
>> void orderly_poweroff(bool force)
>> {
>> if (force) /* do not override the pending "true" */
>> poweroff_force = true;
>> schedule_work(&poweroff_work);
>> ^^^ async call. even here can be pretty big delay if system is
>> under pressure
>> }
>>
>>
>> static int __orderly_poweroff(bool force)
>> {
>> int ret;
>>
>> ret = run_cmd(poweroff_cmd);
>
> When i tried with multiple orderly_poweroff calls ret was always 0.
> So every 250mS i see this ret = 0.
>
>> no wait for the process - only for exec. flags == UMH_WAIT_EXEC
>>
>> if (ret && force) {
>
> So it never entered this path. ret = 0 so if is not executed.
correct, because exec can find poweroff tool and start it, so you,
most probably, have bunch of this tool instance running in parallel
(some of them can fail or block)
Issue 1 - you've sent fix for is actual :).
>>>
>>> Precisely yes!
>>>
>>
>> As I mentioned, the fix is a two fold, a. avoid spam of
>> orderly_poweroff(), but make sure eventually we shutdown.
>
> Just chirping in here a bit myself also, the long latencies in the
> poweroff executing are basically because in our case it will do all of
> the following:
>
> - stop all running daemons
> - kill all remaining processes
> - unload all modules
> - sync / unmount all filesystems
> - etc.
> - poweroff the system when everything else has been gracefully done
>
> The order of these things are not necessarily what I listed above, but
> overall it takes quite a bit of time. It doesn't matter if you execute
> all of this over NFS or SD card or ramdisk, it is a long procedure.
Yes. Thanks for the pointers Tero.
As i had mentioned, Here is the log on DRA72-EVM with arago filesystem
over nfs on the next branch with my patch to restrict orderly_poweroff
to one cycle.
http://pastebin.ubuntu.com/24371980/
I triggered thermal shutdown by using THERMAL_EMULATION.
5-10
Re: [PATCH v2 0/3] of: Make of_match_node() an inline stub for CONFIG_OF=n
On 04/11/17 21:41, Florian Fainelli wrote: > Hi all, > > This patch series makes of_match_node() an inline stub for CONFIG_OF=n. kbuild > reported two build errors which are fixed as preriquisite patches. > > This is based on Linus' master, not sure which tree would merge this, Frank's? It would come in via Rob. I am not comfortable with patch 3/3 at this moment. Version 1 of the patch resulted in two errors from the kbuild test robot. This version results in another error from the kbuild test robot. I know it is a lot of work, but please look at all of the callers of of_match_node() and check whether any of the other callers will have the same type of error that the kbuild test robot is catching. -Frank > > Thanks! > > Florian Fainelli (3): > mfd: max8998: Remove CONFIG_OF around max8998_dt_match > net: macb: Remove CONFIG_OF around DT match table > of: Make of_match_node() an inline stub for CONFIG_OF=n > > drivers/mfd/max8998.c | 2 -- > drivers/net/ethernet/cadence/macb.c | 2 -- > include/linux/of.h | 6 +- > 3 files changed, 5 insertions(+), 5 deletions(-) >
Re: [BUG] alpha: module xxx: Unknown relocation: 1
On Wed, Apr 12, 2017 at 07:36:36PM +1200, Michael Cree wrote: > On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote: > > On 12.04.2017 04:59, Bob Tracy wrote: > > > Bottom line is, no kernel I've built since 4.9 can load a module. All > > > attempts to load a module result in the error message emitted by > > > "arch/alpha/kernel/module.c" as follows: > > > > > > module XXX: Unknown relocation: 1 > > > > I assume it's due this commmit "modversions: treat symbol CRCs as 32 bit > > quantities": > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71810db27c1c853b335675bee335d893bc3d324b > > > > For parisc this patch solves it: > > parisc: support R_PARISC_SECREL32 relocation in modules > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5f655322b1ba4bd46e26e307d04098f9c84df764 > > > > > module XXX: Unknown relocation: 1 > > > > For alpha it seems you need to add similar code to handle R_ALPHA_REFLONG > > to apply_relocate_add() in arch/alpha/kernel/module.c > > Would the attached patch fix it? Untested because I don't see the > above issue. I'm up and running on 4.11.0-rc6. The patch works. Feel free to add me as the "Tested-by". Much appreciated! --Bob
linux-next: manual merge of the tty tree with the bluetooth tree
Hi Greg,
Today's linux-next merge of the tty tree got a conflict in:
include/linux/serdev.h
between commits:
b3f80c8f75ef ("serdev: add serdev_device_wait_until_sent")
5659dab26f09 ("serdev: implement get/set tiocm")
from the bluetooth tree and commit:
6fe729c4bdae ("serdev: Add serdev_device_write subroutine")
from the tty tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/serdev.h
index 37395b8eb8f1,0beaff886992..
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@@ -191,10 -190,8 +195,11 @@@ int serdev_device_open(struct serdev_de
void serdev_device_close(struct serdev_device *);
unsigned int serdev_device_set_baudrate(struct serdev_device *, unsigned int);
void serdev_device_set_flow_control(struct serdev_device *, bool);
+void serdev_device_wait_until_sent(struct serdev_device *, long);
+int serdev_device_get_tiocm(struct serdev_device *);
+int serdev_device_set_tiocm(struct serdev_device *, int, int);
- int serdev_device_write_buf(struct serdev_device *, const unsigned char *,
size_t);
+ void serdev_device_write_wakeup(struct serdev_device *);
+ int serdev_device_write(struct serdev_device *, const unsigned char *,
size_t, unsigned long);
void serdev_device_write_flush(struct serdev_device *);
int serdev_device_write_room(struct serdev_device *);
@@@ -231,16 -228,8 +236,17 @@@ static inline unsigned int serdev_devic
return 0;
}
static inline void serdev_device_set_flow_control(struct serdev_device *sdev,
bool enable) {}
+static inline void serdev_device_wait_until_sent(struct serdev_device *sdev,
long timeout) {}
+static inline int serdev_device_get_tiocm(struct serdev_device *serdev)
+{
+ return -ENOTSUPP;
+}
+static inline int serdev_device_set_tiocm(struct serdev_device *serdev, int
set, int clear)
+{
+ return -ENOTSUPP;
+}
- static inline int serdev_device_write_buf(struct serdev_device *sdev, const
unsigned char *buf, size_t count)
+ static inline int serdev_device_write(struct serdev_device *sdev, const
unsigned char *buf,
+ size_t count, unsigned long timeout)
{
return -ENODEV;
}
Re: [PATCH v3 21/32] powerpc: include default ioremap_nopost() implementation
Benjamin Herrenschmidt writes: > On Tue, 2017-04-11 at 15:24 +0100, Lorenzo Pieralisi wrote: >> Ok, point taken. BTW, may I ask you guys to have a look into this >> please ? >> >> https://lkml.org/lkml/2017/4/6/743 >> >> It is a side effect of this thread (v2), not sure why >> on powerpc has to include . > > Not sure how we ended up with that... it's odd indeed. > > Michael ? Any reason we can't just remove it ? No ... idea. Looks like it was added in: commit b41e5fffe8b81fc939067d8c1c195cc79115d5a3 Author: Emil Medve AuthorDate: Sat May 3 06:34:04 2008 +1000 Commit: Paul Mackerras CommitDate: Mon May 5 16:47:14 2008 +1000 [POWERPC] devres: Add devm_ioremap_prot() We provide an ioremap_flags, so this provides a corresponding devm_ioremap_prot. The slight name difference is at Ben Herrenschmidt's request as he plans on changing ioremap_flags to ioremap_prot in the future. Signed-off-by: Emil Medve Signed-off-by: Kumar Gala Acked-by: Tejun Heo Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Paul Mackerras diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h index afae0697e8ce..e0062d73db1c 100644 --- a/include/asm-powerpc/io.h +++ b/include/asm-powerpc/io.h @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port); #define _PNPWRP0xa79 #define PNPBIOS_BASE 0xf000 +#include +#include + #include #include #include @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address) #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set) +void __iomem *devm_ioremap_prot(struct device *dev, resource_size_t offset, + size_t size, unsigned long flags); + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_IO_H */ I'll try removing it and see what breaks. cheers
Re: [PATCH v5 3/3] blackfin: bf609: let clk_disable() return immediately if clk is NULL
Hi Andrew
2017-03-28 18:17 GMT+09:00 Masahiro Yamada :
> In many of clk_disable() implementations, it is a no-op for a NULL
> pointer input, but this is one of the exceptions.
>
> Making it treewide consistent will allow clock consumers to call
> clk_disable() without NULL pointer check.
>
> Signed-off-by: Masahiro Yamada
This is the last clk_disable() that could cause NULL pointer access.
This is blocking clk consumer cleanup works.
I poked the Blackfin maintainer several times, but no response.
Actually, the maintainer has not been picking up any patches for a long time.
Please pick up this patch through your tree.
> ---
>
> Changes in v5: None
> Changes in v4:
> - Split into per-arch patches
>
> Changes in v3:
> - Return only when clk is NULL. Do not take care of error pointer.
>
> Changes in v2:
> - Rebase on Linux 4.6-rc1
>
> arch/blackfin/mach-bf609/clock.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/blackfin/mach-bf609/clock.c
> b/arch/blackfin/mach-bf609/clock.c
> index 3783058..392a59b 100644
> --- a/arch/blackfin/mach-bf609/clock.c
> +++ b/arch/blackfin/mach-bf609/clock.c
> @@ -97,6 +97,9 @@ EXPORT_SYMBOL(clk_enable);
>
> void clk_disable(struct clk *clk)
> {
> + if (!clk)
> + return;
> +
> if (clk->ops && clk->ops->disable)
> clk->ops->disable(clk);
> }
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 4/4] mm/hmm: exclude 64 bit arch that explicitly fail to work.
Hi Paul, On Wed, 12 Apr 2017 20:30:14 -0400 Paul Gortmaker wrote: > > Since ia64 and ppc64 don't set CONFIG_64BIT, they were already > excluded by the original dependency. My powerpc ppc64_defconfig builds have CONFIG_64BIT set ... $ grep CONFIG_64BIT ~/next/powerpc_ppc64_defconfig/.config CONFIG_64BIT=y -- Cheers, Stephen Rothwell
Re: [PATCH v4 0/5] perf report: Show branch type
On 4/13/2017 10:00 AM, Jin, Yao wrote: On 4/12/2017 6:58 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote: SNIP 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking for branch cross 4K or 2M area. It's an approximate computing for checking if the branch cross 4K page or 2MB page. For example: perf record -g --branch-filter any,save_type perf report --stdio JCC forward: 27.7% JCC backward: 9.8% JMP: 0.0% IND_JMP: 6.5% CALL: 26.6% IND_CALL: 0.0% RET: 29.3% IRET: 0.0% CROSS_4K: 0.0% CROSS_2M: 14.3% got mangled perf report --stdio output for: [root@ibm-x3650m4-02 perf]# ./perf record -j any,save_type kill kill: not enough arguments [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.013 MB perf.data (18 samples) ] [root@ibm-x3650m4-02 perf]# ./perf report --stdio -f | head -30 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 253 of event 'cycles' # Event count (approx.): 253 # # Overhead Command Source Shared Object Source SymbolTarget SymbolBasic Block Cycles # ... ... ... .. # 8.30% perf Um [kernel.vmlinux] [k] __intel_pmu_enable_all.constprop.17 [k] native_write_msr - 7.91% perf Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_all [k] __intel_pmu_enable_all.constprop.17 - 7.91% perf Um [kernel.vmlinux] [k] native_write_msr [k] intel_pmu_lbr_enable_all - 6.32% kill libc-2.24.so [.] _dl_addr [.] _dl_addr - 5.93% perf Um [kernel.vmlinux] [k] perf_iterate_ctx [k] perf_iterate_ctx - 2.77% kill libc-2.24.so [.] malloc [.] malloc - 1.98% kill libc-2.24.so [.] _int_malloc [.] _int_malloc - 1.58% kill [kernel.vmlinux] [k] __rb_insert_augmented[k] __rb_insert_augmented- 1.58% perf Um [kernel.vmlinux] [k] perf_event_exec [k] perf_event_exec - 1.19% kill [kernel.vmlinux] [k] anon_vma_interval_tree_insert[k] anon_vma_interval_tree_insert- 1.19% kill [kernel.vmlinux] [k] free_pgd_range [k] free_pgd_range - 1.19% kill [kernel.vmlinux] [k] n_tty_write [k] n_tty_write - 1.19% perf Um [kernel.vmlinux] [k] native_sched_clock [k] sched_clock - ... SNIP jirka Sorry, I look at this issue at midnight in Shanghai. I misunderstood that the above output was only a mail format issue. Sorry about that. Now I recheck the output, and yes, the perf report output is mangled. But my patch doesn't touch the associated code. Anyway I remove my patches, pull the latest update from perf/core branch and run tests to check if its a regression issue. I test on HSW and SKL both. 1. On HSW. root@hsw:/tmp# perf record -j any kill .. /* SNIP */ For more details see kill(1). [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.014 MB perf.data (9 samples) ] root@hsw:/tmp# perf report --stdio # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 144 of event 'cycles' # Event count (approx.): 144 # # Overhead Command Source Shared Object Source SymbolTarget SymbolBasic Block Cycles # ... ... ... .. # 10.42% kill libc-2.23.so [.] read_alias_file [.] read_alias_file - 9.72% kill [kernel.vmlinux] [k] update_load_avg [k] update_load_avg - 9.03% perf Um [unknown] [k] [k] - 8.33% kill libc-2.23.so [.] _int_malloc [.] _int_malloc - .. /* SNIP */ 0.69% kill [kernel.vmlinux] [k] _raw_spin_lock [k] unmap_page_range - 0.69% perf Um [kernel.vmlinux] [k] __intel_pmu_enable_all [k] native_write_msr - 0.69%
[tip:WIP.sched/cpusallowed 12/13] drivers/cpufreq/sparc-us2e-cpufreq.c:270:69: error: expected ';' before ')' token
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.sched/cpusallowed
head: 4ba98c7ec4094a9123d0d6aabb4497290207b518
commit: 6c06178b50bf61bf9fd4311e99e1f9f470b31b5d [12/13] cpufreq/sparc-us2e:
Remove affinity games
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 6c06178b50bf61bf9fd4311e99e1f9f470b31b5d
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
drivers/cpufreq/sparc-us2e-cpufreq.c: In function 'us2e_freq_target':
>> drivers/cpufreq/sparc-us2e-cpufreq.c:270:69: error: expected ';' before ')'
>> token
return smp_call_function_single(cpu, __us2e_freq_target, &index, 1))
^
>> drivers/cpufreq/sparc-us2e-cpufreq.c:270:69: error: expected statement
>> before ')' token
vim +270 drivers/cpufreq/sparc-us2e-cpufreq.c
264 }
265
266 static int us2e_freq_target(struct cpufreq_policy *policy, unsigned int
index)
267 {
268 unsigned int cpu = policy->cpu;
269
> 270 return smp_call_function_single(cpu, __us2e_freq_target,
> &index, 1))
271 }
272
273 static int __init us2e_freq_cpu_init(struct cpufreq_policy *policy)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v6 1/2] video: ARM CLCD: Move registers to a separate header.
We'd like to reuse these register definitions for the DRM CLCD driver, but there's a bunch of fbdev-specific code in the current header. v2: Add #ifndef guard. Signed-off-by: Eric Anholt --- include/linux/amba/clcd-regs.h | 81 ++ include/linux/amba/clcd.h | 68 +-- 2 files changed, 82 insertions(+), 67 deletions(-) create mode 100644 include/linux/amba/clcd-regs.h diff --git a/include/linux/amba/clcd-regs.h b/include/linux/amba/clcd-regs.h new file mode 100644 index ..69c0e2143003 --- /dev/null +++ b/include/linux/amba/clcd-regs.h @@ -0,0 +1,81 @@ +/* + * David A Rusling + * + * Copyright (C) 2001 ARM Limited + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file COPYING in the main directory of this archive + * for more details. + */ + +#ifndef AMBA_CLCD_REGS_H +#define AMBA_CLCD_REGS_H + +/* + * CLCD Controller Internal Register addresses + */ +#define CLCD_TIM0 0x +#define CLCD_TIM1 0x0004 +#define CLCD_TIM2 0x0008 +#define CLCD_TIM3 0x000c +#define CLCD_UBAS 0x0010 +#define CLCD_LBAS 0x0014 + +#define CLCD_PL110_IENB0x0018 +#define CLCD_PL110_CNTL0x001c +#define CLCD_PL110_STAT0x0020 +#define CLCD_PL110_INTR0x0024 +#define CLCD_PL110_UCUR0x0028 +#define CLCD_PL110_LCUR0x002C + +#define CLCD_PL111_CNTL0x0018 +#define CLCD_PL111_IENB0x001c +#define CLCD_PL111_RIS 0x0020 +#define CLCD_PL111_MIS 0x0024 +#define CLCD_PL111_ICR 0x0028 +#define CLCD_PL111_UCUR0x002c +#define CLCD_PL111_LCUR0x0030 + +#define CLCD_PALL 0x0200 +#define CLCD_PALETTE 0x0200 + +#define TIM2_CLKSEL(1 << 5) +#define TIM2_IVS (1 << 11) +#define TIM2_IHS (1 << 12) +#define TIM2_IPC (1 << 13) +#define TIM2_IOE (1 << 14) +#define TIM2_BCD (1 << 26) + +#define CNTL_LCDEN (1 << 0) +#define CNTL_LCDBPP1 (0 << 1) +#define CNTL_LCDBPP2 (1 << 1) +#define CNTL_LCDBPP4 (2 << 1) +#define CNTL_LCDBPP8 (3 << 1) +#define CNTL_LCDBPP16 (4 << 1) +#define CNTL_LCDBPP16_565 (6 << 1) +#define CNTL_LCDBPP16_444 (7 << 1) +#define CNTL_LCDBPP24 (5 << 1) +#define CNTL_LCDBW (1 << 4) +#define CNTL_LCDTFT(1 << 5) +#define CNTL_LCDMONO8 (1 << 6) +#define CNTL_LCDDUAL (1 << 7) +#define CNTL_BGR (1 << 8) +#define CNTL_BEBO (1 << 9) +#define CNTL_BEPO (1 << 10) +#define CNTL_LCDPWR(1 << 11) +#define CNTL_LCDVCOMP(x) ((x) << 12) +#define CNTL_LDMAFIFOTIME (1 << 15) +#define CNTL_WATERMARK (1 << 16) + +/* ST Microelectronics variant bits */ +#define CNTL_ST_1XBPP_444 0x0 +#define CNTL_ST_1XBPP_5551 (1 << 17) +#define CNTL_ST_1XBPP_565 (1 << 18) +#define CNTL_ST_CDWID_12 0x0 +#define CNTL_ST_CDWID_16 (1 << 19) +#define CNTL_ST_CDWID_18 (1 << 20) +#define CNTL_ST_CDWID_24 ((1 << 19)|(1 << 20)) +#define CNTL_ST_CEAEN (1 << 21) +#define CNTL_ST_LCDBPP24_PACKED(6 << 1) + +#endif /* AMBA_CLCD_REGS_H */ diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h index 1035879b322c..d0c3be77c18e 100644 --- a/include/linux/amba/clcd.h +++ b/include/linux/amba/clcd.h @@ -10,73 +10,7 @@ * for more details. */ #include - -/* - * CLCD Controller Internal Register addresses - */ -#define CLCD_TIM0 0x -#define CLCD_TIM1 0x0004 -#define CLCD_TIM2 0x0008 -#define CLCD_TIM3 0x000c -#define CLCD_UBAS 0x0010 -#define CLCD_LBAS 0x0014 - -#define CLCD_PL110_IENB0x0018 -#define CLCD_PL110_CNTL0x001c -#define CLCD_PL110_STAT0x0020 -#define CLCD_PL110_INTR0x0024 -#define CLCD_PL110_UCUR0x0028 -#define CLCD_PL110_LCUR0x002C - -#define CLCD_PL111_CNTL0x0018 -#define CLCD_PL111_IENB0x001c -#define CLCD_PL111_RIS 0x0020 -#define CLCD_PL111_MIS 0x0024 -#define CLCD_PL111_ICR 0x0028 -#define CLCD_PL111_UCUR0x002c -#define CLCD_PL111_LCUR0x0030 - -#define CLCD_PALL 0x0200 -#define CLCD_PALETTE 0x0200 - -#define TIM2_CLKSEL(1 << 5) -#define TIM2_IVS (1 << 11) -#define TIM2_IHS (1 << 12) -#define TIM2_IPC (1 << 13) -#define TIM2_IOE
[PATCH v6 2/2] drm/pl111: Initial drm/kms driver for pl111
From: Tom Cooksey This is a modesetting driver for the pl111 CLCD display controller found on various ARM platforms such as the Versatile Express. The driver has only been tested on the bcm911360_entphn platform so far, with PRIME-based buffer sharing between vc4 and clcd. It reuses the existing devicetree binding, while not using quite as many of its properties as the fbdev driver does (those are left for future work). v2: Nearly complete rewrite by anholt, cutting 2/3 of the code thanks to DRM core's excellent new helpers. v3: Don't match pl110 any more, don't attach if we don't have a DRM panel, use DRM_GEM_CMA_FOPS, update MAINTAINERS, use the simple display helper, use drm_gem_cma_dumb_create (same as our wrapper). v4: Change the driver's .name to not clash with fbdev in sysfs, drop platform alias, drop redundant "drm" in DRM driver name, hook up .prepare_fb to the CMA helper so that DMA fences should work. v5: Move register definitions inside the driver directory, fix build in COMPILE_TEST and !AMBA mode. v6: Drop TIM2_CLKSEL for now to be consistent with existing DT bindings, switch back to external register definitions. Signed-off-by: Tom Cooksey Signed-off-by: Eric Anholt Reviewed-by: Linus Walleij (v5) --- Documentation/gpu/index.rst | 1 + Documentation/gpu/pl111.rst | 6 + MAINTAINERS | 6 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/pl111/Kconfig | 12 ++ drivers/gpu/drm/pl111/Makefile | 5 + drivers/gpu/drm/pl111/pl111_connector.c | 127 drivers/gpu/drm/pl111/pl111_display.c | 344 drivers/gpu/drm/pl111/pl111_drm.h | 56 ++ drivers/gpu/drm/pl111/pl111_drv.c | 272 + 11 files changed, 832 insertions(+) create mode 100644 Documentation/gpu/pl111.rst create mode 100644 drivers/gpu/drm/pl111/Kconfig create mode 100644 drivers/gpu/drm/pl111/Makefile create mode 100644 drivers/gpu/drm/pl111/pl111_connector.c create mode 100644 drivers/gpu/drm/pl111/pl111_display.c create mode 100644 drivers/gpu/drm/pl111/pl111_drm.h create mode 100644 drivers/gpu/drm/pl111/pl111_drv.c diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index c572f092739e..037a39ac1807 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide drm-uapi i915 meson + pl111 tinydrm vc4 vga-switcheroo diff --git a/Documentation/gpu/pl111.rst b/Documentation/gpu/pl111.rst new file mode 100644 index ..9b03736d33dd --- /dev/null +++ b/Documentation/gpu/pl111.rst @@ -0,0 +1,6 @@ +== + drm/pl111 ARM PrimeCell PL111 CLCD Driver +== + +.. kernel-doc:: drivers/gpu/drm/pl111/pl111_drv.c + :doc: ARM PrimeCell PL111 CLCD Driver diff --git a/MAINTAINERS b/MAINTAINERS index c36dfaeef26b..780630e2055b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4161,6 +4161,12 @@ F: include/drm/drm* F: include/uapi/drm/drm* F: include/linux/vga* +DRM DRIVER FOR ARM PL111 CLCD +M: Eric Anholt +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Supported +F: drivers/gpu/drm/pl111/ + DRM DRIVER FOR AST SERVER GRAPHICS CHIPS M: Dave Airlie S: Odd Fixes diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 78d7fc0ebb57..d1c6c12199b7 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -274,6 +274,8 @@ source "drivers/gpu/drm/meson/Kconfig" source "drivers/gpu/drm/tinydrm/Kconfig" +source "drivers/gpu/drm/pl111/Kconfig" + # Keep legacy drivers last menuconfig DRM_LEGACY diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 59f0f9b696eb..28dcf93e1d8f 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -96,3 +96,4 @@ obj-y += hisilicon/ obj-$(CONFIG_DRM_ZTE) += zte/ obj-$(CONFIG_DRM_MXSFB)+= mxsfb/ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ +obj-$(CONFIG_DRM_PL111) += pl111/ diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig new file mode 100644 index ..ede49efd531f --- /dev/null +++ b/drivers/gpu/drm/pl111/Kconfig @@ -0,0 +1,12 @@ +config DRM_PL111 + tristate "DRM Support for PL111 CLCD Controller" + depends on DRM + depends on ARM || ARM64 || COMPILE_TEST + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE + help + Choose this option for DRM support for the PL111 CLCD controller. + If M is selected the module will be called pl111_drm. + diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile new file mode 100644 index ..01caee7
[git pull] drm fixes for 4.11 rc7
Hi Linus, I was away the end of last week, so some of these would have been in rc6, and it's Easter from tomorrow, so I decided I better dequeue what I have now. The nouveau changes, just add a hw enable for GP107 display (like a pci id addition really), and fix a couple of regressions. i915 has some more gvt fixes, along with a few run of the mill ones, the rcu one seems like a few people have hit it. Otherwise a small udl and small etnaviv fix. Thanks, Dave. The following changes since commit 39da7c509acff13fc8cb12ec1bb20337c988ed36: Linux 4.11-rc6 (2017-04-09 09:49:44 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.11-rc7 for you to fetch changes up to 2ca62d8a606a95e098799f128f6a40a6300d2a2a: Merge branch 'linux-4.11' of git://github.com/skeggsb/linux into drm-fixes (2017-04-13 09:56:05 +1000) i915, gvt, nouveau, udl and etnaviv fixes Ben Skeggs (3): drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi method drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state drm/nouveau: initial support (display-only) for GP107 Changbin Du (1): drm/i915/gvt: exclude cfg space from failsafe mode Chris Wilson (5): drm/i915: Align "unfenced" tiled access on gen2, early gen3 drm/i915/execlists: Wrap tail pointer after reset tweaking drm/i915: Avoid lock dropping between rescheduling drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex drm/i915: Use a dummy timeline name for a signaled fence Dave Airlie (4): Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes Merge tag 'drm-misc-fixes-2017-04-11' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2017-04-12' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'linux-4.11' of git://github.com/skeggsb/linux into drm-fixes Ilia Mirkin (2): drm/nouveau/mpeg: mthd returns true on success now drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one Jani Nikula (2): Merge tag 'gvt-fixes-2017-04-01' of https://github.com/01org/gvt-linux into drm-intel-fixes Merge tag 'gvt-fixes-2017-04-07' of https://github.com/01org/gvt-linux into drm-intel-fixes Jonathan Neuschäfer (1): drm/udl: Fix unaligned memory access in udl_render_hline Joonas Lahtinen (1): drm/i915: Don't call synchronize_rcu_expedited under struct_mutex Matthew Auld (2): drm/i915/perf: destroy stream on sample_flags mismatch drm/i915/perf: remove user triggerable warn Min He (1): drm/i915/gvt: set the correct default value of CTX STATUS PTR Sagar Arun Kamble (1): drm/i915: Suspend GuC prior to GPU Reset during GEM suspend Tina Zhang (1): drm/i915/gvt: remove the redundant info NULL check Wei Yongjun (1): drm/etnaviv: fix missing unlock on error in etnaviv_gpu_submit() Zhenyu Wang (1): drm/i915/gvt: adjust mem size for low resolution type Zhi Wang (2): drm/i915/gvt: Activate/de-activate vGPU in mdev ops. drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 +- drivers/gpu/drm/i915/gvt/cfg_space.c | 3 -- drivers/gpu/drm/i915/gvt/execlist.c | 3 +- drivers/gpu/drm/i915/gvt/firmware.c | 9 ++-- drivers/gpu/drm/i915/gvt/gvt.c| 2 + drivers/gpu/drm/i915/gvt/gvt.h| 5 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 11 ++--- drivers/gpu/drm/i915/gvt/vgpu.c | 45 +++--- drivers/gpu/drm/i915/i915_drv.c | 2 - drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_execbuffer.c| 4 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/i915_gem_request.c | 11 + drivers/gpu/drm/i915/i915_gem_shrinker.c | 26 +++ drivers/gpu/drm/i915/i915_pci.c | 5 ++ drivers/gpu/drm/i915/i915_perf.c | 11 +++-- drivers/gpu/drm/i915/intel_lrc.c | 57 +++ drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +++- drivers/gpu/drm/nouveau/nv50_display.c| 10 ++-- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 32 - drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c | 2 +- drivers/gpu/drm/udl/udl_transfer.c| 3 +- 24 files changed, 180 insertions(+), 79 deletions(-)
Re: [PATCH v2 1/5] kprobes: convert kprobe_lookup_name() to a function
On Wed, 12 Apr 2017 16:28:24 +0530
"Naveen N. Rao" wrote:
> The macro is now pretty long and ugly on powerpc. In the light of
> further changes needed here, convert it to a __weak variant to be
> over-ridden with a nicer looking function.
Looks good to me.
Acked-by: Masami Hiramatsu
Thanks!
>
> Suggested-by: Masami Hiramatsu
> Signed-off-by: Naveen N. Rao
> ---
> arch/powerpc/include/asm/kprobes.h | 53 --
> arch/powerpc/kernel/kprobes.c | 58
> ++
> arch/powerpc/kernel/optprobes.c| 4 +--
> include/linux/kprobes.h| 1 +
> kernel/kprobes.c | 20 ++---
> 5 files changed, 69 insertions(+), 67 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kprobes.h
> b/arch/powerpc/include/asm/kprobes.h
> index 0503c98b2117..a843884aafaf 100644
> --- a/arch/powerpc/include/asm/kprobes.h
> +++ b/arch/powerpc/include/asm/kprobes.h
> @@ -61,59 +61,6 @@ extern kprobe_opcode_t optprobe_template_end[];
> #define MAX_OPTINSN_SIZE (optprobe_template_end -
> optprobe_template_entry)
> #define RELATIVEJUMP_SIZEsizeof(kprobe_opcode_t) /* 4 bytes */
>
> -#ifdef PPC64_ELF_ABI_v2
> -/* PPC64 ABIv2 needs local entry point */
> -#define kprobe_lookup_name(name, addr)
> \
> -{\
> - addr = (kprobe_opcode_t *)kallsyms_lookup_name(name); \
> - if (addr) \
> - addr = (kprobe_opcode_t *)ppc_function_entry(addr); \
> -}
> -#elif defined(PPC64_ELF_ABI_v1)
> -/*
> - * 64bit powerpc ABIv1 uses function descriptors:
> - * - Check for the dot variant of the symbol first.
> - * - If that fails, try looking up the symbol provided.
> - *
> - * This ensures we always get to the actual symbol and not the descriptor.
> - * Also handle format.
> - */
> -#define kprobe_lookup_name(name, addr)
> \
> -{\
> - char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN]; \
> - const char *modsym;
> \
> - bool dot_appended = false; \
> - if ((modsym = strchr(name, ':')) != NULL) { \
> - modsym++; \
> - if (*modsym != '\0' && *modsym != '.') {\
> - /* Convert to */ \
> - strncpy(dot_name, name, modsym - name); \
> - dot_name[modsym - name] = '.'; \
> - dot_name[modsym - name + 1] = '\0'; \
> - strncat(dot_name, modsym, \
> - sizeof(dot_name) - (modsym - name) - 2);\
> - dot_appended = true;\
> - } else {\
> - dot_name[0] = '\0'; \
> - strncat(dot_name, name, sizeof(dot_name) - 1); \
> - } \
> - } else if (name[0] != '.') {\
> - dot_name[0] = '.'; \
> - dot_name[1] = '\0'; \
> - strncat(dot_name, name, KSYM_NAME_LEN - 2); \
> - dot_appended = true;\
> - } else {\
> - dot_name[0] = '\0'; \
> - strncat(dot_name, name, KSYM_NAME_LEN - 1); \
> - } \
> - addr = (kprobe_opcode_t *)kallsyms_lookup_name(dot_name); \
> - if (!addr && dot_appended) {\
> - /* Let's try the original non-dot symbol lookup */ \
> - addr = (kprobe_opcode_t *)kallsyms_lookup_name(name); \
> - } \
> -}
> -#endif
> -
> #define flush_insn_slot(p) do { } while (0)
> #define kretprobe_blacklist_size 0
>
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 331751701fed..a7aa7394954d 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -42,6 +42,64 @@ DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>
> struct kretprobe_blackpoint kretprobe_blacklist[] = {{NULL, NULL}};
>
> +kprobe_opcode_t *kprobe_lookup_name(const char *name)
> +{
> + kprobe_opcode_t *addr;
> +
> +#ifdef PPC64_ELF_ABI
Re: [PATCH] sched/deadline: Throttle a constrained task activated if overflow
On 04/12/2017 at 09:10 PM, luca abeni wrote:
> On Wed, 12 Apr 2017 20:30:04 +0800
> Xunlei Pang wrote:
> [...]
>>> If the relative deadline is different from the period, then the
>>> check is an approximation (and this is the big issue here). I am
>>> still not sure about what is the best thing to do in this case.
>>>
E.g. For (runtime 2ms, deadline 4ms, period 8ms),
for some reason was preempted after running a very short time
0.1ms, after 0.9ms it was scheduled back and immediately sleep
1ms, when it is awakened, remaining runtime is 1.9ms, remaining
deadline(deadline-now) within this period is 2ms, but
dl_entity_overflow() is true. However, clearly it can be correctly
run 1.9ms before deadline comes wthin this period.
>>> Sure, in this case the task can run for 1.9ms before the deadline...
>>> But doing so, it might break the guarantees for other deadline
>>> tasks. This is what the check is trying to avoid.
>> Image this deadline task was preempted after running 0.1ms by another
>> one with an earlier absolute deadline for 1.9ms, after scheduled back
>> it will have the same status (1.9ms remaining runtime, 2ms remaining
>> deadline) under the current implementation.
> The big difference is that in your first example the task blocks for
> some time while being the earliest-deadline task (so, the scheduling
> algorithm would give some execution time to the task, but the task
> does not use it... So, when the task wakes up, it has to check if now it
> is too late for using its reserved execution time).
> On the other hand, in this second example the task is preempted by an
> earlier-deadline (higher priority) task, so there is no risk to have
> execution time reserved to the task that the task does not use
> (if I understand well your examples).
Yes, make sense, thanks!
>
>
We can add a condition in dl_runtime_exceeded(), if its deadline is
passed, then zero its runtime if positive, and a new period begins.
I did some tests with the following patch, seems it works well,
please correct me if I am wrong. ---
kernel/sched/deadline.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a2ce590..600c530 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -498,8 +498,7 @@ static void update_dl_entity(struct
sched_dl_entity *dl_se, struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
struct rq *rq = rq_of_dl_rq(dl_rq);
-if (dl_time_before(dl_se->deadline, rq_clock(rq)) ||
-dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) {
+if (!dl_time_before(rq_clock(rq), dl_se->deadline)) {
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}
>>> I think this will break the guarantees for tasks with relative
>>> deadline equal to period (think about a task with runtime 5ms,
>>> period 10ms and relative deadline 10ms... What happens if the task
>>> executes for 4.9ms, then blocks and immediately wakes up?)
>> For your example, dl_se->deadline is after now, the if condition is
>> false, update_dl_entity() actually does nothing, that is, after
>> wake-up, it will carry (5ms-4.9ms)=0.1ms remaining runtime and
>> (10ms-4.9ms)=5.1ms remaining deadline/period, continue within the
>> current period. After running further 0.1ms, will be throttled by the
>> timer in update_curr_dl().
> Ok, sorry; I saw you inverted rq_clock(rq) and dl_se->deadline), but I
> did not notice you added a "!". My fault.
>
> In this case, with this change the task cannot consume more than
> runtime every period (which is good), but it still risks to cause
> unexpected missed deadlines.
> (if relative deadline == period, on uni-processor the current algorithm
> guarantees that the runtime will always be consumed before the
> scheduling deadline; on multi-processor it guarantees that the runtime
> will be consumed before a maximum delay from the deadline; with this
> change, it is not possible to provide this guarantee anymore).
>
>
> Luca
>
>> It's actually the original logic, I just removed dl_entity_overflow()
>> condition.
>>
>>
>> Regards,
>> Xunlei
>>
>>>
>>> Luca
>>>
@@ -722,13 +721,22 @@ static inline void
dl_check_constrained_dl(struct sched_dl_entity *dl_se)
dl_time_before(rq_clock(rq), dl_next_period(dl_se))) { if
(unlikely(dl_se->dl_boosted || !start_dl_timer(p))) return;
+
+if (dl_se->runtime > 0)
+dl_se->runtime = 0;
+
dl_se->dl_throttled = 1;
}
}
static
-int dl_runtime_exceeded(struct sched_dl_entity *dl_se)
+int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity
*dl_se) {
+if (!dl_time_before(rq_clock(rq), dl_se->deadline)
Re: [PATCH v2 0/5] powerpc: a few kprobe fixes and refactoring
Hi Naveen, BTW, I saw you sent 3 different series, are there any conflict each other? or can we pick those independently? Thanks, On Wed, 12 Apr 2017 16:28:23 +0530 "Naveen N. Rao" wrote: > v1: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1334843.html > > For v2, this series has been re-ordered and rebased on top of > powerpc/next so as to make it easier to resolve conflicts with -tip. No > other changes. > > - Naveen > > > Naveen N. Rao (5): > kprobes: convert kprobe_lookup_name() to a function > powerpc: kprobes: fix handling of function offsets on ABIv2 > powerpc: introduce a new helper to obtain function entry points > powerpc: kprobes: factor out code to emulate instruction into a helper > powerpc: kprobes: emulate instructions on kprobe handler re-entry > > arch/powerpc/include/asm/code-patching.h | 37 ++ > arch/powerpc/include/asm/kprobes.h | 53 -- > arch/powerpc/kernel/kprobes.c| 119 > +-- > arch/powerpc/kernel/optprobes.c | 6 +- > include/linux/kprobes.h | 1 + > kernel/kprobes.c | 21 +++--- > 6 files changed, 147 insertions(+), 90 deletions(-) > > -- > 2.12.1 > -- Masami Hiramatsu
[PATCH v2 6/6] zram: use zram_free_page instead of open-coded
The zram_free_page already handles NULL handle case and same page
so use it to reduce error probability.
(Acutaully, I made a mistake when I handled same page feature)
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 22b249444010..210e449af4c6 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -482,17 +482,8 @@ static void zram_meta_free(struct zram *zram, u64 disksize)
size_t index;
/* Free all pages that are still in this zram device */
- for (index = 0; index < num_pages; index++) {
- unsigned long handle = zram_get_handle(zram, index);
- /*
-* No memory is allocated for same element filled pages.
-* Simply clear same page flag.
-*/
- if (!handle || zram_test_flag(zram, index, ZRAM_SAME))
- continue;
-
- zs_free(zram->mem_pool, handle);
- }
+ for (index = 0; index < num_pages; index++)
+ zram_free_page(zram, index);
zs_destroy_pool(zram->mem_pool);
vfree(zram->table);
@@ -976,9 +967,6 @@ static void zram_reset_device(struct zram *zram)
comp = zram->comp;
disksize = zram->disksize;
-
- /* Reset stats */
- memset(&zram->stats, 0, sizeof(zram->stats));
zram->disksize = 0;
set_capacity(zram->disk, 0);
@@ -987,6 +975,7 @@ static void zram_reset_device(struct zram *zram)
up_write(&zram->init_lock);
/* I/O operation under all of CPU are done so let's free */
zram_meta_free(zram, disksize);
+ memset(&zram->stats, 0, sizeof(zram->stats));
zcomp_destroy(comp);
}
--
2.7.4
[PATCH v2 4/6] zram: remove zram_meta structure
It's redundant now. Instead, remove it and use zram structure
directly.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 189 +-
drivers/block/zram/zram_drv.h | 6 +-
2 files changed, 78 insertions(+), 117 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 931fe099dbc8..002019a552af 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -58,46 +58,46 @@ static inline struct zram *dev_to_zram(struct device *dev)
}
/* flag operations require table entry bit_spin_lock() being held */
-static int zram_test_flag(struct zram_meta *meta, u32 index,
+static int zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- return meta->table[index].value & BIT(flag);
+ return zram->table[index].value & BIT(flag);
}
-static void zram_set_flag(struct zram_meta *meta, u32 index,
+static void zram_set_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- meta->table[index].value |= BIT(flag);
+ zram->table[index].value |= BIT(flag);
}
-static void zram_clear_flag(struct zram_meta *meta, u32 index,
+static void zram_clear_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
{
- meta->table[index].value &= ~BIT(flag);
+ zram->table[index].value &= ~BIT(flag);
}
-static inline void zram_set_element(struct zram_meta *meta, u32 index,
+static inline void zram_set_element(struct zram *zram, u32 index,
unsigned long element)
{
- meta->table[index].element = element;
+ zram->table[index].element = element;
}
-static inline void zram_clear_element(struct zram_meta *meta, u32 index)
+static inline void zram_clear_element(struct zram *zram, u32 index)
{
- meta->table[index].element = 0;
+ zram->table[index].element = 0;
}
-static size_t zram_get_obj_size(struct zram_meta *meta, u32 index)
+static size_t zram_get_obj_size(struct zram *zram, u32 index)
{
- return meta->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
+ return zram->table[index].value & (BIT(ZRAM_FLAG_SHIFT) - 1);
}
-static void zram_set_obj_size(struct zram_meta *meta,
+static void zram_set_obj_size(struct zram *zram,
u32 index, size_t size)
{
- unsigned long flags = meta->table[index].value >> ZRAM_FLAG_SHIFT;
+ unsigned long flags = zram->table[index].value >> ZRAM_FLAG_SHIFT;
- meta->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
+ zram->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
}
#if PAGE_SIZE != 4096
@@ -252,9 +252,8 @@ static ssize_t mem_used_max_store(struct device *dev,
down_read(&zram->init_lock);
if (init_done(zram)) {
- struct zram_meta *meta = zram->meta;
atomic_long_set(&zram->stats.max_used_pages,
- zs_get_total_pages(meta->mem_pool));
+ zs_get_total_pages(zram->mem_pool));
}
up_read(&zram->init_lock);
@@ -327,7 +326,6 @@ static ssize_t compact_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
{
struct zram *zram = dev_to_zram(dev);
- struct zram_meta *meta;
down_read(&zram->init_lock);
if (!init_done(zram)) {
@@ -335,8 +333,7 @@ static ssize_t compact_store(struct device *dev,
return -EINVAL;
}
- meta = zram->meta;
- zs_compact(meta->mem_pool);
+ zs_compact(zram->mem_pool);
up_read(&zram->init_lock);
return len;
@@ -373,8 +370,8 @@ static ssize_t mm_stat_show(struct device *dev,
down_read(&zram->init_lock);
if (init_done(zram)) {
- mem_used = zs_get_total_pages(zram->meta->mem_pool);
- zs_pool_stats(zram->meta->mem_pool, &pool_stats);
+ mem_used = zs_get_total_pages(zram->mem_pool);
+ zs_pool_stats(zram->mem_pool, &pool_stats);
}
orig_size = atomic64_read(&zram->stats.pages_stored);
@@ -417,32 +414,26 @@ static DEVICE_ATTR_RO(debug_stat);
static void zram_slot_lock(struct zram *zram, u32 index)
{
- struct zram_meta *meta = zram->meta;
-
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ bit_spin_lock(ZRAM_ACCESS, &zram->table[index].value);
}
static void zram_slot_unlock(struct zram *zram, u32 index)
{
- struct zram_meta *meta = zram->meta;
-
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ bit_spin_unlock(ZRAM_ACCESS, &zram->table[index].value);
}
static bool zram_same_page_read(struct zram *zram, u32 index,
struct page *page,
unsigned int offset, unsigned int len)
{
- struct zram_meta *meta = zram->meta;
-
[PATCH v2 1/6] zram: handle multiple pages attached bio's bvec
Johannes Thumshirn reported system goes the panic when using NVMe over
Fabrics loopback target with zram.
The reason is zram expects each bvec in bio contains a single page
but nvme can attach a huge bulk of pages attached to the bio's bvec
so that zram's index arithmetic could be wrong so that out-of-bound
access makes system panic.
[1] in mainline solved solved the problem by limiting max_sectors with
SECTORS_PER_PAGE but it makes zram slow because bio should split with
each pages so this patch makes zram aware of multiple pages in a bvec
so it could solve without any regression(ie, bio split).
[1] 0bc315381fe9, zram: set physical queue limits to avoid array out of
bounds accesses
* from v1
* Do not exceed page boundary when set up bv.bv_len in make_request
* change "remained" variable name with "unwritten"
Cc: Hannes Reinecke
Reported-by: Johannes Thumshirn
Tested-by: Johannes Thumshirn
Reviewed-by: Johannes Thumshirn
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 11cc8767af99..9c3f862b72f4 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -137,8 +137,7 @@ static inline bool valid_io_request(struct zram *zram,
static void update_position(u32 *index, int *offset, struct bio_vec *bvec)
{
- if (*offset + bvec->bv_len >= PAGE_SIZE)
- (*index)++;
+ *index += (*offset + bvec->bv_len) / PAGE_SIZE;
*offset = (*offset + bvec->bv_len) % PAGE_SIZE;
}
@@ -838,34 +837,21 @@ static void __zram_make_request(struct zram *zram, struct
bio *bio)
}
bio_for_each_segment(bvec, bio, iter) {
- int max_transfer_size = PAGE_SIZE - offset;
-
- if (bvec.bv_len > max_transfer_size) {
- /*
-* zram_bvec_rw() can only make operation on a single
-* zram page. Split the bio vector.
-*/
- struct bio_vec bv;
-
- bv.bv_page = bvec.bv_page;
- bv.bv_len = max_transfer_size;
- bv.bv_offset = bvec.bv_offset;
+ struct bio_vec bv = bvec;
+ unsigned int unwritten = bvec.bv_len;
+ do {
+ bv.bv_len = min_t(unsigned int, PAGE_SIZE - offset,
+ unwritten);
if (zram_bvec_rw(zram, &bv, index, offset,
-op_is_write(bio_op(bio))) < 0)
+ op_is_write(bio_op(bio))) < 0)
goto out;
- bv.bv_len = bvec.bv_len - max_transfer_size;
- bv.bv_offset += max_transfer_size;
- if (zram_bvec_rw(zram, &bv, index + 1, 0,
-op_is_write(bio_op(bio))) < 0)
- goto out;
- } else
- if (zram_bvec_rw(zram, &bvec, index, offset,
-op_is_write(bio_op(bio))) < 0)
- goto out;
+ bv.bv_offset += bv.bv_len;
+ unwritten -= bv.bv_len;
- update_position(&index, &offset, &bvec);
+ update_position(&index, &offset, &bv);
+ } while (unwritten);
}
bio_endio(bio);
@@ -882,8 +868,6 @@ static blk_qc_t zram_make_request(struct request_queue
*queue, struct bio *bio)
{
struct zram *zram = queue->queuedata;
- blk_queue_split(queue, &bio, queue->bio_split);
-
if (!valid_io_request(zram, bio->bi_iter.bi_sector,
bio->bi_iter.bi_size)) {
atomic64_inc(&zram->stats.invalid_io);
--
2.7.4
[PATCH v2 5/6] zram: introduce zram data accessor
With element, sometime I got confused handle and element access.
It might be my bad but I think it's time to introduce accessor
to prevent future idiot like me.
This patch is just clean-up patch so it shouldn't change any
behavior.
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 002019a552af..22b249444010 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -57,6 +57,16 @@ static inline struct zram *dev_to_zram(struct device *dev)
return (struct zram *)dev_to_disk(dev)->private_data;
}
+static unsigned long zram_get_handle(struct zram *zram, u32 index)
+{
+ return zram->table[index].handle;
+}
+
+static void zram_set_handle(struct zram *zram, u32 index, unsigned long handle)
+{
+ zram->table[index].handle = handle;
+}
+
/* flag operations require table entry bit_spin_lock() being held */
static int zram_test_flag(struct zram *zram, u32 index,
enum zram_pageflags flag)
@@ -82,9 +92,9 @@ static inline void zram_set_element(struct zram *zram, u32
index,
zram->table[index].element = element;
}
-static inline void zram_clear_element(struct zram *zram, u32 index)
+static unsigned long zram_get_element(struct zram *zram, u32 index)
{
- zram->table[index].element = 0;
+ return zram->table[index].element;
}
static size_t zram_get_obj_size(struct zram *zram, u32 index)
@@ -427,13 +437,14 @@ static bool zram_same_page_read(struct zram *zram, u32
index,
unsigned int offset, unsigned int len)
{
zram_slot_lock(zram, index);
- if (unlikely(!zram->table[index].handle) ||
- zram_test_flag(zram, index, ZRAM_SAME)) {
+ if (unlikely(!zram_get_handle(zram, index) ||
+ zram_test_flag(zram, index, ZRAM_SAME))) {
void *mem;
zram_slot_unlock(zram, index);
mem = kmap_atomic(page);
- zram_fill_page(mem + offset, len, zram->table[index].element);
+ zram_fill_page(mem + offset, len,
+ zram_get_element(zram, index));
kunmap_atomic(mem);
return true;
}
@@ -472,7 +483,7 @@ static void zram_meta_free(struct zram *zram, u64 disksize)
/* Free all pages that are still in this zram device */
for (index = 0; index < num_pages; index++) {
- unsigned long handle = zram->table[index].handle;
+ unsigned long handle = zram_get_handle(zram, index);
/*
* No memory is allocated for same element filled pages.
* Simply clear same page flag.
@@ -512,7 +523,7 @@ static bool zram_meta_alloc(struct zram *zram, u64 disksize)
*/
static void zram_free_page(struct zram *zram, size_t index)
{
- unsigned long handle = zram->table[index].handle;
+ unsigned long handle = zram_get_handle(zram, index);
/*
* No memory is allocated for same element filled pages.
@@ -520,7 +531,7 @@ static void zram_free_page(struct zram *zram, size_t index)
*/
if (zram_test_flag(zram, index, ZRAM_SAME)) {
zram_clear_flag(zram, index, ZRAM_SAME);
- zram_clear_element(zram, index);
+ zram_set_element(zram, index, 0);
atomic64_dec(&zram->stats.same_pages);
return;
}
@@ -534,7 +545,7 @@ static void zram_free_page(struct zram *zram, size_t index)
&zram->stats.compr_data_size);
atomic64_dec(&zram->stats.pages_stored);
- zram->table[index].handle = 0;
+ zram_set_handle(zram, index, 0);
zram_set_obj_size(zram, index, 0);
}
@@ -549,7 +560,7 @@ static int zram_decompress_page(struct zram *zram, struct
page *page, u32 index)
return 0;
zram_slot_lock(zram, index);
- handle = zram->table[index].handle;
+ handle = zram_get_handle(zram, index);
size = zram_get_obj_size(zram, index);
src = zs_map_object(zram->mem_pool, handle, ZS_MM_RO);
@@ -715,7 +726,7 @@ static int __zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index)
*/
zram_slot_lock(zram, index);
zram_free_page(zram, index);
- zram->table[index].handle = handle;
+ zram_set_handle(zram, index, handle);
zram_set_obj_size(zram, index, comp_len);
zram_slot_unlock(zram, index);
--
2.7.4
[PATCH v2 2/6] zram: partial IO refactoring
For architecture(PAGE_SIZE > 4K), zram have supported partial IO.
However, the mixed code for handling normal/partial IO is too mess,
error-prone to modify IO handler functions with upcoming feature
so this patch aims for cleaning up zram's IO handling functions.
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 337 +++---
1 file changed, 184 insertions(+), 153 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9c3f862b72f4..c4445995fd13 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -45,6 +45,8 @@ static const char *default_compressor = "lzo";
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+static void zram_free_page(struct zram *zram, size_t index);
+
static inline bool init_done(struct zram *zram)
{
return zram->disksize;
@@ -98,10 +100,17 @@ static void zram_set_obj_size(struct zram_meta *meta,
meta->table[index].value = (flags << ZRAM_FLAG_SHIFT) | size;
}
+#if PAGE_SIZE != 4096
static inline bool is_partial_io(struct bio_vec *bvec)
{
return bvec->bv_len != PAGE_SIZE;
}
+#else
+static inline bool is_partial_io(struct bio_vec *bvec)
+{
+ return false;
+}
+#endif
static void zram_revalidate_disk(struct zram *zram)
{
@@ -191,18 +200,6 @@ static bool page_same_filled(void *ptr, unsigned long
*element)
return true;
}
-static void handle_same_page(struct bio_vec *bvec, unsigned long element)
-{
- struct page *page = bvec->bv_page;
- void *user_mem;
-
- user_mem = kmap_atomic(page);
- zram_fill_page(user_mem + bvec->bv_offset, bvec->bv_len, element);
- kunmap_atomic(user_mem);
-
- flush_dcache_page(page);
-}
-
static ssize_t initstate_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -418,6 +415,53 @@ static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
static DEVICE_ATTR_RO(debug_stat);
+static bool zram_same_page_read(struct zram *zram, u32 index,
+ struct page *page,
+ unsigned int offset, unsigned int len)
+{
+ struct zram_meta *meta = zram->meta;
+
+ bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ if (unlikely(!meta->table[index].handle) ||
+ zram_test_flag(meta, index, ZRAM_SAME)) {
+ void *mem;
+
+ bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ mem = kmap_atomic(page);
+ zram_fill_page(mem + offset, len, meta->table[index].element);
+ kunmap_atomic(mem);
+ return true;
+ }
+ bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+
+ return false;
+}
+
+static bool zram_same_page_write(struct zram *zram, u32 index,
+ struct page *page)
+{
+ unsigned long element;
+ void *mem = kmap_atomic(page);
+
+ if (page_same_filled(mem, &element)) {
+ struct zram_meta *meta = zram->meta;
+
+ kunmap_atomic(mem);
+ /* Free memory associated with this sector now. */
+ bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_free_page(zram, index);
+ zram_set_flag(meta, index, ZRAM_SAME);
+ zram_set_element(meta, index, element);
+ bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+
+ atomic64_inc(&zram->stats.same_pages);
+ return true;
+ }
+ kunmap_atomic(mem);
+
+ return false;
+}
+
static void zram_meta_free(struct zram_meta *meta, u64 disksize)
{
size_t num_pages = disksize >> PAGE_SHIFT;
@@ -504,169 +548,103 @@ static void zram_free_page(struct zram *zram, size_t
index)
zram_set_obj_size(meta, index, 0);
}
-static int zram_decompress_page(struct zram *zram, char *mem, u32 index)
+static int zram_decompress_page(struct zram *zram, struct page *page, u32
index)
{
- int ret = 0;
- unsigned char *cmem;
- struct zram_meta *meta = zram->meta;
+ int ret;
unsigned long handle;
unsigned int size;
+ void *src, *dst;
+ struct zram_meta *meta = zram->meta;
+
+ if (zram_same_page_read(zram, index, page, 0, PAGE_SIZE))
+ return 0;
bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
handle = meta->table[index].handle;
size = zram_get_obj_size(meta, index);
- if (!handle || zram_test_flag(meta, index, ZRAM_SAME)) {
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
- zram_fill_page(mem, PAGE_SIZE, meta->table[index].element);
- return 0;
- }
-
- cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_RO);
+ src = zs_map_object(meta->mem_pool, handle, ZS_MM_RO);
if (size == PAGE
[PATCH v2 3/6] zram: use zram_slot_lock instead of raw bit_spin_lock op
With this clean-up phase, I want to use zram's wrapper function
to lock table access which is more consistent with other zram's
functions.
Reviewed-by: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 41 +++--
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index c4445995fd13..931fe099dbc8 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -415,24 +415,38 @@ static DEVICE_ATTR_RO(io_stat);
static DEVICE_ATTR_RO(mm_stat);
static DEVICE_ATTR_RO(debug_stat);
+static void zram_slot_lock(struct zram *zram, u32 index)
+{
+ struct zram_meta *meta = zram->meta;
+
+ bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+}
+
+static void zram_slot_unlock(struct zram *zram, u32 index)
+{
+ struct zram_meta *meta = zram->meta;
+
+ bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+}
+
static bool zram_same_page_read(struct zram *zram, u32 index,
struct page *page,
unsigned int offset, unsigned int len)
{
struct zram_meta *meta = zram->meta;
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_lock(zram, index);
if (unlikely(!meta->table[index].handle) ||
zram_test_flag(meta, index, ZRAM_SAME)) {
void *mem;
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
mem = kmap_atomic(page);
zram_fill_page(mem + offset, len, meta->table[index].element);
kunmap_atomic(mem);
return true;
}
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
return false;
}
@@ -448,11 +462,11 @@ static bool zram_same_page_write(struct zram *zram, u32
index,
kunmap_atomic(mem);
/* Free memory associated with this sector now. */
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_lock(zram, index);
zram_free_page(zram, index);
zram_set_flag(meta, index, ZRAM_SAME);
zram_set_element(meta, index, element);
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
atomic64_inc(&zram->stats.same_pages);
return true;
@@ -559,7 +573,7 @@ static int zram_decompress_page(struct zram *zram, struct
page *page, u32 index)
if (zram_same_page_read(zram, index, page, 0, PAGE_SIZE))
return 0;
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_lock(zram, index);
handle = meta->table[index].handle;
size = zram_get_obj_size(meta, index);
@@ -578,7 +592,7 @@ static int zram_decompress_page(struct zram *zram, struct
page *page, u32 index)
zcomp_stream_put(zram->comp);
}
zs_unmap_object(meta->mem_pool, handle);
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
/* Should NEVER happen. Return bio error if it does. */
if (unlikely(ret))
@@ -727,11 +741,11 @@ static int __zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index)
* Free memory associated with this sector
* before overwriting unused sectors.
*/
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_lock(zram, index);
zram_free_page(zram, index);
meta->table[index].handle = handle;
zram_set_obj_size(meta, index, comp_len);
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
/* Update stats */
atomic64_add(comp_len, &zram->stats.compr_data_size);
@@ -789,7 +803,6 @@ static void zram_bio_discard(struct zram *zram, u32 index,
int offset, struct bio *bio)
{
size_t n = bio->bi_iter.bi_size;
- struct zram_meta *meta = zram->meta;
/*
* zram manages data in physical block size units. Because logical block
@@ -810,9 +823,9 @@ static void zram_bio_discard(struct zram *zram, u32 index,
}
while (n >= PAGE_SIZE) {
- bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_lock(zram, index);
zram_free_page(zram, index);
- bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
+ zram_slot_unlock(zram, index);
atomic64_inc(&zram->stats.notify_free);
index++;
n -= PAGE_SIZE;
@@ -922,9 +935,9 @@ static void zram_slot_free_notify(struct block_device *bdev,
zram = bdev->bd_disk->private_data;
[PATCH v2 0/6] zram clean up
This patchset aims zram clean-up. [1] clean up multiple pages's bvec handling. [2] clean up partial IO handling [3-6] clean up zram via using accessor and removing pointless structure. With [2-6] applied, we can get a few hundred bytes as well as huge readibility enhance. This patchset is based on 2017-04-11-15-23 + recent ppc64 fixes[1] [1] https://lkml.org/lkml/2017/4/12/924 * from v1 * more clean up - Sergey * Fix zram_reset metadata overwrite - Sergey * Fix bvec handling in __zram_make_request * use zram_free_page in reset rather than zs_free x86: 708 byte save add/remove: 1/1 grow/shrink: 0/11 up/down: 478/-1186 (-708) function old new delta zram_special_page_read - 478+478 zram_reset_device317 314 -3 mem_used_max_store 131 128 -3 compact_store 96 93 -3 mm_stat_show 203 197 -6 zram_add 719 712 -7 zram_slot_free_notify229 214 -15 zram_make_request819 803 -16 zram_meta_free 128 111 -17 zram_free_page 180 151 -29 disksize_store 432 361 -71 zram_decompress_page.isra504 --504 zram_bvec_rw25922080-512 Total: Before=25350773, After=25350065, chg -0.00% ppc64: 231 byte save add/remove: 2/0 grow/shrink: 1/9 up/down: 681/-912 (-231) function old new delta zram_special_page_read - 480+480 zram_slot_lock - 200+200 vermagic 39 40 +1 mm_stat_show 256 248 -8 zram_meta_free 200 184 -16 zram_add 944 912 -32 zram_free_page 348 308 -40 disksize_store 572 492 -80 zram_decompress_page 664 564-100 zram_slot_free_notify292 160-132 zram_make_request 11321000-132 zram_bvec_rw27682396-372 Total: Before=17565825, After=17565594, chg -0.00% Minchan Kim (6): zram: handle multiple pages attached bio's bvec zram: partial IO refactoring zram: use zram_slot_lock instead of raw bit_spin_lock op zram: remove zram_meta structure zram: introduce zram data accessor zram: use zram_free_page instead of open-coded drivers/block/zram/zram_drv.c | 567 +- drivers/block/zram/zram_drv.h | 6 +- 2 files changed, 281 insertions(+), 292 deletions(-) -- 2.7.4
Re: [v3] PCI: Add an option to control probing of VFs before enabling SR-IOV
On Thu, 13 Apr 2017 01:51:40 +0300 bod...@mellanox.com wrote: > From: Bodong Wang > > Sometimes it is not desirable to probe the virtual functions after > SRIOV is enabled. This can save host side resource usage by VF > instances which would be eventually probed to VMs. > > Add a new PCI sysfs interface "sriov_drivers_autoprobe" to control > that from the PF, all current callers still retain the same > functionality. To modify it, echo 0/n/N (disable probe) or 1/y/Y > (enable probe) to: > > /sys/bus/pci/devices//sriov_drivers_autoprobe > > Note that, the choice must be made before enabling VFs. The change > will not take effect if VFs are already enabled. Simply, one can set > sriov_numvfs to 0, choose whether to probe or not, and then resume > sriov_numvfs. > > Signed-off-by: Bodong Wang > Signed-off-by: Eli Cohen > Reviewed-by: Gavin Shan > Reviewed-by: Alex Williamson Whoa, I reviewed the last version, that's different than providing a Reviewed-by, and I've certainly never seen this version until now, so I can't possibly have endorsed it in any way. It's also changed since Gavin saw it and I think Bjorn is in the same boat. Probably a good idea to cc the people you're claiming reviewed this too (cc +Gavin). > Reviewed-by: Bjorn Helgaas > --- > Documentation/ABI/testing/sysfs-bus-pci | 18 ++ > Documentation/PCI/pci-iov-howto.txt | 12 > drivers/pci/iov.c |1 + > drivers/pci/pci-driver.c| 22 ++ > drivers/pci/pci-sysfs.c | 28 > drivers/pci/pci.h |1 + > 6 files changed, 78 insertions(+), 4 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-pci > b/Documentation/ABI/testing/sysfs-bus-pci > index 5a1732b..0878520 100644 > --- a/Documentation/ABI/testing/sysfs-bus-pci > +++ b/Documentation/ABI/testing/sysfs-bus-pci > @@ -301,3 +301,21 @@ Contact: Emil Velikov > Description: > This file contains the revision field of the the PCI device. > The value comes from device config space. The file is read only. > + > +What:/sys/bus/pci/devices/.../sriov_drivers_autoprobe > +Date:April 2017 > +Contact: Bodong Wang > +Description: > + This file appears when a physical PCIe device supports SR-IOV. > + Userspace applications can read and write to this file to > + determine and control the enablement(1/y/Y) or disablement > + (0/n/N) of probing Virtual Functions (VFs) by a compatible > + driver on host side. The default value is 1(enabled) which means > + VFs will be probed and bound to a compatible driver on the host > + side if SR-IOV is enabled. A typical use case is writing 0 to > + this file to disable SR-IOV drivers auto probe, then admin from > + host is able to assign the newly created VFs to virtual machines > + directly after SR-IOV is enabled. Note that, changing this file > + will not affect VFs which are already probed by host. In this > + scenario, the user must first disable SR-IOV, make the change, > + then resume SR-IOV. > diff --git a/Documentation/PCI/pci-iov-howto.txt > b/Documentation/PCI/pci-iov-howto.txt > index 2d91ae2..b6807df 100644 > --- a/Documentation/PCI/pci-iov-howto.txt > +++ b/Documentation/PCI/pci-iov-howto.txt > @@ -68,6 +68,18 @@ To disable SR-IOV capability: > echo 0 > \ > /sys/bus/pci/devices//sriov_numvfs > > +To enable auto probing VFs by a compatible driver on the host, run > +command bellow before enabling SR-IOV capabilities. This is the > +default behavior. > + echo 1 > \ > + > /sys/bus/pci/devices//sriov_drivers_autoprobe > + > +To disable auto probing VFs by a compatible driver on the host, run > +command bellow before enabling SR-IOV capabilities. Updating this > +entry will not affect VFs which are already probed. > + echo 0 > \ > + > /sys/bus/pci/devices//sriov_drivers_autoprobe > + > 3.2 Usage example > > Following piece of code illustrates the usage of the SR-IOV API. > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c > index 2479ae8..d9dc736 100644 > --- a/drivers/pci/iov.c > +++ b/drivers/pci/iov.c > @@ -450,6 +450,7 @@ static int sriov_init(struct pci_dev *dev, int pos) > iov->total_VFs = total; > iov->pgsz = pgsz; > iov->self = dev; > + iov->drivers_autoprobe = true; > pci_read_config_dword(dev, pos + PCI_SRIOV_CAP, &iov->cap); > pci_read_config_byte(dev, pos + PCI_SRIOV_FUNC_LINK, &iov->link); > if (pci_pcie_type(dev) == PCI_EXP_TYPE_RC_END) > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > index afa7271..f99f7fe 100644 > --- a/drivers/pci/pci-driver.c > +++ b/drivers/pci/pci-driver.c > @@ -394,6 +394,18 @@ void __weak pcibios_free_irq(s
Re: [patch 12/13] cpufreq/sparc-us2e: Replace racy task affinity logic
On 12-04-17, 22:07, Thomas Gleixner wrote: > The access to the HBIRD_ESTAR_MODE register in the cpu frequency control > functions must happen on the target CPU. This is achieved by temporarily > setting the affinity of the calling user space thread to the requested CPU > and reset it to the original affinity afterwards. > > That's racy vs. CPU hotplug and concurrent affinity settings for that > thread resulting in code executing on the wrong CPU and overwriting the > new affinity setting. > > Replace it by a straight forward smp function call. > > Signed-off-by: Thomas Gleixner > Cc: "David S. Miller" > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > --- > drivers/cpufreq/sparc-us2e-cpufreq.c | 45 > --- > 1 file changed, 21 insertions(+), 24 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [patch 11/13] cpufreq/sparc-us3: Replace racy task affinity logic
On 12-04-17, 22:07, Thomas Gleixner wrote: > The access to the safari config register in the CPU frequency functions > must be executed on the target CPU. This is achieved by temporarily setting > the affinity of the calling user space thread to the requested CPU and > reset it to the original affinity afterwards. > > That's racy vs. CPU hotplug and concurrent affinity settings for that > thread resulting in code executing on the wrong CPU and overwriting the > new affinity setting. > > Replace it by a straight forward smp function call. > > Signed-off-by: Thomas Gleixner > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: "David S. Miller" > Cc: linux...@vger.kernel.org > --- > drivers/cpufreq/sparc-us3-cpufreq.c | 46 > > 1 file changed, 16 insertions(+), 30 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [patch 10/13] cpufreq/sh: Replace racy task affinity logic
On 12-04-17, 22:07, Thomas Gleixner wrote: > The target() callback must run on the affected cpu. This is achieved by > temporarily setting the affinity of the calling thread to the requested CPU > and reset it to the original affinity afterwards. > > That's racy vs. concurrent affinity settings for that thread resulting in > code executing on the wrong CPU. > > Replace it by work_on_cpu(). All call pathes which invoke the callbacks are > already protected against CPU hotplug. > > Signed-off-by: Thomas Gleixner > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > --- > drivers/cpufreq/sh-cpufreq.c | 45 > +-- > 1 file changed, 27 insertions(+), 18 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [patch 09/13] cpufreq/ia64: Replace racy task affinity logic
On 12-04-17, 22:07, Thomas Gleixner wrote: > The get() and target() callbacks must run on the affected cpu. This is > achieved by temporarily setting the affinity of the calling thread to the > requested CPU and reset it to the original affinity afterwards. > > That's racy vs. concurrent affinity settings for that thread resulting in > code executing on the wrong CPU and overwriting the new affinity setting. > > Replace it by work_on_cpu(). All call pathes which invoke the callbacks are > already protected against CPU hotplug. > > Signed-off-by: Thomas Gleixner > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: Tony Luck > Cc: Fenghua Yu > Cc: linux...@vger.kernel.org > --- > drivers/cpufreq/ia64-acpi-cpufreq.c | 91 > +++- > 1 file changed, 38 insertions(+), 53 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
Hi Cyrille,
On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote:
> Hi Guochun,
>
> Le 05/04/2017 à 10:37, Guochun Mao a écrit :
> > When nor's size larger than 16MByte, nor's address width maybe
> > set to 3 or 4, and controller should change address width according
> > to nor's setting.
> >
> > Signed-off-by: Guochun Mao st
> > ---
> > drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
> > b/drivers/mtd/spi-nor/mtk-quadspi.c
> > index e661877..b637770 100644
> > --- a/drivers/mtd/spi-nor/mtk-quadspi.c
> > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > @@ -104,6 +104,8 @@
> > #define MTK_NOR_MAX_RX_TX_SHIFT6
> > /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
> > #define MTK_NOR_MAX_SHIFT 7
> > +/* nor controller 4-byte address mode enable bit */
> > +#define MTK_NOR_4B_ADDR_EN BIT(4)
> >
> > /* Helpers for accessing the program data / shift data registers */
> > #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
> > @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct
> > mt8173_nor *mt8173_nor)
> > 1);
> > }
> >
> > +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
> > +{
> > + u8 val;
> > + struct spi_nor *nor = &mt8173_nor->nor;
> > +
> > + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +
> > + switch (nor->addr_width) {
> > + case 3:
> > + val &= ~MTK_NOR_4B_ADDR_EN;
> > + break;
> > + case 4:
> > + val |= MTK_NOR_4B_ADDR_EN;
> > + break;
> > + default:
> > + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
> > +nor->addr_width);
> > + break;
> > + }
> > +
> > + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
> > +}
> > +
> > static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> > {
> > int i;
> >
> > + mt8173_nor_set_addr_width(mt8173_nor);
> > +
> > for (i = 0; i < 3; i++) {
>
> Should it be 'i < nor->addr_width' instead of 'i < 3' ?
> Does it work when accessing data after 128Mbit ?
Yes, it can work.
Let's see the whole function,
static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
{
int i;
mt8173_nor_set_addr_width(mt8173_nor);
for (i = 0; i < 3; i++) {
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG
+ i * 4);
addr >>= 8;
}
/* Last register is non-contiguous */
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
}
The nor controller has 4 registers for address.
This '3' indicates the number of contiguous address' registers
base + MTK_NOR_RADR0_REG(0x10)
base + MTK_NOR_RADR1_REG(0x14)
base + MTK_NOR_RADR2_REG(0x18),
but the last address register is non-contiguous,
it's base + MTK_NOR_RADR3_REG(0xc8)
mt8173_nor_set_addr will set addr into these 4 registers by Byte.
The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18)
or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device.
and, it can access data after 128Mbit when sent 4-byte address.
Best regards,
Guochun
>
> Best regards,
>
> Cyrille
>
> > writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i *
> > 4);
> > addr >>= 8;
> >
>
[PATCH] virtio_scsi: Always try to read VPD pages
Passed through SCSI targets may have transfer limits which come from the
host SCSI controller something on the host side other than the target
itself.
To make this work properly, the hypervisor can adjust the target's VPD
information to advertise these limits. But for that to work, the guest has
to look at the VPD pages, which we won't do by default if it is an SPC-2
device, even if it does actually support it.
This adds a workaround to address this, forcing devices attached to a
virtio-scsi controller to always check the VPD pages. This is modelled on
a similar workaround for the storvsc (Hyper-V) SCSI controller, although
that exists for slightly different reasons.
A specific case which causes this is a volume from IBM's IPR RAID
controller (which presents as an SPC-2 device, although it does support
VPD) passed through with qemu's 'scsi-block' device.
Signed-off-by: David Gibson
---
drivers/scsi/virtio_scsi.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 939c47d..961a1fc 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -705,6 +706,28 @@ static int virtscsi_device_reset(struct scsi_cmnd *sc)
return virtscsi_tmf(vscsi, cmd);
}
+static int virtscsi_device_alloc(struct scsi_device *sdevice)
+{
+ /*
+* Passed through SCSI targets (e.g. with qemu's 'scsi-block')
+* may have transfer limits which come from the host SCSI
+* controller something on the host side other than the target
+* itself.
+*
+* To make this work properly, the hypervisor can adjust the
+* target's VPD information to advertise these limits. But
+* for that to work, the guest has to look at the VPD pages,
+* which we won't do by default if it is an SPC-2 device, even
+* if it does actually support it.
+*
+* So, set the blist to always try to read the VPD pages.
+*/
+ sdevice->sdev_bflags = BLIST_TRY_VPD_PAGES;
+
+ return 0;
+}
+
+
/**
* virtscsi_change_queue_depth() - Change a virtscsi target's queue depth
* @sdev: Virtscsi target whose queue depth to change
@@ -783,6 +806,7 @@ static struct scsi_host_template
virtscsi_host_template_single = {
.change_queue_depth = virtscsi_change_queue_depth,
.eh_abort_handler = virtscsi_abort,
.eh_device_reset_handler = virtscsi_device_reset,
+ .slave_alloc = virtscsi_device_alloc,
.can_queue = 1024,
.dma_boundary = UINT_MAX,
--
2.9.3
Re: [PATCH v5] Allow user probes on versioned symbols.
Hi Paul,
On Wed, 12 Apr 2017 09:41:51 -0500
Paul Clarke wrote:
> @@ -396,8 +407,26 @@ static void symbols__sort_by_name(struct rb_root
> *symbols,
> }
> }
>
> +int symbol__match_symbol_name(const char *name, const char *str,
> + enum symbols_tag_includes includes)
> +{
> + const char *versioning;
> +
> + if (includes == SYMBOLS_TAG__INCLUDE_DEFAULT_ONLY &&
> + (versioning = strstr(name,"@@"))) {
> +
> + unsigned int len = strlen(str);
> + if (len < versioning - name)
> + len = versioning - name;
> +
> + return arch__compare_symbol_names_n(name, str, len);
> + } else
> + return arch__compare_symbol_names(name, str);
> +}
> +
> static struct symbol *symbols__find_by_name(struct rb_root *symbols,
> - const char *name)
> + const char *name,
> + unsigned int includes)
Here, you might miss replacing this 'unsigned int' with enum.
(actually, enum is equal to int, not unsigned int)
[SNIP]
> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> index 5245d2f..67b017e 100644
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -348,8 +348,19 @@ void arch__sym_update(struct symbol *s, GElf_Sym *sym);
> #define SYMBOL_A 0
> #define SYMBOL_B 1
>
> +int arch__compare_symbol_names(const char *namea, const char *nameb);
> +int arch__compare_symbol_names_n(const char *namea, const char *nameb,
> + unsigned int n);
> int arch__choose_best_symbol(struct symbol *syma, struct symbol *symb);
>
> +enum symbols_tag_includes {
> + SYMBOLS_TAG__INCLUDE_NONE,
> + SYMBOLS_TAG__INCLUDE_DEFAULT_ONLY
> +};
BTW, would we need such 's' for plural and third person singular for type name?
And also, you should use enum type name for prefix so that other developers
easily find the definition of enumeration, e.g.
enum symbol_tag_include {
SYMBOL_TAG_INCLUDE__NONE = 0,
SYMBOL_TAG_INCLUDE__DEFAULT_ONLY
};
Thank you,
--
Masami Hiramatsu
[PATCH] mm, x86: Add ARCH_HAS_ZONE_DEVICE to Kconfig
Currently ZONE_DEVICE depends on X86_64 and this will get unwieldly as new architectures (and platforms) get ZONE_DEVICE support. Move to an arch selected Kconfig option to save us the trouble. Cc: linux...@kvack.org Signed-off-by: Oliver O'Halloran --- arch/x86/Kconfig | 1 + mm/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c43f47622440..535b4d514792 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -59,6 +59,7 @@ config X86 select ARCH_HAS_STRICT_KERNEL_RWX select ARCH_HAS_STRICT_MODULE_RWX select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAS_ZONE_DEVICE if X86_64 select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI select ARCH_MIGHT_HAVE_PC_PARPORT diff --git a/mm/Kconfig b/mm/Kconfig index c89f472b658c..57c1cbd9a050 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -689,7 +689,7 @@ config ZONE_DEVICE depends on MEMORY_HOTPLUG depends on MEMORY_HOTREMOVE depends on SPARSEMEM_VMEMMAP - depends on X86_64 #arch_add_memory() comprehends device memory + depends on ARCH_HAS_ZONE_DEVICE help Device memory hotplug support allows for establishing pmem, -- 2.9.3
[PATCH 1/3] clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
In common PLL designs, changes to the dividers take effect almost
immediately, while changes to the multipliers (implemented as
dividers in the feedback loop) take a few cycles to work into
the feedback loop for the PLL to stablize.
Sometimes when the PLL clock rate is changed, the decrease in the
divider is too much for the decrease in the multiplier to catch up.
The PLL clock rate will spike, and in some cases, might lock up
completely. This is especially the case if the divider changed is
the pre-divider, which affects the reference frequency.
This patch introduces a clk notifier callback that will gate and
then ungate a clk after a rate change, effectively resetting it,
so it continues to work, despite any possible lockups. Care must
be taken to reparent any consumers to other temporary clocks during
the rate change, and that this notifier callback must be the first
to be registered.
This is intended to fix occasional lockups with cpufreq on newer
Allwinner SoCs, such as the A33 and the H3. Previously it was
thought that reparenting the cpu clock away from the PLL while
it stabilized was enough, as this worked quite well on the A31.
On the A33, hangs have been observed after cpufreq was recently
introduced. With the H3, a more thorough test [1] showed that
reparenting alone isn't enough. The system still locks up unless
the dividers are limited to 1.
A hunch was if the PLL was stuck in some unknown state, perhaps
gating then ungating it would bring it back to normal. Tests
done by Icenowy Zheng using Ondrej's test firmware shows this
to be a valid solution.
[1] http://www.spinics.net/lists/arm-kernel/msg552501.html
Reported-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
Tested-by: Icenowy Zheng
Tested-by: Quentin Schulz
---
drivers/clk/sunxi-ng/ccu_common.c | 49 +++
drivers/clk/sunxi-ng/ccu_common.h | 12 ++
2 files changed, 61 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu_common.c
b/drivers/clk/sunxi-ng/ccu_common.c
index 188fa50d0380..40aac316128f 100644
--- a/drivers/clk/sunxi-ng/ccu_common.c
+++ b/drivers/clk/sunxi-ng/ccu_common.c
@@ -14,11 +14,13 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
#include "ccu_common.h"
+#include "ccu_gate.h"
#include "ccu_reset.h"
static DEFINE_SPINLOCK(ccu_lock);
@@ -39,6 +41,53 @@ void ccu_helper_wait_for_lock(struct ccu_common *common, u32
lock)
WARN_ON(readl_relaxed_poll_timeout(addr, reg, reg & lock, 100, 7));
}
+/*
+ * This clock notifier is called when the frequency of a PLL clock is
+ * changed. In common PLL designs, changes to the dividers take effect
+ * almost immediately, while changes to the multipliers (implemented
+ * as dividers in the feedback loop) take a few cycles to work into
+ * the feedback loop for the PLL to stablize.
+ *
+ * Sometimes when the PLL clock rate is changed, the decrease in the
+ * divider is too much for the decrease in the multiplier to catch up.
+ * The PLL clock rate will spike, and in some cases, might lock up
+ * completely.
+ *
+ * This notifier callback will gate and then ungate the clock,
+ * effectively resetting it, so it proceeds to work. Care must be
+ * taken to reparent consumers to other temporary clocks during the
+ * rate change, and that this notifier callback must be the first
+ * to be registered.
+ */
+static int ccu_pll_notifier_cb(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct ccu_pll_nb *pll = to_ccu_pll_nb(nb);
+ int ret = 0;
+
+ if (event != POST_RATE_CHANGE)
+ goto out;
+
+ ccu_gate_helper_disable(pll->common, pll->enable);
+
+ ret = ccu_gate_helper_enable(pll->common, pll->enable);
+ if (ret)
+ goto out;
+
+ ccu_helper_wait_for_lock(pll->common, pll->lock);
+
+out:
+ return notifier_from_errno(ret);
+}
+
+int ccu_pll_notifier_register(struct ccu_pll_nb *pll_nb)
+{
+ pll_nb->clk_nb.notifier_call = ccu_pll_notifier_cb;
+
+ return clk_notifier_register(pll_nb->common->hw.clk,
+&pll_nb->clk_nb);
+}
+
int sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
const struct sunxi_ccu_desc *desc)
{
diff --git a/drivers/clk/sunxi-ng/ccu_common.h
b/drivers/clk/sunxi-ng/ccu_common.h
index 73d81dc58fc5..d6fdd7a789aa 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -83,6 +83,18 @@ struct sunxi_ccu_desc {
void ccu_helper_wait_for_lock(struct ccu_common *common, u32 lock);
+struct ccu_pll_nb {
+ struct notifier_block clk_nb;
+ struct ccu_common *common;
+
+ u32 enable;
+ u32 lock;
+};
+
+#define to_ccu_pll_nb(_nb) container_of(_nb, struct ccu_pll_nb, clk_nb)
+
+int ccu_pll_notifier_register(struct ccu_pll_nb *pll_nb);
+
int sunxi_ccu_probe(struct device_node *node, void __iomem *reg,
[PATCH 0/3] clk: sunxi-ng: gate/ungate PLL CPU clk after rate change
Hi everyone,
This series adds a clk notifier for use on the PLL CPU clks found in
Allwinner SoCs. Some people have observed issues with the design and
implementation of the CPU PLL clock, starting from the A31. Changes
to the PLL clock need a few cycles to stabilize. If the changes are
too drastic, the dividers in particular, there is a good chance that
the system will hang.
Previously we thought that reparenting the CPU clock away from the PLL
while changes were made, and then reparenting it back once it was stable,
should have been enough to mitigate the issue. Unfortunately it was
not. With cpufreq support for A33 recently introduced in commit
03749eb88e63 ("ARM: dts: sun8i: add opp-v2 table for A33"), system hangs
were observed one out of two to three boots, right after userspace
configured cpufreq to switch to the ondemand governor. Other experiments
done by Ondrej Jirman [1] show that it is not enough to just reparent
the CPU clock, but the PLL clock's dividers must not be used.
We suspect the divider changes make the PLL unstable to the point that
it can not recover, possibly not providing any output afterwards. We
lack any hard evidence (oscilloscope readings or hardware implementation
details) to fully explain the behavior. However, if the hardware is
stuck in some undesired state, it is possible to "reset" it, by gating
the PLL, then ungating it.
This series adds a new clk notifier that does exactly that. The clk
notifier is registered on the PLL clock. Whenever its rate is changed,
the notifier comes in and toggles the gate. The notifier should always
be the first one registered. And all consumers of the clock must also
have notifiers on it to temporarily reparent away during the change.
Patches 2 and 3 register this new notifier for the CPU PLL clocks on
the A33 and H3, respectively. With the first 2 patches applied, the
cpufreq related system hangs on the A33 go away.
Given that commit 03749eb88e63 ("ARM: dts: sun8i: add opp-v2 table for
A33") is already in v4.11-rc, I suggest we either try to merge the
first 2 patches for a very late -rc fix, or drop A33 cpufreq support
from v4.11, and add it later once this series is merged.
Regards
ChenYu
[1] http://www.spinics.net/lists/arm-kernel/msg552501.html
Chen-Yu Tsai (3):
clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks
clk: sunxi-ng: a33: gate then ungate PLL CPU clk after rate change
clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 11
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 11
drivers/clk/sunxi-ng/ccu_common.c| 49
drivers/clk/sunxi-ng/ccu_common.h| 12 +
4 files changed, 83 insertions(+)
--
2.11.0
[PATCH 3/3] clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change
This patch utilizes the new PLL clk notifier to gate then ungate the
PLL CPU clock after rate changes. This should prevent any system hangs
resulting from cpufreq changes to the clk.
Reported-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
Tested-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 4cbc1b701b7c..fc04ef2af1ac 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -1103,6 +1103,13 @@ static const struct sunxi_ccu_desc sun50i_h5_ccu_desc = {
.num_resets = ARRAY_SIZE(sun50i_h5_ccu_resets),
};
+static struct ccu_pll_nb sun8i_h3_pll_cpu_nb = {
+ .common = &pll_cpux_clk.common,
+ /* copy from pll_cpux_clk */
+ .enable = BIT(31),
+ .lock = BIT(28),
+};
+
static struct ccu_mux_nb sun8i_h3_cpu_nb = {
.common = &cpux_clk.common,
.cm = &cpux_clk.mux,
@@ -1130,6 +1137,10 @@ static void __init sunxi_h3_h5_ccu_init(struct
device_node *node,
sunxi_ccu_probe(node, reg, desc);
+ /* Gate then ungate PLL CPU after any rate changes */
+ ccu_pll_notifier_register(&sun8i_h3_pll_cpu_nb);
+
+ /* Reparent CPU during PLL CPU rate changes */
ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
&sun8i_h3_cpu_nb);
}
--
2.11.0
[PATCH 2/3] clk: sunxi-ng: a33: gate then ungate PLL CPU clk after rate change
This patch utilizes the new PLL clk notifier to gate then ungate the
PLL CPU clock after rate changes. This should mitigate the system
hangs observed after the introduction of cpufreq for the A33.
Signed-off-by: Chen-Yu Tsai
Tested-by: Quentin Schulz
---
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 56370c2c7f98..8d38e6510e29 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -756,6 +756,13 @@ static const struct sunxi_ccu_desc sun8i_a33_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets),
};
+static struct ccu_pll_nb sun8i_a33_pll_cpu_nb = {
+ .common = &pll_cpux_clk.common,
+ /* copy from pll_cpux_clk */
+ .enable = BIT(31),
+ .lock = BIT(28),
+};
+
static struct ccu_mux_nb sun8i_a33_cpu_nb = {
.common = &cpux_clk.common,
.cm = &cpux_clk.mux,
@@ -787,6 +794,10 @@ static void __init sun8i_a33_ccu_setup(struct device_node
*node)
sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc);
+ /* Gate then ungate PLL CPU after any rate changes */
+ ccu_pll_notifier_register(&sun8i_a33_pll_cpu_nb);
+
+ /* Reparent CPU during PLL CPU rate changes */
ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
&sun8i_a33_cpu_nb);
}
--
2.11.0
Re: [PATCH] sched: Enabled schedstat when schedstat tracepoints are enabled
Hi Steven,
[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.11-rc6 next-20170412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steven-Rostedt/sched-Enabled-schedstat-when-schedstat-tracepoints-are-enabled/20170413-082900
config: i386-randconfig-x006-201715 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> kernel/sched/core.c:2289:5: error: redefinition of 'schedstat_tracepoint_reg'
int schedstat_tracepoint_reg(void)
^~~~
In file included from kernel/sched/core.c:8:0:
include/linux/sched.h:1463:19: note: previous definition of
'schedstat_tracepoint_reg' was here
static inline int schedstat_tracepoint_reg(void) { return 0; }
^~~~
>> kernel/sched/core.c:2299:6: error: redefinition of
>> 'schedstat_tracepoint_unreg'
void schedstat_tracepoint_unreg(void)
^~
In file included from kernel/sched/core.c:8:0:
include/linux/sched.h:1464:20: note: previous definition of
'schedstat_tracepoint_unreg' was here
static inline void schedstat_tracepoint_unreg(void) { }
^~
kernel/sched/core.c: In function 'schedstat_tracepoint_reg':
kernel/sched/core.c:2297:1: warning: control reaches end of non-void
function [-Wreturn-type]
}
^
vim +/schedstat_tracepoint_reg +2289 kernel/sched/core.c
2283 * regfunc/unregfunc functions. They are protected by the tracepoint
mutex.
2284 * See kernel/tracepoint.c:tracepoint_add_func().
2285 *
2286 * The modifications to schedstat_tracepoint_ref and
schedstat_save_state
2287 * are only done under that mutex, and do not need further protection.
2288 */
> 2289 int schedstat_tracepoint_reg(void)
2290 {
2291 if (!schedstat_tracepoint_ref) {
2292 schedstat_save_state = schedstat_enabled();
2293 if (!schedstat_save_state)
2294 set_schedstats(true);
2295 }
2296 schedstat_tracepoint_ref++;
2297 }
2298
> 2299 void schedstat_tracepoint_unreg(void)
2300 {
2301 schedstat_tracepoint_ref--;
2302 if (schedstat_tracepoint_ref || schedstat_save_state)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular
The Makefile / Kconfig currently controlling compilation of this code is:
clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += vlv2_plat_clock.o
atomisp/Kconfig:menuconfig INTEL_ATOMISP
atomisp/Kconfig:bool "Enable support to Intel MIPI camera drivers"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init was already not in use by this driver, the init
ordering remains unchanged with this commit.
Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman
Cc: Alan Cox
Cc: linux-me...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Paul Gortmaker
---
.../media/atomisp/platform/clock/vlv2_plat_clock.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
index 25e939c50aef..a322539d2621 100644
--- a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
+++ b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
@@ -21,7 +21,7 @@
#include
#include
-#include
+#include
#include
#include "../../include/linux/vlv2_plat_clock.h"
@@ -205,18 +205,10 @@ static int vlv2_plat_clk_probe(struct platform_device
*pdev)
return 0;
}
-static int vlv2_plat_clk_remove(struct platform_device *pdev)
-{
- iounmap(pmc_base);
- pmc_base = NULL;
- return 0;
-}
-
static const struct platform_device_id vlv2_plat_clk_id[] = {
{"vlv2_plat_clk", 0},
{}
};
-MODULE_DEVICE_TABLE(platform, vlv2_plat_clk_id);
static int vlv2_resume(struct device *device)
{
@@ -241,7 +233,6 @@ static const struct dev_pm_ops vlv2_pm_ops = {
static struct platform_driver vlv2_plat_clk_driver = {
.probe = vlv2_plat_clk_probe,
- .remove = vlv2_plat_clk_remove,
.id_table = vlv2_plat_clk_id,
.driver = {
.name = "vlv2_plat_clk",
@@ -254,13 +245,3 @@ static int __init vlv2_plat_clk_init(void)
return platform_driver_register(&vlv2_plat_clk_driver);
}
arch_initcall(vlv2_plat_clk_init);
-
-static void __exit vlv2_plat_clk_exit(void)
-{
- platform_driver_unregister(&vlv2_plat_clk_driver);
-}
-module_exit(vlv2_plat_clk_exit);
-
-MODULE_AUTHOR("Asutosh Pathak ");
-MODULE_DESCRIPTION("Intel VLV2 platform clock driver");
-MODULE_LICENSE("GPL v2");
--
2.11.0
Re: [PATCH v4 0/5] perf report: Show branch type
On 4/12/2017 6:58 PM, Jiri Olsa wrote: On Wed, Apr 12, 2017 at 06:21:01AM +0800, Jin Yao wrote: SNIP 3. Use 2 bits in perf_branch_entry for a "cross" metrics checking for branch cross 4K or 2M area. It's an approximate computing for checking if the branch cross 4K page or 2MB page. For example: perf record -g --branch-filter any,save_type perf report --stdio JCC forward: 27.7% JCC backward: 9.8% JMP: 0.0% IND_JMP: 6.5% CALL: 26.6% IND_CALL: 0.0% RET: 29.3% IRET: 0.0% CROSS_4K: 0.0% CROSS_2M: 14.3% got mangled perf report --stdio output for: [root@ibm-x3650m4-02 perf]# ./perf record -j any,save_type kill kill: not enough arguments [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.013 MB perf.data (18 samples) ] [root@ibm-x3650m4-02 perf]# ./perf report --stdio -f | head -30 # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 253 of event 'cycles' # Event count (approx.): 253 # # Overhead Command Source Shared Object Source Symbol Target SymbolBasic Block Cycles # ... ... ... .. # 8.30% perf Um [kernel.vmlinux] [k] __intel_pmu_enable_all.constprop.17 [k] native_write_msr - 7.91% perf Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_all [k] __intel_pmu_enable_all.constprop.17 - 7.91% perf Um [kernel.vmlinux] [k] native_write_msr [k] intel_pmu_lbr_enable_all - 6.32% kill libc-2.24.so [.] _dl_addr [.] _dl_addr - 5.93% perf Um [kernel.vmlinux] [k] perf_iterate_ctx [k] perf_iterate_ctx - 2.77% kill libc-2.24.so [.] malloc [.] malloc - 1.98% kill libc-2.24.so [.] _int_malloc [.] _int_malloc - 1.58% kill [kernel.vmlinux] [k] __rb_insert_augmented [k] __rb_insert_augmented- 1.58% perf Um [kernel.vmlinux] [k] perf_event_exec [k] perf_event_exec - 1.19% kill [kernel.vmlinux] [k] anon_vma_interval_tree_insert [k] anon_vma_interval_tree_insert- 1.19% kill [kernel.vmlinux] [k] free_pgd_range [k] free_pgd_range - 1.19% kill [kernel.vmlinux] [k] n_tty_write [k] n_tty_write - 1.19% perf Um [kernel.vmlinux] [k] native_sched_clock [k] sched_clock - ... SNIP jirka Sorry, I look at this issue at midnight in Shanghai. I misunderstood that the above output was only a mail format issue. Sorry about that. Now I recheck the output, and yes, the perf report output is mangled. But my patch doesn't touch the associated code. Anyway I remove my patches, pull the latest update from perf/core branch and run tests to check if its a regression issue. I test on HSW and SKL both. 1. On HSW. root@hsw:/tmp# perf record -j any kill .. /* SNIP */ For more details see kill(1). [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.014 MB perf.data (9 samples) ] root@hsw:/tmp# perf report --stdio # To display the perf.data header info, please use --header/--header-only options. # # # Total Lost Samples: 0 # # Samples: 144 of event 'cycles' # Event count (approx.): 144 # # Overhead Command Source Shared Object Source SymbolTarget SymbolBasic Block Cycles # ... ... ... .. # 10.42% kill libc-2.23.so [.] read_alias_file [.] read_alias_file - 9.72% kill [kernel.vmlinux] [k] update_load_avg [k] update_load_avg - 9.03% perf Um [unknown] [k] [k] - 8.33% kill libc-2.23.so [.] _int_malloc [.] _int_malloc - .. /* SNIP */ 0.69% kill [kernel.vmlinux] [k] _raw_spin_lock [k] unmap_page_range - 0.69% perf Um [kernel.vmlinux] [k] __intel_pmu_enable_all [k] native_write_msr - 0.69% perf Um [kernel.vmlinux] [k] intel_pmu_lbr_enable_
Re: [PATCH V3 02/16] block, bfq: add full hierarchical scheduling and cgroups support
Hi Arianna, [auto build test ERROR on block/for-next] [also build test ERROR on v4.11-rc6 next-20170412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paolo-Valente/Introduce-the-BFQ-I-O-scheduler/20170412-021320 base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git for-next config: m32r-allyesconfig (attached as .config) compiler: m32r-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m32r Note: the linux-review/Paolo-Valente/Introduce-the-BFQ-I-O-scheduler/20170412-021320 HEAD 36eb6533f8b6705991185201f75e98880cd223f7 builds fine. It only hurts bisectibility. All error/warnings (new ones prefixed by >>): ^~~ block/bfq-iosched.c:4559:13: error: invalid storage class for function 'bfq_bfqq_may_idle' static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq) ^ block/bfq-iosched.c:4602:13: error: invalid storage class for function 'bfq_bfqq_must_idle' static bool bfq_bfqq_must_idle(struct bfq_queue *bfqq) ^~ block/bfq-iosched.c:4614:26: error: invalid storage class for function 'bfq_select_queue' static struct bfq_queue *bfq_select_queue(struct bfq_data *bfqd) ^~~~ block/bfq-iosched.c:4714:24: error: invalid storage class for function 'bfq_dispatch_rq_from_bfqq' static struct request *bfq_dispatch_rq_from_bfqq(struct bfq_data *bfqd, ^ block/bfq-iosched.c:4746:13: error: invalid storage class for function 'bfq_has_work' static bool bfq_has_work(struct blk_mq_hw_ctx *hctx) ^~~~ block/bfq-iosched.c:4758:24: error: invalid storage class for function '__bfq_dispatch_request' static struct request *__bfq_dispatch_request(struct blk_mq_hw_ctx *hctx) ^~ block/bfq-iosched.c:4843:24: error: invalid storage class for function 'bfq_dispatch_request' static struct request *bfq_dispatch_request(struct blk_mq_hw_ctx *hctx) ^~~~ block/bfq-iosched.c:4862:13: error: invalid storage class for function 'bfq_put_queue' static void bfq_put_queue(struct bfq_queue *bfqq) ^ block/bfq-iosched.c:4884:13: error: invalid storage class for function 'bfq_exit_bfqq' static void bfq_exit_bfqq(struct bfq_data *bfqd, struct bfq_queue *bfqq) ^ block/bfq-iosched.c:4896:13: error: invalid storage class for function 'bfq_exit_icq_bfqq' static void bfq_exit_icq_bfqq(struct bfq_io_cq *bic, bool is_sync) ^ block/bfq-iosched.c:4914:13: error: invalid storage class for function 'bfq_exit_icq' static void bfq_exit_icq(struct io_cq *icq) ^~~~ block/bfq-iosched.c:4927:1: error: invalid storage class for function 'bfq_set_next_ioprio_data' bfq_set_next_ioprio_data(struct bfq_queue *bfqq, struct bfq_io_cq *bic) ^~~~ block/bfq-iosched.c:4973:13: error: invalid storage class for function 'bfq_check_ioprio_change' static void bfq_check_ioprio_change(struct bfq_io_cq *bic, struct bio *bio) ^~~ block/bfq-iosched.c:5001:13: error: invalid storage class for function 'bfq_init_bfqq' static void bfq_init_bfqq(struct bfq_data *bfqd, struct bfq_queue *bfqq, ^ block/bfq-iosched.c:5036:27: error: invalid storage class for function 'bfq_async_queue_prio' static struct bfq_queue **bfq_async_queue_prio(struct bfq_data *bfqd, ^~~~ block/bfq-iosched.c:5055:26: error: invalid storage class for function 'bfq_get_queue' static struct bfq_queue *bfq_get_queue(struct bfq_data *bfqd, ^ block/bfq-iosched.c:5120:13: error: invalid storage class for function 'bfq_update_io_thinktime' static void bfq_update_io_thinktime(struct bfq_data *bfqd, ^~~ block/bfq-iosched.c:5135:1: error: invalid storage class for function 'bfq_update_io_seektime' bfq_update_io_seektime(struct bfq_data *bfqd, struct bfq_queue *bfqq, ^~ block/bfq-iosched.c:5157:13: error: invalid storage class for function 'bfq_update_idle_window' static void bfq_update_idle_window(struct bfq_d
Re: [patch 06/13] sparc/sysfs: Replace racy task affinity logic
From: Thomas Gleixner
Date: Wed, 12 Apr 2017 22:07:32 +0200
> @@ -142,7 +122,8 @@ static unsigned long write_mmustat_enabl
> static ssize_t show_mmustat_enable(struct device *s,
> struct device_attribute *attr, char *buf)
> {
> - unsigned long val = run_on_cpu(s->id, read_mmustat_enable, 0);
> + long val = work_on_cpu(s->id, read_mmustat_enable, 0);
Last argument to work_on_cpu() should be NULL since it's a pointer
I guess.
But otherwise I have no problems with this:
Acked-by: David S. Miller
[PATCH net-next] l2tp: device MTU setup, tunnel socket needs a lock
The MTU overhead calculation in L2TP device set-up
merged via commit b784e7ebfce8cfb16c6f95e14e8532d0768ab7ff
needs to be adjusted to lock the tunnel socket while
referencing the sub-data structures to derive the
socket's IP overhead.
Reported-by: Guillaume Nault
Tested-by: Guillaume Nault
Signed-off-by: R. Parameswaran
---
include/linux/net.h | 2 +-
net/l2tp/l2tp_eth.c | 2 ++
net/socket.c| 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/net.h b/include/linux/net.h
index a42fab2..abcfa46 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -298,7 +298,7 @@ int kernel_sendpage(struct socket *sock, struct page *page,
int offset,
int kernel_sock_ioctl(struct socket *sock, int cmd, unsigned long arg);
int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how);
-/* Following routine returns the IP overhead imposed by a socket. */
+/* Routine returns the IP overhead imposed by a (caller-protected) socket. */
u32 kernel_sock_ip_overhead(struct sock *sk);
#define MODULE_ALIAS_NETPROTO(proto) \
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 138566a..b722d55 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -225,7 +225,9 @@ static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
dev->needed_headroom += session->hdr_len;
return;
}
+ lock_sock(tunnel->sock);
l3_overhead = kernel_sock_ip_overhead(tunnel->sock);
+ release_sock(tunnel->sock);
if (l3_overhead == 0) {
/* L3 Overhead couldn't be identified, this could be
* because tunnel->sock was NULL or the socket's
diff --git a/net/socket.c b/net/socket.c
index eea9970..c2564eb 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3360,7 +3360,7 @@ EXPORT_SYMBOL(kernel_sock_shutdown);
/* This routine returns the IP overhead imposed by a socket i.e.
* the length of the underlying IP header, depending on whether
* this is an IPv4 or IPv6 socket and the length from IP options turned
- * on at the socket.
+ * on at the socket. Assumes that the caller has a lock on the socket.
*/
u32 kernel_sock_ip_overhead(struct sock *sk)
{
--
2.1.4
