Re: [PATCH] watchdog: remove at32ap700x_wdt

[Hans-Christian Noren Egtvedt]

Around Thu 18 Jan 2018 12:08:32 -0800 or thereabout, Guenter Roeck wrote:
> On Thu, Jan 18, 2018 at 08:52:56PM +0100, Corentin Labbe wrote:
>> Since AVR32 is gone, this driver is useless.
>> 
> 
> Quite true.
> 
>> Signed-off-by: Corentin Labbe 
> 
> Reviewed-by: Guenter Roeck 

Acked-by: Hans-Christian Noren Egtvedt 

>> ---
>>  drivers/watchdog/Kconfig  |   9 -
>>  drivers/watchdog/Makefile |   3 -
>>  drivers/watchdog/at32ap700x_wdt.c | 433 
>> --
>>  3 files changed, 445 deletions(-)
>>  delete mode 100644 drivers/watchdog/at32ap700x_wdt.c



-- 
mvh
Hans-Christian Noren Egtvedt

[PATCH][V2] mtd: nand: marvell: remove redundant variable 'oob_len'

[Colin King]

From: Colin Ian King 

Variable oob_len is assigned and never read, hence it is redundant and
can be removed.

Cleans up clang warnings:

drivers/mtd/nand/marvell_nand.c:1356:6: warning: Value stored to 'oob_len'
during its initialization is never read
drivers/mtd/nand/marvell_nand.c:1369:4: warning: Value stored to 'oob_len'
is never read

Signed-off-by: Colin Ian King 
---
 drivers/mtd/nand/marvell_nand.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mtd/nand/marvell_nand.c b/drivers/mtd/nand/marvell_nand.c
index 4bd53b360277..f15ab37edf4e 100644
--- a/drivers/mtd/nand/marvell_nand.c
+++ b/drivers/mtd/nand/marvell_nand.c
@@ -1353,7 +1353,6 @@ static int marvell_nfc_hw_ecc_bch_write_page_raw(struct 
mtd_info *mtd,
int data_len = lt->data_bytes;
int spare_len = lt->spare_bytes;
int ecc_len = lt->ecc_bytes;
-   int oob_len = spare_len + ecc_len;
int spare_offset = 0;
int ecc_offset = (lt->full_chunk_cnt * lt->spare_bytes) +
lt->last_spare_bytes;
@@ -1366,7 +1365,6 @@ static int marvell_nfc_hw_ecc_bch_write_page_raw(struct 
mtd_info *mtd,
data_len = lt->last_data_bytes;
spare_len = lt->last_spare_bytes;
ecc_len = lt->last_ecc_bytes;
-   oob_len = spare_len + ecc_len;
}
 
/* Point to the column of the next chunk */
-- 
2.15.1

Can i trust you??

[Sgt. Britta Lopez]

Good Day,
How are u doing today ? Apologies! I am a military woman ,seeking
your kind assistance to move the sum of ($7M USD) to you, as far
as i can be assured that my money will be safe in your care until
i complete my service here in Afghanistan and come over next
month.
This is legitimate, and there is no danger involved.If
interested, reply immediately for detailed information.
 
Reply to this email sgtbrittalope...@gmail.com
Regards ,
Sgt. Britta Lopez

Re: [PATCH] rtc: remove rtc-at32ap700x

[Hans-Christian Noren Egtvedt]

Around Thu 18 Jan 2018 21:08:46 +0100 or thereabout, Corentin Labbe wrote:
> Since PLATFORM_AT32AP is an AVR32 platform which was removed, the
> rtc driver rtc-at32ap700x is useless.
> This patch remove it.
> 
> Signed-off-by: Corentin Labbe 

Acked-by: Hans-Christian Noren Egtvedt 

> ---
>  drivers/rtc/Kconfig  |   7 --
>  drivers/rtc/Makefile |   1 -
>  drivers/rtc/rtc-at32ap700x.c | 287 
> ---
>  3 files changed, 295 deletions(-)
>  delete mode 100644 drivers/rtc/rtc-at32ap700x.c
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index b71cc7b5fbc9..8ab5f0a5d323 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1402,13 +1402,6 @@ config RTC_DRV_PL031
> To compile this driver as a module, choose M here: the
> module will be called rtc-pl031.
>  
> -config RTC_DRV_AT32AP700X
> - tristate "AT32AP700X series RTC"
> - depends on PLATFORM_AT32AP || COMPILE_TEST
> - help
> -   Driver for the internal RTC (Realtime Clock) on Atmel AVR32
> -   AT32AP700x family processors.
> -
>  config RTC_DRV_AT91RM9200
>   tristate "AT91RM9200 or some AT91SAM9 RTC"
>   depends on ARCH_AT91 || COMPILE_TEST
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 6dfbbe9cd8a2..4fbf87e45a7c 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -33,7 +33,6 @@ obj-$(CONFIG_RTC_DRV_AC100) += rtc-ac100.o
>  obj-$(CONFIG_RTC_DRV_ARMADA38X)  += rtc-armada38x.o
>  obj-$(CONFIG_RTC_DRV_AS3722) += rtc-as3722.o
>  obj-$(CONFIG_RTC_DRV_ASM9260)+= rtc-asm9260.o
> -obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
>  obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
>  obj-$(CONFIG_RTC_DRV_AT91SAM9)   += rtc-at91sam9.o
>  obj-$(CONFIG_RTC_DRV_AU1XXX) += rtc-au1xxx.o



-- 
Best regards,
Hans-Christian Noren Egtvedt

Re: [PATCH 11/14] MIPS: memblock: Print out kernel virtual mem layout

[Matt Redfearn]

Hi Serge,



On 18/01/18 20:18, Serge Semin wrote:

On Thu, Jan 18, 2018 at 12:03:03PM -0800, Florian Fainelli 
 wrote:

On 01/17/2018 02:23 PM, Serge Semin wrote:

It is useful to have the kernel virtual memory layout printed
at boot time so to have the full information about the booted
kernel. In some cases it might be unsafe to have virtual
addresses freely visible in logs, so the %pK format is used if
one want to hide them.

Signed-off-by: Serge Semin 


I personally like having that information because that helps debug and
have a quick reference, but there appears to be a trend to remove this
in the name of security:

https://patchwork.kernel.org/patch/10124007/

maybe hide this behind a configuration option?


Yeah, arm code was the place I picked the function up.) But in my case
I've used %pK so the pointers would disappear from logging when
kptr_restrict sysctl is 1 or 2.
I agree, that we might need to make the printouts optional. If there is
any kernel config, which for instance increases the kernel security we
could also use it or anything else to discard the printouts at compile
time.



Certainly, when KASLR is active it would be preferable to hide this 
information, so you could use CONFIG_RELOCATABLE. The existing KASLR 
stuff additionally hides this kind of information behind 
CONFIG_DEBUG_KERNEL, so that only people actively debugging the kernel 
see it:


http://elixir.free-electrons.com/linux/v4.15-rc8/source/arch/mips/kernel/setup.c#L604

Thanks,
Matt




--
Florian

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

['Greg KH']

On Thu, Jan 18, 2018 at 01:13:15PM +, shufan_lee(李書帆) wrote:
> > +
> > +#include "rt1711h.h"
> 
> Why a .h file for a single .c file?
> 
> Is the suggestion to move all content in rt1711h.h into rt1711h.c?

If it can be, sure, you only need a .h file for things that are shared
among other .c files.

> > +/* I2C */
> > +atomic_t i2c_busy;
> > +atomic_t pm_suspend;
> 
> Why are these atomic?  You know that doesn't mean they do not need locking, 
> right?
> 
> For my understanding, a single operation on atomic_t doesn't need lock, like 
> a single atomic_set.
> But two consecutive operations doesn't guarantee anything. Like atomic_set 
> followed by an atomic_read.
> This part is referenced from fusb302 used to make sure I2C is idle before 
> system suspends.
> It only needs to guarantee a single read/write on these variable is atomic 
> operation, so atomic is used.

It's atomic for read/write, yes, but that does not mean it can not be
instantly changed after the value is read, right?  So you might need to
look and ensure you are not doing something wrong that can race.  A
single lock should be simpler than this type of thing, and will be
correct.

> > +#ifdef CONFIG_DEBUG_FS
> > +struct dentry *dbgdir;
> > +struct rt1711h_dbg_info dbg_info[RT1711H_DBG_MAX];
> > +struct dentry *dbg_files[RT1711H_DBG_MAX];
> > +int dbg_regidx;
> > +struct mutex dbgops_lock;
> > +/* lock for log buffer access */
> > +struct mutex logbuffer_lock;
> > +int logbuffer_head;
> > +int logbuffer_tail;
> > +u8 *logbuffer[LOG_BUFFER_ENTRIES];
> > +#endif /* CONFIG_DEBUG_FS */
> 
> That's a lot of stuff jsut for debugfs.  Why do you care about #define at 
> all?  The code should not.
> 
> Is the suggestion to remove #ifdef CONFIG_DEBUG_FS?

Yes.  Or just move it all to another structure that you can dynamically
add to this one if needed.

> And another 2 locks?  Ick, no.
> 
> dbgops_lock is used to prevent user from accessing different debug files 
> simultaneously.
> Is the suggestion to use the lock of the following one?
> > +/* lock for sharing chip states */
> > +struct mutex lock;

Sure, why not?

> 
> 
> > +snprintf(dirname, len + 9, "rt1711h-%s", dev_name(chip->dev));
> > +if (!chip->dbgdir) {
> > +chip->dbgdir = debugfs_create_dir(dirname, NULL);
> > +if (!chip->dbgdir)
> > +return -ENOMEM;
> 
> No need to ever check the return value of debugfs_ calls, you should not care 
> and can always use the value to any future debugfs calls, if you really need 
> it.
> 
> If it is NULL without checking and we use it in debugfs_create_file, all the 
> debug files will be created in the root of the debugfs filesystem.
> Is this correct?

If it returns NULL then any future calls to debugfs will also not be
working, so all will be fine.  So there is no need to check this.

> 
> 
> > +for (i = 0; i < RT1711H_DBG_MAX; i++) {
> > +info = &chip->dbg_info[i];
> 
> static array of debug info?  That feels odd.
> 
> Is the suggestion to use pointer of array and dynamically allocated it?

If that makes more sense, it's up to you.  Just a suggestion.

thanks,

greg k-h

Wichtige Notiz

[Euro Millions]

Herzlichen Glückwunsch, Sie haben 650.000 Euro in den monatlichen Gewinnspielen 
von Euro Millions / Google Promo am 12. Januar 2018 gewonnen.

Kontaktieren Sie unseren Schadenbearbeiter mit den folgenden Informationen

1. Vollständiger Name
2. Adresse
3. Sex
4. Alter
5. Beruf
6. Telefon

Kelvin Austin
Online-Koordinator

Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions

[Dou Liyang]

At 01/19/2018 03:21 PM, Baoquan He wrote:

On 01/19/18 at 02:42pm, Dou Liyang wrote:

Hi Baoquan,

At 01/05/2018 12:39 PM, Baoquan He wrote:
[...]

   /*
- * Not an __init, needed by kexec/kdump code.
- * For safety IO-APIC and Local APIC need be cleared before this.
+ * In legacy irq mode, full DOS compatibility with the uniprocessor PC/AT is
+ * provided by using the APICs in conjunction with standard 8259A-equivalent
+ * programmable interrupt controllers (PICs). It's necessary to deliver legacy
+ * interrupts even when APIC mode is not enabled. This is required by kexec/
+ * kdump before enter into the 2nd kernel.
*/
   void switch_to_legacy_irq_mode(void)
   {
if (!nr_legacy_irqs())
return;
-   x86_io_apic_ops.disable();
+   ioapic_set_virtual_wire_mode();
+
+   if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config())
+   lapic_set_legacy_irq_mode(ioapic_i8259.pin != -1);


Seems these two function, ioapic/lapic_set_legacy_irq_mode should be
exclusive.


Thanks for looking into this, dou!

It might be not exclusive. You can see mp_spec 3.6.2.2 Virtual Wire Mode


Oops! Sorry to confuse you, here what I want to say is that the code
make me think that we set through IO-APIC first, then set through
Local-APIC then. But, we can be only in one mode of them.

Just worry about this code seems ignore the irq remapping situation.

We call switch_to_legacy_irq_mode() directly in machine_kexec(),
why we also set x86_io_apic_ops:

  .disable = switch_to_legacy_irq_mode


subsection, there are two kinds of virtual wire mode, one is
8259A-Equivalent pics is connected to lint0 of boot cpu LAPIC, the other
is 8259A-Equivalent pics go through IO-APIC, then is connected to lint0
of LAPIC. Whatever it is, LAPIC need be set as through-lapic.



Yes, Absolutely right!


Above is what I got from mp_spec. But from function
native_disable_io_apic() and disconnect_bsp_APIC(), the code seems to be
telling that if io-apic is connected to 8259A-Equivalent pics, we need
mask lvt0 of LAPIC. This conflicts with mp_spec 3.6.2.2.



I think so.

Thanks,
dou.

Thanks
Baoquan


But We do that because both the through-lapic and through-ioapic virtual
wire mode need setup the APIC_SPIV_APIC_ENABLED which is only located in
the lapic_set_legacy_irq_mode(). So we need call them both.

IMO, this cleanup may not make it clear. we can separate these two mode
totally or just keep it like before.

Thanks,
dou.

   }
   #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 1151ccd72ce9..c30f0f273dbd 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -148,5 +148,5 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
   struct x86_io_apic_ops x86_io_apic_ops __ro_after_init = {
.read   = native_io_apic_read,
-   .disable= native_disable_io_apic,
+   .disable= switch_to_legacy_irq_mode,
   };
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 49721b4e1975..751472ddf536 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -37,7 +37,7 @@ static void irq_remapping_disable_io_apic(void)
 * now.
 */
if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config())
-   disconnect_bsp_APIC(0);
+   lapic_set_legacy_irq_mode(0);
   }
   static void __init irq_remapping_modify_x86_ops(void)

Re: [RESEND] phy: sun4i-usb: add support for R40 USB PHY

[Kishon Vijay Abraham I]

Hi,

On Friday 19 January 2018 11:55 AM, Chen-Yu Tsai wrote:
> Hi Kishon,
> 
> On Mon, Jan 15, 2018 at 11:06 PM, Hermann Lauer
>  wrote:
>> On Wed, Jan 03, 2018 at 04:49:44PM +0800, Icenowy Zheng wrote:
>>> Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
>>>
>>> Add support for it.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> Acked-by: Maxime Ripard 
>>> Acked-by: Rob Herring 
>>
>> You may add
>>
>> Tested-by: hermann.la...@iwr.uni-heidelberg.de
> 
> Gentle ping for this patch to be included in 4.16

Sent the pull request for 4.16 to Greg on Jan 2nd. So this can't be included in
4.16. Sorry.

Thanks
Kishon

Re: [PATCH v1 3/3] x86/platform/intel-mid: Add special handling of ACPI HW reduced platforms

[Ingo Molnar]

* Andy Shevchenko  wrote:

> On Wed, 2018-01-17 at 19:34 +0200, Andy Shevchenko wrote:
> > When switching to ACPI HW reduced platforms we still want to
> > initialize timers.
> > Override acpi_reduced_hw_init() to achieve that.
> 
> Just realized, that it may annihilate the other acpi_reduced_hw_init()
> on non-MID platforms...
> 
> Open to suggestions how would be better to deal with this (I really
> don't like the idea to spread MID quirks all over the code).
> 
> P.S. Patch 2 from the series still makes sense per se.

Ok, I'll apply patch #2 to tip:x86/platform.

Thanks,

Ingo

Re: [PATCH] print kdump kernel loaded status in stack dump

[Dave Young]

On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> On (01/18/18 10:02), Andi Kleen wrote:
> > Dave Young  writes:
> > >   printk("%sHardware name: %s\n",
> > >  log_lvl, dump_stack_arch_desc_str);
> > > + if (kexec_crash_loaded())
> > > + printk("%skdump kernel loaded\n", log_lvl);
> > 
> > Oops/warnings are getting longer and longer, often scrolling away
> > from the screen, and if the kernel crashes backscroll does not work
> > anymore, so precious information is lost.
> 
> true. I even ended up having a console_reflush_on_panic() function. it
> simply re-prints with a delay [so I can at least read the oops] logbuf
> entries every once in a while, staring with the first oops_in_progress
> record.
> 

If too many messages printed on screen, then the next flush will 
still scroll up.  I thought about adding an option to improve
printk_delay so it can delay every n lines, eg. 25 rows. Maybe that
idea works for this issue?

BTW, if kdump is used then we should avoid adding extra stuff in panic
path.

> something like below [it's completely hacked up, but at least gives
> an idea]
> 
> ---
> 
>  include/linux/console.h |  1 +
>  kernel/panic.c  |  7 +++
>  kernel/printk/printk.c  | 39 ++-
>  3 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/console.h b/include/linux/console.h
> index b8920a031a3e..502e3f539448 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -168,6 +168,7 @@ extern void console_unlock(void);
>  extern void console_conditional_schedule(void);
>  extern void console_unblank(void);
>  extern void console_flush_on_panic(void);
> +extern void console_reflush_on_panic(void);
>  extern struct tty_driver *console_device(int *);
>  extern void console_stop(struct console *);
>  extern void console_start(struct console *);
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 2cfef408fec9..39cd59bbfaab 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -137,6 +137,7 @@ void panic(const char *fmt, ...)
>   va_list args;
>   long i, i_next = 0;
>   int state = 0;
> + int reflush_tick = 0;
>   int old_cpu, this_cpu;
>   bool _crash_kexec_post_notifiers = crash_kexec_post_notifiers;
>  
> @@ -298,6 +299,12 @@ void panic(const char *fmt, ...)
>   i_next = i + 3600 / PANIC_BLINK_SPD;
>   }
>   mdelay(PANIC_TIMER_STEP);
> +
> + reflush_tick++;
> + if (reflush_tick == 32) { /* don't reflush too often */
> + console_reflush_on_panic();
> + reflush_tick = 0;
> + }
>   }
>  }
>  
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 9cb943c90d98..ef3f28d4c741 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -426,6 +426,10 @@ static u32 log_next_idx;
>  static u64 console_seq;
>  static u32 console_idx;
>  
> +/* index and sequence number of the record which started the oops print out 
> */
> +static u64 log_oops_seq;
> +static u32 log_oops_idx;
> +
>  /* the next printk record to read after the last 'clear' command */
>  static u64 clear_seq;
>  static u32 clear_idx;
> @@ -1736,6 +1740,15 @@ static inline void printk_delay(void)
>   }
>  }
>  
> +/*
> + * Why do we have printk_delay() in vprintk_emit()
> + * and not in console_unlock()?
> + */
> +static inline void console_unlock_delay(void)
> +{
> + printk_delay();
> +}
> +
>  /*
>   * Continuation lines are buffered, and not committed to the record buffer
>   * until the line is complete, or a race forces it. The line fragments
> @@ -1849,6 +1862,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>  
>   /* This stops the holder of console_sem just where we want him */
>   logbuf_lock_irqsave(flags);
> +
>   /*
>* The printf needs to come first; we need the syslog
>* prefix which might be passed-in as a parameter.
> @@ -1890,7 +1904,11 @@ asmlinkage int vprintk_emit(int facility, int level,
>   lflags |= LOG_PREFIX|LOG_NEWLINE;
>  
>   printed_len = log_output(facility, level, lflags, dict, dictlen, text, 
> text_len);
> -
> + /* Oops... */
> + if (oops_in_progress && !log_oops_seq) {
> + log_oops_seq = log_next_seq;
> + log_oops_idx = log_next_idx;
> + }
>   logbuf_unlock_irqrestore(flags);
>  
>   /* If called from the scheduler, we can not call up(). */
> @@ -2396,6 +2414,7 @@ void console_unlock(void)
>  
>   stop_critical_timings();/* don't trace print latency */
>   call_console_drivers(ext_text, ext_len, text, len);
> + console_unlock_delay();
>   start_critical_timings();
>  
>   if (console_lock_spinning_disable_and_check()) {
> @@ -2495,6 +2514,24 @@ void console_flush_on_panic(void)
>   console_unlock();
>  }
>  
> +/**
> + * console_reflush_on_pan

Re: [RFC] Per file OOM badness

[Christian König]

Am 19.01.2018 um 06:39 schrieb He, Roger:

Basically the idea is right to me.

1. But we need smaller granularity to control the contribution to OOM badness.
  Because when the TTM buffer resides in VRAM rather than evict to system 
memory, we should not take this account into badness.
  But I think it is not easy to implement.


I was considering that as well when I wrote the original patch set, but 
then decided against it at least for now.


Basically all VRAM buffers can be swapped to system memory, so they 
potentially need system memory as well. That is especially important 
during suspend/resume.




2. If the TTM buffer(GTT here) is mapped to user for CPU access, not quite sure 
the buffer size is already taken into account for kernel.
  If yes, at last the size will be counted again by your patches.


No that isn't accounted for as far as I know.



So, I am thinking if we can counted the TTM buffer size into:
struct mm_rss_stat {
atomic_long_t count[NR_MM_COUNTERS];
};
Which is done by kernel based on CPU VM (page table).

Something like that:
When GTT allocate suceess:
add_mm_counter(vma->vm_mm, MM_ANONPAGES, buffer_size);

When GTT swapped out:
dec_mm_counter from MM_ANONPAGES frist, then
add_mm_counter(vma->vm_mm, MM_SWAPENTS, buffer_size);  // or MM_SHMEMPAGES or 
add new item.

Update the corresponding item in mm_rss_stat always.
If that, we can control the status update accurately.
What do you think about that?
And is there any side-effect for this approach?


I already tried this when I originally worked on the issue and that 
approach didn't worked because allocated buffers are not associated to 
the process where they are created.


E.g. most display surfaces are created by the X server, but used by 
processes. So if you account the BO to the process who created it we 
would start to kill X again and that is exactly what we try to avoid.


Regards,
Christian.




Thanks
Roger(Hongbo.He)

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Andrey Grodzovsky
Sent: Friday, January 19, 2018 12:48 AM
To: linux-kernel@vger.kernel.org; linux...@kvack.org; 
dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: [RFC] Per file OOM badness

Hi, this series is a revised version of an RFC sent by Christian König a few 
years ago. The original RFC can be found at 
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html

This is the same idea and I've just adressed his concern from the original RFC 
and switched to a callback into file_ops instead of a new member in struct file.

Thanks,
Andrey

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH driver-core] kernfs: fix regression in kernfs_fop_write caused by wrong type

[Ivan Vecera]

Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.

Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0)   <- true here in this case
*ppos += len;
...

Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Signed-off-by: Ivan Vecera 
---
 fs/kernfs/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 9698e51656b1..d8f49c412f50 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -275,7 +275,7 @@ static ssize_t kernfs_fop_write(struct file *file, const 
char __user *user_buf,
 {
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
-   size_t len;
+   ssize_t len;
char *buf;
 
if (of->atomic_write_len) {
-- 
2.13.6

Re: [PATCH] input: remove at32psif

[Hans-Christian Noren Egtvedt]

Around Thu 18 Jan 2018 11:55:43 -0800 or thereabout, Dmitry Torokhov wrote:
> On Thu, Jan 18, 2018 at 08:48:24PM +0100, Corentin Labbe wrote:
>> On Thu, Jan 18, 2018 at 11:20:17AM -0800, Dmitry Torokhov wrote:
>> > On Thu, Jan 18, 2018 at 07:58:11PM +0100, Corentin Labbe wrote:
>> > > Since AVR32 arch is gone, at32psif driver is useless.
>> > > This patch remove it.
>> > > 
>> > > Signed-off-by: Corentin Labbe 
>> > 
>> > Applied, thank you.
>> > 
>> > What about:
>> > 
>> > config TOUCHSCREEN_WM97XX_ATMEL
>> >tristate "WM97xx Atmel accelerated touch"
>> >depends on TOUCHSCREEN_WM97XX && AVR32 
>> > 
>> > ?
>> > 
>> 
>> It was my second target BUT the code content reference to AT91 (wm97xx 
>> continuous touch driver for Atmel AT91 and AVR32) so perhaps it could be 
>> keeped.
>> 
>> But someone need to test it.
> 
> "&& AVR32" means that nobody ever ran it on AT91 though...
> Hans-Christian, any ideas?

I never tested accelerating WM97xx codecs on AT91, hence it is AVR32 only. It
can be removed.

Thanks for cleaning (-:

-- 
Best regards,
Hans-Christian Noren Egtvedt

Re: [PATCH V5 0/2] nvme-pci: fix the timeout case when reset is ongoing

[jianchao.wang]

Hi Keith

Thanks for your time to look into this.

On 01/19/2018 04:01 PM, Keith Busch wrote:
> On Thu, Jan 18, 2018 at 06:10:00PM +0800, Jianchao Wang wrote:
>> Hello
>>
>> Please consider the following scenario.
>> nvme_reset_ctrl
>>   -> set state to RESETTING
>>   -> queue reset_work   
>> (scheduling)
>> nvme_reset_work
>>   -> nvme_dev_disable
>> -> quiesce queues
>> -> nvme_cancel_request 
>>on outstanding requests
>> ---_boundary_
>>   -> nvme initializing (issue request on adminq)
>>
>> Before the _boundary_, not only quiesce the queues, but only cancel
>> all the outstanding requests.
>>
>> A request could expire when the ctrl state is RESETTING.
>>  - If the timeout occur before the _boundary_, the expired requests
>>are from the previous work.
>>  - Otherwise, the expired requests are from the controller initializing
>>procedure, such as sending cq/sq create commands to adminq to setup
>>io queues.
>> In current implementation, nvme_timeout cannot identify the _boundary_ 
>> so only handles second case above.
> 
> Bare with me a moment, as I'm only just now getting a real chance to look
> at this, and I'm not quite sure I follow what problem this is solving.
> 
> The nvme_dev_disable routine makes forward progress without depending on
> timeout handling to complete expired commands. Once controller disabling
> completes, there can't possibly be any started requests that can expire.
> So we don't need nvme_timeout to do anything for requests above the
> boundary.
> 
Yes, once controller disabling completes, any started requests will be handled 
and cannot expire.
But before the _boundary_, there could be a nvme_timeout context runs with 
nvme_dev_disable in parallel.
If a timeout path grabs a request, then nvme_dev_disable cannot get and cancel 
it.
So even though the nvme_dev_disable completes, there still could be a request 
in nvme_timeout context.

The worst case is :
nvme_timeout  nvme_reset_work
if (ctrl->state == RESETTING )  nvme_dev_disable
nvme_dev_disableinitializing procedure

the nvme_dev_disable run with reinit procedure in nvme_reset_work in parallel.


Thanks
Jianchao

[PATCH] input: touchscreen: remove atmel-wm97xx

[Corentin Labbe]

Since AVR32 arch is gone, atmel-wm97xx driver is useless.
Remove it.

Signed-off-by: Corentin Labbe 
---
 drivers/input/touchscreen/Kconfig|  15 --
 drivers/input/touchscreen/Makefile   |   1 -
 drivers/input/touchscreen/atmel-wm97xx.c | 436 ---
 3 files changed, 452 deletions(-)
 delete mode 100644 drivers/input/touchscreen/atmel-wm97xx.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 38a226f9fcbd..4f15496fec8b 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -795,21 +795,6 @@ config TOUCHSCREEN_WM9713
  Say Y here to enable support for the Wolfson Microelectronics
  WM9713 touchscreen controller.
 
-config TOUCHSCREEN_WM97XX_ATMEL
-   tristate "WM97xx Atmel accelerated touch"
-   depends on TOUCHSCREEN_WM97XX && AVR32
-   help
- Say Y here for support for streaming mode with WM97xx touchscreens
- on Atmel AT91 or AVR32 systems with an AC97C module.
-
- Be aware that this will use channel B in the controller for
- streaming data, this must not conflict with other AC97C drivers.
-
- If unsure, say N.
-
- To compile this driver as a module, choose M here: the module will
- be called atmel-wm97xx.
-
 config TOUCHSCREEN_WM97XX_MAINSTONE
tristate "WM97xx Mainstone/Palm accelerated touch"
depends on TOUCHSCREEN_WM97XX && ARCH_PXA
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index d2a2b3b7af27..dddae7973436 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -97,7 +97,6 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX)  += wm97xx-ts.o
 wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705) += wm9705.o
 wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9712) += wm9712.o
 wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9713) += wm9713.o
-obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL) += atmel-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)  += zylonite-wm97xx.o
 obj-$(CONFIG_TOUCHSCREEN_W90X900)  += w90p910_ts.o
diff --git a/drivers/input/touchscreen/atmel-wm97xx.c 
b/drivers/input/touchscreen/atmel-wm97xx.c
deleted file mode 100644
index 9140a43cfe20..
--- a/drivers/input/touchscreen/atmel-wm97xx.c
+++ /dev/null
@@ -1,436 +0,0 @@
-/*
- * Atmel AT91 and AVR32 continuous touch screen driver for Wolfson WM97xx AC97
- * codecs.
- *
- * Copyright (C) 2008 - 2009 Atmel Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define AC97C_ICA  0x10
-#define AC97C_CBRHR0x30
-#define AC97C_CBSR 0x38
-#define AC97C_CBMR 0x3c
-#define AC97C_IER  0x54
-#define AC97C_IDR  0x58
-
-#define AC97C_RXRDY(1 << 4)
-#define AC97C_OVRUN(1 << 5)
-
-#define AC97C_CMR_SIZE_20  (0 << 16)
-#define AC97C_CMR_SIZE_18  (1 << 16)
-#define AC97C_CMR_SIZE_16  (2 << 16)
-#define AC97C_CMR_SIZE_10  (3 << 16)
-#define AC97C_CMR_CEM_LITTLE   (1 << 18)
-#define AC97C_CMR_CEM_BIG  (0 << 18)
-#define AC97C_CMR_CENA (1 << 21)
-
-#define AC97C_INT_CBEVT(1 << 4)
-
-#define AC97C_SR_CAEVT (1 << 3)
-
-#define AC97C_CH_MASK(slot)\
-   (0x7 << (3 * (slot - 3)))
-#define AC97C_CH_ASSIGN(slot, channel) \
-   (AC97C_CHANNEL_##channel << (3 * (slot - 3)))
-#define AC97C_CHANNEL_NONE 0x0
-#define AC97C_CHANNEL_B0x2
-
-#define ac97c_writel(chip, reg, val)   \
-   __raw_writel((val), (chip)->regs + AC97C_##reg)
-#define ac97c_readl(chip, reg) \
-   __raw_readl((chip)->regs + AC97C_##reg)
-
-#ifdef CONFIG_CPU_AT32AP700X
-#define ATMEL_WM97XX_AC97C_IOMEM   (0xfff02800)
-#define ATMEL_WM97XX_AC97C_IRQ (29)
-#define ATMEL_WM97XX_GPIO_DEFAULT  (32+16) /* Pin 16 on port B. */
-#else
-#error Unknown CPU, this driver only supports AT32AP700X CPUs.
-#endif
-
-struct continuous {
-   u16 id;/* codec id */
-   u8 code;   /* continuous code */
-   u8 reads;  /* number of coord reads per read cycle */
-   u32 speed; /* number of coords per second */
-};
-
-#define WM_READS(sp) ((sp / HZ) + 1)
-
-static const struct continuous cinfo[] = {
-   {WM9705_ID2, 0, WM_READS(94), 94},
-   {WM9705_ID2, 1, WM_READS(188), 188},
-   {WM9705_ID2, 2, WM_READS(375), 375},
-   {WM9705_ID2, 3, WM_READS(750), 750},
-   {WM9712_ID2, 0, WM_READS(94), 94},
-   {WM9712_ID2, 1, WM_READS(188), 188},
-   {WM9712_ID2, 2, WM_READS(375), 

Re: [RFC] Per file OOM badness

[Michal Hocko]

On Thu 18-01-18 12:01:32, Eric Anholt wrote:
> Michal Hocko  writes:
> 
> > On Thu 18-01-18 18:00:06, Michal Hocko wrote:
> >> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:
> >> > Hi, this series is a revised version of an RFC sent by Christian König
> >> > a few years ago. The original RFC can be found at 
> >> > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
> >> > 
> >> > This is the same idea and I've just adressed his concern from the 
> >> > original RFC 
> >> > and switched to a callback into file_ops instead of a new member in 
> >> > struct file.
> >> 
> >> Please add the full description to the cover letter and do not make
> >> people hunt links.
> >> 
> >> Here is the origin cover letter text
> >> : I'm currently working on the issue that when device drivers allocate 
> >> memory on
> >> : behalf of an application the OOM killer usually doesn't knew about that 
> >> unless
> >> : the application also get this memory mapped into their address space.
> >> : 
> >> : This is especially annoying for graphics drivers where a lot of the VRAM
> >> : usually isn't CPU accessible and so doesn't make sense to map into the
> >> : address space of the process using it.
> >> : 
> >> : The problem now is that when an application starts to use a lot of VRAM 
> >> those
> >> : buffers objects sooner or later get swapped out to system memory, but 
> >> when we
> >> : now run into an out of memory situation the OOM killer obviously doesn't 
> >> knew
> >> : anything about that memory and so usually kills the wrong process.
> >
> > OK, but how do you attribute that memory to a particular OOM killable
> > entity? And how do you actually enforce that those resources get freed
> > on the oom killer action?
> >
> >> : The following set of patches tries to address this problem by 
> >> introducing a per
> >> : file OOM badness score, which device drivers can use to give the OOM 
> >> killer a
> >> : hint how many resources are bound to a file descriptor so that it can 
> >> make
> >> : better decisions which process to kill.
> >
> > But files are not killable, they can be shared... In other words this
> > doesn't help the oom killer to make an educated guess at all.
> 
> Maybe some more context would help the discussion?
> 
> The struct file in patch 3 is the DRM fd.  That's effectively "my
> process's interface to talking to the GPU" not "a single GPU resource".
> Once that file is closed, all of the process's private, idle GPU buffers
> will be immediately freed (this will be most of their allocations), and
> some will be freed once the GPU completes some work (this will be most
> of the rest of their allocations).
> 
> Some GEM BOs won't be freed just by closing the fd, if they've been
> shared between processes.  Those are usually about 8-24MB total in a
> process, rather than the GBs that modern apps use (or that our testcases
> like to allocate and thus trigger oomkilling of the test harness instead
> of the offending testcase...)
> 
> Even if we just had the private+idle buffers being accounted in OOM
> badness, that would be a huge step forward in system reliability.

OK, in that case I would propose a different approach. We already
have rss_stat. So why do not we simply add a new counter there
MM_KERNELPAGES and consider those in oom_badness? The rule would be
that such a memory is bound to the process life time. I guess we will
find more users for this later.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Heikki Krogerus]

Hi Shu-Fan,

On Fri, Jan 19, 2018 at 05:48:02AM +, shufan_lee(?) wrote:
> Hi Jun,
> 
>   For now, RT1711H is not fully compatible with TCPCI. So the existing tcpci.c
>   may not work for it.

The datasheet for RT1711H does talk about TCPCi and TCPM+TCPC [1].
What are the differences that justify a separate driver?

[1] http://www.richtek.com/assets/product_file/RT1711H/DS1711H-02.pdf


Br,

-- 
heikki

[PATCH] KVM: prevent overlap between user and private memslots

[Eric Biggers]

From: Eric Biggers 

Memslots must not overlap in guest physical memory, since otherwise some
guest physical addresses will not uniquely map to a memslot.  Yet, the
overlap check in __kvm_set_memory_region() allows a memslot that
overlaps one of the "private" memslots, e.g. the memslot reserved for
the TSS on x86.

This seems to be a very old bug that was introduced years ago when
private memory slots were first added.  It seems that later refactoring
incorrectly assumed this bug was intentional and preserved it.

Fix it by removing the loophole for private memslots, so we just check
for overlap against all memslots.

This bug was found by syzkaller, which used a memslot overlap to make
pte_list_remove() be called for the wrong memslot, hitting a BUG():

pte_list_remove: 7185ed42 0->BUG
kernel BUG at arch/x86/kvm/mmu.c:1209!
[...]
RIP: 0010:pte_list_remove+0x107/0x110 arch/x86/kvm/mmu.c:1208
[...]
Call Trace:
 mmu_page_zap_pte+0x7e/0xd0 arch/x86/kvm/mmu.c:2499
 kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2521 [inline]
 kvm_mmu_prepare_zap_page+0x4f/0x340 arch/x86/kvm/mmu.c:2565
 kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5348 [inline]
 kvm_mmu_invalidate_zap_all_pages+0xa6/0x100 arch/x86/kvm/mmu.c:5389
 kvm_mmu_notifier_release+0x4f/0x80 
arch/x86/kvm/../../../virt/kvm/kvm_main.c:468
 __mmu_notifier_release+0x63/0x100 mm/mmu_notifier.c:75
 mmu_notifier_release include/linux/mmu_notifier.h:244 [inline]
 exit_mmap+0x160/0x170 mm/mmap.c:3009
 __mmput kernel/fork.c:966 [inline]
 mmput+0x44/0xd0 kernel/fork.c:987
 exit_mm kernel/exit.c:544 [inline]
 do_exit+0x24a/0xb50 kernel/exit.c:856
 do_group_exit+0x34/0xb0 kernel/exit.c:972
 SYSC_exit_group kernel/exit.c:983 [inline]
 SyS_exit_group+0xb/0x10 kernel/exit.c:981
 entry_SYSCALL_64_fastpath+0x1e/0x8b

Reproducer:

#include 
#include 
#include 

int main()
{
static char buf[4096*3] __attribute__((aligned(4096)));
int kvm, vm, cpu;
struct kvm_mp_state mp_state = { KVM_MP_STATE_SIPI_RECEIVED };
struct kvm_userspace_memory_region memreg = {
.memory_size = sizeof(buf),
.userspace_addr = (__u64)buf,
};

kvm = open("/dev/kvm", O_RDWR);
vm = ioctl(kvm, KVM_CREATE_VM, 0);
ioctl(vm, KVM_CREATE_IRQCHIP);
cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
ioctl(cpu, KVM_SET_MP_STATE, &mp_state);
ioctl(vm, KVM_SET_TSS_ADDR, 0);
ioctl(cpu, KVM_RUN, 0);
ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
}

Reported-by: syzbot 
Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
Cc:  # v2.6.25+
Signed-off-by: Eric Biggers 
---
 virt/kvm/kvm_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 210bf820385a..e536977e7b6d 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
/* Check for overlaps */
r = -EEXIST;
kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
-   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
-   (slot->id == id))
+   if (slot->id == id)
continue;
if (!((base_gfn + npages <= slot->base_gfn) ||
  (base_gfn >= slot->base_gfn + slot->npages)))
-- 
2.16.0

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> In preparation for the following patch which will fix an issue on
> the 8xx by re-using the 'slices', this patch enhances the
> 'slices' implementation to support 32 bits CPUs.
>
> On PPC32, the address space is limited to 4Gbytes, hence only the low
> slices will be used. As of today, the code uses
> SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
> if addr refers to low or high space.
> On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
> 0x1ul degrades to 0. Therefore, the patch modifies
> SLICE_LOW_TOP to (0xul) and modifies the tests to
> (addr <= SLICE_LOW_TOP) which will then always be true on PPC32
> as addr has type 'unsigned long' while not modifying the PPC64
> behaviour.
>
> This patch moves "slices" functions prototypes from page64.h to page.h
>
> The high slices use bitmaps. As bitmap functions are not prepared to
> handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
> slice_bitmap_xxx() macros which will take care of the 0 nbits case.
>
> Signed-off-by: Christophe Leroy 
> ---
>  v2: First patch of v1 serie split in two parts ; added slice_bitmap_xxx() 
> macros.
>
>  arch/powerpc/include/asm/page.h  | 14 +
>  arch/powerpc/include/asm/page_32.h   | 19 
>  arch/powerpc/include/asm/page_64.h   | 21 ++---
>  arch/powerpc/mm/hash_utils_64.c  |  2 +-
>  arch/powerpc/mm/mmu_context_nohash.c |  7 +
>  arch/powerpc/mm/slice.c  | 60 
> 
>  6 files changed, 83 insertions(+), 40 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 8da5d4c1cab2..d0384f9db9eb 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
>  #endif
>  #endif
>  
> +#ifdef CONFIG_PPC_MM_SLICES
> +struct mm_struct;
> +
> +unsigned long slice_get_unmapped_area(unsigned long addr, unsigned long len,
> +   unsigned long flags, unsigned int psize,
> +   int topdown);
> +
> +unsigned int get_slice_psize(struct mm_struct *mm, unsigned long addr);
> +
> +void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
> +void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
> +unsigned long len, unsigned int psize);
> +#endif
> +

Should we do a slice.h ? the way we have other files? and then do

arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so that we
can do type checking.

also related definitions for
#define SLICE_LOW_SHIFT 28
#define SLICE_HIGH_SHIFT0

#define SLICE_LOW_TOP   (0xul)
#define SLICE_NUM_LOW   ((SLICE_LOW_TOP >> SLICE_LOW_SHIFT) + 1)
+#define SLICE_NUM_HIGH 0ul

Common stuff between 64 and 32 can got to
arch/powerpc/include/asm/slice.h ?

It also gives an indication of which 32 bit version we are looking at
here. IIUC 8xx will got to arch/powerpc/include/asm/nohash/32/slice.h?

>  #include 
>  #endif /* __ASSEMBLY__ */
>  
> diff --git a/arch/powerpc/include/asm/page_32.h 
> b/arch/powerpc/include/asm/page_32.h
> index 5c378e9b78c8..f7d1bd1183c8 100644
> --- a/arch/powerpc/include/asm/page_32.h
> +++ b/arch/powerpc/include/asm/page_32.h
> @@ -60,4 +60,23 @@ extern void copy_page(void *to, void *from);
>  
>  #endif /* __ASSEMBLY__ */
>  
> +#ifdef CONFIG_PPC_MM_SLICES
> +
> +#define SLICE_LOW_SHIFT  28
> +#define SLICE_HIGH_SHIFT 0
> +
> +#define SLICE_LOW_TOP(0xul)
> +#define SLICE_NUM_LOW((SLICE_LOW_TOP >> SLICE_LOW_SHIFT) + 1)
> +#define SLICE_NUM_HIGH   0ul
> +
> +#define GET_LOW_SLICE_INDEX(addr)((addr) >> SLICE_LOW_SHIFT)
> +#define GET_HIGH_SLICE_INDEX(addr)   (addr & 0)
> +
> +#ifdef CONFIG_HUGETLB_PAGE
> +#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> +#endif
> +#define HAVE_ARCH_UNMAPPED_AREA
> +#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
> +
> +#endif
> 

Re: [RFC] Per file OOM badness

[Michal Hocko]

[removed the broken quoting - please try to use an email client which
doesn't mess up the qouted text]

On Fri 19-01-18 06:01:26, He, Roger wrote:
[...]
> I think you are misunderstanding here.
> Actually for now, the memory in TTM Pools already has mm_shrink which is 
> implemented in ttm_pool_mm_shrink_init.
> And here the memory we want to make it contribute to OOM badness is not in 
> TTM Pools.
> Because when TTM buffer allocation success, the memory already is removed 
> from TTM Pools.  

I have no idea what TTM buffers are. But this smells like something
rather specific to the particular subsytem. And my main objection here
is that struct file is not a proper vehicle to carry such an
information. So whatever the TTM subsystem does it should contribute to
generic counters rather than abuse fd because it happens to use it to
communicate with userspace.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 00/31] Replacing net_mutex with rw_semaphore

[Kirill Tkhai]

On 18.01.2018 20:43, Andrei Vagin wrote:
> On Mon, Nov 20, 2017 at 09:32:08PM +0300, Kirill Tkhai wrote:
>> Hi,
>>
>> there is the second version of patchset introducing net_sem
>> instead of net_mutex. The patchset adds net_sem in addition
>> to net_mutex and allows pernet_operations to be async. This
>> flag means, the pernet_operations methods are safe to be
>> executed with any othor pernet_operations (un)initializing
>> another net.
>>
>> If there are only async pernet_operations in the system,
>> net_mutex is not used either for setup_net() or for cleanup_net().
>>
>> The flag is little easier, then (un)register_pernet_sys(),
>> as it changes one line only. Also, it requires less changes
>> in code. In future, when all pernet_operations are async,
>> we'll just remove this struct field.
>>
>> The pernet_operations converted in this patchset allow
>> to create minimal .config to have network working, and
>> the changes improve the performance like you may see
>> below:
>>
>> %for i in {1..1}; do unshare -n bash -c exit; done
>> 
>> *before*
>> real 1m40,377s
>> user 0m9,672s
>> sys 0m19,928s
>> 
>> *after*
>> real 0m17,007s
>> user 0m5,311s
>> sys 0m11,779
>> 
>> (5.8 times faster)
> 
> Good job!
> 
> Acked-by: Andrei Vagin 

Thanks, Andrei!

>> ---
>>
>> Kirill Tkhai (31):
>>   net: Assign net to net_namespace_list in setup_net()
>>   net: Cleanup copy_net_ns()
>>   net: Introduce net_sem for protection of pernet_list
>>   net: Move mutex_unlock() in cleanup_net() up
>>   net: Allow pernet_operations to be executed in parallel
>>   net: Convert proc_net_ns_ops
>>   net: Convert net_ns_ops methods
>>   net: Convert sysctl_pernet_ops
>>   net: Convert netfilter_net_ops
>>   net: Convert nf_log_net_ops
>>   net: Convert net_inuse_ops
>>   net: Convert net_defaults_ops
>>   net: Convert netlink_net_ops
>>   net: Convert rtnetlink_net_ops
>>   net: Convert audit_net_ops
>>   net: Convert uevent_net_ops
>>   net: Convert proto_net_ops
>>   net: Convert pernet_subsys ops, registered via net_dev_init()
>>   net: Convert fib_* pernet_operations, registered via subsys_initcall
>>   net: Convert subsys_initcall() registered pernet_operations from 
>> net/sched
>>   net: Convert genl_pernet_ops
>>   net: Convert wext_pernet_ops
>>   net: Convert sysctl_core_ops
>>   net: Convert pernet_subsys, registered from inet_init()
>>   net: Convert unix_net_ops
>>   net: Convert packet_net_ops
>>   net: Convert ipv4_sysctl_ops
>>   net: Convert addrconf_ops
>>   net: Convert loopback_net_ops
>>   net: Convert default_device_ops
>>   net: Convert diag_net_ops
>>
>>
>>  drivers/net/loopback.c  |1 
>>  fs/proc/proc_net.c  |1 
>>  include/linux/rtnetlink.h   |1 
>>  include/net/net_namespace.h |6 +++
>>  kernel/audit.c  |1 
>>  lib/kobject_uevent.c|1 
>>  net/core/dev.c  |2 +
>>  net/core/fib_notifier.c |1 
>>  net/core/fib_rules.c|1 
>>  net/core/net-procfs.c   |2 +
>>  net/core/net_namespace.c|   94 
>> +--
>>  net/core/rtnetlink.c|5 +-
>>  net/core/sock.c |2 +
>>  net/core/sock_diag.c|1 
>>  net/core/sysctl_net_core.c  |1 
>>  net/ipv4/af_inet.c  |2 +
>>  net/ipv4/arp.c  |1 
>>  net/ipv4/devinet.c  |1 
>>  net/ipv4/fib_frontend.c |1 
>>  net/ipv4/icmp.c |1 
>>  net/ipv4/igmp.c |1 
>>  net/ipv4/ip_fragment.c  |1 
>>  net/ipv4/ipmr.c |1 
>>  net/ipv4/ping.c |1 
>>  net/ipv4/proc.c |1 
>>  net/ipv4/raw.c  |1 
>>  net/ipv4/route.c|4 ++
>>  net/ipv4/sysctl_net_ipv4.c  |1 
>>  net/ipv4/tcp_ipv4.c |2 +
>>  net/ipv4/tcp_metrics.c  |1 
>>  net/ipv4/udp.c  |1 
>>  net/ipv4/udplite.c  |1 
>>  net/ipv4/xfrm4_policy.c |1 
>>  net/ipv6/addrconf.c |1 
>>  net/netfilter/core.c|1 
>>  net/netfilter/nf_log.c  |1 
>>  net/netlink/af_netlink.c|1 
>>  net/netlink/genetlink.c |1 
>>  net/packet/af_packet.c  |1 
>>  net/sched/act_api.c |1 
>>  net/sched/sch_api.c |1 
>>  net/sysctl_net.c|1 
>>  net/unix/af_unix.c  |1 
>>  net/wireless/wext-core.c|1 
>>  net/xfrm/xfrm_policy.c  |1 
>>  45 files changed, 114 insertions(+), 41 deletions(-)
>>
>> --
>> Signed-off-by: Kirill Tkhai 

Re: [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> On the 8xx, the page size is set in the PMD entry and applies to
> all pages of the page table pointed by the said PMD entry.
>
> When an app has some regular pages allocated (e.g. see below) and tries
> to mmap() a huge page at a hint address covered by the same PMD entry,
> the kernel accepts the hint allthough the 8xx cannot handle different
> page sizes in the same PMD entry.
>
> 1000-10001000 r-xp  00:0f 2597 /root/malloc
> 1001-10011000 rwxp  00:0f 2597 /root/malloc
>
> mmap(0x1008, 524288, PROT_READ|PROT_WRITE,
>  MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x1008
>
> This results the app remaining forever in do_page_fault()/hugetlb_fault()
> and when interrupting that app, we get the following warning:
>
> [162980.035629] WARNING: CPU: 0 PID: 2777 at 
> arch/powerpc/mm/hugetlbpage.c:354 hugetlb_free_pgd_range+0xc8/0x1e4
> [162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W   4.14.6 #85
> [162980.035744] task: c67e2c00 task.stack: c668e000
> [162980.035783] NIP:  c000fe18 LR: c00e1eec CTR: c00f90c0
> [162980.035830] REGS: c668fc20 TRAP: 0700   Tainted: G W(4.14.6)
> [162980.035854] MSR:  00029032   CR: 24044224 XER: 2000
> [162980.036003]
> [162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 0010 c6869410 1008 
>  77fb4000
> [162980.036003] GPR08: 0001 0683c001  ff80 44028228 10018a34 
> 4008 418004fc
> [162980.036003] GPR16: c668e000 00040100 c668e000 c06c c668fe78 c668e000 
> c6835ba0 c668fd48
> [162980.036003] GPR24:  73ff 7400 0001 77fb4000 100f 
> 1010 1010
> [162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
> [162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
> [162980.036861] Call Trace:
> [162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 
> (unreliable)
> [162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
> [162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
> [162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
> [162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
> [162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
> [162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
> [162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
> [162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
> [162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
> [162980.037781] Instruction dump:
> [162980.037821] 7fdff378 8137 54a3463a 80890020 7d24182e 7c841a14 
> 712a0004 4082ff94
> [162980.038014] 2f89 419e0010 712a0ff0 408200e0 <0fe0> 54a9000a 
> 7f984840 419d0094
> [162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
> [162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
> [162985.363322] BUG: non-zero nr_ptes on freeing mm: -1
>
> In order to fix this, this patch uses the address space "slices"
> implemented for BOOK3S/64 and enhanced to support PPC32 by the
> preceding patch.
>
> This patch modifies the context.id on the 8xx to be in the range
> [1:16] instead of [0:15] in order to identify context.id == 0 as
> not initialised contexts as done on BOOK3S
>
> This patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is
> selected for the 8xx
>
> Alltough we could in theory have as many slices as PMD entries, the
> current slices implementation limits the number of low slices to 16.
> This limitation is not preventing us to fix the initial issue allthough
> it is suboptimal. It will be cured in a subsequent patch.
>
> Fixes: 4b91428699477 ("powerpc/8xx: Implement support of hugepages")
> Signed-off-by: Christophe Leroy 
> ---
>  v2: First patch of v1 serie split in two parts
>
>  arch/powerpc/include/asm/mmu-8xx.h | 6 ++
>  arch/powerpc/kernel/setup-common.c | 2 ++
>  arch/powerpc/mm/8xx_mmu.c  | 2 +-
>  arch/powerpc/mm/hugetlbpage.c  | 2 ++
>  arch/powerpc/mm/mmu_context_nohash.c   | 4 ++--
>  arch/powerpc/mm/slice.c| 2 ++
>  arch/powerpc/platforms/Kconfig.cputype | 1 +
>  7 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-8xx.h 
> b/arch/powerpc/include/asm/mmu-8xx.h
> index 5bb3dbede41a..5f89b6010453 100644
> --- a/arch/powerpc/include/asm/mmu-8xx.h
> +++ b/arch/powerpc/include/asm/mmu-8xx.h
> @@ -169,6 +169,12 @@ typedef struct {
>   unsigned int id;
>   unsigned int active;
>   unsigned long vdso_base;
> +#ifdef CONFIG_PPC_MM_SLICES
> + u16 user_psize; /* page size index */
> + u64 low_slices_psize;   /* page size encodings */
> + unsigned char high_slices_psize[0];
> + unsigned long slb_addr_limit;
> +#endif
>  } mm_context_t;
>  
>  #define PHYS_IMMR_BASE (mfspr(SPRN_IMMR) & 0xfff8)
> diff --git a/arch/powerpc/kernel/setup-common.c 
> b/arch/powerpc/kernel/setup-common.c
> index 9d213542a48b..67075a1cff36 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/se

Re: [PATCH 6/6] s390: scrub registers on kernel entry and KVM exit

[QingFeng Hao]

在 2018/1/19 15:57, Christian Borntraeger 写道:


On 01/19/2018 07:29 AM, QingFeng Hao wrote:


在 2018/1/17 17:48, Martin Schwidefsky 写道:

Clear all user space registers on entry to the kernel and all KVM guest
registers on KVM guest exit if the register does not contain either a
parameter or a result value.

I am not sure if I understand this but it will be safer?

It ist similar to commit 0cb5b30698fd ("kvm: vmx: Scrub hardware GPRs at 
VM-exit").
The idea is to minimize potential payload channels.

Got it! thanks for your explanation!



And can we abstract the operations to be a macro like CLEAR_REG_7?

No, please.
xgr %r7,%r7
is absolutely clear what it does, a MACRO often is not.

nod, this makes sense!

--
Regards
QingFeng Hao

Re: [PATCH] print kdump kernel loaded status in stack dump

[Sergey Senozhatsky]

On (01/19/18 16:16), Dave Young wrote:
> On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> > On (01/18/18 10:02), Andi Kleen wrote:
> > > Dave Young  writes:
> > > > printk("%sHardware name: %s\n",
> > > >log_lvl, dump_stack_arch_desc_str);
> > > > +   if (kexec_crash_loaded())
> > > > +   printk("%skdump kernel loaded\n", log_lvl);
> > > 
> > > Oops/warnings are getting longer and longer, often scrolling away
> > > from the screen, and if the kernel crashes backscroll does not work
> > > anymore, so precious information is lost.
> > 
> > true. I even ended up having a console_reflush_on_panic() function. it
> > simply re-prints with a delay [so I can at least read the oops] logbuf
> > entries every once in a while, staring with the first oops_in_progress
> > record.
> > 
> 
> If too many messages printed on screen, then the next flush will 
> still scroll up. 

right. but it re-prints Oops with a new console_unlock_delay() delay
which gives me enough time to either read it as many times as I want,
or take a picture, etc. it's not as fast as the normal oops print out.

[I'm not entirely sure I see why do we have printk_delay() in
   vprintk_emit()... I mean I probably can see some reasoning behind
   it, but at the same it makes sense to slow down console_unlock()
   as well]

-ss

Re: [PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> While the implementation of the "slices" address space allows
> a significant amount of high slices, it limits the number of
> low slices to 16 due to the use of a single u64 low_slices_psize
> element in struct mm_context_t
>
> On the 8xx, the minimum slice size is the size of the area
> covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
> 16K pages mode. This means we could have resp. up to 1024 and 64
> slices.
>
> In order to override this limitation, this patch switches the
> handling of low_slices to BITMAPs as done already for high_slices.

Does it have a performance impact. When we switched high_slices
that was one of the question asked. Now with a topdown search we should
mostly be using the high_slices. But it will good to get numbers for
ppc64 for this change.


>
> Signed-off-by: Christophe Leroy 
> ---
>  v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.
>
>  arch/powerpc/include/asm/book3s/64/mmu.h |   2 +-
>  arch/powerpc/include/asm/mmu-8xx.h   |   2 +-
>  arch/powerpc/include/asm/paca.h  |   2 +-
>  arch/powerpc/kernel/paca.c   |   3 +-
>  arch/powerpc/mm/hash_utils_64.c  |  13 ++--
>  arch/powerpc/mm/slb_low.S|   8 ++-
>  arch/powerpc/mm/slice.c  | 104 
> +--
>  7 files changed, 74 insertions(+), 60 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index c9448e19847a..27e7e9732ea1 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -91,7 +91,7 @@ typedef struct {
>   struct npu_context *npu_context;
>  
>  #ifdef CONFIG_PPC_MM_SLICES
> - u64 low_slices_psize;   /* SLB page size encodings */
> + unsigned char low_slices_psize[8]; /* SLB page size encodings */

Can that 8 be a #define?


>   unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned long slb_addr_limit;
>  #else

-aneesh

[tip:x86/platform] x86/platform/intel-mid: Move PCI initialization to arch_init()

[tip-bot for Andy Shevchenko]

Commit-ID:  a912a7584ec39647fb032c1001eb69746f27b1d3
Gitweb: https://git.kernel.org/tip/a912a7584ec39647fb032c1001eb69746f27b1d3
Author: Andy Shevchenko 
AuthorDate: Wed, 17 Jan 2018 19:34:08 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 19 Jan 2018 09:15:42 +0100

x86/platform/intel-mid: Move PCI initialization to arch_init()

ACPI redefines x86_init.pci.init when enabled. Though we still need special
treatment for MID platforms.

Move our specific callback to x86_init.pci.arch_init() and, by calling
acpi_noirq_set(), take back a control over IRQ assignment.

Signed-off-by: Andy Shevchenko 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20180117173409.88136-2-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/pci/intel_mid_pci.c| 1 +
 arch/x86/platform/intel-mid/intel-mid.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 5119210..43867bc 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -300,6 +300,7 @@ int __init intel_mid_pci_init(void)
pci_root_ops = intel_mid_pci_ops;
pci_soc_mode = 1;
/* Continue with standard init */
+   acpi_noirq_set();
return 1;
 }
 
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 86676ce..2c67bae 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -194,7 +194,7 @@ void __init x86_intel_mid_early_setup(void)
x86_platform.calibrate_tsc = intel_mid_calibrate_tsc;
x86_platform.get_nmi_reason = intel_mid_get_nmi_reason;
 
-   x86_init.pci.init = intel_mid_pci_init;
+   x86_init.pci.arch_init = intel_mid_pci_init;
x86_init.pci.fixup_irqs = x86_init_noop;
 
legacy_pic = &null_legacy_pic;

Re: [PATCH] print kdump kernel loaded status in stack dump

[Sergey Senozhatsky]

On (01/19/18 16:16), Dave Young wrote:
> I thought about adding an option to improve printk_delay so it can
> delay every n lines, eg. 25 rows. Maybe that idea works for this
> issue?

/* sent the message too soon */

printk_delay() has no effect there. it limits only printk()->vprintk_emit()
and we don't have any new printk()-s once the system has panic-ed. it's
console_unlock() that prints out the oops.

-ss

Re: [RFC] Per file OOM badness

[Christian König]

Am 18.01.2018 um 21:01 schrieb Eric Anholt:

Michal Hocko  writes:


[SNIP]
But files are not killable, they can be shared... In other words this
doesn't help the oom killer to make an educated guess at all.

Maybe some more context would help the discussion?


Thanks for doing this. Wanted to reply yesterday with that information 
as well, but was unfortunately on sick leave.




The struct file in patch 3 is the DRM fd.  That's effectively "my
process's interface to talking to the GPU" not "a single GPU resource".
Once that file is closed, all of the process's private, idle GPU buffers
will be immediately freed (this will be most of their allocations), and
some will be freed once the GPU completes some work (this will be most
of the rest of their allocations).

Some GEM BOs won't be freed just by closing the fd, if they've been
shared between processes.  Those are usually about 8-24MB total in a
process, rather than the GBs that modern apps use (or that our testcases
like to allocate and thus trigger oomkilling of the test harness instead
of the offending testcase...)

Even if we just had the private+idle buffers being accounted in OOM
badness, that would be a huge step forward in system reliability.


Yes, and that's exactly the intention here because currently the OOM 
killer usually kills X when a graphics related application allocates to 
much memory and that is highly undesirable.



: So question at every one: What do you think about this approach?

I thing is just just wrong semantically. Non-reclaimable memory is a
pain, especially when there is way too much of it. If you can free that
memory somehow then you can hook into slab shrinker API and react on the
memory pressure. If you can account such a memory to a particular
process and make sure that the consumption is bound by the process life
time then we can think of an accounting that oom_badness can consider
when selecting a victim.

For graphics, we can't free most of our memory without also effectively
killing the process.  i915 and vc4 have "purgeable" interfaces for
userspace (on i915 this is exposed all the way to GL applications and is
hooked into shrinker, and on vc4 this is so far just used for
userspace-internal buffer caches to be purged when a CMA allocation
fails).  However, those purgeable pools are expected to be a tiny
fraction of the GPU allocations by the process.


Same thing with TTM and amdgpu/radeon. We already have a shrinker hock 
as well and make room as much as we can when needed.


But I think Michal's concerns are valid as well and I thought about them 
when I created the initial patch.


One possible solution which came to my mind is that (IIRC) we not only 
store the usual reference count per GEM object, but also how many 
handles where created for it.


So what we could do is to iterate over all GEM handles of a client and 
account only size/num_handles as badness for the client.


The end result would be that X and the client application would both get 
1/2 of the GEM objects size accounted for.


Regards,
Christian.

Re: [PATCH] smc: return boolean instead of integer in using_ipsec

[Ursula Braun]

On 01/19/2018 12:33 AM, Gustavo A. R. Silva wrote:
> Return statements in functions returning bool should use
> true/false instead of 1/0.
> 
> This issue was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  net/smc/smc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/smc/smc.h b/net/smc/smc.h
> index 0bee9d1..ef13af4 100644
> --- a/net/smc/smc.h
> +++ b/net/smc/smc.h
> @@ -258,7 +258,7 @@ static inline bool using_ipsec(struct smc_sock *smc)
>  #else
>  static inline bool using_ipsec(struct smc_sock *smc)
>  {
> - return 0;
> + return false;
>  }
>  #endif
> 

Gustavo,
thanks for reporting, but your improvement seems to be incomplete. Besides 
changing
line 260 of net/smc/smc.h, line 255 should be adapted the same way. Will you
come up with a second patch version here?

Kind regards, Ursula Braun

Re: [PATCH V5 0/2] nvme-pci: fix the timeout case when reset is ongoing

[Keith Busch]

On Fri, Jan 19, 2018 at 04:14:02PM +0800, jianchao.wang wrote:
> On 01/19/2018 04:01 PM, Keith Busch wrote:
> > The nvme_dev_disable routine makes forward progress without depending on
> > timeout handling to complete expired commands. Once controller disabling
> > completes, there can't possibly be any started requests that can expire.
> > So we don't need nvme_timeout to do anything for requests above the
> > boundary.
> > 
> Yes, once controller disabling completes, any started requests will be 
> handled and cannot expire.
> But before the _boundary_, there could be a nvme_timeout context runs with 
> nvme_dev_disable in parallel.
> If a timeout path grabs a request, then nvme_dev_disable cannot get and 
> cancel it.
> So even though the nvme_dev_disable completes, there still could be a request 
> in nvme_timeout context.
> 
> The worst case is :
> nvme_timeout  nvme_reset_work
> if (ctrl->state == RESETTING )  nvme_dev_disable
> nvme_dev_disableinitializing procedure
> 
> the nvme_dev_disable run with reinit procedure in nvme_reset_work in parallel.

Okay, I see what you're saying. That's a pretty obscure case, as normally
we enter nvme_reset_work with the queues already disabled, but there
are a few cases where we need nvme_reset_work to handle that.

But if we are in that case, I think we really just want to sync the
queues. What do you think of this?

---
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index fde6fd2e7eef..516383193416 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3520,6 +3520,17 @@ void nvme_stop_queues(struct nvme_ctrl *ctrl)
 }
 EXPORT_SYMBOL_GPL(nvme_stop_queues);
 
+void nvme_sync_queues(struct nvme_ctrl *ctrl)
+{
+   struct nvme_ns *ns;
+
+   mutex_lock(&ctrl->namespaces_mutex);
+   list_for_each_entry(ns, &ctrl->namespaces, list)
+   blk_sync_queue(ns->queue);
+   mutex_unlock(&ctrl->namespaces_mutex);
+}
+EXPORT_SYMBOL_GPL(nvme_sync_queues);
+
 void nvme_start_queues(struct nvme_ctrl *ctrl)
 {
struct nvme_ns *ns;
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 8e7fc1b041b7..45b1b8ceddb6 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -374,6 +374,7 @@ void nvme_complete_async_event(struct nvme_ctrl *ctrl, 
__le16 status,
 
 void nvme_stop_queues(struct nvme_ctrl *ctrl);
 void nvme_start_queues(struct nvme_ctrl *ctrl);
+void nvme_sync_queues(struct nvme_ctrl *ctrl)
 void nvme_kill_queues(struct nvme_ctrl *ctrl);
 void nvme_unfreeze(struct nvme_ctrl *ctrl);
 void nvme_wait_freeze(struct nvme_ctrl *ctrl);
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index a2ffb557b616..1fe00be22ad1 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2289,8 +2289,10 @@ static void nvme_reset_work(struct work_struct *work)
 * If we're called to reset a live controller first shut it down before
 * moving on.
 */
-   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
+   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE) {
nvme_dev_disable(dev, false);
+   nvme_sync_queues(&dev->ctrl);
+   }
 
result = nvme_pci_enable(dev);
if (result)
--

Re: [RFC] Per file OOM badness

[Christian König]

Am 19.01.2018 um 09:20 schrieb Michal Hocko:

On Thu 18-01-18 12:01:32, Eric Anholt wrote:

Michal Hocko  writes:


On Thu 18-01-18 18:00:06, Michal Hocko wrote:

On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:

Hi, this series is a revised version of an RFC sent by Christian König
a few years ago. The original RFC can be found at
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html

This is the same idea and I've just adressed his concern from the original RFC
and switched to a callback into file_ops instead of a new member in struct file.

Please add the full description to the cover letter and do not make
people hunt links.

Here is the origin cover letter text
: I'm currently working on the issue that when device drivers allocate memory on
: behalf of an application the OOM killer usually doesn't knew about that unless
: the application also get this memory mapped into their address space.
:
: This is especially annoying for graphics drivers where a lot of the VRAM
: usually isn't CPU accessible and so doesn't make sense to map into the
: address space of the process using it.
:
: The problem now is that when an application starts to use a lot of VRAM those
: buffers objects sooner or later get swapped out to system memory, but when we
: now run into an out of memory situation the OOM killer obviously doesn't knew
: anything about that memory and so usually kills the wrong process.

OK, but how do you attribute that memory to a particular OOM killable
entity? And how do you actually enforce that those resources get freed
on the oom killer action?


: The following set of patches tries to address this problem by introducing a 
per
: file OOM badness score, which device drivers can use to give the OOM killer a
: hint how many resources are bound to a file descriptor so that it can make
: better decisions which process to kill.

But files are not killable, they can be shared... In other words this
doesn't help the oom killer to make an educated guess at all.

Maybe some more context would help the discussion?

The struct file in patch 3 is the DRM fd.  That's effectively "my
process's interface to talking to the GPU" not "a single GPU resource".
Once that file is closed, all of the process's private, idle GPU buffers
will be immediately freed (this will be most of their allocations), and
some will be freed once the GPU completes some work (this will be most
of the rest of their allocations).

Some GEM BOs won't be freed just by closing the fd, if they've been
shared between processes.  Those are usually about 8-24MB total in a
process, rather than the GBs that modern apps use (or that our testcases
like to allocate and thus trigger oomkilling of the test harness instead
of the offending testcase...)

Even if we just had the private+idle buffers being accounted in OOM
badness, that would be a huge step forward in system reliability.

OK, in that case I would propose a different approach. We already
have rss_stat. So why do not we simply add a new counter there
MM_KERNELPAGES and consider those in oom_badness? The rule would be
that such a memory is bound to the process life time. I guess we will
find more users for this later.


I already tried that and the problem with that approach is that some 
buffers are not created by the application which actually uses them.


For example X/Wayland is creating and handing out render buffers to 
application which want to use OpenGL.


So the result is when you always account the application who created the 
buffer the OOM killer will certainly reap X/Wayland first. And that is 
exactly what we want to avoid here.


Regards,
Christian.

Re: [PATCH] print kdump kernel loaded status in stack dump

[Dave Young]

On 01/19/18 at 05:28pm, Sergey Senozhatsky wrote:
> On (01/19/18 16:16), Dave Young wrote:
> > On 01/19/18 at 02:45pm, Sergey Senozhatsky wrote:
> > > On (01/18/18 10:02), Andi Kleen wrote:
> > > > Dave Young  writes:
> > > > >   printk("%sHardware name: %s\n",
> > > > >  log_lvl, dump_stack_arch_desc_str);
> > > > > + if (kexec_crash_loaded())
> > > > > + printk("%skdump kernel loaded\n", log_lvl);
> > > > 
> > > > Oops/warnings are getting longer and longer, often scrolling away
> > > > from the screen, and if the kernel crashes backscroll does not work
> > > > anymore, so precious information is lost.
> > > 
> > > true. I even ended up having a console_reflush_on_panic() function. it
> > > simply re-prints with a delay [so I can at least read the oops] logbuf
> > > entries every once in a while, staring with the first oops_in_progress
> > > record.
> > > 
> > 
> > If too many messages printed on screen, then the next flush will 
> > still scroll up. 
> 
> right. but it re-prints Oops with a new console_unlock_delay() delay
> which gives me enough time to either read it as many times as I want,
> or take a picture, etc. it's not as fast as the normal oops print out.
> 
> [I'm not entirely sure I see why do we have printk_delay() in
>vprintk_emit()... I mean I probably can see some reasoning behind
>it, but at the same it makes sense to slow down console_unlock()
>as well]

Looks like I am the guy who added the code :)  Actually no special
reason, just did not thinking about the performance issue at all at that
time..

> 
>   -ss

Re: [PATCH v4 09/10] kvm, x86: fix spectre-v1 mitigation

[Paolo Bonzini]

On 19/01/2018 01:02, Dan Williams wrote:
> Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup"
> added a raw 'asm("lfence");' to prevent a bounds check bypass of
> 'vmcs_field_to_offset_table'. This does not work for some AMD cpus, see
> the 'ifence' helper,

The code never runs on AMD cpus (it's for Intel virtualization
extensions), so it'd be nice if you could fix up the commit message.

Apart from this, obviously

Acked-by: Paolo Bonzini 

Thanks!

Paolo

> and it otherwise does not use the common
> 'array_ptr' helper designed for these types of fixes. Convert this to
> use 'array_ptr'.
> 
> Cc: Andrew Honig 
> Cc: Jim Mattson 
> Cc: Paolo Bonzini 
> Cc: 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/kvm/vmx.c |   19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index c829d89e2e63..20b9b0b5e336 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "kvm_cache_regs.h"
>  #include "x86.h"
>  
> @@ -898,21 +899,15 @@ static const unsigned short 
> vmcs_field_to_offset_table[] = {
>  
>  static inline short vmcs_field_to_offset(unsigned long field)
>  {
> - BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX);
> -
> - if (field >= ARRAY_SIZE(vmcs_field_to_offset_table))
> - return -ENOENT;
> + const unsigned short *offset;
>  
> - /*
> -  * FIXME: Mitigation for CVE-2017-5753.  To be replaced with a
> -  * generic mechanism.
> -  */
> - asm("lfence");
> + BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX);
>  
> - if (vmcs_field_to_offset_table[field] == 0)
> + offset = array_ptr(vmcs_field_to_offset_table, field,
> + ARRAY_SIZE(vmcs_field_to_offset_table));
> + if (!offset || *offset == 0)
>   return -ENOENT;
> -
> - return vmcs_field_to_offset_table[field];
> + return *offset;
>  }
>  
>  static inline struct vmcs12 *get_vmcs12(struct kvm_vcpu *vcpu)
> 

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Christophe LEROY]

Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.

On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.

This patch moves "slices" functions prototypes from page64.h to page.h

The high slices use bitmaps. As bitmap functions are not prepared to
handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
slice_bitmap_xxx() macros which will take care of the 0 nbits case.

Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts ; added slice_bitmap_xxx() 
macros.

  arch/powerpc/include/asm/page.h  | 14 +
  arch/powerpc/include/asm/page_32.h   | 19 
  arch/powerpc/include/asm/page_64.h   | 21 ++---
  arch/powerpc/mm/hash_utils_64.c  |  2 +-
  arch/powerpc/mm/mmu_context_nohash.c |  7 +
  arch/powerpc/mm/slice.c  | 60 
  6 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 8da5d4c1cab2..d0384f9db9eb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
  #endif
  #endif
  
+#ifdef CONFIG_PPC_MM_SLICES

+struct mm_struct;
+
+unsigned long slice_get_unmapped_area(unsigned long addr, unsigned long len,
+ unsigned long flags, unsigned int psize,
+ int topdown);
+
+unsigned int get_slice_psize(struct mm_struct *mm, unsigned long addr);
+
+void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
+void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
+  unsigned long len, unsigned int psize);
+#endif
+


Should we do a slice.h ? the way we have other files? and then do


Yes we could add a slice.h instead of using page.h for that, good idea.



arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so that we
can do type checking.


Is it really worth duplicating that just for eliminating the 'if 
(nbits)' in one case ?


Only in book3s/64 we will be able to eliminate that, for nohash/32 we 
need to keep the test due to the difference between low and high slices.


In any case, as the nbits we use in slice.c is a constant, the test is 
eliminated at compilation, so I can't see the benefit of making 
different slice_bitmap_() based on platform.


Christophe



also related definitions for
#define SLICE_LOW_SHIFT 28
#define SLICE_HIGH_SHIFT0

#define SLICE_LOW_TOP   (0xul)
#define SLICE_NUM_LOW   ((SLICE_LOW_TOP >> SLICE_LOW_SHIFT) + 1)
+#define SLICE_NUM_HIGH 0ul

Common stuff between 64 and 32 can got to
arch/powerpc/include/asm/slice.h ?

It also gives an indication of which 32 bit version we are looking at
here. IIUC 8xx will got to arch/powerpc/include/asm/nohash/32/slice.h?


  #include 
  #endif /* __ASSEMBLY__ */
  
diff --git a/arch/powerpc/include/asm/page_32.h b/arch/powerpc/include/asm/page_32.h

index 5c378e9b78c8..f7d1bd1183c8 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -60,4 +60,23 @@ extern void copy_page(void *to, void *from);
  
  #endif /* __ASSEMBLY__ */
  
+#ifdef CONFIG_PPC_MM_SLICES

+
+#define SLICE_LOW_SHIFT28
+#define SLICE_HIGH_SHIFT   0
+
+#define SLICE_LOW_TOP   

Re: [PATCH] x86/mce: Make machine check speculation protected

[Woodhouse, David]

On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote:
> The machine check idtentry uses an indirect branch directly from the low
> level code. This evades the speculation protection.
> 
> Replace it by a direct call into C code and issue the indirect call there
> so the compiler can apply the proper speculation protection.
> 
> Signed-off-by: Thomas Gleixner 

Cc: stable for at least 4.9.

> ---
>  arch/x86/entry/entry_64.S|2 +-
>  arch/x86/include/asm/traps.h |1 +
>  arch/x86/kernel/cpu/mcheck/mce.c |5 +
>  3 files changed, 7 insertions(+), 1 deletion(-)
> 
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1264,7 +1264,7 @@ idtentry async_page_fault   do_async_page_
>  #endif
>  
>  #ifdef CONFIG_X86_MCE
> -idtentry machine_check   
> has_error_code=0paranoid=1 do_sym=*machine_check_vector(%rip)
> +idtentry machine_check   do_mce  
> has_error_code=0paranoid=1
>  #endif
>  
>  /*
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -88,6 +88,7 @@ dotraplinkage void do_simd_coprocessor_e
>  #ifdef CONFIG_X86_32
>  dotraplinkage void do_iret_error(struct pt_regs *, long);
>  #endif
> +dotraplinkage void do_mce(struct pt_regs *, long);
>  
>  static inline int get_si_code(unsigned long condition)
>  {
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1785,6 +1785,11 @@ static void unexpected_machine_check(str
>  void (*machine_check_vector)(struct pt_regs *, long error_code) =
>   unexpected_machine_check;
>  
> +dotraplinkage void do_mce(struct pt_regs *regs, long error_code)
> +{
> + machine_check_vector(regs, error_code);
> +}
> +
>  /*
>   * Called for each booted CPU to set up machine checks.
>   * Must be called with preempt off:
> 

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

[Christophe LEROY]

Le 19/01/2018 à 09:26, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


On the 8xx, the page size is set in the PMD entry and applies to
all pages of the page table pointed by the said PMD entry.

When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint allthough the 8xx cannot handle different
page sizes in the same PMD entry.

1000-10001000 r-xp  00:0f 2597 /root/malloc
1001-10011000 rwxp  00:0f 2597 /root/malloc

mmap(0x1008, 524288, PROT_READ|PROT_WRITE,
  MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x1008

This results the app remaining forever in do_page_fault()/hugetlb_fault()
and when interrupting that app, we get the following warning:

[162980.035629] WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354 
hugetlb_free_pgd_range+0xc8/0x1e4
[162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W   4.14.6 #85
[162980.035744] task: c67e2c00 task.stack: c668e000
[162980.035783] NIP:  c000fe18 LR: c00e1eec CTR: c00f90c0
[162980.035830] REGS: c668fc20 TRAP: 0700   Tainted: G W(4.14.6)
[162980.035854] MSR:  00029032   CR: 24044224 XER: 2000
[162980.036003]
[162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 0010 c6869410 1008 
 77fb4000
[162980.036003] GPR08: 0001 0683c001  ff80 44028228 10018a34 
4008 418004fc
[162980.036003] GPR16: c668e000 00040100 c668e000 c06c c668fe78 c668e000 
c6835ba0 c668fd48
[162980.036003] GPR24:  73ff 7400 0001 77fb4000 100f 
1010 1010
[162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
[162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
[162980.036861] Call Trace:
[162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214 (unreliable)
[162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
[162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
[162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
[162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
[162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
[162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
[162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
[162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
[162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
[162980.037781] Instruction dump:
[162980.037821] 7fdff378 8137 54a3463a 80890020 7d24182e 7c841a14 712a0004 
4082ff94
[162980.038014] 2f89 419e0010 712a0ff0 408200e0 <0fe0> 54a9000a 
7f984840 419d0094
[162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
[162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
[162985.363322] BUG: non-zero nr_ptes on freeing mm: -1

In order to fix this, this patch uses the address space "slices"
implemented for BOOK3S/64 and enhanced to support PPC32 by the
preceding patch.

This patch modifies the context.id on the 8xx to be in the range
[1:16] instead of [0:15] in order to identify context.id == 0 as
not initialised contexts as done on BOOK3S

This patch activates CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE is
selected for the 8xx

Alltough we could in theory have as many slices as PMD entries, the
current slices implementation limits the number of low slices to 16.
This limitation is not preventing us to fix the initial issue allthough
it is suboptimal. It will be cured in a subsequent patch.

Fixes: 4b91428699477 ("powerpc/8xx: Implement support of hugepages")
Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts

  arch/powerpc/include/asm/mmu-8xx.h | 6 ++
  arch/powerpc/kernel/setup-common.c | 2 ++
  arch/powerpc/mm/8xx_mmu.c  | 2 +-
  arch/powerpc/mm/hugetlbpage.c  | 2 ++
  arch/powerpc/mm/mmu_context_nohash.c   | 4 ++--
  arch/powerpc/mm/slice.c| 2 ++
  arch/powerpc/platforms/Kconfig.cputype | 1 +
  7 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-8xx.h 
b/arch/powerpc/include/asm/mmu-8xx.h
index 5bb3dbede41a..5f89b6010453 100644
--- a/arch/powerpc/include/asm/mmu-8xx.h
+++ b/arch/powerpc/include/asm/mmu-8xx.h
@@ -169,6 +169,12 @@ typedef struct {
unsigned int id;
unsigned int active;
unsigned long vdso_base;
+#ifdef CONFIG_PPC_MM_SLICES
+   u16 user_psize; /* page size index */
+   u64 low_slices_psize;   /* page size encodings */
+   unsigned char high_slices_psize[0];
+   unsigned long slb_addr_limit;
+#endif
  } mm_context_t;
  
  #define PHYS_IMMR_BASE (mfspr(SPRN_IMMR) & 0xfff8)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 9d213542a48b..67075a1cff36 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -927,6 +927,8 @@ void __init setup_arch(char **cmdline_p)
  #ifdef CONFIG_PPC64
if (!radix_enabled()

Re: [PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices

[Christophe LEROY]

Le 19/01/2018 à 09:30, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_t

On the 8xx, the minimum slice size is the size of the area
covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
16K pages mode. This means we could have resp. up to 1024 and 64
slices.

In order to override this limitation, this patch switches the
handling of low_slices to BITMAPs as done already for high_slices.


Does it have a performance impact. When we switched high_slices
that was one of the question asked. Now with a topdown search we should
mostly be using the high_slices. But it will good to get numbers for
ppc64 for this change.


It should have almost no performance impact at all, because all bitmap 
functions used a simplified way when the number of bits is small and 
constant:


-   ret->low_slices = 0;
+   slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);


static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
{
if (small_const_nbits(nbits))
*dst = 0UL;
else {
unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
memset(dst, 0, len);
}
}



-   dst->low_slices |= src->low_slices;
+   slice_bitmap_or(dst->low_slices, dst->low_slices, src->low_slices,
+   SLICE_NUM_LOW);


static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
const unsigned long *src2, unsigned int nbits)
{
if (small_const_nbits(nbits))
*dst = *src1 | *src2;
else
__bitmap_or(dst, src1, src2, nbits);
}







Signed-off-by: Christophe Leroy 
---
  v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.

  arch/powerpc/include/asm/book3s/64/mmu.h |   2 +-
  arch/powerpc/include/asm/mmu-8xx.h   |   2 +-
  arch/powerpc/include/asm/paca.h  |   2 +-
  arch/powerpc/kernel/paca.c   |   3 +-
  arch/powerpc/mm/hash_utils_64.c  |  13 ++--
  arch/powerpc/mm/slb_low.S|   8 ++-
  arch/powerpc/mm/slice.c  | 104 +--
  7 files changed, 74 insertions(+), 60 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
b/arch/powerpc/include/asm/book3s/64/mmu.h
index c9448e19847a..27e7e9732ea1 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -91,7 +91,7 @@ typedef struct {
struct npu_context *npu_context;
  
  #ifdef CONFIG_PPC_MM_SLICES

-   u64 low_slices_psize;   /* SLB page size encodings */
+   unsigned char low_slices_psize[8]; /* SLB page size encodings */


Can that 8 be a #define?


Sure





unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
unsigned long slb_addr_limit;
  #else


-aneesh



Christophe

Re: [PATCH] rtc: remove rtc-at32ap700x

[Alexandre Belloni]

On 19/01/2018 at 08:27:33 +0100, Hans-Christian Noren Egtvedt wrote:
> Around Thu 18 Jan 2018 21:08:46 +0100 or thereabout, Corentin Labbe wrote:
> > Since PLATFORM_AT32AP is an AVR32 platform which was removed, the
> > rtc driver rtc-at32ap700x is useless.
> > This patch remove it.
> > 
> > Signed-off-by: Corentin Labbe 
> 
> Acked-by: Hans-Christian Noren Egtvedt 
> 

Well, my plan was to keep it for a little while, but whatever :)

> > ---
> >  drivers/rtc/Kconfig  |   7 --
> >  drivers/rtc/Makefile |   1 -
> >  drivers/rtc/rtc-at32ap700x.c | 287 
> > ---
> >  3 files changed, 295 deletions(-)
> >  delete mode 100644 drivers/rtc/rtc-at32ap700x.c
> > 
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index b71cc7b5fbc9..8ab5f0a5d323 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -1402,13 +1402,6 @@ config RTC_DRV_PL031
> >   To compile this driver as a module, choose M here: the
> >   module will be called rtc-pl031.
> >  
> > -config RTC_DRV_AT32AP700X
> > -   tristate "AT32AP700X series RTC"
> > -   depends on PLATFORM_AT32AP || COMPILE_TEST
> > -   help
> > - Driver for the internal RTC (Realtime Clock) on Atmel AVR32
> > - AT32AP700x family processors.
> > -
> >  config RTC_DRV_AT91RM9200
> > tristate "AT91RM9200 or some AT91SAM9 RTC"
> > depends on ARCH_AT91 || COMPILE_TEST
> > diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> > index 6dfbbe9cd8a2..4fbf87e45a7c 100644
> > --- a/drivers/rtc/Makefile
> > +++ b/drivers/rtc/Makefile
> > @@ -33,7 +33,6 @@ obj-$(CONFIG_RTC_DRV_AC100)   += rtc-ac100.o
> >  obj-$(CONFIG_RTC_DRV_ARMADA38X)+= rtc-armada38x.o
> >  obj-$(CONFIG_RTC_DRV_AS3722)   += rtc-as3722.o
> >  obj-$(CONFIG_RTC_DRV_ASM9260)  += rtc-asm9260.o
> > -obj-$(CONFIG_RTC_DRV_AT32AP700X)+= rtc-at32ap700x.o
> >  obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
> >  obj-$(CONFIG_RTC_DRV_AT91SAM9) += rtc-at91sam9.o
> >  obj-$(CONFIG_RTC_DRV_AU1XXX)   += rtc-au1xxx.o
> 
> 
> 
> -- 
> Best regards,
> Hans-Christian Noren Egtvedt

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

pull-request: wireless-drivers-next 2018-01-19

[Kalle Valo]

Hi Dave,

a pull request to net-next tree for 4.16. This should be the last pull
request in this cycle, unless Linus releases -rc9 of course. Only few
patches so should be an easy one. Please let me know if there are any
problems.

Kalle

The following changes since commit 79d891c1bbb6573cef31dbc2030fba61cfa1df6d:

  Merge tag 'linux-can-next-for-4.16-20180105' of 
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next 
(2018-01-15 16:13:34 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2018-01-19

for you to fetch changes up to 5f9066930b5da506b38be895b956ac5f854c374b:

  rtlwifi: Support A-MSDU in A-MPDU capability (2018-01-18 15:27:11 +0200)


wireless-drivers-next patches for 4.16

Final few patches before the merge window, nothing really special.

ath9k

* add MSI support (not enabled by default yet)

rtlwifi

* support A-MSDU in A-MPDU aggregation


AceLan Kao (1):
  ath9k: add a quirk to set use_msi automatically

Brian Norris (2):
  Revert "mwifiex: cancel pcie/sdio work in remove/shutdown handler"
  mwifiex: resolve reset vs. remove()/shutdown() deadlocks

Colin Ian King (3):
  ath10k: fix spelling mistake: "addrress" -> "address"
  ath10k: remove redundant -ve check against u32 integer size
  rtlwifi: btcoexist: remove redundant variable fw_ps_state

Kalle Valo (2):
  ath10k: fix recently introduced checkpatch warnings
  Merge ath-next from git://git.kernel.org/.../kvalo/ath.git

Larry Finger (1):
  rtlwifi: btcoex: Remove typedef statements

Lorenzo Bianconi (2):
  mt76: fix possible NULL pointer dereferencing in mt76x2_ampdu_action()
  mt76: fix possible NULL pointer dereferencing in mt76x2_mac_write_txwi()

Maya Erez (1):
  MAINTAINERS: wireless: update wil6210 maintainer entry

Ping-Ke Shih (7):
  rtlwifi: Use mutex to replace spin_lock to protect IPS and LPS
  rtlwifi: fix scan channel 1 fail after IPS
  rtlwifi: btcoex: Add power_on_setting routine
  rtlwifi: btcoex: Remove global variables from btcoex
  rtlwifi: btcoex: Add common function for qeurying BT information
  rtlwifi: btcoex: add rfe_type parameter to btcoex
  rtlwifi: Support A-MSDU in A-MPDU capability

Russell Hu (1):
  ath9k: add MSI support

Ryan Hsu (1):
  ath10k: add sanity check to ie_len before parsing fw/board ie

Tsang-Shian Lin (1):
  rtlwifi: unlink bss when un-association

 MAINTAINERS|   4 +-
 drivers/net/wireless/ath/ath10k/ce.h   |   1 +
 drivers/net/wireless/ath/ath10k/core.c |  14 +-
 drivers/net/wireless/ath/ath10k/htt.h  |   1 +
 drivers/net/wireless/ath/ath10k/pci.c  |   5 +-
 drivers/net/wireless/ath/ath9k/hw.c|  33 +-
 drivers/net/wireless/ath/ath9k/hw.h|   3 +
 drivers/net/wireless/ath/ath9k/init.c  |  57 +++
 drivers/net/wireless/ath/ath9k/mac.c   |  47 +++
 drivers/net/wireless/ath/ath9k/pci.c   |  21 +-
 drivers/net/wireless/ath/ath9k/reg.h   |  15 +
 drivers/net/wireless/marvell/mwifiex/pcie.c|   7 +-
 drivers/net/wireless/marvell/mwifiex/sdio.c|   2 -
 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c|   2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_main.c   |   4 +-
 drivers/net/wireless/realtek/rtlwifi/base.c|   7 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 401 +
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   | 178 +
 .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.c   | 234 ++--
 .../wireless/realtek/rtlwifi/btcoexist/rtl_btc.h   |   4 +-
 drivers/net/wireless/realtek/rtlwifi/core.c|  18 +
 drivers/net/wireless/realtek/rtlwifi/pci.c |   5 +-
 drivers/net/wireless/realtek/rtlwifi/ps.c  |  29 +-
 drivers/net/wireless/realtek/rtlwifi/usb.c |   1 -
 drivers/net/wireless/realtek/rtlwifi/wifi.h|  16 +-
 25 files changed, 875 insertions(+), 234 deletions(-)

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

On 2018/01/18 07:51, Alexander Duyck wrote:
> On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier  wrote:
> > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
> > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
> > icr=0x8004 (_INT_ASSERTED | _OTHER) in the same situation.
> 
> Isn't 0x8004 (_INT_ASSERTED | _LSC)? The assumption I based my

Yes. The numeric value is correct. I made a mistake when writing down
the flag names.

> patch on was that the VMware code was sending _OTHER instead of _LSC
> to trigger LSC events. As such in my version of the workaround I just

It's not so deterministic, sadly. In my tests, upon entry into
e1000_msix_other() after e1000e_trigger_lsc(), with no workaround patch
I've seen:
icr=0x0
icr=0x3d
Reserved RXDMT0 Reserved LSC TXDW
icr=0x46
RXO LSC TXQE
and someone else reported:
icr=0x3c
Reserved RXDMT0 Reserved LSC

> went through and did the testing if the _RXO bit was set, otherwise I
> assumed that whatever event was received must have been meant to
> trigger an _LSC type event since that worked in the past.
> 
> > Some experimentation showed that this flaw in vmware e1000e emulation can
> > be worked around by not setting Other in EIAC. This is how it was before
> > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).
> 
> Did this actually set the _LSC bit or was it just giving you the
> _OTHER bit? The ICR for that combination would come out 0x8100.

With my patch, after e1000e_trigger_lsc(), it results in icr=0x8104
on real and emulated hardware.

IMO, the resulting icr read is cleaner than with your patch but it
depends on an undocumented quirk of the emulated vmware e1000e, so I
don't know which of the two workarounds is more desirable.

If you'd like to stick with your patch though, I think that you should
definitely rewrite it as:

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9f18d39bdc8f..68c0bcb8287f 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1928,7 +1928,12 @@ static irqreturn_t e1000_msix_other(int __always_unused 
irq, void *data)
__napi_schedule(&adapter->napi);
}
}
-   if (icr & E1000_ICR_LSC) {
+   if (icr & E1000_ICR_LSC || !(icr & E1000_ICR_RXO)) {
+   /* We assume if the RXO bit is not set that this is a
+* link status change event. This is needed due to emulated
+* versions of the device that may not correctly populate
+* the LSC bit.
+*/
ew32(ICR, E1000_ICR_LSC);
hw->mac.get_link_status = true;
/* guard against interrupt when we're going down */

> 
> > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > Signed-off-by: Benjamin Poirier 
> > ---
> >
> > Jeff, I'm sending as RFC since it looks like a problem that should be fixed
> > in vmware. If you'd like to have the workaround in e1000e, I'll submit.
> 
> I would appreciate it if you could review/test the patch I submitted
> for the same issue. Specifically I would want to make certain that it
> still addresses the original RXO interrupt burst issue your reported.

I've tested both my patch and yours; they both allow link up on vmware;
link up on real 82574 and rxo mitigation on real 82574. I couldn't
conveniently test rxo on vmware.

> 
> Thanks.
> 
> - Alex
> 

Re: [PATCH] KVM: prevent overlap between user and private memslots

[Wanpeng Li]

2018-01-19 16:18 GMT+08:00 Eric Biggers :
> From: Eric Biggers 
>
> Memslots must not overlap in guest physical memory, since otherwise some
> guest physical addresses will not uniquely map to a memslot.  Yet, the
> overlap check in __kvm_set_memory_region() allows a memslot that
> overlaps one of the "private" memslots, e.g. the memslot reserved for
> the TSS on x86.
>
> This seems to be a very old bug that was introduced years ago when
> private memory slots were first added.  It seems that later refactoring
> incorrectly assumed this bug was intentional and preserved it.
>
> Fix it by removing the loophole for private memslots, so we just check
> for overlap against all memslots.
>
> This bug was found by syzkaller, which used a memslot overlap to make
> pte_list_remove() be called for the wrong memslot, hitting a BUG():
>
> pte_list_remove: 7185ed42 0->BUG
> kernel BUG at arch/x86/kvm/mmu.c:1209!
> [...]
> RIP: 0010:pte_list_remove+0x107/0x110 arch/x86/kvm/mmu.c:1208
> [...]
> Call Trace:
>  mmu_page_zap_pte+0x7e/0xd0 arch/x86/kvm/mmu.c:2499
>  kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2521 [inline]
>  kvm_mmu_prepare_zap_page+0x4f/0x340 arch/x86/kvm/mmu.c:2565
>  kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5348 [inline]
>  kvm_mmu_invalidate_zap_all_pages+0xa6/0x100 arch/x86/kvm/mmu.c:5389
>  kvm_mmu_notifier_release+0x4f/0x80 
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:468
>  __mmu_notifier_release+0x63/0x100 mm/mmu_notifier.c:75
>  mmu_notifier_release include/linux/mmu_notifier.h:244 [inline]
>  exit_mmap+0x160/0x170 mm/mmap.c:3009
>  __mmput kernel/fork.c:966 [inline]
>  mmput+0x44/0xd0 kernel/fork.c:987
>  exit_mm kernel/exit.c:544 [inline]
>  do_exit+0x24a/0xb50 kernel/exit.c:856
>  do_group_exit+0x34/0xb0 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0xb/0x10 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1e/0x8b
>
> Reproducer:
>
> #include 
> #include 
> #include 
>
> int main()
> {
> static char buf[4096*3] __attribute__((aligned(4096)));
> int kvm, vm, cpu;
> struct kvm_mp_state mp_state = { KVM_MP_STATE_SIPI_RECEIVED };
> struct kvm_userspace_memory_region memreg = {
> .memory_size = sizeof(buf),
> .userspace_addr = (__u64)buf,
> };
>
> kvm = open("/dev/kvm", O_RDWR);
> vm = ioctl(kvm, KVM_CREATE_VM, 0);
> ioctl(vm, KVM_CREATE_IRQCHIP);
> cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
> ioctl(cpu, KVM_SET_MP_STATE, &mp_state);
> ioctl(vm, KVM_SET_TSS_ADDR, 0);
> ioctl(cpu, KVM_RUN, 0);
> ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
> }
>
> Reported-by: syzbot 
> Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
> Cc:  # v2.6.25+
> Signed-off-by: Eric Biggers 

Please refer to this one. https://patchwork.kernel.org/patch/9645377/

Regards,
Wanpeng Li

> ---
>  virt/kvm/kvm_main.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 210bf820385a..e536977e7b6d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
> /* Check for overlaps */
> r = -EEXIST;
> kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
> -   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
> -   (slot->id == id))
> +   if (slot->id == id)
> continue;
> if (!((base_gfn + npages <= slot->base_gfn) ||
>   (base_gfn >= slot->base_gfn + slot->npages)))
> --
> 2.16.0
>

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[李書帆]

Hi Heikki,

  For example, the flow of tcpci_init is a little bit different.
  In tcpci_init, there are more parameters need to be set for RT1711H.

Best Regards,
*
Shu-Fan Lee
Richtek Technology Corporation
TEL: +886-3-5526789 #2359
FAX: +886-3-5526612
*

-Original Message-
From: Heikki Krogerus [mailto:heikki.kroge...@linux.intel.com]
Sent: Friday, January 19, 2018 4:22 PM
To: shufan_lee(李書帆)
Cc: 'Jun Li'; ShuFanLee; cy_huang(黃啟原); linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org; Guenter Roeck
Subject: Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

Hi Shu-Fan,

On Fri, Jan 19, 2018 at 05:48:02AM +, shufan_lee(?) wrote:
> Hi Jun,
>
>   For now, RT1711H is not fully compatible with TCPCI. So the existing tcpci.c
>   may not work for it.

The datasheet for RT1711H does talk about TCPCi and TCPM+TCPC [1].
What are the differences that justify a separate driver?

[1] http://www.richtek.com/assets/product_file/RT1711H/DS1711H-02.pdf


Br,

--
heikki
* Email Confidentiality Notice 

The information contained in this e-mail message (including any attachments) 
may be confidential, proprietary, privileged, or otherwise exempt from 
disclosure under applicable laws. It is intended to be conveyed only to the 
designated recipient(s). Any use, dissemination, distribution, printing, 
retaining or copying of this e-mail (including its attachments) by unintended 
recipient(s) is strictly prohibited and may be unlawful. If you are not an 
intended recipient of this e-mail, or believe that you have received this 
e-mail in error, please notify the sender immediately (by replying to this 
e-mail), delete any and all copies of this e-mail (including any attachments) 
from your system, and do not disclose the content of this e-mail to any other 
person. Thank you!

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Aneesh Kumar K.V]

On 01/19/2018 02:14 PM, Christophe LEROY wrote:



Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.

On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.

This patch moves "slices" functions prototypes from page64.h to page.h

The high slices use bitmaps. As bitmap functions are not prepared to
handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
slice_bitmap_xxx() macros which will take care of the 0 nbits case.

Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts ; added 
slice_bitmap_xxx() macros.


  arch/powerpc/include/asm/page.h  | 14 +
  arch/powerpc/include/asm/page_32.h   | 19 
  arch/powerpc/include/asm/page_64.h   | 21 ++---
  arch/powerpc/mm/hash_utils_64.c  |  2 +-
  arch/powerpc/mm/mmu_context_nohash.c |  7 +
  arch/powerpc/mm/slice.c  | 60 


  6 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h 
b/arch/powerpc/include/asm/page.h

index 8da5d4c1cab2..d0384f9db9eb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
  #endif
  #endif
+#ifdef CONFIG_PPC_MM_SLICES
+struct mm_struct;
+
+unsigned long slice_get_unmapped_area(unsigned long addr, unsigned 
long len,

+  unsigned long flags, unsigned int psize,
+  int topdown);
+
+unsigned int get_slice_psize(struct mm_struct *mm, unsigned long addr);
+
+void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
+void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
+   unsigned long len, unsigned int psize);
+#endif
+


Should we do a slice.h ? the way we have other files? and then do


Yes we could add a slice.h instead of using page.h for that, good idea.



arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so that we
can do type checking.


Is it really worth duplicating that just for eliminating the 'if 
(nbits)' in one case ?


Only in book3s/64 we will be able to eliminate that, for nohash/32 we 
need to keep the test due to the difference between low and high slices.


the other advantage is we move the SLICE_LOW_SHIFT to the right 
location. IMHO mm subystem is really complex with these really 
overloaded headers. If we can keep it  seperate we should with minimal 
code duplication?


In any case, as the nbits we use in slice.c is a constant, the test is 
eliminated at compilation, so I can't see the benefit of making 


-aneesh

Re: [PATCH V5 0/2] nvme-pci: fix the timeout case when reset is ongoing

[jianchao.wang]

Hi Keith

Thanks for your kindly and detailed response and patch.

On 01/19/2018 04:42 PM, Keith Busch wrote:
> On Fri, Jan 19, 2018 at 04:14:02PM +0800, jianchao.wang wrote:
>> On 01/19/2018 04:01 PM, Keith Busch wrote:
>>> The nvme_dev_disable routine makes forward progress without depending on
>>> timeout handling to complete expired commands. Once controller disabling
>>> completes, there can't possibly be any started requests that can expire.
>>> So we don't need nvme_timeout to do anything for requests above the
>>> boundary.
>>>
>> Yes, once controller disabling completes, any started requests will be 
>> handled and cannot expire.
>> But before the _boundary_, there could be a nvme_timeout context runs with 
>> nvme_dev_disable in parallel.
>> If a timeout path grabs a request, then nvme_dev_disable cannot get and 
>> cancel it.
>> So even though the nvme_dev_disable completes, there still could be a 
>> request in nvme_timeout context.
>>
>> The worst case is :
>> nvme_timeout  nvme_reset_work
>> if (ctrl->state == RESETTING )  nvme_dev_disable
>> nvme_dev_disableinitializing procedure
>>
>> the nvme_dev_disable run with reinit procedure in nvme_reset_work in 
>> parallel.
> 
> Okay, I see what you're saying. That's a pretty obscure case, as normally
> we enter nvme_reset_work with the queues already disabled, but there
> are a few cases where we need nvme_reset_work to handle that.
> 
> But if we are in that case, I think we really just want to sync the
> queues. What do you think of this?
> 
> ---
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index fde6fd2e7eef..516383193416 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -3520,6 +3520,17 @@ void nvme_stop_queues(struct nvme_ctrl *ctrl)
>  }
>  EXPORT_SYMBOL_GPL(nvme_stop_queues);
>  
> +void nvme_sync_queues(struct nvme_ctrl *ctrl)
> +{
> + struct nvme_ns *ns;
> +
> + mutex_lock(&ctrl->namespaces_mutex);
> + list_for_each_entry(ns, &ctrl->namespaces, list)
> + blk_sync_queue(ns->queue);
> + mutex_unlock(&ctrl->namespaces_mutex);
> +}
> +EXPORT_SYMBOL_GPL(nvme_sync_queues);
> +
>  void nvme_start_queues(struct nvme_ctrl *ctrl)
>  {
>   struct nvme_ns *ns;
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 8e7fc1b041b7..45b1b8ceddb6 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -374,6 +374,7 @@ void nvme_complete_async_event(struct nvme_ctrl *ctrl, 
> __le16 status,
>  
>  void nvme_stop_queues(struct nvme_ctrl *ctrl);
>  void nvme_start_queues(struct nvme_ctrl *ctrl);
> +void nvme_sync_queues(struct nvme_ctrl *ctrl)
>  void nvme_kill_queues(struct nvme_ctrl *ctrl);
>  void nvme_unfreeze(struct nvme_ctrl *ctrl);
>  void nvme_wait_freeze(struct nvme_ctrl *ctrl);
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index a2ffb557b616..1fe00be22ad1 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -2289,8 +2289,10 @@ static void nvme_reset_work(struct work_struct *work)
>* If we're called to reset a live controller first shut it down before
>* moving on.
>*/
> - if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
> + if (dev->ctrl.ctrl_config & NVME_CC_ENABLE) {
>   nvme_dev_disable(dev, false);
> + nvme_sync_queues(&dev->ctrl);
> + }
>  
>   result = nvme_pci_enable(dev);
>   if (result)
> --
> 

We should not use blk_sync_queue here, the requeue_work and run_work will be 
canceled.
Just flush_work(&q->timeout_work) should be ok.

In addition, we could check NVME_CC_ENABLE in nvme_dev_disable to avoid 
redundant invoking.
:)

Thanks
Jianchao

ITS ALL ABOUT FACEBOOK

[Facebook Int'l]

Hello ,

It’s hard to believe it right??? Facebook celebrates its 14th year anniversary. 
That means 14-years ago, I, Mark Zuckerberg and my pals were in our Harvard 
dorm rooms making history, 
launching what would become the largest social network of all time, now rolling 
in billions of dollars via 
commercials, with company worth of over a hundred billion dollars
To help commemorate this occasion, we are giving back to 14,000 users 
$14,000.00USD (Fourteen Thousand Dollars) 
and a grand prize of 14,000,000.USD (Fourteen Million Dollars) to 14 lucky 
users and has launched a new feature called 
‘Look Back’, where each user's "Look Back" compilation contains 15 or so of 
your most-liked photos, statuses, and 
life events set to a catchy tune. Find yours at https://facebook.com/lookback/ 
. It's all about 14.
Please, get back for the verification of your details for prompt payment by 
sending Your Unique Code (FB/BF14-13M5250UD) 
using your registration email, to the Verification Department at; 
dustinmoskovitz.faceb...@gmail.com

Dustin Moskovitz
Facebook Team
Copyright © 2018 Facebook Int'l

Facebook Celebrates its 14th Year Anniversary

Re: [PATCH net-next v3] xfrm: Add ESN support for IPSec HW offload

[Steffen Klassert]

On Mon, Jan 15, 2018 at 10:06:06AM -0800, Shannon Nelson wrote:
> On 1/14/2018 1:39 AM, yoss...@mellanox.com wrote:
> > From: Yossef Efraim 
> > 
> > This patch adds ESN support to IPsec device offload.
> > Adding new xfrm device operation to synchronize device ESN.
> > 
> > Signed-off-by: Yossef Efraim 
> > ---
> > Changes from v1:
> >   - Added documentation
> > 
> > Changes from v2:
> >   - Due to Shannon Nelson's request, xfrm_dev_state_add() fails if ESN is
> > requested and xdo_dev_state_advance_esn() is not implemented
> 
> This works for me - thanks!
> Signed-off-by: Shannon Nelson 

Applied to ipsec-next, thanks everyone!

[Patch v1 3/8] ACPI / LPIT: Export lpit_read_residency_count_address()

[Rajneesh Bhardwaj]

From: Srinivas Pandruvada 

Export lpit_read_residency_count_address(), so that it can be used from
drivers built as module. With the recent changes, the builtin_pci
functionality of the intel_pmc_core driver is removed and now it can be
built as a module to read this exported interface to calculate the PMC base
address.

Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org

Tested-by: Rajneesh Bhardwaj 
Signed-off-by: Srinivas Pandruvada 
---

 drivers/acpi/acpi_lpit.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
index e94e478dd18b..cf4fc0161164 100644
--- a/drivers/acpi/acpi_lpit.c
+++ b/drivers/acpi/acpi_lpit.c
@@ -100,6 +100,7 @@ int lpit_read_residency_count_address(u64 *address)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(lpit_read_residency_count_address);
 
 static void lpit_update_residency(struct lpit_residency_info *info,
 struct acpi_lpit_native *lpit_native)
-- 
2.7.4

Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC

[poza]

On 2018-01-19 10:14, Sinan Kaya wrote:

On 1/18/2018 11:23 PM, p...@codeaurora.org wrote:

On 2018-01-18 23:33, Sinan Kaya wrote:

On 1/18/2018 1:00 PM, p...@codeaurora.org wrote:
I think you would put into include/linux/pci.h only if there is an 
external
use of constant outside of drivers/pci directory. Otherwise, you 
should keep
the setting inside one of the header files in drivers/pci 
directory.


I don't see any other subsystem caring about DPC_FATAL definition.


ok so you are suggesting to move only DPC_FATAL ? so then AER can 
stay where it is.


Now that both AER and DPC handling is getting unified, I think it 
makes sense to
keep all error codes (AER+DPC) together in drivers/pci/pci.h rather 
than having

them split in aer.h and dpc.h.

Otherwise, how would we avoid having a new error type defined with 
the

existing values.


I agree, its is just that drivers/acpi/apet/ghes.c has to do
#include ../../pci/pci.h


That's bad. I was just thinking about the DPC error code only. I didn't 
realize

AER error codes are being referenced from ghes.c.



but thats okay I think.  let me move error codes to drivers/pci/pci.h.


It is better if error codes move to include/linux/pci.h and keep them 
together.




The problem with moving them to include/linux/pci.h, it falls into 
global scope, besides

they have to be renamed to/prefixed with PCI_ERR_xxx

the use of AER_FATAL, DPC_FATAL etc.. is very limited in entire linux. 
and likely to be so.

I think moving them to drivers/pci/pci.h would be more restricted/local

let me make patch-set based on that, and see how it looks like. we can 
arrive at some consensus then.




Regards,
Oza.

[Patch v1 4/8] platform/x86: intel_pmc_core: Read base address from LPIT

[Rajneesh Bhardwaj]

From: Srinivas Pandruvada 

Read SLP_S0 address from ACPI LPIT table when present and use PMC
specific SLP_S0 offset to get the base address of PMC MMIO.

Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Srinivas Pandruvada 
---
 drivers/platform/x86/intel_pmc_core.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index f7616600e8ab..549ee5852d4f 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -20,6 +20,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
 #include 
 #include 
 #include 
@@ -455,6 +456,7 @@ static int __init pmc_core_probe(void)
 {
const struct x86_cpu_id *cpu_id;
struct pmc_dev *pmcdev = &pmc;
+   u64 slp_s0_addr;
int err;
 
cpu_id = x86_match_cpu(intel_pmc_core_ids);
@@ -462,7 +464,12 @@ static int __init pmc_core_probe(void)
return -ENODEV;
 
pmcdev->map = (struct pmc_reg_map *)cpu_id->driver_data;
-   pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT;
+
+   if (lpit_read_residency_count_address(&slp_s0_addr))
+   pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT;
+   else
+   pmcdev->base_addr = slp_s0_addr - pmcdev->map->slp_s0_offset;
+
pmcdev->regbase = ioremap(pmcdev->base_addr,
  pmcdev->map->regmap_length);
if (!pmcdev->regbase)
-- 
2.7.4

[Patch v1 2/8] platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration

[Rajneesh Bhardwaj]

From: Srinivas Pandruvada 

The Only use of PCI device enumeration here is to get the PMC base address
which is a fixed value i.e. 0xFE00. On some platforms this can be read
through a non standard PCI BAR. But after Kabylake, PMC is not exposed as a
PCI device anymore. There are other non standard methods like ACPI LPIT
which can also be used for obtaining this value.

For simplicity, this value can be hardcoded as it won't change.

Since we don't have a PMC PCI device on any platform after Kabylake, this
creates a foundation for future SoC support.

Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Srinivas Pandruvada 
---
 drivers/platform/x86/intel_pmc_core.c | 91 ---
 drivers/platform/x86/intel_pmc_core.h |  3 +-
 2 files changed, 33 insertions(+), 61 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index 43cee8877ee3..f7616600e8ab 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -18,12 +18,12 @@
  *
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -119,13 +119,6 @@ static const struct pmc_reg_map spt_reg_map = {
.pm_read_disable_bit = SPT_PMC_READ_DISABLE_BIT,
 };
 
-static const struct pci_device_id pmc_pci_ids[] = {
-   { PCI_VDEVICE(INTEL, SPT_PMC_PCI_DEVICE_ID),
-   (kernel_ulong_t)&spt_reg_map },
-   { 0, },
-};
-MODULE_DEVICE_TABLE(pci, pmc_pci_ids);
-
 static inline u8 pmc_core_reg_read_byte(struct pmc_dev *pmcdev, int offset)
 {
return readb(pmcdev->regbase + offset);
@@ -446,79 +439,59 @@ static inline void pmc_core_dbgfs_unregister(struct 
pmc_dev *pmcdev)
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_MOBILE, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)NULL},
+   (kernel_ulong_t)&spt_reg_map},
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_DESKTOP, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)NULL},
+   (kernel_ulong_t)&spt_reg_map},
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_MOBILE, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)NULL},
+   (kernel_ulong_t)&spt_reg_map},
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_DESKTOP, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)NULL},
+   (kernel_ulong_t)&spt_reg_map},
{}
 };
 
-static int pmc_core_probe(struct pci_dev *dev, const struct pci_device_id *id)
+MODULE_DEVICE_TABLE(x86cpu, intel_pmc_core_ids);
+
+static int __init pmc_core_probe(void)
 {
-   struct device *ptr_dev = &dev->dev;
-   struct pmc_dev *pmcdev = &pmc;
const struct x86_cpu_id *cpu_id;
-   const struct pmc_reg_map *map = (struct pmc_reg_map *)id->driver_data;
+   struct pmc_dev *pmcdev = &pmc;
int err;
 
cpu_id = x86_match_cpu(intel_pmc_core_ids);
-   if (!cpu_id) {
-   dev_dbg(&dev->dev, "PMC Core: cpuid mismatch.\n");
-   return -EINVAL;
-   }
-
-   err = pcim_enable_device(dev);
-   if (err < 0) {
-   dev_dbg(&dev->dev, "PMC Core: failed to enable Power Management 
Controller.\n");
-   return err;
-   }
-
-   err = pci_read_config_dword(dev,
-   SPT_PMC_BASE_ADDR_OFFSET,
-   &pmcdev->base_addr);
-   if (err < 0) {
-   dev_dbg(&dev->dev, "PMC Core: failed to read PCI config 
space.\n");
-   return err;
-   }
-   pmcdev->base_addr &= PMC_BASE_ADDR_MASK;
-   dev_dbg(&dev->dev, "PMC Core: PWRMBASE is %#x\n", pmcdev->base_addr);
-
-   pmcdev->regbase = devm_ioremap_nocache(ptr_dev,
- pmcdev->base_addr,
- SPT_PMC_MMIO_REG_LEN);
-   if (!pmcdev->regbase) {
-   dev_dbg(&dev->dev, "PMC Core: ioremap failed.\n");
+   if (!cpu_id)
+   return -ENODEV;
+
+   pmcdev->map = (struct pmc_reg_map *)cpu_id->driver_data;
+   pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT;
+   pmcdev->regbase = ioremap(pmcdev->base_addr,
+ pmcdev->map->regmap_length);
+   if (!pmcdev->regbase)
return -ENOMEM;
-   }
 
mutex_init(&pmcdev->lock);
-   pmcdev->map = map;
pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit();
 
err = pmc_core_dbgfs_register(pmcdev);
-   if (err < 0)
-   dev_warn(&dev->dev, "PMC Core: debugfs register failed.\n");
+   if (err < 0) {
+   pr_warn(" debugfs register failed.\n");
+   iounmap(pmcdev->regbase);
+   return err;
+   }
 
+   pr_info(" initialized\n");
return 0;
 }
+module_init(pmc_core_probe)
 
-static void pmc_core_remove(struct pci_

[Patch v1 1/8] platform/x86: intel_pmc_core: Refactor debugfs entries

[Rajneesh Bhardwaj]

When on a platform if we can't show MPHY and PLL status, don't even bother
to create a debugfs entry as it will fail anyway. In fact unless OEM builds
a special BIOS for test, it will fail on every production system.

This will help to add future platform support where we can't support these
entries.

Suggested-by: Andriy Shevchenko 
Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 44 +--
 1 file changed, 16 insertions(+), 28 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index cf8b3b34a979..43cee8877ee3 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -407,43 +407,31 @@ static void pmc_core_dbgfs_unregister(struct pmc_dev 
*pmcdev)
 
 static int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
 {
-   struct dentry *dir, *file;
 
-   dir = debugfs_create_dir("pmc_core", NULL);
-   if (!dir)
-   return -ENOMEM;
+   pmcdev->dbgfs_dir = debugfs_create_dir("pmc_core", NULL);
 
-   pmcdev->dbgfs_dir = dir;
-   file = debugfs_create_file("slp_s0_residency_usec", 0444,
-  dir, pmcdev, &pmc_core_dev_state);
-   if (!file)
-   goto err;
+   if (!pmcdev->dbgfs_dir)
+   return -ENOMEM;
 
-   file = debugfs_create_file("pch_ip_power_gating_status", 0444,
-  dir, pmcdev, &pmc_core_ppfear_ops);
-   if (!file)
-   goto err;
+   debugfs_create_file("slp_s0_residency_usec", 0444, pmcdev->dbgfs_dir,
+   pmcdev, &pmc_core_dev_state);
 
-   file = debugfs_create_file("mphy_core_lanes_power_gating_status", 0444,
-  dir, pmcdev, &pmc_core_mphy_pg_ops);
-   if (!file)
-   goto err;
+   debugfs_create_file("pch_ip_power_gating_status", 0444,
+   pmcdev->dbgfs_dir, pmcdev, &pmc_core_ppfear_ops);
 
-   file = debugfs_create_file("pll_status", 0444, dir, pmcdev,
-  &pmc_core_pll_ops);
-   if (!file)
-   goto err;
+   debugfs_create_file("ltr_ignore", 0644, pmcdev->dbgfs_dir, pmcdev,
+   &pmc_core_ltr_ignore_ops);
 
-   file = debugfs_create_file("ltr_ignore", 0644, dir, pmcdev,
-  &pmc_core_ltr_ignore_ops);
+   if (pmcdev->map->pll_sts)
+   debugfs_create_file("pll_status", 0444, pmcdev->dbgfs_dir,
+   pmcdev, &pmc_core_pll_ops);
 
-   if (!file)
-   goto err;
+   if (pmcdev->map->mphy_sts)
+   debugfs_create_file("mphy_core_lanes_power_gating_status",
+   0444, pmcdev->dbgfs_dir, pmcdev,
+   &pmc_core_mphy_pg_ops);
 
return 0;
-err:
-   pmc_core_dbgfs_unregister(pmcdev);
-   return -ENODEV;
 }
 #else
 static inline int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
-- 
2.7.4

[Patch v1 0/8] platform/x86: intel_pmc_core: Add CFL/CNL Support

[Rajneesh Bhardwaj]

This series is the successor to
https://www.spinics.net/lists/platform-driver-x86/msg14524.html and adds
support for Intel Coffeelake and Cannonlake SoCs.

This also presents an alternative to https://lkml.org/lkml/2017/11/17/876
and introduces Cannonlake SoC to intel-family.h

The following patches,

 '0003-ACPI-LPIT-Export-lpit_read_residency_count_address.patch' and
 '0006-x86-cpu-Add-Cannonlake-to-Intel-family.patch' 

do not belong to platform-drivers-x86 subsystem but the other patches in the
series depend on them so, requesting the respective MAINTAINERS for their
review and ACK so that these two patches can also go through the
platform-drivers-x86 subsystem.


Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: linux-a...@vger.kernel.org

Cc: Dave Hansen 
Cc: Thomas Gleixner 
cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org

Tested on Coffeelake, Cannonlake and Kabylake with 4.15-rc8 kernel.

Rajneesh Bhardwaj (5):
  platform/x86: intel_pmc_core: Refactor debugfs entries
  platform/x86: intel_pmc_core: Convert to ICPU macro
  x86/cpu: Add Cannonlake to Intel family
  platform/x86: intel_pmc_core: Add CannonLake PCH support
  platform/x86: intel_pmc_core: Special case for Coffeelake

Srinivas Pandruvada (3):
  platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration
  ACPI / LPIT: Export lpit_read_residency_count_address()
  platform/x86: intel_pmc_core: Read base address from LPIT

 arch/x86/include/asm/intel-family.h   |   6 +
 drivers/acpi/acpi_lpit.c  |   1 +
 drivers/platform/x86/intel_pmc_core.c | 242 +-
 drivers/platform/x86/intel_pmc_core.h |  14 +-
 4 files changed, 174 insertions(+), 89 deletions(-)

-- 
2.7.4

[Patch v1 5/8] platform/x86: intel_pmc_core: Convert to ICPU macro

[Rajneesh Bhardwaj]

Use ICPU macro to refactor code related to x86_cpu_id for better
readability.

Suggested-by: Andriy Shevchenko 
Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index 549ee5852d4f..da9326740647 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -33,6 +33,9 @@
 
 #include "intel_pmc_core.h"
 
+#define ICPU(cpu, data) \
+   { X86_VENDOR_INTEL, 6, cpu, X86_FEATURE_MWAIT, (kernel_ulong_t)data }
+
 static struct pmc_dev pmc;
 
 static const struct pmc_bit_map spt_pll_map[] = {
@@ -439,14 +442,10 @@ static inline void pmc_core_dbgfs_unregister(struct 
pmc_dev *pmcdev)
 #endif /* CONFIG_DEBUG_FS */
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
-   { X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_MOBILE, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)&spt_reg_map},
-   { X86_VENDOR_INTEL, 6, INTEL_FAM6_SKYLAKE_DESKTOP, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)&spt_reg_map},
-   { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_MOBILE, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)&spt_reg_map},
-   { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_DESKTOP, X86_FEATURE_MWAIT,
-   (kernel_ulong_t)&spt_reg_map},
+   ICPU(INTEL_FAM6_SKYLAKE_MOBILE, &spt_reg_map),
+   ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, &spt_reg_map),
+   ICPU(INTEL_FAM6_KABYLAKE_MOBILE, &spt_reg_map),
+   ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, &spt_reg_map),
{}
 };
 
-- 
2.7.4

Re: [PATCH v2 tip/master 0/3] kprobes/x86: retpoline: Fix kprobes for retpoline

[David Woodhouse]

On Fri, 2018-01-19 at 01:13 +0900, Masami Hiramatsu wrote:
> Masami Hiramatsu (3):
>   retpoline: Introduce start/end markers of indirect thunk
>   kprobes/x86: Blacklist indirect thunk functions for kprobes
>   kprobes/x86: Disable optimizing on the function jumps to indirect thunk

For all three:

Acked-by: David Woodhouse 
Cc: sta...@vger.kernel.org

Thank you.

smime.p7s
Description: S/MIME cryptographic signature

[Patch v1 6/8] x86/cpu: Add Cannonlake to Intel family

[Rajneesh Bhardwaj]

Add CPUID of Cannonlake (CNL) processors to Intel family list.

Cc: Dave Hansen 
Cc: Thomas Gleixner 
cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org

Suggested-by: Tony Luck 
Signed-off-by: Megha Dey 
Signed-off-by: Rajneesh Bhardwaj 
---
 arch/x86/include/asm/intel-family.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/intel-family.h 
b/arch/x86/include/asm/intel-family.h
index 35a6bc4da8ad..cf090e584202 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -10,6 +10,10 @@
  *
  * Things ending in "2" are usually because we have no better
  * name for them.  There's no processor called "SILVERMONT2".
+ *
+ * While adding a new CPUID for a new microarchitecture, add a new
+ * group to keep logically sorted out in chronological order. Within
+ * that group keep the CPUID for the variants sorted by model number.
  */
 
 #define INTEL_FAM6_CORE_YONAH  0x0E
@@ -49,6 +53,8 @@
 #define INTEL_FAM6_KABYLAKE_MOBILE 0x8E
 #define INTEL_FAM6_KABYLAKE_DESKTOP0x9E
 
+#define INTEL_FAM6_CANNONLAKE_MOBILE   0x66
+
 /* "Small Core" Processors (Atom) */
 
 #define INTEL_FAM6_ATOM_PINEVIEW   0x1C
-- 
2.7.4

[Patch v1 7/8] platform/x86: intel_pmc_core: Add CannonLake PCH support

[Rajneesh Bhardwaj]

This adds support for Cannonlake PCH which is used by Cannonlake and
Coffeelake SoCs.

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 85 +++
 drivers/platform/x86/intel_pmc_core.h | 11 +
 2 files changed, 96 insertions(+)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index da9326740647..f0d067a33a56 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -123,6 +123,90 @@ static const struct pmc_reg_map spt_reg_map = {
.pm_read_disable_bit = SPT_PMC_READ_DISABLE_BIT,
 };
 
+/* Cannonlake: PGD PFET Enable Ack Status Register(s) bitmap */
+static const struct pmc_bit_map cnp_pfear_map[] = {
+   {"PMC", BIT(0)},
+   {"OPI-DMI", BIT(1)},
+   {"SPI/eSPI",BIT(2)},
+   {"XHCI",BIT(3)},
+   {"SPA", BIT(4)},
+   {"SPB", BIT(5)},
+   {"SPC", BIT(6)},
+   {"GBE", BIT(7)},
+
+   {"SATA",BIT(0)},
+   {"HDA_PGD0",BIT(1)},
+   {"HDA_PGD1",BIT(2)},
+   {"HDA_PGD2",BIT(3)},
+   {"HDA_PGD3",BIT(4)},
+   {"SPD", BIT(5)},
+   {"LPSS",BIT(6)},
+   {"LPC", BIT(7)},
+
+   {"SMB", BIT(0)},
+   {"ISH", BIT(1)},
+   {"P2SB",BIT(2)},
+   {"NPK_VNN", BIT(3)},
+   {"SDX", BIT(4)},
+   {"SPE", BIT(5)},
+   {"Fuse",BIT(6)},
+   {"Res_23",  BIT(7)},
+
+   {"CSME_FSC",BIT(0)},
+   {"USB3_OTG",BIT(1)},
+   {"EXI", BIT(2)},
+   {"CSE", BIT(3)},
+   {"csme_kvm",BIT(4)},
+   {"csme_pmt",BIT(5)},
+   {"csme_clink",  BIT(6)},
+   {"csme_ptio",   BIT(7)},
+
+   {"csme_usbr",   BIT(0)},
+   {"csme_susram", BIT(1)},
+   {"csme_smt1",   BIT(2)},
+   {"CSME_SMT4",   BIT(3)},
+   {"csme_sms2",   BIT(4)},
+   {"csme_sms1",   BIT(5)},
+   {"csme_rtc",BIT(6)},
+   {"csme_psf",BIT(7)},
+
+   {"SBR0",BIT(0)},
+   {"SBR1",BIT(1)},
+   {"SBR2",BIT(2)},
+   {"SBR3",BIT(3)},
+   {"SBR4",BIT(4)},
+   {"SBR5",BIT(5)},
+   {"CSME_PECI",   BIT(6)},
+   {"PSF1",BIT(7)},
+
+   {"PSF2",BIT(0)},
+   {"PSF3",BIT(1)},
+   {"PSF4",BIT(2)},
+   {"CNVI",BIT(3)},
+   {"UFS0",BIT(4)},
+   {"EMMC",BIT(5)},
+   {"Res_6",   BIT(6)},
+   {"SBR6",BIT(7)},
+
+   {"SBR7",BIT(0)},
+   {"NPK_AON", BIT(1)},
+   {"HDA_PGD4",BIT(2)},
+   {"HDA_PGD5",BIT(3)},
+   {"HDA_PGD6",BIT(4)},
+   {}
+};
+
+static const struct pmc_reg_map cnp_reg_map = {
+   .pfear_sts = cnp_pfear_map,
+   .slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
+   .ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
+   .regmap_length = CNP_PMC_MMIO_REG_LEN,
+   .ppfear0_offset = CNP_PMC_HOST_PPFEAR0A,
+   .ppfear_buckets = CNP_PPFEAR_NUM_ENTRIES,
+   .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
+   .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
+};
+
 static inline u8 pmc_core_reg_read_byte(struct pmc_dev *pmcdev, int offset)
 {
return readb(pmcdev->regbase + offset);
@@ -446,6 +530,7 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, &spt_reg_map),
ICPU(INTEL_FAM6_KABYLAKE_MOBILE, &spt_reg_map),
ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, &spt_reg_map),
+   ICPU(INTEL_FAM6_CANNONLAKE_MOBILE, &cnp_reg_map),
{}
 };
 
diff --git a/drivers/platform/x86/intel_pmc_core.h 
b/drivers/platform/x86/intel_pmc_core.h
index 9df4a60a179f..8b7731e6dea2 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -121,6 +121,17 @@ enum ppfear_regs {
 #define SPT_PMC_BIT_MPHY_CMN_LANE2 BIT(2)
 #define SPT_PMC_BIT_MPHY_CMN_LANE3 BIT(3)
 
+/* Cannonlake Power Management Controller register offsets */
+#define CNP_PMC_SLP_S0_RES_COUNTER_OFFSET  0x193C
+#define CNP_PMC_LTR_IGNORE_OFFSET  0x1B0C
+#define CNP_PMC_PM_CFG_OFFSET  0x1818
+/* Cannonlake: PGD PFET Enable Ack Status Register(s) start */
+#define CNP_PMC_HOST_PPFEAR0A  0x1D90
+
+#define CNP_PMC_MMIO_REG_LEN  

ACPI: sbshc: remove raw pointer from printk message

[Greg Kroah-Hartman]

There's no need to be printing a raw kernel pointer to the kernel log at
every boot.  So just remove it, and change the whole message to use the
correct dev_info() call at the same time.

Reported-by: Wang Qize 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
index 2fa8304171e0..217e1caf58d6 100644
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -275,8 +275,8 @@ static int acpi_smbus_hc_add(struct acpi_device *device)
device->driver_data = hc;
 
acpi_ec_add_query_handler(hc->ec, hc->query_bit, NULL, smbus_alarm, hc);
-   printk(KERN_INFO PREFIX "SBS HC: EC = 0x%p, offset = 0x%0x, query_bit = 
0x%0x\n",
-   hc->ec, hc->offset, hc->query_bit);
+   dev_info(&device->dev, "SBS HC: offset = 0x%0x, query_bit = 0x%0x\n",
+hc->offset, hc->query_bit);
 
return 0;
 }

[Patch v1 8/8] platform/x86: intel_pmc_core: Special case for Coffeelake

[Rajneesh Bhardwaj]

Intel CoffeeLake SoC uses CPU ID of KabyLake but has Cannonlake PCH, so in
this case PMC register details from Cannonlake PCH must be used.

In order to identify whether the given platform is Coffeelake, scan for the
Sunrisepoint PMC PCI Id.

KBL CPUID   SPT PCIID
-
KBL |   Y   |   Y   |
-
CFL |   Y   |   N   |
-

Signed-off-by: Srinivas Pandruvada 
Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/platform/x86/intel_pmc_core.c | 14 ++
 drivers/platform/x86/intel_pmc_core.h |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index f0d067a33a56..67e85ee4ab32 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -536,6 +537,11 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
 
 MODULE_DEVICE_TABLE(x86cpu, intel_pmc_core_ids);
 
+static const struct pci_device_id pmc_pci_ids[] = {
+   { PCI_VDEVICE(INTEL, SPT_PMC_PCI_DEVICE_ID), 0},
+   { 0, },
+};
+
 static int __init pmc_core_probe(void)
 {
const struct x86_cpu_id *cpu_id;
@@ -549,6 +555,14 @@ static int __init pmc_core_probe(void)
 
pmcdev->map = (struct pmc_reg_map *)cpu_id->driver_data;
 
+   /*
+* Coffeelake has CPU ID of Kabylake and Cannonlake PCH. So here
+* Sunrisepoint PCH regmap can't be used. Use Cannonlake PCH regmap
+* in this case.
+*/
+   if (!pci_dev_present(pmc_pci_ids))
+   pmcdev->map = (struct pmc_reg_map *)&cnp_reg_map;
+
if (lpit_read_residency_count_address(&slp_s0_addr))
pmcdev->base_addr = PMC_BASE_ADDR_DEFAULT;
else
diff --git a/drivers/platform/x86/intel_pmc_core.h 
b/drivers/platform/x86/intel_pmc_core.h
index 8b7731e6dea2..5fa5f97870aa 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -23,6 +23,8 @@
 
 #define PMC_BASE_ADDR_DEFAULT  0xFE00
 
+/* Sunrise Point Power Management Controller PCI Device ID */
+#define SPT_PMC_PCI_DEVICE_ID  0x9d21
 #define SPT_PMC_BASE_ADDR_OFFSET   0x48
 #define SPT_PMC_SLP_S0_RES_COUNTER_OFFSET  0x13c
 #define SPT_PMC_PM_CFG_OFFSET  0x18
-- 
2.7.4

Re: [PATCH] KVM: prevent overlap between user and private memslots

[Wanpeng Li]

2018-01-19 17:01 GMT+08:00 Wanpeng Li :
> 2018-01-19 16:18 GMT+08:00 Eric Biggers :
>> From: Eric Biggers 
>>
>> Memslots must not overlap in guest physical memory, since otherwise some
>> guest physical addresses will not uniquely map to a memslot.  Yet, the
>> overlap check in __kvm_set_memory_region() allows a memslot that
>> overlaps one of the "private" memslots, e.g. the memslot reserved for
>> the TSS on x86.
>>
>> This seems to be a very old bug that was introduced years ago when
>> private memory slots were first added.  It seems that later refactoring
>> incorrectly assumed this bug was intentional and preserved it.
>>
>> Fix it by removing the loophole for private memslots, so we just check
>> for overlap against all memslots.
>>
>> This bug was found by syzkaller, which used a memslot overlap to make
>> pte_list_remove() be called for the wrong memslot, hitting a BUG():
>>
>> pte_list_remove: 7185ed42 0->BUG
>> kernel BUG at arch/x86/kvm/mmu.c:1209!
>> [...]
>> RIP: 0010:pte_list_remove+0x107/0x110 arch/x86/kvm/mmu.c:1208
>> [...]
>> Call Trace:
>>  mmu_page_zap_pte+0x7e/0xd0 arch/x86/kvm/mmu.c:2499
>>  kvm_mmu_page_unlink_children arch/x86/kvm/mmu.c:2521 [inline]
>>  kvm_mmu_prepare_zap_page+0x4f/0x340 arch/x86/kvm/mmu.c:2565
>>  kvm_zap_obsolete_pages arch/x86/kvm/mmu.c:5348 [inline]
>>  kvm_mmu_invalidate_zap_all_pages+0xa6/0x100 arch/x86/kvm/mmu.c:5389
>>  kvm_mmu_notifier_release+0x4f/0x80 
>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:468
>>  __mmu_notifier_release+0x63/0x100 mm/mmu_notifier.c:75
>>  mmu_notifier_release include/linux/mmu_notifier.h:244 [inline]
>>  exit_mmap+0x160/0x170 mm/mmap.c:3009
>>  __mmput kernel/fork.c:966 [inline]
>>  mmput+0x44/0xd0 kernel/fork.c:987
>>  exit_mm kernel/exit.c:544 [inline]
>>  do_exit+0x24a/0xb50 kernel/exit.c:856
>>  do_group_exit+0x34/0xb0 kernel/exit.c:972
>>  SYSC_exit_group kernel/exit.c:983 [inline]
>>  SyS_exit_group+0xb/0x10 kernel/exit.c:981
>>  entry_SYSCALL_64_fastpath+0x1e/0x8b
>>
>> Reproducer:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main()
>> {
>> static char buf[4096*3] __attribute__((aligned(4096)));
>> int kvm, vm, cpu;
>> struct kvm_mp_state mp_state = { KVM_MP_STATE_SIPI_RECEIVED };
>> struct kvm_userspace_memory_region memreg = {
>> .memory_size = sizeof(buf),
>> .userspace_addr = (__u64)buf,
>> };
>>
>> kvm = open("/dev/kvm", O_RDWR);
>> vm = ioctl(kvm, KVM_CREATE_VM, 0);
>> ioctl(vm, KVM_CREATE_IRQCHIP);
>> cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
>> ioctl(cpu, KVM_SET_MP_STATE, &mp_state);
>> ioctl(vm, KVM_SET_TSS_ADDR, 0);
>> ioctl(cpu, KVM_RUN, 0);
>> ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
>> }
>>
>> Reported-by: syzbot 
>> Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
>> Cc:  # v2.6.25+
>> Signed-off-by: Eric Biggers 
>
> Please refer to this one. https://patchwork.kernel.org/patch/9645377/

https://lkml.org/lkml/2017/3/27/57

>
> Regards,
> Wanpeng Li
>
>> ---
>>  virt/kvm/kvm_main.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 210bf820385a..e536977e7b6d 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -974,8 +974,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
>> /* Check for overlaps */
>> r = -EEXIST;
>> kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
>> -   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
>> -   (slot->id == id))
>> +   if (slot->id == id)
>> continue;
>> if (!((base_gfn + npages <= slot->base_gfn) ||
>>   (base_gfn >= slot->base_gfn + slot->npages)))
>> --
>> 2.16.0
>>

Re: [PATCH v2 3/5] powerpc/mm: Allow more than 16 low slices

[Aneesh Kumar K.V]

On 01/19/2018 02:29 PM, Christophe LEROY wrote:



Le 19/01/2018 à 09:30, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices_psize
element in struct mm_context_t

On the 8xx, the minimum slice size is the size of the area
covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
16K pages mode. This means we could have resp. up to 1024 and 64
slices.

In order to override this limitation, this patch switches the
handling of low_slices to BITMAPs as done already for high_slices.


Does it have a performance impact. When we switched high_slices
that was one of the question asked. Now with a topdown search we should
mostly be using the high_slices. But it will good to get numbers for
ppc64 for this change.


It should have almost no performance impact at all, because all bitmap 
functions used a simplified way when the number of bits is small and 
constant:


-    ret->low_slices = 0;
+    slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);


static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
{
 if (small_const_nbits(nbits))
     *dst = 0UL;
 else {
     unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
     memset(dst, 0, len);
 }
}



-    dst->low_slices |= src->low_slices;
+    slice_bitmap_or(dst->low_slices, dst->low_slices, src->low_slices,
+    SLICE_NUM_LOW);


static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
     const unsigned long *src2, unsigned int nbits)
{
 if (small_const_nbits(nbits))
     *dst = *src1 | *src2;
 else
     __bitmap_or(dst, src1, src2, nbits);
}





may be capture that in commit message saying since we are 64 bit on 
ppc64 there is no impact there?


-aneesh

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Christophe LEROY]

Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :



On 01/19/2018 02:14 PM, Christophe LEROY wrote:



Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.

On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.

This patch moves "slices" functions prototypes from page64.h to page.h

The high slices use bitmaps. As bitmap functions are not prepared to
handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
slice_bitmap_xxx() macros which will take care of the 0 nbits case.

Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts ; added 
slice_bitmap_xxx() macros.


  arch/powerpc/include/asm/page.h  | 14 +
  arch/powerpc/include/asm/page_32.h   | 19 
  arch/powerpc/include/asm/page_64.h   | 21 ++---
  arch/powerpc/mm/hash_utils_64.c  |  2 +-
  arch/powerpc/mm/mmu_context_nohash.c |  7 +
  arch/powerpc/mm/slice.c  | 60 


  6 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h 
b/arch/powerpc/include/asm/page.h

index 8da5d4c1cab2..d0384f9db9eb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
  #endif
  #endif
+#ifdef CONFIG_PPC_MM_SLICES
+struct mm_struct;
+
+unsigned long slice_get_unmapped_area(unsigned long addr, unsigned 
long len,

+  unsigned long flags, unsigned int psize,
+  int topdown);
+
+unsigned int get_slice_psize(struct mm_struct *mm, unsigned long 
addr);

+
+void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
+void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
+   unsigned long len, unsigned int psize);
+#endif
+


Should we do a slice.h ? the way we have other files? and then do


Yes we could add a slice.h instead of using page.h for that, good idea.



arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so that we
can do type checking.


Is it really worth duplicating that just for eliminating the 'if 
(nbits)' in one case ?


Only in book3s/64 we will be able to eliminate that, for nohash/32 we 
need to keep the test due to the difference between low and high slices.


the other advantage is we move the SLICE_LOW_SHIFT to the right 
location. IMHO mm subystem is really complex with these really 
overloaded headers. If we can keep it  seperate we should with minimal 
code duplication?


For the constants I fully agree with your proposal and I will do it. I 
was only questionning the benefit of moving the slice_bitmap_() 
stuff, taking into account that the 'if (nbits)' test is already 
eliminated by the compiler.


Christophe



In any case, as the nbits we use in slice.c is a constant, the test is 
eliminated at compilation, so I can't see the benefit of making 


-aneesh

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Aneesh Kumar K.V]

On 01/19/2018 02:37 PM, Christophe LEROY wrote:



Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :



On 01/19/2018 02:14 PM, Christophe LEROY wrote:



Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.

On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.

This patch moves "slices" functions prototypes from page64.h to page.h

The high slices use bitmaps. As bitmap functions are not prepared to
handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
slice_bitmap_xxx() macros which will take care of the 0 nbits case.

Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts ; added 
slice_bitmap_xxx() macros.


  arch/powerpc/include/asm/page.h  | 14 +
  arch/powerpc/include/asm/page_32.h   | 19 
  arch/powerpc/include/asm/page_64.h   | 21 ++---
  arch/powerpc/mm/hash_utils_64.c  |  2 +-
  arch/powerpc/mm/mmu_context_nohash.c |  7 +
  arch/powerpc/mm/slice.c  | 60 


  6 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h 
b/arch/powerpc/include/asm/page.h

index 8da5d4c1cab2..d0384f9db9eb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
  #endif
  #endif
+#ifdef CONFIG_PPC_MM_SLICES
+struct mm_struct;
+
+unsigned long slice_get_unmapped_area(unsigned long addr, unsigned 
long len,

+  unsigned long flags, unsigned int psize,
+  int topdown);
+
+unsigned int get_slice_psize(struct mm_struct *mm, unsigned long 
addr);

+
+void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
+void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
+   unsigned long len, unsigned int psize);
+#endif
+


Should we do a slice.h ? the way we have other files? and then do


Yes we could add a slice.h instead of using page.h for that, good idea.



arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so that we
can do type checking.


Is it really worth duplicating that just for eliminating the 'if 
(nbits)' in one case ?


Only in book3s/64 we will be able to eliminate that, for nohash/32 we 
need to keep the test due to the difference between low and high slices.


the other advantage is we move the SLICE_LOW_SHIFT to the right 
location. IMHO mm subystem is really complex with these really 
overloaded headers. If we can keep it  seperate we should with minimal 
code duplication?


For the constants I fully agree with your proposal and I will do it. I 
was only questionning the benefit of moving the slice_bitmap_() 
stuff, taking into account that the 'if (nbits)' test is already 
eliminated by the compiler.




That is compiler dependent as you are finding with the other patch where 
if (0) didn't get compiled out


-aneesh

Re: [PATCH 3/3] encrypted-keys: document new fscrypt key format

[André Draszik]

Thank you Ted,

On Wed, 2018-01-17 at 13:05 -0500, Theodore Ts'o wrote:
> On Wed, Jan 17, 2018 at 02:38:59PM +, André Draszik wrote:
> > > > [...]
> > > 
> > > Please be very clear about exactly what security properties are
> > > achieved
> > > by
> > > using encrypted-keys.
> > 
> > I've left out all of this in the updated documentation, as any such
> > information should probably be in Documentation/security/keys/trusted-
> > encrypted.rst in the first place.
> 
> Where is this document going to be found / when will it be written?
> It seems really odd to be requesting a do code review when the
> specifications aren't available and/or haven't been written yet.  I
> prefer to review the *design* first, as opposed to trying to both
> review the code and try to guess at the design and review my guess of
> the design at the same time

Does v3's commit message https://patchwork.kernel.org/patch/10173189/ serve
as a good enough design document?

Cheers,
Andre'

Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions

[Baoquan He]

On 01/19/18 at 04:06pm, Dou Liyang wrote:
> 
> 
> At 01/19/2018 03:21 PM, Baoquan He wrote:
> > On 01/19/18 at 02:42pm, Dou Liyang wrote:
> > > Hi Baoquan,
> > > 
> > > At 01/05/2018 12:39 PM, Baoquan He wrote:
> > > [...]
> > > >/*
> > > > - * Not an __init, needed by kexec/kdump code.
> > > > - * For safety IO-APIC and Local APIC need be cleared before this.
> > > > + * In legacy irq mode, full DOS compatibility with the uniprocessor 
> > > > PC/AT is
> > > > + * provided by using the APICs in conjunction with standard 
> > > > 8259A-equivalent
> > > > + * programmable interrupt controllers (PICs). It's necessary to 
> > > > deliver legacy
> > > > + * interrupts even when APIC mode is not enabled. This is required by 
> > > > kexec/
> > > > + * kdump before enter into the 2nd kernel.
> > > > */
> > > >void switch_to_legacy_irq_mode(void)
> > > >{
> > > > if (!nr_legacy_irqs())
> > > > return;
> > > > -   x86_io_apic_ops.disable();
> > > > +   ioapic_set_virtual_wire_mode();
> > > > +
> > > > +   if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config())
> > > > +   lapic_set_legacy_irq_mode(ioapic_i8259.pin != -1);
> > > 
> > > Seems these two function, ioapic/lapic_set_legacy_irq_mode should be
> > > exclusive.
> > 
> > Thanks for looking into this, dou!
> > 
> > It might be not exclusive. You can see mp_spec 3.6.2.2 Virtual Wire Mode
> 
> Oops! Sorry to confuse you, here what I want to say is that the code
> make me think that we set through IO-APIC first, then set through
> Local-APIC then. But, we can be only in one mode of them.
> 
> Just worry about this code seems ignore the irq remapping situation.
> 
> We call switch_to_legacy_irq_mode() directly in machine_kexec(),
> why we also set x86_io_apic_ops:
> 
>   .disable = switch_to_legacy_irq_mode

You are right, this is not very clear. Since we call switch_to_legacy_irq_mode()
directly, nobody will call x86_io_apic_ops.disable() any more.

Should keep native_disable_io_apic() and let x86_io_apic_ops.disable()
to point at it.

Thanks
Baoquan
> 
> > subsection, there are two kinds of virtual wire mode, one is
> > 8259A-Equivalent pics is connected to lint0 of boot cpu LAPIC, the other
> > is 8259A-Equivalent pics go through IO-APIC, then is connected to lint0
> > of LAPIC. Whatever it is, LAPIC need be set as through-lapic.
> > 
> 
> Yes, Absolutely right!
> 
> > Above is what I got from mp_spec. But from function
> > native_disable_io_apic() and disconnect_bsp_APIC(), the code seems to be
> > telling that if io-apic is connected to 8259A-Equivalent pics, we need
> > mask lvt0 of LAPIC. This conflicts with mp_spec 3.6.2.2.
> > 
> 
> I think so.
> 
> Thanks,
>   dou.
> > Thanks
> > Baoquan
> > > 
> > > But We do that because both the through-lapic and through-ioapic virtual
> > > wire mode need setup the APIC_SPIV_APIC_ENABLED which is only located in
> > > the lapic_set_legacy_irq_mode(). So we need call them both.
> > > 
> > > IMO, this cleanup may not make it clear. we can separate these two mode
> > > totally or just keep it like before.
> > > 
> > > Thanks,
> > >   dou.
> > > >}
> > > >#ifdef CONFIG_X86_32
> > > > diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
> > > > index 1151ccd72ce9..c30f0f273dbd 100644
> > > > --- a/arch/x86/kernel/x86_init.c
> > > > +++ b/arch/x86/kernel/x86_init.c
> > > > @@ -148,5 +148,5 @@ void arch_restore_msi_irqs(struct pci_dev *dev)
> > > >struct x86_io_apic_ops x86_io_apic_ops __ro_after_init = {
> > > > .read   = native_io_apic_read,
> > > > -   .disable= native_disable_io_apic,
> > > > +   .disable= switch_to_legacy_irq_mode,
> > > >};
> > > > diff --git a/drivers/iommu/irq_remapping.c 
> > > > b/drivers/iommu/irq_remapping.c
> > > > index 49721b4e1975..751472ddf536 100644
> > > > --- a/drivers/iommu/irq_remapping.c
> > > > +++ b/drivers/iommu/irq_remapping.c
> > > > @@ -37,7 +37,7 @@ static void irq_remapping_disable_io_apic(void)
> > > >  * now.
> > > >  */
> > > > if (boot_cpu_has(X86_FEATURE_APIC) || apic_from_smp_config())
> > > > -   disconnect_bsp_APIC(0);
> > > > +   lapic_set_legacy_irq_mode(0);
> > > >}
> > > >static void __init irq_remapping_modify_x86_ops(void)
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> 
> 

Re: [PATCH 4/8] irqchip/gic-v3: add ability to save/restore GIC/ITS state

[Marc Zyngier]

On 18/01/18 23:33, Brian Norris wrote:
> Hi,
> 
> On Sat, Jan 13, 2018 at 06:10:52PM +, Marc Zyngier wrote:
>> On Fri, 12 Jan 2018 21:24:18 +,
>> Derek Basehore wrote:
>>>
>>> Some platforms power off GIC logic in S3, so we need to save/restore
>>
>> S3 is a not a GIC concept, and is only vaguely mentioned in terms of
>> the rk3399 silicon, if grep serves me right. Please expand on what
>> state this is exactly.
>>
>>> state. This adds a DT-binding to save/restore the GICD/GICR/GITS
>>> states using the new CPU_PM_SYSTEM_ENTER/EXIT CPU PM states.
>>
>> DT binding? I can't see any in this patch.
>>
>>>
>>> Change-Id: I1fb2117296373fa67397fdd4a8960077b241462e
>>
>> It's been mentioned somewhere else in the thread: these tags have no
>> purpose in the kernel. Please sanitise your patches before posting them.
>>
>>> Signed-off-by: Derek Basehore 
>>> Signed-off-by: Brian Norris 
>>
>> Who is the author of this patch? If that's a joined authorship, please
>> use the Co-Developed-by: tag.
> 
> I only did some minimal code shuffling when rebasing and working with
> this code in our downstream tree. I probably didn't actually need to
> apply my Signed-off-by at the time, but Derek carried it along anyway.
> 
> Derek is the author, and I'd be perfectly fine dropping my S-o-b from
> these patches.
> 
>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>>> index 9a7a15049903..95d37fb6f458 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c

[...]

>>> +   if (IS_ERR(gicr_ctx)) {
>>> +   err = PTR_ERR(gicr_ctx);
>>> +   goto out_free_gicd_ctx;
>>> +   }
>>> +   }
>>
>> You really want to kill the box because something went wrong in your
>> save area allocation? It doesn't feel quite right.
> 
> Isn't that what all drivers (including irqchip drivers) do on failed
> allocations? What else would we do? Pretend that we can limp along and
> just b0rk the system when it suspends?
It would certainly give the user a chance to diagnostic the problem
(which is otherwise pretty hard if the system doesn't boot). We kill the
system if we cannot continue. In this case, we can. So why not try it?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

[Pavan Kondeti]

Hi Steven,

>  /* Called from hardirq context */
> -static void try_to_push_tasks(void *arg)
> +void rto_push_irq_work_func(struct irq_work *work)
>  {
> -   struct rt_rq *rt_rq = arg;
> -   struct rq *rq, *src_rq;
> -   int this_cpu;
> +   struct rq *rq;
> int cpu;
>
> -   this_cpu = rt_rq->push_cpu;
> +   rq = this_rq();
>
> -   /* Paranoid check */
> -   BUG_ON(this_cpu != smp_processor_id());
> -
> -   rq = cpu_rq(this_cpu);
> -   src_rq = rq_of_rt_rq(rt_rq);
> -
> -again:
> +   /*
> +* We do not need to grab the lock to check for has_pushable_tasks.
> +* When it gets updated, a check is made if a push is possible.
> +*/
> if (has_pushable_tasks(rq)) {
> raw_spin_lock(&rq->lock);
> -   push_rt_task(rq);
> +   push_rt_tasks(rq);
> raw_spin_unlock(&rq->lock);
> }
>
> -   /* Pass the IPI to the next rt overloaded queue */
> -   raw_spin_lock(&rt_rq->push_lock);
> -   /*
> -* If the source queue changed since the IPI went out,
> -* we need to restart the search from that CPU again.
> -*/
> -   if (rt_rq->push_flags & RT_PUSH_IPI_RESTART) {
> -   rt_rq->push_flags &= ~RT_PUSH_IPI_RESTART;
> -   rt_rq->push_cpu = src_rq->cpu;
> -   }
> +   raw_spin_lock(&rq->rd->rto_lock);
>
> -   cpu = find_next_push_cpu(src_rq);
> +   /* Pass the IPI to the next rt overloaded queue */
> +   cpu = rto_next_cpu(rq);
>
> -   if (cpu >= nr_cpu_ids)
> -   rt_rq->push_flags &= ~RT_PUSH_IPI_EXECUTING;
> -   raw_spin_unlock(&rt_rq->push_lock);
> +   raw_spin_unlock(&rq->rd->rto_lock);
>
> -   if (cpu >= nr_cpu_ids)
> +   if (cpu < 0)
> return;

I am seeing "spinlock already unlocked" BUG for rd->rto_lock on a 4.9
stable kernel based system. This issue is observed only after
inclusion of this patch. It appears to me that rq->rd can change
between spinlock is acquired and released in rto_push_irq_work_func()
IRQ work if hotplug is in progress. It was only reported couple of
times during long stress testing. The issue can be easily reproduced
if an artificial delay is introduced between lock and unlock of
rto_lock. The rq->rd is changed under rq->lock, so we can protect this
race with rq->lock. The below patch solved the problem. we are taking
rq->lock in pull_rt_task()->tell_cpu_to_push(), so I extended the same
here. Please let me know your thoughts on this.

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d863d39..478192b 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2284,6 +2284,7 @@ void rto_push_irq_work_func(struct irq_work *work)
raw_spin_unlock(&rq->lock);
}

+   raw_spin_lock(&rq->lock);
raw_spin_lock(&rq->rd->rto_lock);

/* Pass the IPI to the next rt overloaded queue */
@@ -2291,11 +2292,10 @@ void rto_push_irq_work_func(struct irq_work *work)

raw_spin_unlock(&rq->rd->rto_lock);

-   if (cpu < 0)
-   return;
-
/* Try the next RT overloaded CPU */
-   irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+   if (cpu >= 0)
+   irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+   raw_spin_unlock(&rq->lock);
 }
 #endif /* HAVE_RT_PUSH_IPI */


Thanks,
Pavan

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Heikki Krogerus]

Hi,

On Fri, Jan 19, 2018 at 09:01:24AM +, shufan_lee(?|) wrote:
> Hi Heikki,
> 
>   For example, the flow of tcpci_init is a little bit different.
>   In tcpci_init, there are more parameters need to be set for RT1711H.

Different init parameters is really not a reason for a fork of the
driver. The configuration of the TCPC will depend on the platform and
TCPC vendor most cases.


Thanks,

-- 
heikki

[PATCH v2 0/9] add UniPhier audio system support

[Katsuhiro Suzuki]

This series adds support for Socionext audio system for
UniPhier LD11/LD20 SoCs. This driver supports I2S output
for Line-In, Line-Out and S/PDIF output.

UniPhier AIO DAI driver provides sound devices such as I2S, S/PDIF.
Since the AIO has mixed register map for those I/Os, it is hard to
split register areas for each sound devices.

---

Changes in v2:
  - Add comments to aiodma_irq()
  - Add members to struct uniphier_aio_sub and add methods
for compress audio
  - Expose clocking to userspace
  - Fix bad name 'srcport' to 'src'
  - Split DMA, DAI patches from large one
  - Validate parameters in hw_params()
  - Add error checks
  - Fix typo in error messages
  - Change license comment style to C++ from C

Katsuhiro Suzuki (9):
  ASoC: uniphier: add DT bindings documentation for UniPhier AIO
  ASoC: uniphier: add support for UniPhier AIO common driver
  ASoC: uniphier: add support for UniPhier AIO DMA driver
  ASoC: uniphier: add support for UniPhier AIO CPU DAI driver
  ASoC: uniphier: add support for UniPhier AIO compress audio
  ASoC: uniphier: add support for UniPhier LD11/LD20 AIO driver
  arm64: dts: uniphier: add sound node for UniPhier
  arm64: dts: uniphier: add speaker out for UniPhier LD11/LD20 boards
  arm64: dts: uniphier: add compress audio out for UniPhier LD11/LD20

 .../devicetree/bindings/sound/uniphier,aio.txt |   36 +
 .../boot/dts/socionext/uniphier-ld11-global.dts|  120 +++
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   |   31 +
 .../boot/dts/socionext/uniphier-ld20-global.dts|  120 +++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   |   35 +
 sound/soc/uniphier/Kconfig |   22 +
 sound/soc/uniphier/Makefile|6 +
 sound/soc/uniphier/aio-compress.c  |  440 
 sound/soc/uniphier/aio-core.c  | 1104 
 sound/soc/uniphier/aio-cpu.c   |  570 ++
 sound/soc/uniphier/aio-dma.c   |  318 ++
 sound/soc/uniphier/aio-ld11.c  |  431 
 sound/soc/uniphier/aio-reg.h   |  462 
 sound/soc/uniphier/aio.h   |  355 +++
 14 files changed, 4050 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt
 create mode 100644 sound/soc/uniphier/aio-compress.c
 create mode 100644 sound/soc/uniphier/aio-core.c
 create mode 100644 sound/soc/uniphier/aio-cpu.c
 create mode 100644 sound/soc/uniphier/aio-dma.c
 create mode 100644 sound/soc/uniphier/aio-ld11.c
 create mode 100644 sound/soc/uniphier/aio-reg.h
 create mode 100644 sound/soc/uniphier/aio.h

-- 
2.15.0

[PATCH v2 1/9] ASoC: uniphier: add DT bindings documentation for UniPhier AIO

[Katsuhiro Suzuki]

This patch adds DT binding documentation for UniPhier
AIO audio subsystem.

Acked-by: Rob Herring 
Signed-off-by: Katsuhiro Suzuki 
---
 .../devicetree/bindings/sound/uniphier,aio.txt | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt

diff --git a/Documentation/devicetree/bindings/sound/uniphier,aio.txt 
b/Documentation/devicetree/bindings/sound/uniphier,aio.txt
new file mode 100644
index ..73f6c27ae4f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/uniphier,aio.txt
@@ -0,0 +1,36 @@
+Socionext UniPhier SoC audio driver
+
+The Socionext UniPhier audio subsystem consists of I2S and S/PDIF blocks in
+the same register space.
+
+Required properties:
+- compatible  : should be one of the following:
+   "socionext,uniphier-ld11-aio"
+   "socionext,uniphier-ld20-aio"
+- reg : offset and length of the register set for the device.
+- interrupts  : should contain I2S or S/PDIF interrupt.
+- pinctrl-names   : should be "default".
+- pinctrl-0   : defined I2S signal pins for an external codec chip.
+- clock-names : should include following entries:
+"aio"
+- clocks  : a list of phandle, should contain an entry for each
+entry in clock-names.
+- reset-names : should include following entries:
+"aio"
+- resets  : a list of phandle, should contain an entry for each
+entry in reset-names.
+- #sound-dai-cells: should be 1.
+
+Example:
+   audio {
+   compatible = "socionext,uniphier-ld20-aio";
+   reg = <0x5600 0x8>;
+   interrupts = <0 144 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_aout>;
+   clock-names = "aio";
+   clocks = <&sys_clk 40>;
+   reset-names = "aio";
+   resets = <&sys_rst 40>;
+   #sound-dai-cells = <1>;
+   };
-- 
2.15.0

[PATCH v2 7/9] arm64: dts: uniphier: add sound node for UniPhier

[Katsuhiro Suzuki]

This patch adds audio controller, codec and simple card node of
UniPhier AIO sound system for LD11/20 SoCs.

Signed-off-by: Katsuhiro Suzuki 
---
 .../boot/dts/socionext/uniphier-ld11-global.dts| 72 ++
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 31 ++
 .../boot/dts/socionext/uniphier-ld20-global.dts| 72 ++
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 35 +++
 4 files changed, 210 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index 2452b2243f42..4eb8d00a8c02 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -37,6 +37,29 @@
device_type = "memory";
reg = <0 0x8000 0 0x4000>;
};
+
+   soc@0 {
+   sound {
+   compatible = "audio-graph-card";
+   label = "UniPhier LD11";
+   widgets = "Headphone", "Headphone Jack";
+
+   dais = <&i2s_port2
+   &i2s_port4
+   &spdif_port0>;
+   };
+
+   spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   spdif_tx: endpoint {
+   remote-endpoint = <&spdif_hiecout1>;
+   };
+   };
+   };
+   };
 };
 
 &serial0 {
@@ -72,3 +95,52 @@
 &nand {
status = "okay";
 };
+
+&audio {
+   i2s_port0: port@0 {
+   i2s_hdmi: endpoint {
+   };
+   };
+
+   i2s_port1: port@1 {
+   i2s_pcmin2: endpoint {
+   };
+   };
+
+   i2s_port2: port@2 {
+   i2s_line: endpoint {
+   remote-endpoint = <&evea_line>;
+   };
+   };
+
+   i2s_port3: port@3 {
+   i2s_hpcmout1: endpoint {
+   };
+   };
+
+   i2s_port4: port@4 {
+   i2s_pcmout3: endpoint {
+   remote-endpoint = <&evea_hp>;
+   };
+   };
+
+   spdif_port0: port@5 {
+   spdif_hiecout1: endpoint {
+   remote-endpoint = <&spdif_tx>;
+   };
+   };
+};
+
+&evea {
+   port@0 {
+   evea_line: endpoint {
+   remote-endpoint = <&i2s_line>;
+   };
+   };
+
+   port@1 {
+   evea_hp: endpoint {
+   remote-endpoint = <&i2s_pcmout3>;
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index cd7c2d0a1f64..0e38252c05d7 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -187,6 +187,29 @@
 <21 217 3>;
};
 
+   audio: audio@5600 {
+   compatible = "socionext,uniphier-ld11-aio";
+   reg = <0x5600 0x8>;
+   interrupts = <0 144 4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_aout>;
+   clock-names = "aio";
+   clocks = <&sys_clk 40>;
+   reset-names = "aio";
+   resets = <&sys_rst 40>;
+   #sound-dai-cells = <1>;
+   };
+
+   evea: codec@5790 {
+   compatible = "socionext,uniphier-evea";
+   reg = <0x5790 0x1000>;
+   clock-names = "evea", "exiv";
+   clocks = <&sys_clk 41>, <&sys_clk 42>;
+   reset-names = "evea", "exiv", "adamv";
+   resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>;
+   #sound-dai-cells = <1>;
+   };
+
adamv@5792 {
compatible = "socionext,uniphier-ld11-adamv",
 "simple-mfd", "syscon";
@@ -475,3 +498,11 @@
 };
 
 #include "uniphier-pinctrl.dtsi"
+
+&pinctrl_aout {
+   drive-strength = <4>;   /* default: 4mA */
+   group_1 {
+   pins = "AO1ARC";
+   drive-strength = <8>;   /* 8mA */
+   };
+};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index fc2bc9d75d35..ebcd65631bca 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -37,6 +37,29 @@
device_type = "memory";
reg = <

[PATCH v2 9/9] arm64: dts: uniphier: add compress audio out for UniPhier LD11/LD20

[Katsuhiro Suzuki]

This patch adds compress audio node for S/PDIF on UniPhier LD11/20
global boards. And adds settings of AIO for it.

Signed-off-by: Katsuhiro Suzuki 
---
 .../boot/dts/socionext/uniphier-ld11-global.dts| 30 +-
 .../boot/dts/socionext/uniphier-ld20-global.dts| 30 +-
 2 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index ca09251a3eab..51cb717e5e56 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -48,7 +48,8 @@
dais = <&i2s_port2
&i2s_port3
&i2s_port4
-   &spdif_port0>;
+   &spdif_port0
+   &comp_spdif_port0>;
};
 
spdif-out {
@@ -61,6 +62,17 @@
};
};
};
+
+   comp-spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   comp_spdif_tx: endpoint {
+   remote-endpoint = 
<&comp_spdif_hiecout1>;
+   };
+   };
+   };
};
 };
 
@@ -149,6 +161,22 @@
remote-endpoint = <&spdif_tx>;
};
};
+
+   src_port0: port@6 {
+   i2s_epcmout2: endpoint {
+   };
+   };
+
+   src_port1: port@7 {
+   i2s_epcmout3: endpoint {
+   };
+   };
+
+   comp_spdif_port0: port@8 {
+   comp_spdif_hiecout1: endpoint {
+   remote-endpoint = <&comp_spdif_tx>;
+   };
+   };
 };
 
 &evea {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index 0728832ce552..0bda5c1382bc 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -48,7 +48,8 @@
dais = <&i2s_port2
&i2s_port3
&i2s_port4
-   &spdif_port0>;
+   &spdif_port0
+   &comp_spdif_port0>;
};
 
spdif-out {
@@ -61,6 +62,17 @@
};
};
};
+
+   comp-spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   comp_spdif_tx: endpoint {
+   remote-endpoint = 
<&comp_spdif_hiecout1>;
+   };
+   };
+   };
};
 };
 
@@ -131,6 +143,22 @@
remote-endpoint = <&spdif_tx>;
};
};
+
+   src_port0: port@6 {
+   i2s_epcmout2: endpoint {
+   };
+   };
+
+   src_port1: port@7 {
+   i2s_epcmout3: endpoint {
+   };
+   };
+
+   comp_spdif_port0: port@8 {
+   comp_spdif_hiecout1: endpoint {
+   remote-endpoint = <&comp_spdif_tx>;
+   };
+   };
 };
 
 &evea {
-- 
2.15.0

[PATCH v2 4/9] ASoC: uniphier: add support for UniPhier AIO CPU DAI driver

[Katsuhiro Suzuki]

This patch adds CPU DAI driver for UniPhier AIO audio sound system.

This module provides PCM devices for all input/output port of AIO
such as I2S, S/PDIF.

Signed-off-by: Katsuhiro Suzuki 

---

Changes in v2:
  - Change license comment style to C++ from C
  - Add error checks
  - Fix typo in error messages
  - Expose MCLK clock and PLL settings to user
  - Validate parameters in hw_params()
  - Fix missing checks for return value
---
 sound/soc/uniphier/Makefile  |   2 +-
 sound/soc/uniphier/aio-cpu.c | 570 +++
 sound/soc/uniphier/aio.h |   9 +
 3 files changed, 580 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/uniphier/aio-cpu.c

diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
index 9efe0feffdc2..3ef2784b2383 100644
--- a/sound/soc/uniphier/Makefile
+++ b/sound/soc/uniphier/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o
+snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o aio-cpu.o
 
 obj-$(CONFIG_SND_SOC_UNIPHIER_AIO) += snd-soc-uniphier-aio-cpu.o
 
diff --git a/sound/soc/uniphier/aio-cpu.c b/sound/soc/uniphier/aio-cpu.c
new file mode 100644
index ..55f3248a31fd
--- /dev/null
+++ b/sound/soc/uniphier/aio-cpu.c
@@ -0,0 +1,570 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext UniPhier AIO ALSA CPU DAI driver.
+//
+// Copyright (c) 2016-2018 Socionext Inc.
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License
+// as published by the Free Software Foundation; version 2
+// of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, see .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aio.h"
+
+static bool is_valid_pll(struct uniphier_aio_chip *chip, int pll_id)
+{
+   struct device *dev = &chip->pdev->dev;
+
+   if (pll_id < 0 || chip->num_plls <= pll_id) {
+   dev_err(dev, "PLL(%d) is not supported\n", pll_id);
+   return false;
+   }
+
+   return chip->plls[pll_id].enable;
+}
+
+static bool match_spec(const struct uniphier_aio_spec *spec,
+  const char *name, int dir)
+{
+   if (dir == SNDRV_PCM_STREAM_PLAYBACK &&
+   spec->swm.dir != PORT_DIR_OUTPUT) {
+   return false;
+   }
+
+   if (dir == SNDRV_PCM_STREAM_CAPTURE &&
+   spec->swm.dir != PORT_DIR_INPUT) {
+   return false;
+   }
+
+   if (spec->name && strcmp(spec->name, name) == 0)
+   return true;
+
+   if (spec->gname && strcmp(spec->gname, name) == 0)
+   return true;
+
+   return false;
+}
+
+/**
+ * find_spec - find HW specification info by name
+ * @aio: the AIO device pointer
+ * @name: name of device
+ * @direction: the direction of substream, SNDRV_PCM_STREAM_*
+ *
+ * Find hardware specification information from list by device name. This
+ * information is used for telling the difference of SoCs to driver.
+ *
+ * Specification list is array of 'struct uniphier_aio_spec' which is defined
+ * in each drivers (see: aio-i2s.c).
+ *
+ * Return: The pointer of hardware specification of AIO if successful,
+ * otherwise NULL on error.
+ */
+static const struct uniphier_aio_spec *find_spec(struct uniphier_aio *aio,
+const char *name,
+int direction)
+{
+   const struct uniphier_aio_chip_spec *chip_spec = aio->chip->chip_spec;
+   int i;
+
+   for (i = 0; i < chip_spec->num_specs; i++) {
+   const struct uniphier_aio_spec *spec = &chip_spec->specs[i];
+
+   if (match_spec(spec, name, direction))
+   return spec;
+   }
+
+   return NULL;
+}
+
+/**
+ * find_divider - find clock divider by frequency
+ * @aio: the AIO device pointer
+ * @pll_id: PLL ID, should be AUD_PLL_XX
+ * @freq: required frequency
+ *
+ * Find suitable clock divider by frequency.
+ *
+ * Return: The ID of PLL if successful, otherwise negative error value.
+ */
+static int find_divider(struct uniphier_aio *aio, int pll_id, unsigned int 
freq)
+{
+   struct uniphier_aio_pll *pll;
+   int mul[] = { 1, 1, 1, 2, };
+   int div[] = { 2, 3, 1, 3, };
+   int i;
+
+   if (!is_valid_pll(aio->chip, pll_id))
+   return -EINVAL;
+
+   pll = &aio->chip->plls[pll_id];
+   for (i = 0; i < ARRAY_SIZE(mul); i++)
+   if (pll->freq * mul[i] / div[i] == f

[PATCH v2 3/9] ASoC: uniphier: add support for UniPhier AIO DMA driver

[Katsuhiro Suzuki]

This patch adds supports for UniPhier AIO DMA.

This module shared register area with all sound devices for
I2S, S/PDIF and so on. Since the AIO has mixed register map
for those I/Os, it is hard to split register areas for each
sound devices.

Signed-off-by: Katsuhiro Suzuki 

---

Changes in v2:
  - Change license comment style to C++ from C
  - Add error checks
  - Fix typo in error messages
  - Split DMA, CPU DAI patches from large one
  - Add comments to aiodma_irq()
  - Fix missing checks for return value
---
 sound/soc/uniphier/Makefile  |   2 +-
 sound/soc/uniphier/aio-dma.c | 317 +++
 sound/soc/uniphier/aio.h |   2 +
 3 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/uniphier/aio-dma.c

diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
index f3b36aba4879..9efe0feffdc2 100644
--- a/sound/soc/uniphier/Makefile
+++ b/sound/soc/uniphier/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-snd-soc-uniphier-aio-cpu-objs := aio-core.o
+snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o
 
 obj-$(CONFIG_SND_SOC_UNIPHIER_AIO) += snd-soc-uniphier-aio-cpu.o
 
diff --git a/sound/soc/uniphier/aio-dma.c b/sound/soc/uniphier/aio-dma.c
new file mode 100644
index ..6d0ca6dde913
--- /dev/null
+++ b/sound/soc/uniphier/aio-dma.c
@@ -0,0 +1,317 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext UniPhier AIO DMA driver.
+//
+// Copyright (c) 2016-2018 Socionext Inc.
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License
+// as published by the Free Software Foundation; version 2
+// of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, see .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aio.h"
+
+static struct snd_pcm_hardware uniphier_aiodma_hw = {
+   .info = SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID |
+   SNDRV_PCM_INFO_INTERLEAVED,
+   .period_bytes_min = 256,
+   .period_bytes_max = 4096,
+   .periods_min  = 4,
+   .periods_max  = 1024,
+   .buffer_bytes_max = 128 * 1024,
+};
+
+static void aiodma_pcm_irq(struct uniphier_aio_sub *sub)
+{
+   struct snd_pcm_runtime *runtime = sub->substream->runtime;
+   int bytes = runtime->period_size *
+   runtime->channels * samples_to_bytes(runtime, 1);
+   int ret;
+
+   spin_lock(&sub->lock);
+   ret = aiodma_rb_set_threshold(sub, runtime->dma_bytes,
+ sub->threshold + bytes);
+   if (!ret)
+   sub->threshold += bytes;
+
+   aiodma_rb_sync(sub, runtime->dma_addr, runtime->dma_bytes, bytes);
+   aiodma_rb_clear_irq(sub);
+   spin_unlock(&sub->lock);
+
+   snd_pcm_period_elapsed(sub->substream);
+}
+
+static void aiodma_compr_irq(struct uniphier_aio_sub *sub)
+{
+   struct snd_compr_runtime *runtime = sub->cstream->runtime;
+   int bytes = runtime->fragment_size;
+   int ret;
+
+   spin_lock(&sub->lock);
+   ret = aiodma_rb_set_threshold(sub, sub->compr_bytes,
+ sub->threshold + bytes);
+   if (!ret)
+   sub->threshold += bytes;
+
+   aiodma_rb_sync(sub, sub->compr_addr, sub->compr_bytes, bytes);
+   aiodma_rb_clear_irq(sub);
+   spin_unlock(&sub->lock);
+
+   snd_compr_fragment_elapsed(sub->cstream);
+}
+
+static irqreturn_t aiodma_irq(int irq, void *p)
+{
+   struct platform_device *pdev = p;
+   struct uniphier_aio_chip *chip = platform_get_drvdata(pdev);
+   irqreturn_t ret = IRQ_NONE;
+   int i, j;
+
+   for (i = 0; i < chip->num_aios; i++) {
+   struct uniphier_aio *aio = &chip->aios[i];
+
+   for (j = 0; j < ARRAY_SIZE(aio->sub); j++) {
+   struct uniphier_aio_sub *sub = &aio->sub[j];
+
+   /* Skip channel that does not trigger */
+   if (!sub->running || !aiodma_rb_is_irq(sub))
+   continue;
+
+   if (sub->substream)
+   aiodma_pcm_irq(sub);
+   if (sub->cstream)
+   aiodma_compr_irq(sub);
+
+   ret = IRQ_HANDLED;
+   }
+   }
+
+   return ret;
+}
+
+static int uniphier_aiodma_open(struct snd_pcm_substream *substream)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+
+   snd_soc_set_runtime_hwparams(substream, &uniphier_aiodma_hw);
+
+   r

[PATCH v2 8/9] arm64: dts: uniphier: add speaker out for UniPhier LD11/LD20 boards

[Katsuhiro Suzuki]

This patch adds codec node for TI TAS571x on UniPhier LD11/20
global boards. And adds settings of AIO for speaker out.

Signed-off-by: Katsuhiro Suzuki 
---
 .../boot/dts/socionext/uniphier-ld11-global.dts  | 20 
 .../boot/dts/socionext/uniphier-ld20-global.dts  | 20 
 2 files changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index 4eb8d00a8c02..ca09251a3eab 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 #include "uniphier-ld11.dtsi"
+#include "dt-bindings/gpio/uniphier-gpio.h"
 
 / {
model = "UniPhier LD11 Global Board (REF_LD11_GP)";
@@ -45,6 +46,7 @@
widgets = "Headphone", "Headphone Jack";
 
dais = <&i2s_port2
+   &i2s_port3
&i2s_port4
&spdif_port0>;
};
@@ -73,6 +75,20 @@
 &i2c0 {
status = "okay";
 
+   tas5707a@1d {
+   compatible = "ti,tas5711";
+   reg = <0x1d>;
+   reset-gpios = <&gpio UNIPHIER_GPIO_PORT(23, 4) GPIO_ACTIVE_LOW>;
+   pdn-gpios = <&gpio UNIPHIER_GPIO_PORT(23, 5) GPIO_ACTIVE_LOW>;
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   tas_speaker: endpoint {
+   remote-endpoint = <&i2s_hpcmout1>;
+   };
+   };
+   };
+
eeprom@50 {
compatible = "st,24c64", "atmel,24c64";
reg = <0x50>;
@@ -109,17 +125,21 @@
 
i2s_port2: port@2 {
i2s_line: endpoint {
+   dai-format = "i2s";
remote-endpoint = <&evea_line>;
};
};
 
i2s_port3: port@3 {
i2s_hpcmout1: endpoint {
+   dai-format = "i2s";
+   remote-endpoint = <&tas_speaker>;
};
};
 
i2s_port4: port@4 {
i2s_pcmout3: endpoint {
+   dai-format = "i2s";
remote-endpoint = <&evea_hp>;
};
};
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index ebcd65631bca..0728832ce552 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -10,6 +10,7 @@
 
 /dts-v1/;
 #include "uniphier-ld20.dtsi"
+#include "dt-bindings/gpio/uniphier-gpio.h"
 
 / {
model = "UniPhier LD20 Global Board (REF_LD20_GP)";
@@ -45,6 +46,7 @@
widgets = "Headphone", "Headphone Jack";
 
dais = <&i2s_port2
+   &i2s_port3
&i2s_port4
&spdif_port0>;
};
@@ -72,6 +74,20 @@
 
 &i2c0 {
status = "okay";
+
+   tas5707@1b {
+   compatible = "ti,tas5711";
+   reg = <0x1b>;
+   reset-gpios = <&gpio UNIPHIER_GPIO_PORT(0, 0) GPIO_ACTIVE_LOW>;
+   pdn-gpios = <&gpio UNIPHIER_GPIO_PORT(0, 1) GPIO_ACTIVE_LOW>;
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   tas_speaker: endpoint {
+   remote-endpoint = <&i2s_hpcmout1>;
+   };
+   };
+   };
 };
 
 &nand {
@@ -91,17 +107,21 @@
 
i2s_port2: port@2 {
i2s_line: endpoint {
+   dai-format = "i2s";
remote-endpoint = <&evea_line>;
};
};
 
i2s_port3: port@3 {
i2s_hpcmout1: endpoint {
+   dai-format = "i2s";
+   remote-endpoint = <&tas_speaker>;
};
};
 
i2s_port4: port@4 {
i2s_pcmout3: endpoint {
+   dai-format = "i2s";
remote-endpoint = <&evea_hp>;
};
};
-- 
2.15.0

[PATCH v2 2/9] ASoC: uniphier: add support for UniPhier AIO common driver

[Katsuhiro Suzuki]

This patch adds common functions for UniPhier AIO audio sound
system. This provides commonly used APIs for input/output control
registers for UniPhier AIO.

This module provides all sound devices for I2S, S/PDIF and so on.
Since the AIO has mixed register map for those I/Os, it is hard
to split register areas for each sound devices.

Signed-off-by: Katsuhiro Suzuki 

---

Changes in v2:
  - Change license comment style to C++ from C
  - Split DMA, DAI patches from large one
  - Fix bad name 'srcport' to 'src'
  - Add members to struct uniphier_aio_sub and add methods
for compress audio
  - Change to void if function has no fail
---
 sound/soc/uniphier/Kconfig|   10 +
 sound/soc/uniphier/Makefile   |4 +
 sound/soc/uniphier/aio-core.c | 1104 +
 sound/soc/uniphier/aio-reg.h  |  462 +
 sound/soc/uniphier/aio.h  |  343 +
 5 files changed, 1923 insertions(+)
 create mode 100644 sound/soc/uniphier/aio-core.c
 create mode 100644 sound/soc/uniphier/aio-reg.h
 create mode 100644 sound/soc/uniphier/aio.h

diff --git a/sound/soc/uniphier/Kconfig b/sound/soc/uniphier/Kconfig
index 02886a457eaf..78ce101d2cc2 100644
--- a/sound/soc/uniphier/Kconfig
+++ b/sound/soc/uniphier/Kconfig
@@ -8,6 +8,16 @@ config SND_SOC_UNIPHIER
  audio interfaces to support below.
  If unsure select "N".
 
+config SND_SOC_UNIPHIER_AIO
+   tristate "UniPhier AIO DAI Driver"
+   select REGMAP_MMIO
+   depends on SND_SOC_UNIPHIER
+   help
+ This adds ASoC driver support for Socionext UniPhier
+ 'AIO' Audio Input/Output subsystem.
+ Select Y if you use such device.
+ If unsure select "N".
+
 config SND_SOC_UNIPHIER_EVEA_CODEC
tristate "UniPhier SoC internal audio codec"
depends on SND_SOC_UNIPHIER
diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
index 3be00d72f5e5..f3b36aba4879 100644
--- a/sound/soc/uniphier/Makefile
+++ b/sound/soc/uniphier/Makefile
@@ -1,3 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
+snd-soc-uniphier-aio-cpu-objs := aio-core.o
+
+obj-$(CONFIG_SND_SOC_UNIPHIER_AIO) += snd-soc-uniphier-aio-cpu.o
+
 snd-soc-uniphier-evea-objs := evea.o
 obj-$(CONFIG_SND_SOC_UNIPHIER_EVEA_CODEC) += snd-soc-uniphier-evea.o
diff --git a/sound/soc/uniphier/aio-core.c b/sound/soc/uniphier/aio-core.c
new file mode 100644
index ..7e9451ca24af
--- /dev/null
+++ b/sound/soc/uniphier/aio-core.c
@@ -0,0 +1,1104 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext UniPhier AIO ALSA common driver.
+//
+// Copyright (c) 2016-2018 Socionext Inc.
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License
+// as published by the Free Software Foundation; version 2
+// of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, see .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aio.h"
+#include "aio-reg.h"
+
+static u64 rb_cnt(u64 wr, u64 rd, u64 len)
+{
+   if (rd <= wr)
+   return wr - rd;
+   else
+   return len - (rd - wr);
+}
+
+static u64 rb_cnt_to_end(u64 wr, u64 rd, u64 len)
+{
+   if (rd <= wr)
+   return wr - rd;
+   else
+   return len - rd;
+}
+
+static u64 rb_space(u64 wr, u64 rd, u64 len)
+{
+   if (rd <= wr)
+   return len - (wr - rd) - 8;
+   else
+   return rd - wr - 8;
+}
+
+static u64 rb_space_to_end(u64 wr, u64 rd, u64 len)
+{
+   if (rd > wr)
+   return rd - wr - 8;
+   else if (rd > 0)
+   return len - wr;
+   else
+   return len - wr - 8;
+}
+
+u64 aio_rb_cnt(struct uniphier_aio_sub *sub)
+{
+   return rb_cnt(sub->wr_offs, sub->rd_offs, sub->compr_bytes);
+}
+
+u64 aio_rbt_cnt_to_end(struct uniphier_aio_sub *sub)
+{
+   return rb_cnt_to_end(sub->wr_offs, sub->rd_offs, sub->compr_bytes);
+}
+
+u64 aio_rb_space(struct uniphier_aio_sub *sub)
+{
+   return rb_space(sub->wr_offs, sub->rd_offs, sub->compr_bytes);
+}
+
+u64 aio_rb_space_to_end(struct uniphier_aio_sub *sub)
+{
+   return rb_space_to_end(sub->wr_offs, sub->rd_offs, sub->compr_bytes);
+}
+
+/**
+ * aio_chip_set_pll - set frequency to audio PLL
+ * @chip  : the AIO chip pointer
+ * @source: PLL
+ * @freq  : frequency in Hz, 0 is ignored
+ *
+ * Sets frequency of audio PLL. This function can be called anytime,
+ * but it takes time till PLL is locked.
+ *
+ * Return: Zero if successful, otherwise a negative value on error.
+ */
+int aio_chip_set_pll(struct u

[PATCH v2 6/9] ASoC: uniphier: add support for UniPhier LD11/LD20 AIO driver

[Katsuhiro Suzuki]

This patch adds support for UniPhier AIO sound driver
which is included in UniPhier LD11/LD20 SoCs.

Signed-off-by: Katsuhiro Suzuki 

---

Changes in v2:
  - Change license comment style to C++ from C
  - Expose clocking to userspace
  - Add settings for compress audio
---
 sound/soc/uniphier/Kconfig|  11 ++
 sound/soc/uniphier/Makefile   |   2 +
 sound/soc/uniphier/aio-ld11.c | 431 ++
 3 files changed, 444 insertions(+)
 create mode 100644 sound/soc/uniphier/aio-ld11.c

diff --git a/sound/soc/uniphier/Kconfig b/sound/soc/uniphier/Kconfig
index 1a55ccebd8f5..5da545b9bf2a 100644
--- a/sound/soc/uniphier/Kconfig
+++ b/sound/soc/uniphier/Kconfig
@@ -19,6 +19,17 @@ config SND_SOC_UNIPHIER_AIO
  Select Y if you use such device.
  If unsure select "N".
 
+config SND_SOC_UNIPHIER_LD11
+   tristate "UniPhier LD11/LD20 Device Driver"
+   depends on SND_SOC_UNIPHIER
+   select SND_SOC_UNIPHIER_AIO
+   select SND_SOC_UNIPHIER_AIO_DMA
+   help
+ This adds ASoC driver for Socionext UniPhier LD11/LD20
+ input and output that can be used with other codecs.
+ Select Y if you use such device.
+ If unsure select "N".
+
 config SND_SOC_UNIPHIER_EVEA_CODEC
tristate "UniPhier SoC internal audio codec"
depends on SND_SOC_UNIPHIER
diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
index 4448175c70ab..587a89700950 100644
--- a/sound/soc/uniphier/Makefile
+++ b/sound/soc/uniphier/Makefile
@@ -1,7 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
 snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o aio-cpu.o aio-compress.o
+snd-soc-uniphier-aio-ld11-objs := aio-ld11.o
 
 obj-$(CONFIG_SND_SOC_UNIPHIER_AIO) += snd-soc-uniphier-aio-cpu.o
+obj-$(CONFIG_SND_SOC_UNIPHIER_LD11) += snd-soc-uniphier-aio-ld11.o
 
 snd-soc-uniphier-evea-objs := evea.o
 obj-$(CONFIG_SND_SOC_UNIPHIER_EVEA_CODEC) += snd-soc-uniphier-evea.o
diff --git a/sound/soc/uniphier/aio-ld11.c b/sound/soc/uniphier/aio-ld11.c
new file mode 100644
index ..8e40e6c2e42f
--- /dev/null
+++ b/sound/soc/uniphier/aio-ld11.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext UniPhier AIO ALSA driver for LD11/LD20.
+//
+// Copyright (c) 2016-2018 Socionext Inc.
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License
+// as published by the Free Software Foundation; version 2
+// of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, see .
+
+#include 
+
+#include "aio.h"
+
+static const struct uniphier_aio_spec uniphier_aio_ld11[] = {
+   /* for HDMI PCM In, Pin:AI1Dx */
+   {
+   .name = AUD_NAME_PCMIN1,
+   .gname = AUD_GNAME_HDMI,
+   .swm = {
+   .type  = PORT_TYPE_I2S,
+   .dir   = PORT_DIR_INPUT,
+   .rb= { 21, 14, },
+   .ch= { 21, 14, },
+   .iif   = { 5, 3, },
+   .iport = { 0, AUD_HW_PCMIN1, },
+   },
+   },
+
+   /* for SIF In, Pin:AI2Dx */
+   {
+   .name = AUD_NAME_PCMIN2,
+   .swm = {
+   .type  = PORT_TYPE_I2S,
+   .dir   = PORT_DIR_INPUT,
+   .rb= { 22, 15, },
+   .ch= { 22, 15, },
+   .iif   = { 6, 4, },
+   .iport = { 1, AUD_HW_PCMIN2, },
+   },
+   },
+
+   /* for Line In, Pin:AI3Dx */
+   {
+   .name = AUD_NAME_PCMIN3,
+   .gname = AUD_GNAME_LINE,
+   .swm = {
+   .type  = PORT_TYPE_EVE,
+   .dir   = PORT_DIR_INPUT,
+   .rb= { 23, 16, },
+   .ch= { 23, 16, },
+   .iif   = { 7, 5, },
+   .iport = { 2, AUD_HW_PCMIN3, },
+   },
+   },
+
+   /* for S/PDIF In, Pin:AI1IEC */
+   {
+   .name = AUD_NAME_IECIN1,
+   .gname = AUD_GNAME_IEC,
+   .swm = {
+   .type  = PORT_TYPE_SPDIF,
+   .dir   = PORT_DIR_INPUT,
+   .rb= { 26, 17, },
+   .ch= { 26, 17, },
+   .iif   = { 10, 6, },
+   .iport = { 3, AUD_HW_IECIN1, },
+   },
+   },
+
+   /* for Speaker, Pin:AO1Dx */
+   {
+   .name = AUD_NAME_HPCMOUT1,
+   .swm = {
+

[PATCH v2 5/9] ASoC: uniphier: add support for UniPhier AIO compress audio

[Katsuhiro Suzuki]

This patch adds support of UniPhier AIO compress audio.
For passing through compress audio to S/PDIF.

Signed-off-by: Katsuhiro Suzuki 
---
 sound/soc/uniphier/Kconfig|   1 +
 sound/soc/uniphier/Makefile   |   2 +-
 sound/soc/uniphier/aio-compress.c | 440 ++
 sound/soc/uniphier/aio-dma.c  |   1 +
 sound/soc/uniphier/aio.h  |   1 +
 5 files changed, 444 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/uniphier/aio-compress.c

diff --git a/sound/soc/uniphier/Kconfig b/sound/soc/uniphier/Kconfig
index 78ce101d2cc2..1a55ccebd8f5 100644
--- a/sound/soc/uniphier/Kconfig
+++ b/sound/soc/uniphier/Kconfig
@@ -11,6 +11,7 @@ config SND_SOC_UNIPHIER
 config SND_SOC_UNIPHIER_AIO
tristate "UniPhier AIO DAI Driver"
select REGMAP_MMIO
+   select SND_SOC_COMPRESS
depends on SND_SOC_UNIPHIER
help
  This adds ASoC driver support for Socionext UniPhier
diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
index 3ef2784b2383..4448175c70ab 100644
--- a/sound/soc/uniphier/Makefile
+++ b/sound/soc/uniphier/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o aio-cpu.o
+snd-soc-uniphier-aio-cpu-objs := aio-core.o aio-dma.o aio-cpu.o aio-compress.o
 
 obj-$(CONFIG_SND_SOC_UNIPHIER_AIO) += snd-soc-uniphier-aio-cpu.o
 
diff --git a/sound/soc/uniphier/aio-compress.c 
b/sound/soc/uniphier/aio-compress.c
new file mode 100644
index ..7f7abe3ae99d
--- /dev/null
+++ b/sound/soc/uniphier/aio-compress.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Socionext UniPhier AIO Compress Audio driver.
+//
+// Copyright (c) 2017-2018 Socionext Inc.
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License
+// as published by the Free Software Foundation; version 2
+// of the License.
+//
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, see .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "aio.h"
+
+static int uniphier_aio_compr_prepare(struct snd_compr_stream *cstream);
+static int uniphier_aio_compr_hw_free(struct snd_compr_stream *cstream);
+
+static int uniphier_aio_comprdma_new(struct snd_soc_pcm_runtime *rtd)
+{
+   struct snd_compr *compr = rtd->compr;
+   struct device *dev = compr->card->dev;
+   struct uniphier_aio *aio = uniphier_priv(rtd->cpu_dai);
+   struct uniphier_aio_sub *sub = &aio->sub[compr->direction];
+   size_t size = AUD_RING_SIZE;
+   int dma_dir = DMA_FROM_DEVICE, ret;
+
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(33));
+   if (ret)
+   return ret;
+
+   sub->compr_area = kzalloc(size, GFP_KERNEL);
+   if (!sub->compr_area)
+   return -ENOMEM;
+
+   if (sub->swm->dir == PORT_DIR_OUTPUT)
+   dma_dir = DMA_TO_DEVICE;
+
+   sub->compr_addr = dma_map_single(dev, sub->compr_area, size, dma_dir);
+   ret = dma_mapping_error(dev, sub->compr_addr);
+   if (ret) {
+   kfree(sub->compr_area);
+   sub->compr_area = NULL;
+
+   return ret;
+   }
+
+   sub->compr_bytes = size;
+
+   return 0;
+}
+
+static int uniphier_aio_comprdma_free(struct snd_soc_pcm_runtime *rtd)
+{
+   struct snd_compr *compr = rtd->compr;
+   struct device *dev = compr->card->dev;
+   struct uniphier_aio *aio = uniphier_priv(rtd->cpu_dai);
+   struct uniphier_aio_sub *sub = &aio->sub[compr->direction];
+   int dma_dir = DMA_FROM_DEVICE;
+
+   if (sub->swm->dir == PORT_DIR_OUTPUT)
+   dma_dir = DMA_TO_DEVICE;
+
+   dma_unmap_single(dev, sub->compr_addr, sub->compr_bytes, dma_dir);
+   kfree(sub->compr_area);
+   sub->compr_area = NULL;
+
+   return 0;
+}
+
+static int uniphier_aio_compr_open(struct snd_compr_stream *cstream)
+{
+   struct snd_soc_pcm_runtime *rtd = cstream->private_data;
+   struct uniphier_aio *aio = uniphier_priv(rtd->cpu_dai);
+   struct uniphier_aio_sub *sub = &aio->sub[cstream->direction];
+   int ret;
+
+   if (sub->cstream)
+   return -EBUSY;
+
+   sub->cstream = cstream;
+   sub->pass_through = 1;
+   sub->use_mmap = false;
+
+   ret = uniphier_aio_comprdma_new(rtd);
+   if (ret)
+   return ret;
+
+   ret = aio_init(sub);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int uniphier_aio_compr_free(struct snd_compr_stream *cstream)
+{
+   st

[PATCH] phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving VBUS

[Chen-Yu Tsai]

The AXP223 PMIC, like the AXP221, does not generate VBUS change
interrupts when N_VBUSEN is used to drive VBUS for the OTG port
on the board.

This was not noticed until recently, as most A23/A33 boards use
a GPIO pin that does not support interrupts for OTG ID detection.
This forces the driver to use polling. However the A33-OlinuXino
uses a pin that does support interrupts, so the driver uses them.
However the VBUS interrupt never fires, and the driver never gets
to update the VBUS status. This results in musb timing out waiting
for VBUS to rise.

This was worked around for the AXP221 by resorting to polling
changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for
missing Vbus det interrupts on A31"). This patch adds the A23 and
A33 to the list of SoCs that need the workaround.

Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the
  sun8i-a33 SoC")
Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the
  sun8i-a23 SoC")
Cc:  # 4.3.x: 68dbc2ce77bb phy-sun4i-usb:
Use of_match_node to get model specific config data
Cc:  # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb:
Fix optional gpios failing probe
Cc:  # 4.3.x: 04e59a0211ff phy-sun4i-usb:
Fix irq free conditions to match request conditions
Cc:  # 4.3.x: 91d96f06a760 phy-sun4i-usb:
Add workaround for missing Vbus det interrupts on A31
Cc:  # 4.3.x
Signed-off-by: Chen-Yu Tsai 
---

This list might get longer if the newer AXP8xx PMICs also have this
behavior. We could switch to a boolean in the per-compatible data,
or just always use polling. The yet-merged R40 support will have this
issue as well, as the R40 is paired with the AXP221. But for now,
I'd like to have something that is easier to backport to stable, so
we can at least fix this for the A23 and A33.

Also, checkpatch.pl doesn't like the stable kernel prerequisite lines.

---
 drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
b/drivers/phy/allwinner/phy-sun4i-usb.c
index aa857be692cf..d5ae307ef4e1 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -410,11 +410,13 @@ static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data 
*data)
return true;
 
/*
-* The A31 companion pmic (axp221) does not generate vbus change
-* interrupts when the board is driving vbus, so we must poll
+* The A31/A23/A33 companion pmics (AXP221/AXP223) do not
+* generate vbus change interrupts when the board is driving
+* vbus using the N_VBUSEN pin on the pmic, so we must poll
 * when using the pmic for vbus-det _and_ we're driving vbus.
 */
-   if (data->cfg->type == sun6i_a31_phy &&
+   if ((data->cfg->type == sun6i_a31_phy ||
+data->cfg->type == sun8i_a33_phy) &&
data->vbus_power_supply && data->phys[0].regulator_on)
return true;
 
@@ -885,7 +887,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
 
 static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.num_phys = 2,
-   .type = sun4i_a10_phy,
+   .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-- 
2.15.1

Re: [RFC] Per file OOM badness

[Michel Dänzer]

On 2018-01-19 09:39 AM, Christian König wrote:
> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
>> On Thu 18-01-18 12:01:32, Eric Anholt wrote:
>>> Michal Hocko  writes:
>>>
 On Thu 18-01-18 18:00:06, Michal Hocko wrote:
> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:
>> Hi, this series is a revised version of an RFC sent by Christian
>> König
>> a few years ago. The original RFC can be found at
>> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
>>
>>
>> This is the same idea and I've just adressed his concern from the
>> original RFC
>> and switched to a callback into file_ops instead of a new member
>> in struct file.
> Please add the full description to the cover letter and do not make
> people hunt links.
>
> Here is the origin cover letter text
> : I'm currently working on the issue that when device drivers
> allocate memory on
> : behalf of an application the OOM killer usually doesn't knew
> about that unless
> : the application also get this memory mapped into their address
> space.
> :
> : This is especially annoying for graphics drivers where a lot of
> the VRAM
> : usually isn't CPU accessible and so doesn't make sense to map
> into the
> : address space of the process using it.
> :
> : The problem now is that when an application starts to use a lot
> of VRAM those
> : buffers objects sooner or later get swapped out to system memory,
> but when we
> : now run into an out of memory situation the OOM killer obviously
> doesn't knew
> : anything about that memory and so usually kills the wrong process.
 OK, but how do you attribute that memory to a particular OOM killable
 entity? And how do you actually enforce that those resources get freed
 on the oom killer action?

> : The following set of patches tries to address this problem by
> introducing a per
> : file OOM badness score, which device drivers can use to give the
> OOM killer a
> : hint how many resources are bound to a file descriptor so that it
> can make
> : better decisions which process to kill.
 But files are not killable, they can be shared... In other words this
 doesn't help the oom killer to make an educated guess at all.
>>> Maybe some more context would help the discussion?
>>>
>>> The struct file in patch 3 is the DRM fd.  That's effectively "my
>>> process's interface to talking to the GPU" not "a single GPU resource".
>>> Once that file is closed, all of the process's private, idle GPU buffers
>>> will be immediately freed (this will be most of their allocations), and
>>> some will be freed once the GPU completes some work (this will be most
>>> of the rest of their allocations).
>>>
>>> Some GEM BOs won't be freed just by closing the fd, if they've been
>>> shared between processes.  Those are usually about 8-24MB total in a
>>> process, rather than the GBs that modern apps use (or that our testcases
>>> like to allocate and thus trigger oomkilling of the test harness instead
>>> of the offending testcase...)
>>>
>>> Even if we just had the private+idle buffers being accounted in OOM
>>> badness, that would be a huge step forward in system reliability.
>> OK, in that case I would propose a different approach. We already
>> have rss_stat. So why do not we simply add a new counter there
>> MM_KERNELPAGES and consider those in oom_badness? The rule would be
>> that such a memory is bound to the process life time. I guess we will
>> find more users for this later.
> 
> I already tried that and the problem with that approach is that some
> buffers are not created by the application which actually uses them.
> 
> For example X/Wayland is creating and handing out render buffers to
> application which want to use OpenGL.
> 
> So the result is when you always account the application who created the
> buffer the OOM killer will certainly reap X/Wayland first. And that is
> exactly what we want to avoid here.

FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
anymore. With DRI3 and Wayland, buffers are allocated by the clients and
then shared with the X / Wayland server.

Also, in all cases, the amount of memory allocated for buffers shared
between DRI/Wayland clients and the server should be relatively small
compared to the amount of memory allocated for buffers used only locally
in the client, particularly for clients which create significant memory
pressure.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build

[Niklas Cassel]

If CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y, the build fails with:

  drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate'
  undeclared here (not in a function)

When building drivers/pci/dwc/pci-dra7xx.c without CONFIG_PCI,
gcc is usually smart enough to realize that RC specific code
is unreachable and can thus be eliminated.

However, gcc cannot do this if there is a function that isn't
even declared.

Hence fix the issue by introducing a dummy for pci_irqd_intx_xlate().

Acked-by: Arnd Bergmann 
Acked-by: Lorenzo Pieralisi 
Signed-off-by: Niklas Cassel 
---
 include/linux/pci.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 83299833a6ce..41c676a011f4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1675,6 +1675,13 @@ static inline int pci_get_new_domain_nr(void) { return 
-ENOSYS; }
 #define dev_is_pf(d) (false)
 static inline bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
 { return false; }
+static inline int pci_irqd_intx_xlate(struct irq_domain *d,
+ struct device_node *node,
+ const u32 *intspec,
+ unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{ return -EINVAL; }
 #endif /* CONFIG_PCI */
 
 /* Include architecture-dependent settings and functions */
-- 
2.14.2

how to disable cache_firmware for specific driver/device

[Kassey]

hi, Ming Lei:
   is there any config/flag to disable cache_firmware for specific
driver/device ?
-- 
Best regards
Kassey

Re: how to disable cache_firmware for specific driver/device

[Kassey]

add correct email for Ming Lei

On Fri, Jan 19, 2018 at 5:39 PM, Kassey  wrote:
> hi, Ming Lei:
>is there any config/flag to disable cache_firmware for specific
> driver/device ?
> --
> Best regards
> Kassey



-- 
Best regards
Kassey

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Christophe LEROY]

Le 19/01/2018 à 10:13, Aneesh Kumar K.V a écrit :



On 01/19/2018 02:37 PM, Christophe LEROY wrote:



Le 19/01/2018 à 10:02, Aneesh Kumar K.V a écrit :



On 01/19/2018 02:14 PM, Christophe LEROY wrote:



Le 19/01/2018 à 09:24, Aneesh Kumar K.V a écrit :

Christophe Leroy  writes:


In preparation for the following patch which will fix an issue on
the 8xx by re-using the 'slices', this patch enhances the
'slices' implementation to support 32 bits CPUs.

On PPC32, the address space is limited to 4Gbytes, hence only the low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.

This patch moves "slices" functions prototypes from page64.h to 
page.h


The high slices use bitmaps. As bitmap functions are not prepared to
handling bitmaps of size 0, the bitmap_xxx() calls are wrapped into
slice_bitmap_xxx() macros which will take care of the 0 nbits case.

Signed-off-by: Christophe Leroy 
---
  v2: First patch of v1 serie split in two parts ; added 
slice_bitmap_xxx() macros.


  arch/powerpc/include/asm/page.h  | 14 +
  arch/powerpc/include/asm/page_32.h   | 19 
  arch/powerpc/include/asm/page_64.h   | 21 ++---
  arch/powerpc/mm/hash_utils_64.c  |  2 +-
  arch/powerpc/mm/mmu_context_nohash.c |  7 +
  arch/powerpc/mm/slice.c  | 60 


  6 files changed, 83 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h 
b/arch/powerpc/include/asm/page.h

index 8da5d4c1cab2..d0384f9db9eb 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -342,6 +342,20 @@ typedef struct page *pgtable_t;
  #endif
  #endif
+#ifdef CONFIG_PPC_MM_SLICES
+struct mm_struct;
+
+unsigned long slice_get_unmapped_area(unsigned long addr, 
unsigned long len,

+  unsigned long flags, unsigned int psize,
+  int topdown);
+
+unsigned int get_slice_psize(struct mm_struct *mm, unsigned long 
addr);

+
+void slice_set_user_psize(struct mm_struct *mm, unsigned int psize);
+void slice_set_range_psize(struct mm_struct *mm, unsigned long 
start,

+   unsigned long len, unsigned int psize);
+#endif
+


Should we do a slice.h ? the way we have other files? and then do


Yes we could add a slice.h instead of using page.h for that, good idea.



arch/powerpc/include/asm/book3s/64/slice.h that will carry
#define slice_bitmap_zero(dst, nbits) \
do { if (nbits) bitmap_zero(dst, nbits); } while (0)
#define slice_bitmap_set(dst, pos, nbits) \
do { if (nbits) bitmap_set(dst, pos, nbits); } while (0)
#define slice_bitmap_copy(dst, src, nbits) \
do { if (nbits) bitmap_copy(dst, src, nbits); } while (0)
#define slice_bitmap_and(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_and(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_or(dst, src1, src2, nbits) \
do { if (nbits) bitmap_or(dst, src1, src2, nbits); } while (0)
#define slice_bitmap_andnot(dst, src1, src2, nbits) \
({ (nbits) ? bitmap_andnot(dst, src1, src2, nbits) : 0; })
#define slice_bitmap_equal(src1, src2, nbits) \
({ (nbits) ? bitmap_equal(src1, src2, nbits) : 1; })
#define slice_bitmap_empty(src, nbits) \
({ (nbits) ? bitmap_empty(src, nbits) : 1; })

This without that if(nbits) check and a proper static inline so 
that we

can do type checking.


Is it really worth duplicating that just for eliminating the 'if 
(nbits)' in one case ?


Only in book3s/64 we will be able to eliminate that, for nohash/32 
we need to keep the test due to the difference between low and high 
slices.


the other advantage is we move the SLICE_LOW_SHIFT to the right 
location. IMHO mm subystem is really complex with these really 
overloaded headers. If we can keep it  seperate we should with 
minimal code duplication?


For the constants I fully agree with your proposal and I will do it. I 
was only questionning the benefit of moving the slice_bitmap_() 
stuff, taking into account that the 'if (nbits)' test is already 
eliminated by the compiler.




That is compiler dependent as you are finding with the other patch where 
if (0) didn't get compiled out


I don't think so. When I had the missing prototype, the compilation goes 
ok, including the final link. Which means at the end the code is not 
included since radix_enabled() evaluates to 0.


Many many parts of the kernel are based on this assumption.

Christophe



-aneesh

Re: [PATCH] print kdump kernel loaded status in stack dump

[Sergey Senozhatsky]

On (01/19/18 16:42), Dave Young wrote:
[..]
> > [I'm not entirely sure I see why do we have printk_delay() in
> >vprintk_emit()... I mean I probably can see some reasoning behind
> >it, but at the same it makes sense to slow down console_unlock()
> >as well]
> 
> Looks like I am the guy who added the code :)

LOL :)

> Actually no special reason, just did not thinking about the performance
> issue at all at that time..

it's quite reasonable to have it in vprintk_emit(), actually.

the thing is that it limits the rate at which new messages appear in
the kernel log buffer, which does not necessarily correspond to the rate
at which new messages appear on the consoles.

printk has a "direct path"  printk -> console_unlock() -> consoles,
and "indirect path" - when it fails to acquire console semaphore,
because it's locked by someone else. that someone else, a console_sem
owner, might be scheduled out under console_sem; all printks in the
meantime will just log_store() messages [after printk_delay()].
once the console_sem owner will be back to running it will resume
console_unlock() printing loop and print out all pending messages
immediately [modulo preemption]. so there are ways for messages to
bypass printk_delay() and appear on the consoles with no visible
delay.

additionally printk_delay() does touch_nmi_watchdog() so we,
technically, are fine with moving it to console_unlock().

-ss

RE: [RFC v2 1/5] vfio/type1: Introduce iova list and add iommu aperture validity check

[Shameerali Kolothum Thodi]

Hi Alex,

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 18, 2018 12:05 AM
> To: Shameerali Kolothum Thodi 
> Cc: eric.au...@redhat.com; pmo...@linux.vnet.ibm.com;
> k...@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> ; John Garry ; xuwei (O)
> 
> Subject: Re: [RFC v2 1/5] vfio/type1: Introduce iova list and add iommu
> aperture validity check
> 
> On Fri, 12 Jan 2018 16:45:27 +
> Shameer Kolothum  wrote:
> 
> > This introduces an iova list that is valid for dma mappings. Make
> > sure the new iommu aperture window is valid and doesn't conflict
> > with any existing dma mappings during attach. Also update the iova
> > list with new aperture window during attach/detach.
> >
> > Signed-off-by: Shameer Kolothum 
> > ---
> >  drivers/vfio/vfio_iommu_type1.c | 177
> 
> >  1 file changed, 177 insertions(+)
> >
> > diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> > index e30e29a..11cbd49 100644
> > --- a/drivers/vfio/vfio_iommu_type1.c
> > +++ b/drivers/vfio/vfio_iommu_type1.c
> > @@ -60,6 +60,7 @@
> >
> >  struct vfio_iommu {
> > struct list_headdomain_list;
> > +   struct list_headiova_list;
> > struct vfio_domain  *external_domain; /* domain for external user
> */
> > struct mutexlock;
> > struct rb_root  dma_list;
> > @@ -92,6 +93,12 @@ struct vfio_group {
> > struct list_headnext;
> >  };
> >
> > +struct vfio_iova {
> > +   struct list_headlist;
> > +   phys_addr_t start;
> > +   phys_addr_t end;
> > +};
> 
> dma_list uses dma_addr_t for the iova.  IOVAs are naturally DMA
> addresses, why are we using phys_addr_t?

Ok. I will change that to dma_addr_t.

> > +
> >  /*
> >   * Guest RAM pinning working set or DMA target
> >   */
> > @@ -1192,6 +1199,123 @@ static bool vfio_iommu_has_sw_msi(struct
> iommu_group *group, phys_addr_t *base)
> > return ret;
> >  }
> >
> > +static int vfio_insert_iova(phys_addr_t start, phys_addr_t end,
> > +   struct list_head *head)
> > +{
> > +   struct vfio_iova *region;
> > +
> > +   region = kmalloc(sizeof(*region), GFP_KERNEL);
> > +   if (!region)
> > +   return -ENOMEM;
> > +
> > +   INIT_LIST_HEAD(®ion->list);
> > +   region->start = start;
> > +   region->end = end;
> > +
> > +   list_add_tail(®ion->list, head);
> > +   return 0;
> > +}
> 
> As I'm reading through this series, I'm learning that there are a lot
> of assumptions and subtle details that should be documented.  For
> instance, the IOMMU API only provides a single geometry and we build
> upon that here as this patch creates a list, but there's only a single
> entry for now.  The following patches carve that single iova range into
> pieces and somewhat subtly use the list_head passed to keep the list
> sorted, allowing the first/last_entry tricks used throughout.  Subtle
> interfaces are prone to bugs.

Agree. The iova list management logic needs to be documented properly.
I will address this in next revision.

> > +
> > +/*
> > + * Find whether a mem region overlaps with existing dma mappings
> > + */
> > +static bool vfio_find_dma_overlap(struct vfio_iommu *iommu,
> > + phys_addr_t start, phys_addr_t end)
> > +{
> > +   struct rb_node *n = rb_first(&iommu->dma_list);
> > +
> > +   for (; n; n = rb_next(n)) {
> > +   struct vfio_dma *dma;
> > +
> > +   dma = rb_entry(n, struct vfio_dma, node);
> > +
> > +   if (end < dma->iova)
> > +   break;
> > +   if (start >= dma->iova + dma->size)
> > +   continue;
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> 
> Why do we need this in addition to the existing vfio_find_dma()?  Why
> doesn't this use the tree structure of the dma_list?

Ok. I will take a look at the vfio_find_dma().

> > +
> > +/*
> > + * Check the new iommu aperture is a valid one
> > + */
> > +static int vfio_iommu_valid_aperture(struct vfio_iommu *iommu,
> > +phys_addr_t start,
> > +phys_addr_t end)
> > +{
> > +   struct vfio_iova *first, *last;
> > +   struct list_head *iova = &iommu->iova_list;
> > +
> > +   if (list_empty(iova))
> > +   return 0;
> > +
> > +   /* Check if new one is outside the current aperture */
> 
> "Disjoint sets"
> 
> > +   first = list_first_entry(iova, struct vfio_iova, list);
> > +   last = list_last_entry(iova, struct vfio_iova, list);
> > +   if ((start > last->end) || (end < first->start))
> > +   return -EINVAL;
> > +
> > +   /* Check for any existing dma mappings outside the new start */
> > +   if (start > first->start) {
> > +   if (vfio_find_dma_overlap(iommu, first->start, start - 1))
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* Check for any existing 

RE: [RFC v2 2/5] vfio/type1: Check reserve region conflict and update iova list

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, January 18, 2018 12:05 AM
> To: Shameerali Kolothum Thodi 
> Cc: eric.au...@redhat.com; pmo...@linux.vnet.ibm.com;
> k...@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm
> ; John Garry ; xuwei (O)
> 
> Subject: Re: [RFC v2 2/5] vfio/type1: Check reserve region conflict and update
> iova list
> 
> On Fri, 12 Jan 2018 16:45:28 +
> Shameer Kolothum  wrote:
> 
> > This retrieves the reserved regions associated with dev group and
> > checks for conflicts with any existing dma mappings. Also update
> > the iova list excluding the reserved regions.
> >
> > Signed-off-by: Shameer Kolothum 
> > ---
> >  drivers/vfio/vfio_iommu_type1.c | 161
> +++-
> >  1 file changed, 159 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> > index 11cbd49..7609070 100644
> > --- a/drivers/vfio/vfio_iommu_type1.c
> > +++ b/drivers/vfio/vfio_iommu_type1.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1199,6 +1200,20 @@ static bool vfio_iommu_has_sw_msi(struct
> iommu_group *group, phys_addr_t *base)
> > return ret;
> >  }
> >
> 
> /* list_sort helper */
> 
> > +static int vfio_resv_cmp(void *priv, struct list_head *a, struct list_head 
> > *b)
> > +{
> > +   struct iommu_resv_region *ra, *rb;
> > +
> > +   ra = container_of(a, struct iommu_resv_region, list);
> > +   rb = container_of(b, struct iommu_resv_region, list);
> > +
> > +   if (ra->start < rb->start)
> > +   return -1;
> > +   if (ra->start > rb->start)
> > +   return 1;
> > +   return 0;
> > +}
> > +
> >  static int vfio_insert_iova(phys_addr_t start, phys_addr_t end,
> > struct list_head *head)
> >  {
> > @@ -1274,6 +1289,24 @@ static int vfio_iommu_valid_aperture(struct
> vfio_iommu *iommu,
> >  }
> >
> >  /*
> > + * Check reserved region conflicts with existing dma mappings
> > + */
> > +static int vfio_iommu_resv_region_conflict(struct vfio_iommu *iommu,
> > +   struct list_head *resv_regions)
> > +{
> > +   struct iommu_resv_region *region;
> > +
> > +   /* Check for conflict with existing dma mappings */
> > +   list_for_each_entry(region, resv_regions, list) {
> > +   if (vfio_find_dma_overlap(iommu, region->start,
> > +   region->start + region->length - 1))
> > +   return -EINVAL;
> > +   }
> > +
> > +   return 0;
> > +}
> 
> This basically does the same test as vfio_iommu_valid_aperture but
> properly names it a conflict test.  Please be consistent.  Should this
> also return bool, "conflict" is a yes/no answer.

Ok.
 
> > +
> > +/*
> >   * Adjust the iommu aperture window if new aperture is a valid one
> >   */
> >  static int vfio_iommu_iova_aper_adjust(struct vfio_iommu *iommu,
> > @@ -1316,6 +1349,51 @@ static int vfio_iommu_iova_aper_adjust(struct
> vfio_iommu *iommu,
> > return 0;
> >  }
> >
> > +/*
> > + * Check and update iova region list in case a reserved region
> > + * overlaps the iommu iova range
> > + */
> > +static int vfio_iommu_iova_resv_adjust(struct vfio_iommu *iommu,
> > +   struct list_head *resv_regions)
> 
> "resv_region" in previous function, just "resv" here, use consistent
> names.  Also, what are we adjusting.  Maybe "exclude" is a better term.

Ok.

> > +{
> > +   struct iommu_resv_region *resv;
> > +   struct list_head *iova = &iommu->iova_list;
> > +   struct vfio_iova *n, *next;
> > +
> > +   list_for_each_entry(resv, resv_regions, list) {
> > +   phys_addr_t start, end;
> > +
> > +   start = resv->start;
> > +   end = resv->start + resv->length - 1;
> > +
> > +   list_for_each_entry_safe(n, next, iova, list) {
> > +   phys_addr_t a, b;
> > +   int ret = 0;
> > +
> > +   a = n->start;
> > +   b = n->end;
> 
> 'a' and 'b' variables actually make this incredibly confusing.  Use
> better variable names or just drop them entirely, it's much easier to
> follow as n->start & n->end.

I will drop the name and go with  n->start & n->end.
 
> > +   /* No overlap */
> > +   if ((start > b) || (end < a))
> > +   continue;
> > +   /* Split the current node and create holes */
> > +   if (start > a)
> > +   ret = vfio_insert_iova(a, start - 1, &n->list);
> > +   if (!ret && end < b)
> > +   ret = vfio_insert_iova(end + 1, b, &n->list);
> > +   if (ret)
> > +   return ret;
> > +
> > +   list_del(&n->list);
> 
> This is trickier than it appears and deserves some explanation.  AIUI,
>

Re: [PATCH V5 1/2] nvme-pci: introduce RECONNECTING state to mark initializing procedure

[jianchao.wang]

Hi Max

Thanks for your kindly comment and response.

On 01/18/2018 06:17 PM, Max Gurtovoy wrote:
> 
> On 1/18/2018 12:10 PM, Jianchao Wang wrote:
>> After Sagi's commit (nvme-rdma: fix concurrent reset and reconnect),
>> both nvme-fc/rdma have following pattern:
>> RESETTING    - quiesce blk-mq queues, teardown and delete queues/
>>     connections, clear out outstanding IO requests...
>> RECONNECTING - establish new queues/connections and some other
>>     initializing things.
> 
> I guess we can call it NVME_CTRL_CONNECTING in later patch (more suitable 
> name for this state now).

I think we can change the name in another patchset in which just talk about the 
more suitable names of the states.
:)
Thanks
Jianchao

Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

[Sergey Senozhatsky]

On (01/17/18 20:13), Rasmus Villemoes wrote:
[..]
> >> Hmm, how does one have git commit not remove the C preprocessor at the
> >> start of the module?
> > 
> > Probably just add a space in front of the entire program.
> 
> If you use at least git 2.0.0 [1], set commit.cleanup to "scissors".
> Something like
> 
>   git config commit.cleanup scissors
> 
> should do the trick. Instead of stripping all lines starting with #,
> that will only strip stuff below a line containing
> 
> #  >8 

one thing that it changes is that now when you squash commits


# This is the first patch

first patch commit messages

# This is the second patch

second patch commit message

#  >8 



those "# This is the first patch" and "# This is the second patch"
won't be removed automatically. takes some time to get used to it.

-ss

Re: [PATCH 5/5] crypto: ahash.c: Require export/import in ahash

[Kamil Konieczny]

On 18.01.2018 22:31, Marek Vasut wrote:
> On 01/18/2018 07:34 PM, Kamil Konieczny wrote:
>> Export and import are mandatory in async hash. As drivers were
>> rewritten, drop empty wrappers and correct init of ahash transformation.
> 
> Are you moving checks from the core subsystem to drivers ? This looks
> really nonsensical and the commit message doesn't explain the rationale
> for that at all.

I am removing checks from core. Export and import were optional in beginnig
of crypto framework, but as time goes on they become mandatory.

> 
>> Signed-off-by: Kamil Konieczny 
>> ---
>>  crypto/ahash.c | 18 ++
>>  1 file changed, 2 insertions(+), 16 deletions(-)
>>
>> diff --git a/crypto/ahash.c b/crypto/ahash.c
>> index 3a35d67de7d9..c3cce508c1d4 100644
>> --- a/crypto/ahash.c
>> +++ b/crypto/ahash.c
>> @@ -434,16 +434,6 @@ static int ahash_def_finup(struct ahash_request *req)
>>  return ahash_def_finup_finish1(req, err);
>>  }
>>  
>> -static int ahash_no_export(struct ahash_request *req, void *out)
>> -{
>> -return -ENOSYS;
>> -}
>> -
>> -static int ahash_no_import(struct ahash_request *req, const void *in)
>> -{
>> -return -ENOSYS;
>> -}
>> -
>>  static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
>>  {
>>  struct crypto_ahash *hash = __crypto_ahash_cast(tfm);
>> @@ -451,8 +441,6 @@ static int crypto_ahash_init_tfm(struct crypto_tfm *tfm)
>>  
>>  hash->setkey = ahash_nosetkey;
>>  hash->has_setkey = false;
>> -hash->export = ahash_no_export;
>> -hash->import = ahash_no_import;
>>  
>>  if (tfm->__crt_alg->cra_type != &crypto_ahash_type)
>>  return crypto_init_shash_ops_async(tfm);
>> @@ -462,15 +450,13 @@ static int crypto_ahash_init_tfm(struct crypto_tfm 
>> *tfm)
>>  hash->final = alg->final;
>>  hash->finup = alg->finup ?: ahash_def_finup;
>>  hash->digest = alg->digest;
>> +hash->export = alg->export;
>> +hash->import = alg->import;
>>  
>>  if (alg->setkey) {
>>  hash->setkey = alg->setkey;
>>  hash->has_setkey = true;
>>  }
>> -if (alg->export)
>> -hash->export = alg->export;
>> -if (alg->import)
>> -hash->import = alg->import;
>>  
>>  return 0;
>>  }
>>
> 
> 

-- 
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland

Re: [PATCH net-next v2] net: stmmac: Fix reception of Broadcom switches tags

[Giuseppe CAVALLARO]

On 1/19/2018 12:12 AM, Florian Fainelli wrote:

Broadcom tags inserted by Broadcom switches put a 4 byte header after
the MAC SA and before the EtherType, which may look like some sort of 0
length LLC/SNAP packet (tcpdump and wireshark do think that way). With
ACS enabled in stmmac the packets were truncated to 8 bytes on
reception, whereas clearing this bit allowed normal reception to occur.

In order to make that possible, we need to pass a net_device argument to
the different core_init() functions and we are dependent on the Broadcom
tagger padding packets correctly (which it now does). To be as little
invasive as possible, this is only done for gmac1000 when the network
device is DSA-enabled (netdev_uses_dsa() returns true).

Signed-off-by: Florian Fainelli 


Acked-by: Giuseppe Cavallaro 


---
Changes in v2:

- fixed build failure in dwmac4_core.c
- updated dwmac100_core.c to also clear the ASTP bit

  drivers/net/ethernet/stmicro/stmmac/common.h |  2 +-
  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c|  3 ++-
  drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 12 +++-
  drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c  | 15 +--
  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c| 12 +++-
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c|  2 +-
  6 files changed, 39 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index ce2ea2d491ac..2ffe76c0ff74 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -474,7 +474,7 @@ struct mac_device_info;
  /* Helpers to program the MAC core */
  struct stmmac_ops {
/* MAC core initialization */
-   void (*core_init)(struct mac_device_info *hw, int mtu);
+   void (*core_init)(struct mac_device_info *hw, struct net_device *dev);
/* Enable the MAC RX/TX */
void (*set_mac)(void __iomem *ioaddr, bool enable);
/* Enable and verify that the IPC module is supported */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 9eb7f65d8000..a3fa65b1ca8e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -483,7 +483,8 @@ static int sun8i_dwmac_init(struct platform_device *pdev, 
void *priv)
return 0;
  }
  
-static void sun8i_dwmac_core_init(struct mac_device_info *hw, int mtu)

+static void sun8i_dwmac_core_init(struct mac_device_info *hw,
+ struct net_device *dev)
  {
void __iomem *ioaddr = hw->pcsr;
u32 v;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 8a86340ff2d3..540d21786a43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -25,18 +25,28 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "stmmac_pcs.h"
  #include "dwmac1000.h"
  
-static void dwmac1000_core_init(struct mac_device_info *hw, int mtu)

+static void dwmac1000_core_init(struct mac_device_info *hw,
+   struct net_device *dev)
  {
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + GMAC_CONTROL);
+   int mtu = dev->mtu;
  
  	/* Configure GMAC core */

value |= GMAC_CORE_INIT;
  
+	/* Clear ACS bit because Ethernet switch tagging formats such as

+* Broadcom tags can look like invalid LLC/SNAP packets and cause the
+* hardware to truncate packets on reception.
+*/
+   if (netdev_uses_dsa(dev))
+   value &= ~GMAC_CONTROL_ACS;
+
if (mtu > 1500)
value |= GMAC_CONTROL_2K;
if (mtu > 2000)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 8ef517356313..91b23f9db31a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -25,15 +25,26 @@
  
***/
  
  #include 

+#include 
  #include 
  #include "dwmac100.h"
  
-static void dwmac100_core_init(struct mac_device_info *hw, int mtu)

+static void dwmac100_core_init(struct mac_device_info *hw,
+  struct net_device *dev)
  {
void __iomem *ioaddr = hw->pcsr;
u32 value = readl(ioaddr + MAC_CONTROL);
  
-	writel((value | MAC_CORE_INIT), ioaddr + MAC_CONTROL);

+   value |= MAC_CORE_INIT;
+
+   /* Clear ASTP bit because Ethernet switch tagging formats such as
+* Broadcom tags can look like invalid LLC/SNAP packets and cause the
+* hardware to truncate packets on reception.
+*/
+   if (netdev_uses_dsa(dev))
+   value &= ~MAC_CON

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

[Joerg Roedel]

Hey Andy,

On Wed, Jan 17, 2018 at 10:10:23AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel  wrote:

> > Just read up on vm86 mode control transfers and the stack layout then.
> > Looks like I need to check for eflags.vm=1 and copy four more registers
> > from/to the entry stack. Thanks for pointing that out.
> 
> You could just copy those slots unconditionally.  After all, you're
> slowing down entries by an epic amount due to writing CR3 on with PCID
> off, so four words copied should be entirely lost in the noise.  OTOH,
> checking for VM86 mode is just a single bt against EFLAGS.
> 
> With the modern (rewritten a year or two ago by Brian Gerst) vm86
> code, all the slots (those actually in pt_regs) are in the same
> location regardless of whether we're in VM86 mode or not, but we're
> still fiddling with the bottom of the stack.  Since you're controlling
> the switch to the kernel thread stack, you can easily just write the
> frame to the correct location, so you should not need to context
> switch sp1 -- you can do it sanely and leave sp1 as the actual bottom
> of the kernel stack no matter what.  In fact, you could probably avoid
> context switching sp0, either, which would be a nice cleanup.

I am not sure what you mean by "not context switching sp0/sp1" ...

> So I recommend the following.  Keep sp0 as the bottom of the sysenter
> stack no matter what.  Then do:
> 
> bt $X86_EFLAGS_VM_BIT
> jc .Lfrom_vm_\@
> 
> push 5 regs to real stack, starting at four-word offset (so they're in
> the right place)
> update %esp
> ...
> .Lupdate_esp_\@
> 
> .Lfrom_vm_\@:
> push 9 regs to real stack, starting at the bottom
> jmp .Lupdate_esp_\@
> 
> Does that seem reasonable?  It's arguably much nicer than what we have
> now.

But that looks like a good idea. Having a consistent stack with and
without vm86 is certainly a nice cleanup.


Regards,

Joerg

Re: [PATCH 03/16] x86/entry/32: Leave the kernel via the trampoline stack

[Joerg Roedel]

On Wed, Jan 17, 2018 at 10:12:32AM -0800, Andy Lutomirski wrote:
> I would optimize for simplicity, not speed.  You're already planning
> to write to CR3, which is serializing, blows away the TLB, *and* takes
> the absurdly large amount of time that the microcode needs to blow
> away the TLB.

Okay, so I am going to do the stack-switch before pt_regs is restored.
This is at least better than playing games with hiding the entry/exit
%esp somewhere in stack-memory.


Thanks,

Joerg

Re: [PATCH 08/16] x86/pgtable/32: Allocate 8k page-tables when PTI is enabled

[Joerg Roedel]

On Wed, Jan 17, 2018 at 03:43:14PM -0800, Andy Lutomirski wrote:
> On Tue, Jan 16, 2018 at 8:36 AM, Joerg Roedel  wrote:
> >  #ifdef CONFIG_X86_PAE
> >  .globl initial_pg_pmd
> >  initial_pg_pmd:
> > .fill 1024*KPMDS,4,0
> > +   .fill PTI_USER_PGD_FILL,4,0
> 
> Couldn't this be simplified to just .align PGD_ALIGN, 0 without the .fill?

You are right, will change that.

Thanks,

Joerg

Re: [RFC] Per file OOM badness

[Christian König]

Am 19.01.2018 um 10:32 schrieb Michel Dänzer:

On 2018-01-19 09:39 AM, Christian König wrote:

Am 19.01.2018 um 09:20 schrieb Michal Hocko:

On Thu 18-01-18 12:01:32, Eric Anholt wrote:

Michal Hocko  writes:


On Thu 18-01-18 18:00:06, Michal Hocko wrote:

On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:

Hi, this series is a revised version of an RFC sent by Christian
König
a few years ago. The original RFC can be found at
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html


This is the same idea and I've just adressed his concern from the
original RFC
and switched to a callback into file_ops instead of a new member
in struct file.

Please add the full description to the cover letter and do not make
people hunt links.

Here is the origin cover letter text
: I'm currently working on the issue that when device drivers
allocate memory on
: behalf of an application the OOM killer usually doesn't knew
about that unless
: the application also get this memory mapped into their address
space.
:
: This is especially annoying for graphics drivers where a lot of
the VRAM
: usually isn't CPU accessible and so doesn't make sense to map
into the
: address space of the process using it.
:
: The problem now is that when an application starts to use a lot
of VRAM those
: buffers objects sooner or later get swapped out to system memory,
but when we
: now run into an out of memory situation the OOM killer obviously
doesn't knew
: anything about that memory and so usually kills the wrong process.

OK, but how do you attribute that memory to a particular OOM killable
entity? And how do you actually enforce that those resources get freed
on the oom killer action?


: The following set of patches tries to address this problem by
introducing a per
: file OOM badness score, which device drivers can use to give the
OOM killer a
: hint how many resources are bound to a file descriptor so that it
can make
: better decisions which process to kill.

But files are not killable, they can be shared... In other words this
doesn't help the oom killer to make an educated guess at all.

Maybe some more context would help the discussion?

The struct file in patch 3 is the DRM fd.  That's effectively "my
process's interface to talking to the GPU" not "a single GPU resource".
Once that file is closed, all of the process's private, idle GPU buffers
will be immediately freed (this will be most of their allocations), and
some will be freed once the GPU completes some work (this will be most
of the rest of their allocations).

Some GEM BOs won't be freed just by closing the fd, if they've been
shared between processes.  Those are usually about 8-24MB total in a
process, rather than the GBs that modern apps use (or that our testcases
like to allocate and thus trigger oomkilling of the test harness instead
of the offending testcase...)

Even if we just had the private+idle buffers being accounted in OOM
badness, that would be a huge step forward in system reliability.

OK, in that case I would propose a different approach. We already
have rss_stat. So why do not we simply add a new counter there
MM_KERNELPAGES and consider those in oom_badness? The rule would be
that such a memory is bound to the process life time. I guess we will
find more users for this later.

I already tried that and the problem with that approach is that some
buffers are not created by the application which actually uses them.

For example X/Wayland is creating and handing out render buffers to
application which want to use OpenGL.

So the result is when you always account the application who created the
buffer the OOM killer will certainly reap X/Wayland first. And that is
exactly what we want to avoid here.

FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
anymore. With DRI3 and Wayland, buffers are allocated by the clients and
then shared with the X / Wayland server.


Good point, when I initially looked at that problem DRI3 wasn't widely 
used yet.



Also, in all cases, the amount of memory allocated for buffers shared
between DRI/Wayland clients and the server should be relatively small
compared to the amount of memory allocated for buffers used only locally
in the client, particularly for clients which create significant memory
pressure.


That is unfortunately only partially true. When you have a single 
runaway application which tries to allocate everything it would indeed 
work as you described.


But when I tested this a few years ago with X based desktop the 
applications which actually used most of the memory where Firefox and 
Thunderbird. Unfortunately they never got accounted for that.


Now, on my current Wayland based desktop it actually doesn't look much 
better. Taking a look at radeon_gem_info/amdgpu_gem_info the majority of 
all memory was allocated either by gnome-shell or Xwayland.


Regards,
Christian.

Re: [RFC] Per file OOM badness

[Michel Dänzer]

On 2018-01-19 10:58 AM, Christian König wrote:
> Am 19.01.2018 um 10:32 schrieb Michel Dänzer:
>> On 2018-01-19 09:39 AM, Christian König wrote:
>>> Am 19.01.2018 um 09:20 schrieb Michal Hocko:
 On Thu 18-01-18 12:01:32, Eric Anholt wrote:
> Michal Hocko  writes:
>
>> On Thu 18-01-18 18:00:06, Michal Hocko wrote:
>>> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote:
 Hi, this series is a revised version of an RFC sent by Christian
 König
 a few years ago. The original RFC can be found at
 https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html



 This is the same idea and I've just adressed his concern from the
 original RFC
 and switched to a callback into file_ops instead of a new member
 in struct file.
>>> Please add the full description to the cover letter and do not make
>>> people hunt links.
>>>
>>> Here is the origin cover letter text
>>> : I'm currently working on the issue that when device drivers
>>> allocate memory on
>>> : behalf of an application the OOM killer usually doesn't knew
>>> about that unless
>>> : the application also get this memory mapped into their address
>>> space.
>>> :
>>> : This is especially annoying for graphics drivers where a lot of
>>> the VRAM
>>> : usually isn't CPU accessible and so doesn't make sense to map
>>> into the
>>> : address space of the process using it.
>>> :
>>> : The problem now is that when an application starts to use a lot
>>> of VRAM those
>>> : buffers objects sooner or later get swapped out to system memory,
>>> but when we
>>> : now run into an out of memory situation the OOM killer obviously
>>> doesn't knew
>>> : anything about that memory and so usually kills the wrong process.
>> OK, but how do you attribute that memory to a particular OOM killable
>> entity? And how do you actually enforce that those resources get
>> freed
>> on the oom killer action?
>>
>>> : The following set of patches tries to address this problem by
>>> introducing a per
>>> : file OOM badness score, which device drivers can use to give the
>>> OOM killer a
>>> : hint how many resources are bound to a file descriptor so that it
>>> can make
>>> : better decisions which process to kill.
>> But files are not killable, they can be shared... In other words this
>> doesn't help the oom killer to make an educated guess at all.
> Maybe some more context would help the discussion?
>
> The struct file in patch 3 is the DRM fd.  That's effectively "my
> process's interface to talking to the GPU" not "a single GPU
> resource".
> Once that file is closed, all of the process's private, idle GPU
> buffers
> will be immediately freed (this will be most of their allocations),
> and
> some will be freed once the GPU completes some work (this will be most
> of the rest of their allocations).
>
> Some GEM BOs won't be freed just by closing the fd, if they've been
> shared between processes.  Those are usually about 8-24MB total in a
> process, rather than the GBs that modern apps use (or that our
> testcases
> like to allocate and thus trigger oomkilling of the test harness
> instead
> of the offending testcase...)
>
> Even if we just had the private+idle buffers being accounted in OOM
> badness, that would be a huge step forward in system reliability.
 OK, in that case I would propose a different approach. We already
 have rss_stat. So why do not we simply add a new counter there
 MM_KERNELPAGES and consider those in oom_badness? The rule would be
 that such a memory is bound to the process life time. I guess we will
 find more users for this later.
>>> I already tried that and the problem with that approach is that some
>>> buffers are not created by the application which actually uses them.
>>>
>>> For example X/Wayland is creating and handing out render buffers to
>>> application which want to use OpenGL.
>>>
>>> So the result is when you always account the application who created the
>>> buffer the OOM killer will certainly reap X/Wayland first. And that is
>>> exactly what we want to avoid here.
>> FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland
>> anymore. With DRI3 and Wayland, buffers are allocated by the clients and
>> then shared with the X / Wayland server.
> 
> Good point, when I initially looked at that problem DRI3 wasn't widely
> used yet.
> 
>> Also, in all cases, the amount of memory allocated for buffers shared
>> between DRI/Wayland clients and the server should be relatively small
>> compared to the amount of memory allocated for buffers used only locally
>> in the client, particularly for clients which create significant memory
>> pressure.
> 
> That is unfo

Re: [mm 4.15-rc8] Random oopses under memory pressure.

[Kirill A. Shutemov]

On Thu, Jan 18, 2018 at 06:22:13PM +0100, Michal Hocko wrote:
> On Thu 18-01-18 18:40:26, Kirill A. Shutemov wrote:
> [...]
> > +   /*
> > +* Make sure that pages are in the same section before doing pointer
> > +* arithmetics.
> > +*/
> > +   if (page_to_section(pvmw->page) != page_to_section(page))
> > +   return false;
> 
> OK, THPs shouldn't cross memory sections AFAIK. My brain is meltdown
> these days so this might be a completely stupid question. But why don't
> you simply compare pfns? This would be just simpler, no?

In original code, we already had pvmw->page around and I thought it would
be easier to get page for the pte intead of looking for pfn for both
sides.

We these changes it's no longer the case.

Do you care enough to send a patch? :)

-- 
 Kirill A. Shutemov

[PATCH] x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

[Jan Kiszka]

Otherwise, Linux will not recognize precalibrated_tsc_khz and disable
the tsc as clocksource.

Signed-off-by: Jan Kiszka 
---
 arch/x86/kernel/jailhouse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 7ade152133c7..2b7ebbe9043d 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -176,6 +176,7 @@ static void __init jailhouse_init_platform(void)
pr_debug("Jailhouse: PM-Timer IO Port: %#x\n", pmtmr_ioport);
 
precalibrated_tsc_khz = setup_data.tsc_khz;
+   setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ);
 
pci_probe = 0;
 

[PATCH] x86/jailhouse: Respect pci=lastbus command line settings

[Jan Kiszka]

Limiting the scan width to the known last bus via the command line can
accelerate the boot noteworthy.

Signed-off-by: Jan Kiszka 
---
 arch/x86/kernel/jailhouse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index 2b7ebbe9043d..b68fd895235a 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -119,8 +119,10 @@ static int __init jailhouse_pci_arch_init(void)
/*
 * There are no bridges on the virtual PCI root bus under Jailhouse,
 * thus no other way to discover all devices than a full scan.
+* Respect any overrides via the command line, though.
 */
-   pcibios_last_bus = 0xff;
+   if (pcibios_last_bus < 0)
+   pcibios_last_bus = 0xff;
 
return 0;
 }

Re: [PATCH net] xfrm: Add SA to hardware at the end of xfrm_state_construct()

[Steffen Klassert]

On Wed, Jan 17, 2018 at 03:52:41PM +0200, yoss...@mellanox.com wrote:
> From: Yossi Kuperman 
> 
> Current code configures the hardware with a new SA before the state has been
> fully initialized. During this time interval, an incoming ESP packet can cause
> a crash due to a NULL dereference. More specifically, xfrm_input() considers
> the packet as valid, and yet, anti-replay mechanism is not initialized.
> 
> Move hardware configuration to the end of xfrm_state_construct(), and mark
> the state as valid once the SA is fully initialized.
> 
> Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
> Signed-off-by: Aviad Yehezkel 
> Signed-off-by: Aviv Heller 
> Signed-off-by: Yossi Kuperman 

Applied, thanks Yossi!