Re: [PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM

[Christophe LEROY]

Le 22/02/2018 à 13:15, Jonathan Neuschäfer a écrit :

This patchset solves the same problem as my previous one[1] but follows
a rather different approach. Instead of implementing DISCONTIGMEM for
PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller
to the existing page_is_ram function, and unified page_is_ram to search
memblock.memory on PPC64 and PPC32.

The intended result is, as before, that my Wii can allocate the MMIO
range of its GPIO controller, which was previously not possible, because
the reserved memory hack (__allow_ioremap_reserved) didn't affect the
API in kernel/resource.c.

Thanks to Christophe Leroy for reviewing the previous patchset.


I tested your new serie, it doesn't break my 8xx so it is OK for me.

Christophe



[1]: https://www.spinics.net/lists/kernel/msg2726786.html

Jonathan Neuschäfer (5):
   powerpc: mm: Simplify page_is_ram by using memblock_is_memory
   powerpc: mm: Use memblock API for PPC32 page_is_ram
   powerpc/mm/32: Use page_is_ram to check for RAM
   powerpc: wii: Don't rely on the reserved memory hack
   powerpc/mm/32: Remove the reserved memory hack

  arch/powerpc/mm/init_32.c|  5 -
  arch/powerpc/mm/mem.c| 12 +---
  arch/powerpc/mm/mmu_decl.h   |  1 -
  arch/powerpc/mm/pgtable_32.c |  4 +---
  arch/powerpc/platforms/embedded6xx/wii.c | 14 +-
  5 files changed, 3 insertions(+), 33 deletions(-)

Re: [PATCH RESEND 1/2] mm: swap: clean up swap readahead

[Huang, Ying]

 writes:
[snip]

> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 39ae7cfad90f..c56cce64b2c3 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -332,32 +332,38 @@ struct page *lookup_swap_cache(swp_entry_t entry, 
> struct vm_area_struct *vma,
>  unsigned long addr)
>  {
>   struct page *page;
> - unsigned long ra_info;
> - int win, hits, readahead;
>  
>   page = find_get_page(swap_address_space(entry), swp_offset(entry));
>  
>   INC_CACHE_INFO(find_total);
>   if (page) {
> + bool vma_ra = swap_use_vma_readahead();
> + bool readahead = TestClearPageReadahead(page);
> +

TestClearPageReadahead() cannot be called for compound page.  As in

PAGEFLAG(Readahead, reclaim, PF_NO_COMPOUND)
TESTCLEARFLAG(Readahead, reclaim, PF_NO_COMPOUND)

>   INC_CACHE_INFO(find_success);
>   if (unlikely(PageTransCompound(page)))
>   return page;
> - readahead = TestClearPageReadahead(page);

So we can only call it here after checking whether page is compound.

Best Regards,
Huang, Ying

> - if (vma) {
> - ra_info = GET_SWAP_RA_VAL(vma);
> - win = SWAP_RA_WIN(ra_info);
> - hits = SWAP_RA_HITS(ra_info);
> +
> + if (vma && vma_ra) {
> + unsigned long ra_val;
> + int win, hits;
> +
> + ra_val = GET_SWAP_RA_VAL(vma);
> + win = SWAP_RA_WIN(ra_val);
> + hits = SWAP_RA_HITS(ra_val);
>   if (readahead)
>   hits = min_t(int, hits + 1, SWAP_RA_HITS_MAX);
>   atomic_long_set(&vma->swap_readahead_info,
>   SWAP_RA_VAL(addr, win, hits));
>   }
> +
>   if (readahead) {
>   count_vm_event(SWAP_RA_HIT);
> - if (!vma)
> + if (!vma || !vma_ra)
>   atomic_inc(&swapin_readahead_hits);
>   }
>   }
> +
>   return page;
>  }
>

[snip]

Re: What was last kernel that booted on hardware XY? database was Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2A

[Pavel Machek]

Hi!

> >> > BTW... I'd really like to have a database of machine, kernel version,
> >> > cpuinfo, config... So that questions like "what is the latest kernel
> >> > that is known to be running on this hardware" and "what config should
> >> > I start from".
> >> >
> >> > For example, I have nokia N810 here. It was supported by Linux at some
> >> > point, but then we moved to dts, and stuff changed, and I can no
> >> > longer figure how to boot it.
> >> >
> >> > I guess "what was last kernel that worked on Cyrix MII" is also
> >> > relevant question.
> >> >
> >> > Is there such database? If not, would people be interested in
> >> > contributing if I create one?
> >> >
> >>
> >> I am interested and will help. I have i486/i586/Pentium Pro/Pentium
> >> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet
> >> have Pentium III systems.
> >>
> >> I think an associated goal would be to fix those broken versions.
> >>
> >> I think this is a great project for college students to get experience
> >> with. Who else is interested?
> >
> > Ok, I started something:
> >
> > https://github.com/pavelmachek/missy
> >
> This is a good start. Could we start to create a hierarchy of major
> architectures next? I propose the following:

For desktop PCs, I guess grouping by CPU type makes sense. But I guess
I'd prefer grouping CPUs by manufacturer, not by CPU "family".

So I'd propose

pc/intel/i486
pc/cyrix/cx486
pc/amd/am486
...

> You would put the computer you tested it on inside one of these directories.
> 
> This will need to be edited if you choose to use it. I left out items
> I know little about, such as Geode GX1, Geode LX, VIA C3-2, VIA C7,
> Transmeta Crusoe and Efficeon, Winchip-2, Winchip-C6, and certainly
> others.

Advantage is, that even if you know little about the chip, you know
who manufactured it and how it is called :-).

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: collecting simple benchmark scripts?

[Pavel Machek]

Hi!

> In a separate thread, some folks were looking for some simple
> benchmarks for evaluating various changes to kernel internals (as
> opposed to the much more focused things like xfstests). For me, this
> has been an area of lore and passed-around scripts, and it seems like
> maybe we should have a subdirectory of tools/testing/benchmarks/ or
> something to collect these?
> 
> (Or maybe this already exists and I've totally missed it?)
> 
> I've got at least one micro-benchmark in
> tools/testing/selftests/seccomp/seccomp_benchmark.c, and searches show
> tools/testing/selftests/vm/gup_benchmark.c too, but I was thinking of
> either more generali things more like the famous "kernel build
> benchmark" or a wrapper for running hackbench to get some statistics
> out of it, etc.

Ok, I guess my micro-benchmark is too micro for you, but I like to use

"time cat /dev/urandom | head -c 1000 |  bzip2 -9 - | wc -c"

I have a page with various results online somewhere, probably at

http://atrey.karlin.mff.cuni.cz/~pavel/quickbench.html


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCHv4 2/4] ASoC: codec: cpcap: new codec

[Pavel Machek]

On Fri 2018-02-16 14:27:16, Mark Brown wrote:
> On Fri, Feb 16, 2018 at 02:51:13PM +0100, Sebastian Reichel wrote:
> > On Fri, Feb 16, 2018 at 11:39:01AM +, Mark Brown wrote:
> 
> > > We don't have default lines like this for other MFDs...
> 
> > Is there a reason not to add them? It looks very useful to me:
> 
> Consistency.  It's a lot easier to apply a single rule to everything
> than it is to have to individually think through and discuss the
> decisions on every individual driver, especially when there will
> inevitably be some cases where there are conflicting requirements from
> different users.  As you said in the rest of your mail hand configuring
> kernels is already a very specialist thing at the best of times.

Yes, so please don't make it any harder than it needs to be. Having to
enable (by hand) more than one option per chip is annoying and error-prone.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

[kbuild test robot]

Hi Ram,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-skiroot_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the 
linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/pkeys.h:9:0,
from arch/powerpc/include/asm/mman.h:16,
from include/uapi/linux/mman.h:5,
from include/linux/mman.h:9,
from arch/powerpc/kernel/asm-offsets.c:22:
   arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared 
>> (first use in this function); did you mean 'VM_PKEY_BIT3'?
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
   arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 
'ARCH_VM_PKEY_FLAGS'
 return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~
   arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is 
reported only once for each function it appears in
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
   arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 
'ARCH_VM_PKEY_FLAGS'
 return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~
   arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
   arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared 
(first use in this function); did you mean 'VM_PKEY_BIT3'?
  ((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
   ^~~~
   VM_PKEY_BIT3
   arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared 
>> (first use in this function); did you mean 'VM_PKEY_BIT3'?
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
   arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 
'ARCH_VM_PKEY_FLAGS'
 return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
 ^~
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +32 arch/powerpc/include/asm/pkeys.h

4fb158f6 Ram Pai 2018-01-18  30  
4fb158f6 Ram Pai 2018-01-18  31  #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | 
VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32 VM_PKEY_BIT3 | 
VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18  33  

:: The code at line 32 was first introduced by commit
:: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation 
status of all pkeys

:: TO: Ram Pai 
:: CC: Michael Ellerman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/4] Staging: gdm724x: hci: Changed camel-case to snake-case.

[Greg KH]

On Thu, Feb 22, 2018 at 05:32:59PM -0800, Quytelda Kahja wrote:
> Changed a variable name from camel to snake case to fix a coding style
> issue.
> 
> Signed-off-by: Quytelda Kahja 
> ---
>  drivers/staging/gdm724x/hci_packet.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/gdm724x/hci_packet.h 
> b/drivers/staging/gdm724x/hci_packet.h
> index 22ce8b9477b6..f8837c7103ac 100644
> --- a/drivers/staging/gdm724x/hci_packet.h
> +++ b/drivers/staging/gdm724x/hci_packet.h
> @@ -50,7 +50,7 @@ struct tlv {
>  struct sdu_header {
>   __dev16 cmd_evt;
>   __dev16 len;
> - __dev32 dftEpsId;
> + __dev32 dft_eps_ID;
>   __dev32 bearer_ID;
>   __dev32 nic_type;
>  } __packed;

Why not just delete the whole structure if no one is using it?

thanks,

greg k-h

Re: [PATCH] Staging: rtl8192e: rtllib_crypt_tkip.c: Use __func__ instead of function name and proper code ident for else statement

[Greg KH]

On Fri, Feb 23, 2018 at 12:57:16AM +0530, Debopriyo Ghosh wrote:
> From: Debopriyo 
> 
> This is a patch to the rtllib_crypt_tkip.c file that fixes 2 issues found
> by the checkpatch.pl tool
> 1.Use of __func__ instead of function name
> 2.proper code identation for else statement

When you have to list different things you are doing in a single patch,
that's a huge sign you need to break the patch up into multiple ones.

Please do that here.

thanks,

greg k-h

Re: [RFC tip/locking/lockdep v5 08/17] lockdep: Fix recursive read lock related safe->unsafe detection

[Boqun Feng]

On Thu, Feb 22, 2018 at 06:46:54PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 22, 2018 at 03:08:55PM +0800, Boqun Feng wrote:
> > There are four cases for recursive read lock realted deadlocks:
> > 
> > (--(X..Y)--> means a strong dependency path starts with a --(X*)-->
> > dependency and ends with a --(*Y)-- dependency.)
> > 
> > 1.  An irq-safe lock L1 has a dependency --(*..*)--> to an
> > irq-unsafe lock L2.
> > 
> > 2.  An irq-read-safe lock L1 has a dependency --(N..*)--> to an
> > irq-unsafe lock L2.
> > 
> > 3.  An irq-safe lock L1 has a dependency --(*..N)--> to an
> > irq-read-unsafe lock L2.
> > 
> > 4.  An irq-read-safe lock L1 has a dependency --(N..N)--> to an
> > irq-read-unsafe lock L2.
> > 
> > The current check_usage() only checks 1) and 2), so this patch adds
> > checks for 3) and 4) and makes sure when find_usage_{back,for}wards find
> > an irq-read-{,un}safe lock, the traverse path should ends at a
> > dependency --(*N)-->. Note when we search backwards, --(*N)--> indicates
> > a real dependency --(N*)-->.
> 
> This adds 4 __bfs() searches for every new link.
> 
> Can't we make the existing traversals smarter?

Haven't really thought this one through, I will try. But as you said, we
only need to do more searchs for _new_ links, so I think it's the slow
path, would the performance matter that much?

Regards,
Boqun


signature.asc
Description: PGP signature

Re: [PATCH v11 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

[Simon Horman]

On Thu, Feb 22, 2018 at 11:37:20AM +0100, Jacopo Mondi wrote:
> Add Capture Engine Unit (CEU) node to device tree.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Laurent Pinchart 
> Acked-by: Hans Verkuil 

I have marked this patch as deferred as it depends on the binding for
"renesas,r7s72100-ceu".  Please repost or otherwise ping me once that
dependency has been accepted.

Re: [PATCH v2 0/3] new driver for Valve Steam Controller

[Benjamin Tissoires]

On Thu, Feb 22, 2018 at 6:48 PM, Rodrigo Rivas Costa
 wrote:
> On Thu, Feb 22, 2018 at 06:06:30PM +0100, Benjamin Tissoires wrote:
>> On Thu, Feb 22, 2018 at 5:31 PM, Rodrigo Rivas Costa
>>  wrote:
>> > On Thu, Feb 22, 2018 at 10:10:40AM +0100, Benjamin Tissoires wrote:
>> >> On Thu, Feb 22, 2018 at 1:13 AM, Pierre-Loup A. Griffais
>> >>  wrote:
>> >> >
>> >> >
>> >> > On 02/21/2018 12:21 PM, Rodrigo Rivas Costa wrote:
>> >> >>
>> >> >> On Tue, Feb 20, 2018 at 04:09:39PM -0800, Pierre-Loup A. Griffais 
>> >> >> wrote:
>> >> >>>
>> >> >>> On 02/20/2018 03:20 PM, Rodrigo Rivas Costa wrote:
>> >> 
>> >>  On Tue, Feb 20, 2018 at 02:29:48PM -0800, Pierre-Loup A. Griffais 
>> >>  wrote:
>> >>  About the left trackpad/joystick, currently I'm not treating them
>> >>  different. I'm out of ABS axes, and anyway, it is not likely that the
>> >>  left pad and the joystick be used at the same time (I only have one 
>> >>  left
>> >>  thumb). Nevertheless, if we really want to make them apart, we can 
>> >>  use
>> >>  bits 10.3 (lpad_touch) and 10.7 (lpad_and_joy) together. I described 
>> >>  the
>> >>  details in [2], but I'm not currently doing that in this driver.
>> >> >>>
>> >> >>>
>> >> >>> I didn't necessarily mean exposing it, but in the event a user is 
>> >> >>> using
>> >> >>> both
>> >> >>> at the same time (it happens, using claw grip with some games is
>> >> >>> necessary
>> >> >>> to use the D-pad while deflecting the stick), then you'll most likely 
>> >> >>> run
>> >> >>> into issues unless you demux the inbound data, since we were also out 
>> >> >>> of
>> >> >>> left analog fields and mux them together if used at the same time. Not
>> >> >>> sure
>> >> >>> if you're already handling that case, but not doing it would result in
>> >> >>> the
>> >> >>> stick appearing to fully deflect every other input report if the user 
>> >> >>> is
>> >> >>> doing both at the same time.
>> >> >>
>> >> >>
>> >> >> "Claw grip"? Is that a real thing? Yes, it is! Well, you're totally
>> >> >> right. I think that it will be best to fully separate the left-pad and
>> >> >> the joystick. Maybe the left-pad can be mapped to ABS_HAT1{X,Y]...
>> >> >>
>> >>  About the gyroscope/acceleration/quaternion, you know the issue
>> >>  that the wireless gives gyro plus quat but no accel, while the wired
>> >>  gives all three. My general idea is to create an additional input 
>> >>  device
>> >>  with INPUT_PROP_ACCELEROMETER to expose what is available. Pity is 
>> >>  that
>> >>  the wireless gives no accel, maybe there is some command to enable 
>> >>  it?
>> >> >>>
>> >> >>>
>> >> >>> It should be three neighboring bits for that setting; does this not 
>> >> >>> work
>> >> >>> for
>> >> >>> you?
>> >> >>>
>> >> >>> // Bitmask that define which IMU features to enable.
>> >> >>> typedef enum
>> >> >>> {
>> >> >>> SETTING_GYRO_MODE_OFF   = 0x,
>> >> >>> SETTING_GYRO_MODE_STEERING  = 0x0001,
>> >> >>> SETTING_GYRO_MODE_TILT  = 0x0002,
>> >> >>> SETTING_GYRO_MODE_SEND_ORIENTATION  = 0x0004,
>> >> >>> SETTING_GYRO_MODE_SEND_RAW_ACCEL= 0x0008,
>> >> >>> SETTING_GYRO_MODE_SEND_RAW_GYRO = 0x0010,
>> >> >>> } SettingGyroMode;
>> >> >>
>> >> >>
>> >> >> Thanks for that, it will be useful! Those are the values to be written
>> >> >> to what I called "register 0x30" with {0x87 0x03 0x30 X 0x00}. 
>> >> >> Currently
>> >> >> I am writing 0x14 to enable and 0x00 to disable. I suspected it was a
>> >> >> bit-field...
>> >> >>
>> >> >>> In general I'm concerned about sending of the gyro-enable message
>> >> >>> potentially impairing Steam functionality if it's running at the same
>> >> >>> time
>> >> >>> (eg. if gyro gets disabled over the radio while Steam still needs 
>> >> >>> it), or
>> >> >>> sending any stateful messages to the device. For instance, are you 
>> >> >>> ever
>> >> >>> sending the "blank configuration" setting? I assume you must be or 
>> >> >>> users
>> >> >>> would still get keyboard/mouse input over these USB endpoints while
>> >> >>> trying
>> >> >>> to interact with the controller. But sending this after Steam 
>> >> >>> programmed
>> >> >>> a
>> >> >>> setting, or instructed the controller to go back to lizard mode 
>> >> >>> because
>> >> >>> it
>> >> >>> was requested by a configuration, would be problematic.
>> >> >>
>> >> >>
>> >> >> Sure, but this patchset should be safe, shouldn't it?
>> >> >> Maube future patches that play with the gyro/force-feedback could be
>> >> >> disabled by default, and could need a module parameter to be enabled.
>> >> >> That way Steam Client will work out-of-the-box anywhere but proficient
>> >> >> users could use the extra functionality easily.
>> >> >>
>> >> >> Related to that, Benjamin Tissoires replied to 1/3:
>> >> 
>> >>  --- a/drivers/hid/hid-quirks.c
>> >>

Re: [0/8] target-iSCSI: Adjustments for several function implementations

[SF Markus Elfring]

> You're 1/8 patch had an actual bug fix hidden amongst the style churn.

It showed the general possibility to adjust the source code structure
for the function “chap_server_compute_md5” also because of the usage
of the single jump label “out” before.


> I don't see any such fixes in the other patches.

This view is appropriate.

Further update steps show different transformation possibilities.


> My opinion from https://www.spinics.net/lists/target-devel/msg16342.html
> hasn't changed. FWIW, I'd prefer to see LIO adopt a policy similar to:
> https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#How_not_to_start

It seems that you express a few aspects for general change resistance.
Will the circumstances evolve for similar software improvements?

Regards,
Markus

RE: [PATCH v5] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

[Tian, Kevin]

> From: Alex Williamson
> Sent: Friday, February 23, 2018 6:59 AM
> 
> On Thu,  1 Feb 2018 01:27:38 -0500
> Suravee Suthikulpanit  wrote:
> 
> > VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which
> requires
> > IOTLB flushing for every unmapping. This results in large IOTLB flushing
> > overhead when handling pass-through devices has a large number of
> mapped
> > IOVAs. This can be avoided by using the new IOTLB flushing interface.
> >
> > Cc: Alex Williamson 
> > Cc: Joerg Roedel 
> > Signed-off-by: Suravee Suthikulpanit 
> > ---
> >
> > Changes from v4 (https://lkml.org/lkml/2018/1/31/153)
> >  * Change return type from ssize_t back to size_t since we no longer
> >changing IOMMU API. Also update error handling logic accordingly.
> >  * In unmap_unpin_fast(), also sync when failing to allocate entry.
> >  * Some code restructuring and variable renaming.
> >
> >  drivers/vfio/vfio_iommu_type1.c | 128
> 
> >  1 file changed, 117 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio_iommu_type1.c
> b/drivers/vfio/vfio_iommu_type1.c
> > index e30e29a..6041530 100644
> > --- a/drivers/vfio/vfio_iommu_type1.c
> > +++ b/drivers/vfio/vfio_iommu_type1.c
> > @@ -102,6 +102,13 @@ struct vfio_pfn {
> > atomic_tref_count;
> >  };
> >
> > +struct vfio_regions {
> > +   struct list_head list;
> > +   dma_addr_t iova;
> > +   phys_addr_t phys;
> > +   size_t len;
> > +};
> > +
> >  #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)\
> > (!list_empty(&iommu->domain_list))
> >
> > @@ -648,11 +655,102 @@ static int
> vfio_iommu_type1_unpin_pages(void *iommu_data,
> > return i > npage ? npage : (i > 0 ? i : -EINVAL);
> >  }
> >
> > +static long vfio_sync_unpin(struct vfio_dma *dma, struct vfio_domain
> *domain,
> > +   struct list_head *regions)
> > +{
> > +   long unlocked = 0;
> > +   struct vfio_regions *entry, *next;
> > +
> > +   iommu_tlb_sync(domain->domain);
> > +
> > +   list_for_each_entry_safe(entry, next, regions, list) {
> > +   unlocked += vfio_unpin_pages_remote(dma,
> > +   entry->iova,
> > +   entry->phys >>
> PAGE_SHIFT,
> > +   entry->len >> PAGE_SHIFT,
> > +   false);
> > +   list_del(&entry->list);
> > +   kfree(entry);
> > +   }
> > +
> > +   cond_resched();
> > +
> > +   return unlocked;
> > +}
> > +
> > +/*
> > + * Generally, VFIO needs to unpin remote pages after each IOTLB flush.
> > + * Therefore, when using IOTLB flush sync interface, VFIO need to keep
> track
> > + * of these regions (currently using a list).
> > + *
> > + * This value specifies maximum number of regions for each IOTLB flush
> sync.
> > + */
> > +#define VFIO_IOMMU_TLB_SYNC_MAX512
> > +
> > +static size_t unmap_unpin_fast(struct vfio_domain *domain,
> > +  struct vfio_dma *dma, dma_addr_t *iova,
> > +  size_t len, phys_addr_t phys, long *unlocked,
> > +  struct list_head *unmapped_list,
> > +  int *unmapped_cnt)
> > +{
> > +   size_t unmapped = 0;
> > +   struct vfio_regions *entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> > +
> > +   if (entry) {
> > +   unmapped = iommu_unmap_fast(domain->domain, *iova,
> len);
> > +
> > +   if (!unmapped) {
> > +   kfree(entry);
> > +   } else {
> > +   iommu_tlb_range_add(domain->domain, *iova,
> unmapped);
> > +   entry->iova = *iova;
> > +   entry->phys = phys;
> > +   entry->len  = unmapped;
> > +   list_add_tail(&entry->list, unmapped_list);
> > +
> > +   *iova += unmapped;
> > +   (*unmapped_cnt)++;
> > +   }
> > +   }
> > +
> > +   /*
> > +* Sync if the number of fast-unmap regions hits the limit
> > +* or in case of errors.
> > +*/
> > +   if (*unmapped_cnt >= VFIO_IOMMU_TLB_SYNC_MAX
> || !unmapped) {
> > +   *unlocked += vfio_sync_unpin(dma, domain,
> > +unmapped_list);
> > +   *unmapped_cnt = 0;
> > +   }

I'm not sure why returning ZERO is treated as only unmap error 
here, but if looking at __iommu_unmap clearly there are other
error codes returned also. I know it's not introduced by this
patch but Alex, was it deliberately implemented such way under 
any assumption or a typo?

Thanks
Kevin

Re: [2/2] crypto: bcm: One function call less in do_shash() after error detection

[SF Markus Elfring]

> This patch is pointless as kfree on NULL is a no-op.

I prefer to avoid unnecessary function calls generally.

Regards,
Markus

[PATCH v11 0/7] Address error and recovery for AER and DPC

[Oza Pawandeep]

This patch set brings in error handling support for DPC

The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER gets triggered, but also when DPC get
triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.

DPC should enumerate the devices after recovering the link, which is
achieved by implementing error_resume callback.

Changes since v10:
Christoph Hellwig's, David Laight's and Randy Dunlap's
comments addressed.
> renamed pci_do_recovery to pcie_do_recovery
> removed inner braces in conditional statements.
> restrctured the code in pci_wait_for_link 
> EXPORT_SYMBOL_GPL
Changes since v9:
Sinan's comments addressed.
> bool active = true; unnecessary variable removed.
Changes since v8:
Fixed Kbuild errors.
Changes since v7:
Rebased the code on pci master
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/helgaas/pci
Changes since v6:
Sinan's and Stefan's comments implemented.
> reordered patch 6 and 7
> cleaned up
Changes since v5:
Sinan's and Keith's comments incorporated.
> made separate patch for mutex
> unified error repotting codes into driver/pci/pci.h
> got rid of wait link active/inactive and
  made generic function in driver/pci/pci.c
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and recovery
> removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error Message,
the Requester ID from the Message is recorded in the DPC Error
Source ID register and that Message is discarded and not forwarded Upstream.
"
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check

Oza Pawandeep (7):
  PCI/AER: Rename error recovery to generic pci naming
  PCI/AER: factor out error reporting from AER
  PCI/ERR: add mutex to synchronize recovery
  PCI/DPC: Unify and plumb error handling into DPC
  PCI/AER: Unify aer error defines at single space
  PCI/DPC: Enumerate the devices after DPC trigger event
  PCI: Unify wait for link active into generic pci

 drivers/acpi/apei/ghes.c   |   1 +
 drivers/pci/hotplug/pciehp_hpc.c   |  21 +-
 drivers/pci/pci.c  |  39 +++-
 drivers/pci/pci.h  |  11 +
 drivers/pci/pcie/Makefile  |   2 +-
 drivers/pci/pcie/aer/aerdrv.h  |  30 ---
 drivers/pci/pcie/aer/aerdrv_core.c | 293 +-
 drivers/pci/pcie/aer/aerdrv_errprint.c |   1 +
 drivers/pci/pcie/pcie-dpc.c| 115 ++-
 drivers/pci/pcie/pcie-err.c| 366 +
 drivers/pci/pcie/portdrv.h |   2 +
 include/linux/aer.h|   4 -
 include/linux/pci.h|   1 +
 13 files changed, 534 insertions(+), 352 deletions(-)
 create mode 100644 drivers/pci/pcie/pcie-err.c

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v11 1/7] PCI/AER: Rename error recovery to generic pci naming

[Oza Pawandeep]

This patch renames error recovery to generic name with pci prefix

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index a4bfea5..aeb83a0 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -478,7 +478,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
 }
 
 /**
- * do_recovery - handle nonfatal/fatal error recovery process
+ * pcie_do_recovery - handle nonfatal/fatal error recovery process
  * @dev: pointer to a pci_dev data structure of agent detecting an error
  * @severity: error severity type
  *
@@ -486,7 +486,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
  * error detected message to all downstream drivers within a hierarchy in
  * question and return the returned code.
  */
-static void do_recovery(struct pci_dev *dev, int severity)
+static void pcie_do_recovery(struct pci_dev *dev, int severity)
 {
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
@@ -566,7 +566,7 @@ static void handle_error_source(struct pcie_device *aerdev,
pci_write_config_dword(dev, pos + PCI_ERR_COR_STATUS,
info->status);
} else
-   do_recovery(dev, info->severity);
+   pcie_do_recovery(dev, info->severity);
 }
 
 #ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -631,7 +631,7 @@ static void aer_recover_work_func(struct work_struct *work)
}
cper_print_aer(pdev, entry.severity, entry.regs);
if (entry.severity != AER_CORRECTABLE)
-   do_recovery(pdev, entry.severity);
+   pcie_do_recovery(pdev, entry.severity);
pci_dev_put(pdev);
}
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v11 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

[Oza Pawandeep]

Implement error_resume callback in DPC so, after DPC trigger event
enumerates the devices beneath.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index e15bcda..751efc0 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -126,6 +126,21 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
 }
 
 /**
+ * dpc_error_resume - enumerate the devices beneath
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver during fatal recovery.
+ */
+static void dpc_error_resume(struct pci_dev *pdev)
+{
+   if (pci_wait_for_link(pdev, true)) {
+   pci_lock_rescan_remove();
+   pci_rescan_bus(pdev->bus);
+   pci_unlock_rescan_remove();
+   }
+}
+
+/**
  * dpc_reset_link - reset link DPC  routine
  * @dev: pointer to Root Port's pci_dev data structure
  *
@@ -364,6 +379,7 @@ static void dpc_remove(struct pcie_device *dev)
.probe  = dpc_probe,
.remove = dpc_remove,
.reset_link = dpc_reset_link,
+   .error_resume   = dpc_error_resume,
 };
 
 static int __init dpc_service_init(void)
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index 1ea4b9a..1e1bf98 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -236,6 +236,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
  * @state: error state
  * @error_mesg: message to print
  * @cb: callback to be broadcast
+ * @severity: error severity
  *
  * Invoked during error recovery process. Once being invoked, the content
  * of error severity will be broadcast to all downstream drivers in a
@@ -244,7 +245,8 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int 
severity)
 static pci_ers_result_t broadcast_error_message(struct pci_dev *dev,
enum pci_channel_state state,
char *error_mesg,
-   int (*cb)(struct pci_dev *, void *))
+   int (*cb)(struct pci_dev *, void *),
+   int severity)
 {
struct aer_broadcast_data result_data;
 
@@ -256,6 +258,17 @@ static pci_ers_result_t broadcast_error_message(struct 
pci_dev *dev,
result_data.result = PCI_ERS_RESULT_RECOVERED;
 
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+   /* If DPC is triggered, call resume error handler
+* because, at this point we can safely assume that
+* link recovery has happened, this is only handled if
+* callback is resume, as this function can be called
+* with multiple callbacks.
+*/
+   if ((severity == DPC_FATAL) &&
+   (cb == report_resume)) {
+   cb(dev, NULL);
+   return PCI_ERS_RESULT_RECOVERED;
+   }
/*
 * If the error is reported by a bridge, we think this error
 * is related to the downstream link of the bridge, so we
@@ -305,7 +318,8 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"error_detected",
-   report_error_detected);
+   report_error_detected,
+   severity);
 
if (severity == AER_FATAL ||
severity == DPC_FATAL) {
@@ -321,7 +335,8 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"mmio_enabled",
-   report_mmio_enabled);
+   report_mmio_enabled,
+   severity);
 
if (status == PCI_ERS_RESULT_NEED_RESET) {
/*
@@ -332,7 +347,8 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
status = broadcast_error_message(dev,
state,
"slot_reset",
-   report_slot_reset);
+   report_slot_reset,
+   severity);
}
 
if (status != PCI_ERS_RESULT_RECOVERED)
@@ -342,7 +358,8 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
broadcast_error_message(dev,
state,
"resume",
-   report_resume);
+   report_resume,
+   severity);
 
dev_info(&dev->dev, "Device recovery successful\n");
mutex_unlock(&pci_err_recovery_lock);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v11 4/7] PCI/DPC: Unify and plumb error handling into DPC

[Oza Pawandeep]

Current DPC driver does not do recovery, e.g. calling end-point's driver's
callbacks, which sanitize the sw.

DPC driver implements link_reset callback, and calls pcie_do_recovery.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index abc514e..f8575da 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,6 +343,8 @@ static inline resource_size_t pci_resource_alignment(struct 
pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
+#define DPC_FATAL  4
+
 void pcie_do_recovery(struct pci_dev *dev, int severity);
 
 #ifdef CONFIG_PCIEASPM
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 38e40c6..5c01c63 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -13,6 +13,7 @@
 #include 
 #include "../pci.h"
 #include "aer/aerdrv.h"
+#include "portdrv.h"
 
 struct dpc_dev {
struct pcie_device  *dev;
@@ -45,6 +46,58 @@ struct dpc_dev {
"Memory Request Completion Timeout", /* Bit Position 18 */
 };
 
+static int find_dpc_dev_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver;
+   struct device **dev = (struct device **) data;;
+
+   if (device->bus == &pcie_port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *dev = device;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+static struct device *pci_find_dpc_dev(struct pci_dev *pdev)
+{
+   struct device *dev = NULL;
+
+   device_for_each_child(&pdev->dev, &dev, find_dpc_dev_iter);
+
+   return dev;
+}
+
+static int find_dpc_service_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver;
+   struct pcie_port_service_driver **drv =
+   (struct pcie_port_service_driver **) data;
+
+   if (device->bus == &pcie_port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);
+   if (service_driver->service == PCIE_PORT_SERVICE_DPC) {
+   *drv = service_driver;
+   return 1;
+   }
+   }
+
+   return 0;
+}
+
+struct pcie_port_service_driver *pci_find_dpc_service(struct pci_dev *dev)
+{
+   struct pcie_port_service_driver *drv = NULL;
+
+   device_for_each_child(&dev->dev, &drv, find_dpc_service_iter);
+
+   return drv;
+}
+EXPORT_SYMBOL_GPL(pci_find_dpc_service);
+
 static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 {
unsigned long timeout = jiffies + HZ;
@@ -82,12 +135,25 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)
dev_warn(dev, "Link state not disabled for DPC event\n");
 }
 
-static void dpc_work(struct work_struct *work)
+/**
+ * dpc_reset_link - reset link DPC  routine
+ * @dev: pointer to Root Port's pci_dev data structure
+ *
+ * Invoked by Port Bus driver when performing link reset at Root Port.
+ */
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
 {
-   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
-   struct pci_dev *dev, *temp, *pdev = dpc->dev->port;
struct pci_bus *parent = pdev->subordinate;
-   u16 cap = dpc->cap_pos, ctl;
+   struct pci_dev *dev, *temp;
+   struct dpc_dev *dpc;
+   struct pcie_device *pciedev;
+   struct device *devdpc;
+   u16 cap, ctl;
+
+   devdpc = pci_find_dpc_dev(pdev);
+   pciedev = to_pcie_device(devdpc);
+   dpc = get_service_data(pciedev);
+   cap = dpc->cap_pos;
 
pci_lock_rescan_remove();
list_for_each_entry_safe_reverse(dev, temp, &parent->devices,
@@ -104,21 +170,31 @@ static void dpc_work(struct work_struct *work)
 
dpc_wait_link_inactive(dpc);
if (dpc->rp_extensions && dpc_wait_rp_inactive(dpc))
-   return;
+   return PCI_ERS_RESULT_DISCONNECT;
if (dpc->rp_extensions && dpc->rp_pio_status) {
pci_write_config_dword(pdev, cap + PCI_EXP_DPC_RP_PIO_STATUS,
   dpc->rp_pio_status);
dpc->rp_pio_status = 0;
}
 
-   pci_write_config_word(pdev, cap + PCI_EXP_DPC_STATUS,
+   pci_write_config_word(pdev, dpc->cap_pos + PCI_EXP_DPC_STATUS,
PCI_EXP_DPC_STATUS_TRIGGER | PCI_EXP_DPC_STATUS_INTERRUPT);
 
pci_read_config_word(pdev, cap + PCI_EXP_DPC_CTL, &ctl);
pci_write_config_word(pdev, cap + PCI_EXP_DPC_CTL,
- ctl | PCI_EXP_DPC_CTL_INT_EN);
+   ctl | PCI_EXP_DPC_CTL_INT_EN);
+
+   return PCI_ERS_RESULT_RECOVERED;
 }
 
+static void dpc_work(struct work_struct *work)
+{
+   struct dpc_dev *dpc = container_of(work, struct dpc_dev, work);
+   struct pci_dev *pdev = dpc->d

[PATCH v11 2/7] PCI/AER: factor out error reporting from AER

[Oza Pawandeep]

This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
DPC should be able to register callbacks and attmept recovery when DPC
trigger event occurs.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index fcd8191..abc514e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -342,6 +342,9 @@ static inline resource_size_t pci_resource_alignment(struct 
pci_dev *dev,
 
 void pci_enable_acs(struct pci_dev *dev);
 
+/* PCI error reporting and recovery */
+void pcie_do_recovery(struct pci_dev *dev, int severity);
+
 #ifdef CONFIG_PCIEASPM
 void pcie_aspm_init_link_state(struct pci_dev *pdev);
 void pcie_aspm_exit_link_state(struct pci_dev *pdev);
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 223e4c3..d669497 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -6,7 +6,7 @@
 # Build PCI Express ASPM if needed
 obj-$(CONFIG_PCIEASPM) += aspm.o
 
-pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o
+pcieportdrv-y  := portdrv_core.o portdrv_pci.o portdrv_bus.o 
pcie-err.o
 pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o
 
 obj-$(CONFIG_PCIEPORTBUS)  += pcieportdrv.o
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 5449e5c..bc9db53 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -76,36 +76,6 @@ struct aer_rpc {
 */
 };
 
-struct aer_broadcast_data {
-   enum pci_channel_state state;
-   enum pci_ers_result result;
-};
-
-static inline pci_ers_result_t merge_result(enum pci_ers_result orig,
-   enum pci_ers_result new)
-{
-   if (new == PCI_ERS_RESULT_NO_AER_DRIVER)
-   return PCI_ERS_RESULT_NO_AER_DRIVER;
-
-   if (new == PCI_ERS_RESULT_NONE)
-   return orig;
-
-   switch (orig) {
-   case PCI_ERS_RESULT_CAN_RECOVER:
-   case PCI_ERS_RESULT_RECOVERED:
-   orig = new;
-   break;
-   case PCI_ERS_RESULT_DISCONNECT:
-   if (new == PCI_ERS_RESULT_NEED_RESET)
-   orig = PCI_ERS_RESULT_NEED_RESET;
-   break;
-   default:
-   break;
-   }
-
-   return orig;
-}
-
 extern struct bus_type pcie_port_bus_type;
 void aer_isr(struct work_struct *work);
 void aer_print_error(struct pci_dev *dev, struct aer_err_info *info);
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c
index aeb83a0..f60b1bb 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include "aerdrv.h"
+#include "../../pci.h"
 
 #definePCI_EXP_AER_FLAGS   (PCI_EXP_DEVCTL_CERE | 
PCI_EXP_DEVCTL_NFERE | \
 PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -230,191 +231,6 @@ static bool find_source_device(struct pci_dev *parent,
return true;
 }
 
-static int report_error_detected(struct pci_dev *dev, void *data)
-{
-   pci_ers_result_t vote;
-   const struct pci_error_handlers *err_handler;
-   struct aer_broadcast_data *result_data;
-   result_data = (struct aer_broadcast_data *) data;
-
-   device_lock(&dev->dev);
-   dev->error_state = result_data->state;
-
-   if (!dev->driver ||
-   !dev->driver->err_handler ||
-   !dev->driver->err_handler->error_detected) {
-   if (result_data->state == pci_channel_io_frozen &&
-   dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
-   /*
-* In case of fatal recovery, if one of down-
-* stream device has no driver. We might be
-* unable to recover because a later insmod
-* of a driver for this device is unaware of
-* its hw state.
-*/
-   pci_printk(KERN_DEBUG, dev, "device has %s\n",
-  dev->driver ?
-  "no AER-aware driver" : "no driver");
-   }
-
-   /*
-* If there's any device in the subtree that does not
-* have an error_detected callback, returning
-* PCI_ERS_RESULT_NO_AER_DRIVER prevents calling of
-* the subsequent mmio_enabled/slot_reset/resume
-* callbacks of "any" device in the subtree. All the
-* devices in the subtree are left in the error state
-* without recovery.
-*/
-
-   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
-   vote = PCI_ERS_RESULT_NO_AER_DRIVER;
-   else
-   vote = PCI_ERS_RESULT_NONE;
-   } else {
-   err_handler = dev->driver->err_handler;
-   vote 

[tip:x86/platform] x86/pci: Simplify code by using the new dmi_get_bios_year() helper

[tip-bot for Andy Shevchenko]

Commit-ID:  69c42d493db452ea87c1ac56e83c978512f4e6ec
Gitweb: https://git.kernel.org/tip/69c42d493db452ea87c1ac56e83c978512f4e6ec
Author: Andy Shevchenko 
AuthorDate: Thu, 22 Feb 2018 14:59:21 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:20:30 +0100

x86/pci: Simplify code by using the new dmi_get_bios_year() helper

...instead of open coding its functionality.

No changes in functionality.

Signed-off-by: Andy Shevchenko 
Cc: Bjorn Helgaas 
Cc: Jean Delvare 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20180222125923.57385-2-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/pci/acpi.c| 8 ++--
 arch/x86/pci/direct.c  | 5 ++---
 arch/x86/pci/mmconfig-shared.c | 9 ++---
 3 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 7df49c40665e..00e60de30328 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -140,12 +140,8 @@ static const struct dmi_system_id pci_crs_quirks[] 
__initconst = {
 
 void __init pci_acpi_crs_quirks(void)
 {
-   int year;
-
-   if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008) {
-   if (iomem_resource.end <= 0x)
-   pci_use_crs = false;
-   }
+   if ((dmi_get_bios_year() < 2008) && (iomem_resource.end <= 0x))
+   pci_use_crs = false;
 
dmi_check_system(pci_crs_quirks);
 
diff --git a/arch/x86/pci/direct.c b/arch/x86/pci/direct.c
index 2d9503323d10..a51074c55982 100644
--- a/arch/x86/pci/direct.c
+++ b/arch/x86/pci/direct.c
@@ -195,14 +195,13 @@ static const struct pci_raw_ops pci_direct_conf2 = {
 static int __init pci_sanity_check(const struct pci_raw_ops *o)
 {
u32 x = 0;
-   int year, devfn;
+   int devfn;
 
if (pci_probe & PCI_NO_CHECKS)
return 1;
/* Assume Type 1 works for newer systems.
   This handles machines that don't have anything on PCI Bus 0. */
-   dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL);
-   if (year >= 2001)
+   if (dmi_get_bios_year() >= 2001)
return 1;
 
for (devfn = 0; devfn < 0x100; devfn++) {
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0b40482578b8 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -547,19 +547,14 @@ static void __init pci_mmcfg_reject_broken(int early)
 static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
struct acpi_mcfg_allocation *cfg)
 {
-   int year;
-
if (cfg->address < 0x)
return 0;
 
if (!strncmp(mcfg->header.oem_id, "SGI", 3))
return 0;
 
-   if (mcfg->header.revision >= 1) {
-   if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
-   year >= 2010)
-   return 0;
-   }
+   if ((mcfg->header.revision >= 1) && (dmi_get_bios_year() >= 2010))
+   return 0;
 
pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
   "is above 4GB, ignored\n", cfg->pci_segment,

[PATCH v11 6/7] PCI: Unify wait for link active into generic pci

[Oza Pawandeep]

Clients such as pciehp, dpc are using pcie_wait_link_active, which waits
till the link becomes active or inactive.

Made generic function and moved it to drivers/pci/pci.c

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 18a42f8..de9b0ea 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -231,25 +231,11 @@ bool pciehp_check_link_active(struct controller *ctrl)
return ret;
 }
 
-static void __pcie_wait_link_active(struct controller *ctrl, bool active)
+static bool pcie_wait_link_active(struct controller *ctrl)
 {
-   int timeout = 1000;
-
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   while (timeout > 0) {
-   msleep(10);
-   timeout -= 10;
-   if (pciehp_check_link_active(ctrl) == active)
-   return;
-   }
-   ctrl_dbg(ctrl, "Data Link Layer Link Active not %s in 1000 msec\n",
-   active ? "set" : "cleared");
-}
+   struct pci_dev *pdev = ctrl_dev(ctrl);
 
-static void pcie_wait_link_active(struct controller *ctrl)
-{
-   __pcie_wait_link_active(ctrl, true);
+   return pci_wait_for_link(pdev, true);
 }
 
 static bool pci_bus_check_dev(struct pci_bus *bus, int devfn)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd1..f8d44b4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4176,6 +4176,37 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
return 0;
 }
 
+/**
+ * pci_wait_for_link - Wait for link till its active/inactive
+ * @pdev: Bridge device
+ * @active: waiting for active or inactive ?
+ *
+ * Use this to wait till link becomes active or inactive.
+ */
+bool pci_wait_for_link(struct pci_dev *pdev, bool active)
+{
+   int timeout = 1000;
+   bool ret;
+   u16 lnk_status;
+
+   for (;;) {
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
+   if (ret == active)
+   return true;
+   if (timeout <= 0)
+   break;
+   timeout -= 10;
+   }
+
+   dev_printk(KERN_DEBUG, &pdev->dev,
+  "Data Link Layer Link Active not %s in 1000 msec\n",
+  active ? "set" : "cleared");
+
+   return false;
+}
+EXPORT_SYMBOL(pci_wait_for_link);
+
 void pci_reset_secondary_bus(struct pci_dev *dev)
 {
u16 ctrl;
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 5c01c63..e15bcda 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -120,19 +120,9 @@ static int dpc_wait_rp_inactive(struct dpc_dev *dpc)
 
 static void dpc_wait_link_inactive(struct dpc_dev *dpc)
 {
-   unsigned long timeout = jiffies + HZ;
struct pci_dev *pdev = dpc->dev->port;
-   struct device *dev = &dpc->dev->device;
-   u16 lnk_status;
 
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
-   while (lnk_status & PCI_EXP_LNKSTA_DLLLA &&
-   !time_after(jiffies, timeout)) {
-   msleep(10);
-   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
-   }
-   if (lnk_status & PCI_EXP_LNKSTA_DLLLA)
-   dev_warn(dev, "Link state not disabled for DPC event\n");
+   pci_wait_for_link(pdev, false);
 }
 
 /**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 024a1be..cb674c3 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1195,6 +1195,7 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
 int pci_request_selected_regions(struct pci_dev *, int, const char *);
 int pci_request_selected_regions_exclusive(struct pci_dev *, int, const char 
*);
 void pci_release_selected_regions(struct pci_dev *, int);
+bool pci_wait_for_link(struct pci_dev *pdev, bool active);
 
 /* drivers/pci/bus.c */
 struct pci_bus *pci_bus_get(struct pci_bus *bus);
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] perf annotate: Support to display the LBR data in tui mode

[Peter Zijlstra]

On Fri, Feb 23, 2018 at 10:35:58PM +0800, Jin Yao wrote:
> Unlike the perf report interactive annotate mode, the perf annotate
> doesn't display the LBR data.
> 
> perf record -b ...
> perf annotate function
> 
> It should show IPC/cycle, but it doesn't.

There is far more than IPC/cycle for the LBR data, so this Changelog is
misleading.

Also, I think that this patch goes the wrong way, we should reduce the
divergence of the various modes, not make it worse.

[tip:x86/platform] ACPI/sleep: Simplify code by using the new dmi_get_bios_year() helper

[tip-bot for Andy Shevchenko]

Commit-ID:  9c0a30b67bd916a7da1a7101dbf3115e5f10d852
Gitweb: https://git.kernel.org/tip/9c0a30b67bd916a7da1a7101dbf3115e5f10d852
Author: Andy Shevchenko 
AuthorDate: Thu, 22 Feb 2018 14:59:22 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:20:30 +0100

ACPI/sleep: Simplify code by using the new dmi_get_bios_year() helper

...instead of open coding its functionality.

No changes in functionality.

Signed-off-by: Andy Shevchenko 
Cc: Bjorn Helgaas 
Cc: Jean Delvare 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20180222125923.57385-3-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 drivers/acpi/sleep.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 46cde0912762..b35923e3a926 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -376,12 +376,10 @@ void __init acpi_sleep_no_blacklist(void)
 
 static void __init acpi_sleep_dmi_check(void)
 {
-   int year;
-
if (ignore_blacklist)
return;
 
-   if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year >= 2012)
+   if (dmi_get_bios_year() >= 2012)
acpi_nvs_nosave_s3();
 
dmi_check_system(acpisleep_dmi_table);

[PATCH v11 5/7] PCI/AER: Unify aer error defines at single space

[Oza Pawandeep]

This patch moves AER error defines to drivers/pci/pci.h.
So that it unifies the error repoting codes at single place along with dpc

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..7ae9bb3 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -56,6 +56,7 @@
 #include 
 
 #include "apei-internal.h"
+#include "../../pci/pci.h"
 
 #define GHES_PFX   "GHES: "
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8575da..c8394ec 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,7 +343,11 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,
 void pci_enable_acs(struct pci_dev *dev);
 
 /* PCI error reporting and recovery */
-#define DPC_FATAL  4
+#define AER_NONFATAL   0
+#define AER_FATAL  1
+#define AER_CORRECTABLE2
+
+#define DPC_FATAL  4
 
 void pcie_do_recovery(struct pci_dev *dev, int severity);
 
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c 
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 6a352e6..4c59f37 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -19,6 +19,7 @@
 #include 
 
 #include "aerdrv.h"
+#include "../../pci.h"
 #include 
 
 #define AER_AGENT_RECEIVER 0
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 8f87bbe..3eac8ed 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -11,10 +11,6 @@
 #include 
 #include 
 
-#define AER_NONFATAL   0
-#define AER_FATAL  1
-#define AER_CORRECTABLE2
-
 struct pci_dev;
 
 struct aer_header_log_regs {
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 9c68986..d75c75b 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include "../../../drivers/pci/pci.h"
 
 /*
  * MCE Extended Error Log trace event
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[tip:x86/platform] dmi: Introduce the dmi_get_bios_year() helper function

[tip-bot for Andy Shevchenko]

Commit-ID:  492a1abd61e4b4f78c1c5804840a304a9e32da04
Gitweb: https://git.kernel.org/tip/492a1abd61e4b4f78c1c5804840a304a9e32da04
Author: Andy Shevchenko 
AuthorDate: Thu, 22 Feb 2018 14:59:20 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:20:30 +0100

dmi: Introduce the dmi_get_bios_year() helper function

The pattern to only extract the year portion of date is used in
several places and more users may come.

By using this helper they may create slightly cleaner code.

Signed-off-by: Andy Shevchenko 
[ Minor stylistic cleanup. ]
Cc: Bjorn Helgaas 
Cc: Jean Delvare 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20180222125923.57385-1-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 include/linux/dmi.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index 46e151172d95..0bade156e908 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -147,4 +147,13 @@ static inline const struct dmi_system_id *
 
 #endif
 
+static inline int dmi_get_bios_year(void)
+{
+   int year;
+
+   dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL);
+
+   return year;
+}
+
 #endif /* __DMI_H__ */

[PATCH v11 3/7] PCI/ERR: add mutex to synchronize recovery

[Oza Pawandeep]

This patch protects pci_do_recovery with mutex.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index fcd5add..f830975 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -20,6 +20,8 @@
 #include 
 #include "portdrv.h"
 
+static DEFINE_MUTEX(pci_err_recovery_lock);
+
 struct aer_broadcast_data {
enum pci_channel_state state;
enum pci_ers_result result;
@@ -283,6 +285,8 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
pci_ers_result_t status, result = PCI_ERS_RESULT_RECOVERED;
enum pci_channel_state state;
 
+   mutex_lock(&pci_err_recovery_lock);
+
if (severity == AER_FATAL)
state = pci_channel_io_frozen;
else
@@ -326,9 +330,11 @@ void pcie_do_recovery(struct pci_dev *dev, int severity)
report_resume);
 
dev_info(&dev->dev, "Device recovery successful\n");
+   mutex_unlock(&pci_err_recovery_lock);
return;
 
 failed:
/* TODO: Should kernel panic here? */
dev_info(&dev->dev, "Device recovery failed\n");
+   mutex_unlock(&pci_err_recovery_lock);
 }
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.,
a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[tip:x86/pti] KVM/x86: Remove indirect MSR op calls from SPEC_CTRL

[tip-bot for Paolo Bonzini]

Commit-ID:  ecb586bd29c99fb4de599dec388658e74388daad
Gitweb: https://git.kernel.org/tip/ecb586bd29c99fb4de599dec388658e74388daad
Author: Paolo Bonzini 
AuthorDate: Thu, 22 Feb 2018 16:43:17 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:24:35 +0100

KVM/x86: Remove indirect MSR op calls from SPEC_CTRL

Having a paravirt indirect call in the IBRS restore path is not a
good idea, since we are trying to protect from speculative execution
of bogus indirect branch targets.  It is also slower, so use
native_wrmsrl() on the vmentry path too.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Jim Mattson 
Cc: David Woodhouse 
Cc: KarimAllah Ahmed 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Thomas Gleixner 
Cc: k...@vger.kernel.org
Cc: sta...@vger.kernel.org
Fixes: d28b387fb74da95d69d2615732f50cceb38e9a4d
Link: http://lkml.kernel.org/r/20180222154318.20361-2-pbonz...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kvm/svm.c | 7 ---
 arch/x86/kvm/vmx.c | 7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index b3e488a74828..1598beeda11c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -5355,7 +5356,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
 * being speculatively taken.
 */
if (svm->spec_ctrl)
-   wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl);
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl);
 
asm volatile (
"push %%" _ASM_BP "; \n\t"
@@ -5465,10 +5466,10 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
 * save it.
 */
if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
-   rdmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl);
+   svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
 
if (svm->spec_ctrl)
-   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, 0);
 
/* Eliminate branch target predictions from guest mode */
vmexit_fill_RSB();
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3dec126aa302..0927be315965 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "trace.h"
@@ -9452,7 +9453,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
 * being speculatively taken.
 */
if (vmx->spec_ctrl)
-   wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
 
vmx->__launched = vmx->loaded_vmcs->launched;
asm(
@@ -9588,10 +9589,10 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu 
*vcpu)
 * save it.
 */
if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
-   rdmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl);
+   vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
 
if (vmx->spec_ctrl)
-   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, 0);
 
/* Eliminate branch target predictions from guest mode */
vmexit_fill_RSB();

[tip:x86/pti] KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely()

[tip-bot for Paolo Bonzini]

Commit-ID:  946fbbc13dce68902f64515b610eeb2a6c3d7a64
Gitweb: https://git.kernel.org/tip/946fbbc13dce68902f64515b610eeb2a6c3d7a64
Author: Paolo Bonzini 
AuthorDate: Thu, 22 Feb 2018 16:43:18 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:24:36 +0100

KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path 
as unlikely()

vmx_vcpu_run() and svm_vcpu_run() are large functions, and giving
branch hints to the compiler can actually make a substantial cycle
difference by keeping the fast path contiguous in memory.

With this optimization, the retpoline-guest/retpoline-host case is
about 50 cycles faster.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Jim Mattson 
Cc: David Woodhouse 
Cc: KarimAllah Ahmed 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Thomas Gleixner 
Cc: k...@vger.kernel.org
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180222154318.20361-3-pbonz...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kvm/svm.c | 2 +-
 arch/x86/kvm/vmx.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 1598beeda11c..24c9521ebc24 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5465,7 +5465,7 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
 * If the L02 MSR bitmap does not intercept the MSR, then we need to
 * save it.
 */
-   if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
+   if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))
svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
 
if (svm->spec_ctrl)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 0927be315965..7f8401d05939 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9588,7 +9588,7 @@ static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
 * If the L02 MSR bitmap does not intercept the MSR, then we need to
 * save it.
 */
-   if (!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))
+   if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL)))
vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL);
 
if (vmx->spec_ctrl)

[tip:x86/platform] pci: Simplify code by using the new dmi_get_bios_year() helper

[tip-bot for Andy Shevchenko]

Commit-ID:  ac95090a0440be1b17aa1b5d9462d9c67146ce0b
Gitweb: https://git.kernel.org/tip/ac95090a0440be1b17aa1b5d9462d9c67146ce0b
Author: Andy Shevchenko 
AuthorDate: Thu, 22 Feb 2018 14:59:23 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:20:31 +0100

pci: Simplify code by using the new dmi_get_bios_year() helper

...instead of open coding its functionality.

No changes in functionality.

Signed-off-by: Andy Shevchenko 
Cc: Bjorn Helgaas 
Cc: Jean Delvare 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Thomas Gleixner 
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20180222125923.57385-4-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 drivers/pci/pci.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..ae654e21439d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2258,8 +2258,6 @@ void pci_config_pm_runtime_put(struct pci_dev *pdev)
  */
 bool pci_bridge_d3_possible(struct pci_dev *bridge)
 {
-   unsigned int year;
-
if (!pci_is_pcie(bridge))
return false;
 
@@ -2287,10 +2285,8 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
 * It should be safe to put PCIe ports from 2015 or newer
 * to D3.
 */
-   if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
-   year >= 2015) {
+   if (dmi_get_bios_year() >= 2015)
return true;
-   }
break;
}
 

[PATCH v3] x86: consider effective protection attributes in W+X check

[Jan Beulich]

Using just the leaf page table entry flags would cause a false warning
in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
Hand through both the current entry's flags as well as the accumulated
effective value (the latter as pgprotval_t instead of pgprot_t, as it's
not an actual entry's value).

This in particular eliminates the false W+X warning when running under
Xen, as commit 2cc42bac1c ("x86-64/Xen: eliminate W+X mappings") has to
make the necessary adjustment in L2 rather than L1 (the reason is
explained there). I.e. _PAGE_RW is clear there in L1, but _PAGE_NX is
set in L2.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
---
v3: Fix build issue with CONFIG_KASAN.
v2: Re-base onto tip tree. Add Xen related paragraph to description.
---
 arch/x86/mm/dump_pagetables.c |   94 +-
 1 file changed, 58 insertions(+), 36 deletions(-)

--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -29,6 +29,7 @@
 struct pg_state {
int level;
pgprot_t current_prot;
+   pgprotval_t effective_prot;
unsigned long start_address;
unsigned long current_address;
const struct addr_marker *marker;
@@ -235,9 +236,9 @@ static unsigned long normalize_addr(unsi
  * print what we collected so far.
  */
 static void note_page(struct seq_file *m, struct pg_state *st,
- pgprot_t new_prot, int level)
+ pgprot_t new_prot, pgprotval_t new_eff, int level)
 {
-   pgprotval_t prot, cur;
+   pgprotval_t prot, cur, eff;
static const char units[] = "BKMGTPE";
 
/*
@@ -247,23 +248,24 @@ static void note_page(struct seq_file *m
 */
prot = pgprot_val(new_prot);
cur = pgprot_val(st->current_prot);
+   eff = st->effective_prot;
 
if (!st->level) {
/* First entry */
st->current_prot = new_prot;
+   st->effective_prot = new_eff;
st->level = level;
st->marker = address_markers;
st->lines = 0;
pt_dump_seq_printf(m, st->to_dmesg, "---[ %s ]---\n",
   st->marker->name);
-   } else if (prot != cur || level != st->level ||
+   } else if (prot != cur || new_eff != eff || level != st->level ||
   st->current_address >= st->marker[1].start_address) {
const char *unit = units;
unsigned long delta;
int width = sizeof(unsigned long) * 2;
-   pgprotval_t pr = pgprot_val(st->current_prot);
 
-   if (st->check_wx && (pr & _PAGE_RW) && !(pr & _PAGE_NX)) {
+   if (st->check_wx && (eff & _PAGE_RW) && !(eff & _PAGE_NX)) {
WARN_ONCE(1,
  "x86/mm: Found insecure W+X mapping at 
address %p/%pS\n",
  (void *)st->start_address,
@@ -317,21 +319,30 @@ static void note_page(struct seq_file *m
 
st->start_address = st->current_address;
st->current_prot = new_prot;
+   st->effective_prot = new_eff;
st->level = level;
}
 }
 
-static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t 
addr, unsigned long P)
+static inline pgprotval_t effective_prot(pgprotval_t prot1, pgprotval_t prot2)
+{
+   return (prot1 & prot2 & (_PAGE_USER | _PAGE_RW)) |
+  ((prot1 | prot2) & _PAGE_NX);
+}
+
+static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr,
+  pgprotval_t eff_in, unsigned long P)
 {
int i;
pte_t *start;
-   pgprotval_t prot;
+   pgprotval_t prot, eff;
 
start = (pte_t *)pmd_page_vaddr(addr);
for (i = 0; i < PTRS_PER_PTE; i++) {
prot = pte_flags(*start);
+   eff = effective_prot(eff_in, prot);
st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
-   note_page(m, st, __pgprot(prot), 5);
+   note_page(m, st, __pgprot(prot), eff, 5);
start++;
}
 }
@@ -351,7 +362,7 @@ static inline bool kasan_page_table(stru
(pgtable_l5_enabled && __pa(pt) == __pa(kasan_zero_p4d)) ||
__pa(pt) == __pa(kasan_zero_pud)) {
pgprotval_t prot = pte_flags(kasan_zero_pte[0]);
-   note_page(m, st, __pgprot(prot), 5);
+   note_page(m, st, __pgprot(prot), 0, 5);
return true;
}
return false;
@@ -366,42 +377,45 @@ static inline bool kasan_page_table(stru
 
 #if PTRS_PER_PMD > 1
 
-static void walk_pmd_level(struct seq_file *m, struct pg_state *st, pud_t 
addr, unsigned long P)
+static void walk_pmd_level(struct seq_file *m, struct pg_state *st, pud_t addr,
+  pgprotval_t eff_in, unsigned long P)
 {
int i;
pmd_t *start, *pmd_start;
-   pgprotval_

[tip:locking/urgent] locking/xchg/alpha: Clean up barrier usage by using smp_mb() in place of __ASM__MB

[tip-bot for Andrea Parri]

Commit-ID:  79d442461df7478cdd0c50d9b8a76f431f150fa3
Gitweb: https://git.kernel.org/tip/79d442461df7478cdd0c50d9b8a76f431f150fa3
Author: Andrea Parri 
AuthorDate: Thu, 22 Feb 2018 10:24:29 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:38:15 +0100

locking/xchg/alpha: Clean up barrier usage by using smp_mb() in place of 
__ASM__MB

Replace each occurrence of __ASM__MB with a (trailing) smp_mb() in
xchg(), cmpxchg(), and remove the now unused __ASM__MB definitions;
this improves readability, with no additional synchronization cost.

Suggested-by: Will Deacon 
Signed-off-by: Andrea Parri 
Acked-by: Paul E. McKenney 
Cc: Alan Stern 
Cc: Andrew Morton 
Cc: Ivan Kokshaysky 
Cc: Linus Torvalds 
Cc: Matt Turner 
Cc: Peter Zijlstra 
Cc: Richard Henderson 
Cc: Thomas Gleixner 
Cc: linux-al...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1519291469-5702-1-git-send-email-parri.and...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/alpha/include/asm/cmpxchg.h |  6 --
 arch/alpha/include/asm/xchg.h| 16 
 2 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/alpha/include/asm/cmpxchg.h b/arch/alpha/include/asm/cmpxchg.h
index 46ebf14aed4e..8a2b331e43fe 100644
--- a/arch/alpha/include/asm/cmpxchg.h
+++ b/arch/alpha/include/asm/cmpxchg.h
@@ -6,7 +6,6 @@
  * Atomic exchange routines.
  */
 
-#define __ASM__MB
 #define xchg(type, args...)__xchg ## type ## _local(args)
 #define cmpxchg(type, args...) __cmpxchg ## type ## _local(args)
 #include 
@@ -33,10 +32,6 @@
cmpxchg_local((ptr), (o), (n)); \
 })
 
-#ifdef CONFIG_SMP
-#undef __ASM__MB
-#define __ASM__MB  "\tmb\n"
-#endif
 #undef xchg
 #undef cmpxchg
 #define xchg(type, args...)__xchg ##type(args)
@@ -64,7 +59,6 @@
cmpxchg((ptr), (o), (n));   \
 })
 
-#undef __ASM__MB
 #undef cmpxchg
 
 #endif /* _ALPHA_CMPXCHG_H */
diff --git a/arch/alpha/include/asm/xchg.h b/arch/alpha/include/asm/xchg.h
index e2660866ce97..e1facf6fc244 100644
--- a/arch/alpha/include/asm/xchg.h
+++ b/arch/alpha/include/asm/xchg.h
@@ -28,12 +28,12 @@ xchg(_u8, volatile char *m, unsigned long val)
"   or  %1,%2,%2\n"
"   stq_c   %2,0(%3)\n"
"   beq %2,2f\n"
-   __ASM__MB
".subsection 2\n"
"2: br  1b\n"
".previous"
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
: "r" ((long)m), "1" (val) : "memory");
+   smp_mb();
 
return ret;
 }
@@ -52,12 +52,12 @@ xchg(_u16, volatile short *m, unsigned long val)
"   or  %1,%2,%2\n"
"   stq_c   %2,0(%3)\n"
"   beq %2,2f\n"
-   __ASM__MB
".subsection 2\n"
"2: br  1b\n"
".previous"
: "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
: "r" ((long)m), "1" (val) : "memory");
+   smp_mb();
 
return ret;
 }
@@ -72,12 +72,12 @@ xchg(_u32, volatile int *m, unsigned long val)
"   bis $31,%3,%1\n"
"   stl_c %1,%2\n"
"   beq %1,2f\n"
-   __ASM__MB
".subsection 2\n"
"2: br 1b\n"
".previous"
: "=&r" (val), "=&r" (dummy), "=m" (*m)
: "rI" (val), "m" (*m) : "memory");
+   smp_mb();
 
return val;
 }
@@ -92,12 +92,12 @@ xchg(_u64, volatile long *m, unsigned long val)
"   bis $31,%3,%1\n"
"   stq_c %1,%2\n"
"   beq %1,2f\n"
-   __ASM__MB
".subsection 2\n"
"2: br 1b\n"
".previous"
: "=&r" (val), "=&r" (dummy), "=m" (*m)
: "rI" (val), "m" (*m) : "memory");
+   smp_mb();
 
return val;
 }
@@ -150,12 +150,12 @@ cmpxchg(_u8, volatile char *m, unsigned char old, 
unsigned char new)
"   stq_c   %2,0(%4)\n"
"   beq %2,3f\n"
"2:\n"
-   __ASM__MB
".subsection 2\n"
"3: br  1b\n"
".previous"
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
+   smp_mb();
 
return prev;
 }
@@ -177,12 +177,12 @@ cmpxchg(_u16, volatile short *m, unsigned short old, 
unsigned short new)
"   stq_c   %2,0(%4)\n"
"   beq %2,3f\n"
"2:\n"
-   __ASM__MB
".subsection 2\n"
"3: br  1b\n"
".previous"
: "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
: "r" ((long)m), "Ir" (old), "1" (new) : "memory");
+   smp_mb();
 
return prev;
 }
@@ -200,12 +200,12 @@ cmpxchg(_u32, volatile int *m, int old, int new)
"   stl_c %1,%2\n"
"   beq %1,3f\n"
"2:\n"
-   __ASM__MB
".subsection 2\n"
"3: br 1b\

[tip:locking/urgent] locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs

[tip-bot for Andrea Parri]

Commit-ID:  472e8c55cf6622d1c112dc2bc777f68bbd4189db
Gitweb: https://git.kernel.org/tip/472e8c55cf6622d1c112dc2bc777f68bbd4189db
Author: Andrea Parri 
AuthorDate: Thu, 22 Feb 2018 10:24:48 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:38:16 +0100

locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs

Successful RMW operations are supposed to be fully ordered, but
Alpha's xchg() and cmpxchg() do not meet this requirement.

Will Deacon noticed the bug:

  > So MP using xchg:
  >
  > WRITE_ONCE(x, 1)
  > xchg(y, 1)
  >
  > smp_load_acquire(y) == 1
  > READ_ONCE(x) == 0
  >
  > would be allowed.

... which thus violates the above requirement.

Fix it by adding a leading smp_mb() to the xchg() and cmpxchg() implementations.

Reported-by: Will Deacon 
Signed-off-by: Andrea Parri 
Acked-by: Paul E. McKenney 
Cc: Alan Stern 
Cc: Andrew Morton 
Cc: Ivan Kokshaysky 
Cc: Linus Torvalds 
Cc: Matt Turner 
Cc: Peter Zijlstra 
Cc: Richard Henderson 
Cc: Thomas Gleixner 
Cc: linux-al...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1519291488-5752-1-git-send-email-parri.and...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/alpha/include/asm/xchg.h | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/include/asm/xchg.h b/arch/alpha/include/asm/xchg.h
index e1facf6fc244..e2b59fac5257 100644
--- a/arch/alpha/include/asm/xchg.h
+++ b/arch/alpha/include/asm/xchg.h
@@ -12,6 +12,10 @@
  * Atomic exchange.
  * Since it can be used to implement critical sections
  * it must clobber "memory" (also for interrupts in UP).
+ *
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
  */
 
 static inline unsigned long
@@ -19,6 +23,7 @@ xchg(_u8, volatile char *m, unsigned long val)
 {
unsigned long ret, tmp, addr64;
 
+   smp_mb();
__asm__ __volatile__(
"   andnot  %4,7,%3\n"
"   insbl   %1,%4,%1\n"
@@ -43,6 +48,7 @@ xchg(_u16, volatile short *m, unsigned long val)
 {
unsigned long ret, tmp, addr64;
 
+   smp_mb();
__asm__ __volatile__(
"   andnot  %4,7,%3\n"
"   inswl   %1,%4,%1\n"
@@ -67,6 +73,7 @@ xchg(_u32, volatile int *m, unsigned long val)
 {
unsigned long dummy;
 
+   smp_mb();
__asm__ __volatile__(
"1: ldl_l %0,%4\n"
"   bis $31,%3,%1\n"
@@ -87,6 +94,7 @@ xchg(_u64, volatile long *m, unsigned long val)
 {
unsigned long dummy;
 
+   smp_mb();
__asm__ __volatile__(
"1: ldq_l %0,%4\n"
"   bis $31,%3,%1\n"
@@ -128,9 +136,12 @@ xchg(, volatile void *ptr, unsigned long x, int size)
  * store NEW in MEM.  Return the initial value in MEM.  Success is
  * indicated by comparing RETURN with OLD.
  *
- * The memory barrier is placed in SMP unconditionally, in order to
- * guarantee that dependency ordering is preserved when a dependency
- * is headed by an unsuccessful operation.
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
+ * The trailing memory barrier is placed in SMP unconditionally, in
+ * order to guarantee that dependency ordering is preserved when a
+ * dependency is headed by an unsuccessful operation.
  */
 
 static inline unsigned long
@@ -138,6 +149,7 @@ cmpxchg(_u8, volatile char *m, unsigned char old, 
unsigned char new)
 {
unsigned long prev, tmp, cmp, addr64;
 
+   smp_mb();
__asm__ __volatile__(
"   andnot  %5,7,%4\n"
"   insbl   %1,%5,%1\n"
@@ -165,6 +177,7 @@ cmpxchg(_u16, volatile short *m, unsigned short old, 
unsigned short new)
 {
unsigned long prev, tmp, cmp, addr64;
 
+   smp_mb();
__asm__ __volatile__(
"   andnot  %5,7,%4\n"
"   inswl   %1,%5,%1\n"
@@ -192,6 +205,7 @@ cmpxchg(_u32, volatile int *m, int old, int new)
 {
unsigned long prev, cmp;
 
+   smp_mb();
__asm__ __volatile__(
"1: ldl_l %0,%5\n"
"   cmpeq %0,%3,%1\n"
@@ -215,6 +229,7 @@ cmpxchg(_u64, volatile long *m, unsigned long old, 
unsigned long new)
 {
unsigned long prev, cmp;
 
+   smp_mb();
__asm__ __volatile__(
"1: ldq_l %0,%5\n"
"   cmpeq %0,%3,%1\n"

[tip:x86/urgent] x86/topology: Fix function name in documentation

[tip-bot for Dou Liyang]

Commit-ID:  0c52f7c5499dc708a64742da0cb7eb4f6d94588b
Gitweb: https://git.kernel.org/tip/0c52f7c5499dc708a64742da0cb7eb4f6d94588b
Author: Dou Liyang 
AuthorDate: Thu, 22 Feb 2018 16:48:12 +0800
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:40:12 +0100

x86/topology: Fix function name in documentation

topology_sibling_cpumask() is the correct thread-related topology
function in the kernel:

  s/topology_sibling_mask/topology_sibling_cpumask

Signed-off-by: Dou Liyang 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: cor...@lwn.net
Cc: linux-...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180222084812.14497-1-douly.f...@cn.fujitsu.com
Signed-off-by: Ingo Molnar 
---
 Documentation/x86/topology.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/x86/topology.txt b/Documentation/x86/topology.txt
index f3e9d7e9ed6c..2953e3ec9a02 100644
--- a/Documentation/x86/topology.txt
+++ b/Documentation/x86/topology.txt
@@ -108,7 +108,7 @@ The topology of a system is described in the units of:
 
 The number of online threads is also printed in /proc/cpuinfo "siblings."
 
-  - topology_sibling_mask():
+  - topology_sibling_cpumask():
 
 The cpumask contains all online threads in the core to which a thread
 belongs.

[tip:x86/mm] x86/boot/compressed/64: Fix warning for 32-bit trampoline memcpy()

[tip-bot for Arnd Bergmann]

Commit-ID:  fba407e1710ae4c558e1e2b55b5a55b2c07a596d
Gitweb: https://git.kernel.org/tip/fba407e1710ae4c558e1e2b55b5a55b2c07a596d
Author: Arnd Bergmann 
AuthorDate: Thu, 22 Feb 2018 12:28:05 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:29:54 +0100

x86/boot/compressed/64: Fix warning for 32-bit trampoline memcpy()

GCC-8 warns that we copy TRAMPOLINE_32BIT_CODE_SIZE bytes from the pointer
to the function into actual trampoline, when that pointer is only 8 bytes:

  In file included from arch/x86/boot/compressed/pgtable_64.c:3:
  arch/x86/boot/compressed/pgtable_64.c: In function 'paging_prepare':
  arch/x86/boot/compressed/../string.h:18:23: error: '__builtin_memcpy' reading 
96 bytes from a region of size 8 [-Werror=stringop-overflow=]
   #define memcpy(d,s,l) __builtin_memcpy(d,s,l)
   ^~~
  arch/x86/boot/compressed/pgtable_64.c:62:2: note: in expansion of macro 
'memcpy'
memcpy(trampoline + TRAMPOLINE_32BIT_CODE_OFFSET / sizeof(unsigned long),
^~

It turns out that the declaration is incorrect here: trampoline_32bit_src
is defined as a function in arch/x86/boot/compressed/head_64.S, not a
pointer to a function. Fixing the prototype to match addresses the warning.

Suggested-by: Kirill A. Shutemov 
Signed-off-by: Arnd Bergmann 
Cc: Linus Torvalds 
Cc: Martin Sebor 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: b91993a87aff ("x86/boot/compressed/64: Prepare trampoline memory")
Link: http://lkml.kernel.org/r/20180222112817.456380-1-a...@arndb.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/boot/compressed/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/boot/compressed/pgtable.h 
b/arch/x86/boot/compressed/pgtable.h
index 6e0db2260147..5e0b1c4abef4 100644
--- a/arch/x86/boot/compressed/pgtable.h
+++ b/arch/x86/boot/compressed/pgtable.h
@@ -12,7 +12,7 @@
 
 #ifndef __ASSEMBLER__
 
-extern void (*trampoline_32bit_src)(void *return_ptr);
+extern void trampoline_32bit_src(void *return_ptr);
 
 #endif /* __ASSEMBLER__ */
 #endif /* BOOT_COMPRESSED_PAGETABLE_H */

[tip:x86/urgent] x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations

[tip-bot for Samuel Neves]

Commit-ID:  4596749339e06dc7a424fc08a15eded850ed78b7
Gitweb: https://git.kernel.org/tip/4596749339e06dc7a424fc08a15eded850ed78b7
Author: Samuel Neves 
AuthorDate: Wed, 21 Feb 2018 20:50:36 +
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:47:47 +0100

x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across 
CPU hotplug operations

Without this fix, /proc/cpuinfo will display an incorrect amount
of CPU cores, after bringing them offline and online again, as
exemplified below:

  $ cat /proc/cpuinfo | grep cores
  cpu cores : 4
  cpu cores : 8
  cpu cores : 8
  cpu cores : 20
  cpu cores : 4
  cpu cores : 3
  cpu cores : 2
  cpu cores : 2

This patch fixes this by always zeroing the booted_cores variable
upon turning off a logical CPU.

Tested-by: Dou Liyang 
Signed-off-by: Samuel Neves 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: jgr...@suse.com
Cc: l...@kernel.org
Cc: pra...@redhat.com
Cc: vkuzn...@redhat.com
Link: http://lkml.kernel.org/r/20180221205036.5244-1-sne...@dei.uc.pt
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/smpboot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 9eee25d07586..ff99e2b6fc54 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1437,6 +1437,7 @@ static void remove_siblinginfo(int cpu)
cpumask_clear(topology_sibling_cpumask(cpu));
cpumask_clear(topology_core_cpumask(cpu));
c->cpu_core_id = 0;
+   c->booted_cores = 0;
cpumask_clear_cpu(cpu, cpu_sibling_setup_mask);
recompute_smt_state();
 }

Re: [PATCH v1 2/2] drm/panel: otm8009a: Add support for the optional power-supply

[Philippe CORNU]

Hi Thierry & David,

May I ask you please your feedback on this small patch?
Many thanks,

Philippe :-)

On 02/05/2018 10:45 AM, Philippe Cornu wrote:
> Add support for the optional power-supply.
> 
> Note: A "dummy regulator" is returned by devm_regulator_get()
> if the optional regulator is not present in the device tree,
> simplifying the source code when enabling/disabling the regulator.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 17 +
>   1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index 72530983d55d..90f1ae4af93c 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -11,6 +11,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   
>   #define DRV_NAME "orisetech_otm8009a"
> @@ -62,6 +63,7 @@ struct otm8009a {
>   struct drm_panel panel;
>   struct backlight_device *bl_dev;
>   struct gpio_desc *reset_gpio;
> + struct regulator *supply;
>   bool prepared;
>   bool enabled;
>   };
> @@ -279,6 +281,8 @@ static int otm8009a_unprepare(struct drm_panel *panel)
>   msleep(20);
>   }
>   
> + regulator_disable(ctx->supply);
> +
>   ctx->prepared = false;
>   
>   return 0;
> @@ -292,6 +296,12 @@ static int otm8009a_prepare(struct drm_panel *panel)
>   if (ctx->prepared)
>   return 0;
>   
> + ret = regulator_enable(ctx->supply);
> + if (ret < 0) {
> + DRM_ERROR("failed to enable supply: %d\n", ret);
> + return ret;
> + }
> +
>   if (ctx->reset_gpio) {
>   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
>   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> @@ -414,6 +424,13 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
>   return PTR_ERR(ctx->reset_gpio);
>   }
>   
> + ctx->supply = devm_regulator_get(dev, "power");
> + if (IS_ERR(ctx->supply)) {
> + ret = PTR_ERR(ctx->supply);
> + dev_err(dev, "failed to request regulator: %d\n", ret);
> + return ret;
> + }
> +
>   mipi_dsi_set_drvdata(dsi, ctx);
>   
>   ctx->dev = dev;
> 

[PATCH v2 0/2] v2 patches for stm32-exti irq hierarchy

[Radoslaw Pietrzyk]

Radoslaw Pietrzyk (2):
  irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain
  pinctrl: stm32: Optimizes and enhances stm32gpio irqchip

 drivers/irqchip/irq-stm32-exti.c  | 13 -
 drivers/pinctrl/stm32/pinctrl-stm32.c |  3 ++-
 2 files changed, 2 insertions(+), 14 deletions(-)

-- 
1.9.1

Re: [PATCH v1 1/2] dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel

[Yannick FERTRE]

Reviewed-by: Yannick Fertré 


On 02/08/2018 03:30 PM, Philippe Cornu wrote:
> The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
> TFT LCD panel connected using a MIPI-DSI video interface.
>
> Signed-off-by: Philippe Cornu 
> ---
>   .../bindings/display/panel/raydium,rm68200.txt | 25 
> ++
>   1 file changed, 25 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt 
> b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
> new file mode 100644
> index ..cbb79ef3bfc9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
> @@ -0,0 +1,25 @@
> +Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel
> +
> +The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
> +panel connected using a MIPI-DSI video interface.
> +
> +Required properties:
> +  - compatible: "raydium,rm68200"
> +  - reg: the virtual channel number of a DSI peripheral
> +
> +Optional properties:
> +  - reset-gpios: a GPIO spec for the reset pin (active low).
> +  - power-supply: phandle of the regulator that provides the supply voltage.
> +  - backlight: phandle of the backlight device attached to the panel.
> +
> +Example:
> +&dsi {
> + ...
> + panel@0 {
> + compatible = "raydium,rm68200";
> + reg = <0>;
> + reset-gpios = <&gpiof 15 GPIO_ACTIVE_LOW>;
> + power-supply = <&v1v8>;
> + backlight = <&pwm_backlight>;
> + };
> +};

Re: [PATCH v1 2/2] drm/panel: Add support for Raydium rm68200 panel driver

[Yannick FERTRE]

Reviewed-by: Yannick Fertré 


On 02/08/2018 03:30 PM, Philippe Cornu wrote:
> This patch adds Raydium Semiconductor Corporation rm68200
> 5.5" 720x1280 TFT LCD panel driver (MIPI-DSI video mode).
>
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/Kconfig |   8 +
>   drivers/gpu/drm/panel/Makefile|   1 +
>   drivers/gpu/drm/panel/panel-raydium-rm68200.c | 464 
> ++
>   3 files changed, 473 insertions(+)
>   create mode 100755 drivers/gpu/drm/panel/panel-raydium-rm68200.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 988048ebcc22..08d99dd46765 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -108,6 +108,14 @@ config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
> Pi 7" Touchscreen.  To compile this driver as a module,
> choose M here.
>   
> +config DRM_PANEL_RAYDIUM_RM68200
> + tristate "Raydium rm68200 720x1280 dsi 2dl video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + help
> +   Say Y here if you want to enable support for Raydium rm68200
> +   720x1280 dsi 2dl video mode panel
> +
>   config DRM_PANEL_SAMSUNG_S6E3HA2
>   tristate "Samsung S6E3HA2 DSI video mode panel"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 3d2a88d0e965..f26efc11d746 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>   obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
>   obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
> panel-panasonic-vvx10f034n00.o
>   obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
> panel-raspberrypi-touchscreen.o
> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> new file mode 100755
> index ..f3e15873d05a
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> @@ -0,0 +1,464 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics SA 2017
> + *
> + * Authors: Philippe Cornu 
> + *  Yannick Fertre 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRV_NAME "raydium_rm68200"
> +
> +/*** Manufacturer Command Set ***/
> +#define MCS_CMD_MODE_SW  0xFE /* CMD Mode Switch */
> +#define MCS_CMD1_UCS 0x00 /* User Command Set (UCS = CMD1) */
> +#define MCS_CMD2_P0  0x01 /* Manufacture Command Set Page0 (CMD2 P0) */
> +#define MCS_CMD2_P1  0x02 /* Manufacture Command Set Page1 (CMD2 P1) */
> +#define MCS_CMD2_P2  0x03 /* Manufacture Command Set Page2 (CMD2 P2) */
> +#define MCS_CMD2_P3  0x04 /* Manufacture Command Set Page3 (CMD2 P3) */
> +
> +/* CMD2 P0 commands (Display Options and Power) */
> +#define MCS_STBCTR   0x12 /* TE1 Output Setting Zig-Zag Connection */
> +#define MCS_SGOPCTR  0x16 /* Source Bias Current */
> +#define MCS_SDCTR0x1A /* Source Output Delay Time */
> +#define MCS_INVCTR   0x1B /* Inversion Type */
> +#define MCS_EXT_PWR_IC   0x24 /* External PWR IC Control */
> +#define MCS_SETAVDD  0x27 /* PFM Control for AVDD Output */
> +#define MCS_SETAVEE  0x29 /* PFM Control for AVEE Output */
> +#define MCS_BT2CTR   0x2B /* DDVDL Charge Pump Control */
> +#define MCS_BT3CTR   0x2F /* VGH Charge Pump Control */
> +#define MCS_BT4CTR   0x34 /* VGL Charge Pump Control */
> +#define MCS_VCMCTR   0x46 /* VCOM Output Level Control */
> +#define MCS_SETVGN   0x52 /* VG M/S N Control */
> +#define MCS_SETVGP   0x54 /* VG M/S P Control */
> +#define MCS_SW_CTRL  0x5F /* Interface Control for PFM and MIPI */
> +
> +/* CMD2 P2 commands (GOA Timing Control) - no description in datasheet */
> +#define GOA_VSTV10x00
> +#define GOA_VSTV20x07
> +#define GOA_VCLK10x0E
> +#define GOA_VCLK20x17
> +#define GOA_VCLK_OPT10x20
> +#define GOA_BICLK1   0x2A
> +#define GOA_BICLK2   0x37
> +#define GOA_BICLK3   0x44
> +#define GOA_BICLK4   0x4F
> +#define GOA_BICLK_OPT1   0x5B
> +#define GOA_BICLK_OPT2   0x60
> +#define MCS_GOA_GPO1 0x6D
> +#define MCS_GOA_GPO2 0x71
> +#define MCS_GOA_EQ   0x74
> +#define MCS_GOA_CLK_GALLON 0x7C
> +#define MCS_GOA_FS_SEL0  0x7E
> +#define MCS_GOA_FS_SEL1  0x87
> +#define MCS_GOA_FS_SEL2  0x91
> +#define MCS_GOA_FS_SEL3  0x9B
> +#define MCS_GOA_BS_SEL0  0xAC
> +#define MCS_GOA_BS_SEL1  0xB5
> +#define MCS_GOA_BS_SEL2  0xBF
> +#define MCS_GOA_BS_SEL3  0xC9
> +#define MCS_GOA_BS_SEL4  0xD3
> +
> +/* CMD2 P3 commands (Gamma) */
> +#define MCS_GAMMA_VP 

[PATCH v2 2/2] pinctrl: stm32: Optimizes and enhances stm32gpio irqchip

[Radoslaw Pietrzyk]

- removes unneeded irq_chip.irq_eoi callback
- adds irq_chip.irq_set_wake callback for possible
in the future GPIO wakeup
- adds irq_chip.irq_ack callback

Signed-off-by: Radoslaw Pietrzyk 
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 617df16..6cbcff4 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -268,10 +268,11 @@ static void stm32_gpio_irq_release_resources(struct 
irq_data *irq_data)
 
 static struct irq_chip stm32_gpio_irq_chip = {
.name   = "stm32gpio",
-   .irq_eoi= irq_chip_eoi_parent,
+   .irq_ack   = irq_chip_ack_parent,
.irq_mask   = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
.irq_set_type   = irq_chip_set_type_parent,
+   .irq_set_wake   = irq_chip_set_wake_parent,
.irq_request_resources = stm32_gpio_irq_request_resources,
.irq_release_resources = stm32_gpio_irq_release_resources,
 };
-- 
1.9.1

[PATCH v2 1/2] irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

[Radoslaw Pietrzyk]

- discards setting handle_simple_irq handler for hierarchy interrupts
- removes acking in chained irq handler as this is done by
irq_chip itself inside handle_edge_irq
- removes unneeded irq_domain_ops.xlate callback

Signed-off-by: Radoslaw Pietrzyk 
---
 drivers/irqchip/irq-stm32-exti.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
index 36f0fbe..8013a87 100644
--- a/drivers/irqchip/irq-stm32-exti.c
+++ b/drivers/irqchip/irq-stm32-exti.c
@@ -79,13 +79,6 @@ static unsigned long stm32_exti_pending(struct 
irq_chip_generic *gc)
return irq_reg_readl(gc, stm32_bank->pr_ofst);
 }
 
-static void stm32_exti_irq_ack(struct irq_chip_generic *gc, u32 mask)
-{
-   const struct stm32_exti_bank *stm32_bank = gc->private;
-
-   irq_reg_writel(gc, mask, stm32_bank->pr_ofst);
-}
-
 static void stm32_irq_handler(struct irq_desc *desc)
 {
struct irq_domain *domain = irq_desc_get_handler_data(desc);
@@ -106,7 +99,6 @@ static void stm32_irq_handler(struct irq_desc *desc)
for_each_set_bit(n, &pending, IRQS_PER_BANK) {
virq = irq_find_mapping(domain, irq_base + n);
generic_handle_irq(virq);
-   stm32_exti_irq_ack(gc, BIT(n));
}
}
}
@@ -176,16 +168,12 @@ static int stm32_irq_set_wake(struct irq_data *data, 
unsigned int on)
 static int stm32_exti_alloc(struct irq_domain *d, unsigned int virq,
unsigned int nr_irqs, void *data)
 {
-   struct irq_chip_generic *gc;
struct irq_fwspec *fwspec = data;
irq_hw_number_t hwirq;
 
hwirq = fwspec->param[0];
-   gc = irq_get_domain_generic_chip(d, hwirq);
 
irq_map_generic_chip(d, virq, hwirq);
-   irq_domain_set_info(d, virq, hwirq, &gc->chip_types->chip, gc,
-   handle_simple_irq, NULL, NULL);
 
return 0;
 }
@@ -200,7 +188,6 @@ static void stm32_exti_free(struct irq_domain *d, unsigned 
int virq,
 
 struct irq_domain_ops irq_exti_domain_ops = {
.map= irq_map_generic_chip,
-   .xlate  = irq_domain_xlate_onetwocell,
.alloc  = stm32_exti_alloc,
.free   = stm32_exti_free,
 };
-- 
1.9.1

Re: [PATCH v2] drm/stm: check pitch and size calculations even if !CONFIG_MMU

[Philippe CORNU]

Hi Benjamin,

On 01/31/2018 09:05 AM, Benjamin Gaignard wrote:
> In all cases we have to check pitch and size calculations to speed up
> data transfer.
> 
> Fixes: 21f815bf773c ("drm/stm: drv: Improve data transfers")
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>   drivers/gpu/drm/stm/drv.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 8bc7e8418b8d..9ab00a87f7cc 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -35,7 +35,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
>  struct drm_device *dev,
>  struct drm_mode_create_dumb *args)
>   {
> -#ifdef CONFIG_MMU
>   unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>   
>   /*
> @@ -44,7 +43,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
>*/
>   args->pitch = roundup(min_pitch, 128);
>   args->height = roundup(args->height, 4);
> -#endif

Reviewed-by: Philippe Cornu 

Many thanks,
Philippe :-)

>   
>   return drm_gem_cma_dumb_create_internal(file, dev, args);
>   }
> 

Re: [1/2] ARM: irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

[Radosław Pietrzyk]

Hi Ludovic,
Please check latest v2 patches series and let me know if it works on
stm32h7 as it does on stm32f4

2018-02-22 12:01 GMT+01:00 Radosław Pietrzyk :
> Hi Ludovic,
> I have tested on stm32f429-disco and it works without a problem.
> handle_edge_irq is not used in current implementation because it is
> substituted by handle_simple_irq in an alloc callback either way which
> causes that irq_ack callback is not invoked as well (acking is done in
> chained handler).
>
> 2018-02-22 11:55 GMT+01:00 Ludovic BARRE :
>> Hi Radek
>>
>> I've tested your change on stm32h743i-eval.dts board
>> and gpio-keys tests are not functional.
>> No interrupt occurs when we push or release button
>> (cat /proc/interrupt).
>>
>> Board: stm32h743i-eval.dts
>> Test description: gpio-keys (gpioc 13 => exti 13), with gpio or interrupt
>> property.
>>
>> comment below
>>
>>
>> On 02/21/2018 02:50 PM, radek wrote:
>>>
>>> - allocates generic chip with handle_simple_irq
>>> which simplifies irq_domain_ops.alloc callback
>>> - removes ack register from generic chip which is not used for
>>> handle_simple_irq as acking is done in a chained handler
>>> - removes unneeded irq_domain_ops.xlate callback
>>>
>>> Signed-off-by: Radoslaw Pietrzyk 
>>> ---
>>>   drivers/irqchip/irq-stm32-exti.c | 10 +-
>>>   1 file changed, 1 insertion(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-stm32-exti.c
>>> b/drivers/irqchip/irq-stm32-exti.c
>>> index 36f0fbe..42e74e3 100644
>>> --- a/drivers/irqchip/irq-stm32-exti.c
>>> +++ b/drivers/irqchip/irq-stm32-exti.c
>>> @@ -176,16 +176,12 @@ static int stm32_irq_set_wake(struct irq_data *data,
>>> unsigned int on)
>>>   static int stm32_exti_alloc(struct irq_domain *d, unsigned int virq,
>>> unsigned int nr_irqs, void *data)
>>>   {
>>> -   struct irq_chip_generic *gc;
>>> struct irq_fwspec *fwspec = data;
>>> irq_hw_number_t hwirq;
>>> hwirq = fwspec->param[0];
>>> -   gc = irq_get_domain_generic_chip(d, hwirq);
>>> irq_map_generic_chip(d, virq, hwirq);
>>> -   irq_domain_set_info(d, virq, hwirq, &gc->chip_types->chip, gc,
>>> -   handle_simple_irq, NULL, NULL);
>>> return 0;
>>>   }
>>> @@ -200,7 +196,6 @@ static void stm32_exti_free(struct irq_domain *d,
>>> unsigned int virq,
>>> struct irq_domain_ops irq_exti_domain_ops = {
>>> .map= irq_map_generic_chip,
>>> -   .xlate  = irq_domain_xlate_onetwocell,
>>> .alloc  = stm32_exti_alloc,
>>> .free   = stm32_exti_free,
>>>   };
>>> @@ -231,7 +226,7 @@ __init stm32_exti_init(const struct stm32_exti_bank
>>> **stm32_exti_banks,
>>> }
>>> ret = irq_alloc_domain_generic_chips(domain, IRQS_PER_BANK, 1,
>>> "exti",
>>> -handle_edge_irq, clr, 0, 0);
>>> +handle_simple_irq, clr, 0,
>>> 0);
>>
>>
>> EXTI hardware block is trigged on pulse event rising or failing edge.
>> Why do you change to handle_simple_irq ?
>>
>>> if (ret) {
>>> pr_err("%pOF: Could not allocate generic interrupt
>>> chip.\n",
>>> node);
>>> @@ -246,13 +241,10 @@ __init stm32_exti_init(const struct stm32_exti_bank
>>> **stm32_exti_banks,
>>> gc->reg_base = base;
>>> gc->chip_types->type = IRQ_TYPE_EDGE_BOTH;
>>> -   gc->chip_types->chip.irq_ack = irq_gc_ack_set_bit;
>>> gc->chip_types->chip.irq_mask = irq_gc_mask_clr_bit;
>>> gc->chip_types->chip.irq_unmask = irq_gc_mask_set_bit;
>>> gc->chip_types->chip.irq_set_type = stm32_irq_set_type;
>>> gc->chip_types->chip.irq_set_wake = stm32_irq_set_wake;
>>> -   gc->chip_types->regs.ack = stm32_bank->pr_ofst;
>>> -   gc->chip_types->regs.mask = stm32_bank->imr_ofst;
>>> gc->private = (void *)stm32_bank;
>>> /* Determine number of irqs supported */
>>>
>>
>> BR
>> Ludo

Re: [PATCH 00/17] Add kexec_file_load support to s390

[Dave Young]

On 02/14/18 at 10:54am, Philipp Rudo wrote:
> Hi Dave,
> 
> I just browsed AKASHI's patches (v7). The way I see it the common code changes
> are on different areas of kexec_file and shouldn't get in conflict. Only in 
> the
> arch code (s390 and arm64) some function calls might need an update. But I 
> have
> to take a closer look on the patches first.

I'm tring both in local branch with both series (V8 from AKASHI and this 
series),
but there are indeed some conflicts, may because AKASHI factored out some arch
code from ppc/x86 to common code.

> 
> @AKASHI: Welcome to the list. While browsing I couldn't find any
> arch_apply_relocation function for arm64. These require the biggest changes in
> my patch set. Did I just miss it or does arm64 work differently?
> 
> @Dave: Happy holiday

Thank you!

> 
> Thanks
> Philipp
> 
> On Wed, 14 Feb 2018 15:35:43 +0800
> Dave Young  wrote:
> 
> > Hi Philipp,
> > 
> > I added AKASHI in cc, he posted arm64 kexec_file series previously.
> > I would like to read both series especially the general part, but
> > maybe at the end of this month because of a holiday..
> > 
> > From the patch log the cleanup looks nice, but still need read the
> > details.
> > 
> > On 02/12/18 at 11:07am, Philipp Rudo wrote:
> > > Hi everybody
> > > 
> > > resending the series as there was no reaction, yet. Furthermore i was told
> > > that Andrew and the x86 list should also be CCed, so welcome.
> > > 
> > > No changes made to the patches since first time i sent them. The patches
> > > apply to the current master (v4.16-rc1).
> > > 
> > > Thanks
> > > Philipp
> > > 
> > > ---
> > > 
> > > this series adds the kexec_file_load system call to s390. Before the 
> > > system
> > > call is added there are some preparations/clean ups to common
> > > kexec_file_load. In detail this series contains:
> > > 
> > > Patch #1&2: Minor cleanups/fixes.
> > > 
> > > Patch #3-9: Clean up the purgatory load/relocation code. Especially remove
> > > the mis-use of the purgatory_info->sechdrs->sh_offset field, currently
> > > holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw)
> > > depending on the section. With these patches the section address will be
> > > calculated verbosely and sh_offset will contain the offset of the section
> > > in the stripped purgatory binary (purgatory_buf).
> > > 
> > > Patch #10: Allows architectures to set the purgaory load address. This
> > > patch is important for s390 as the kernel and purgatory have to be loaded
> > > to fixed addresses. In current code this is impossible as the purgatory
> > > load is opaque to the architecture.
> > > 
> > > Patch #11: Moves x86 purgatories sha implementation to common lib/
> > > directory.
> > > 
> > > Patches #12-17 finally adds the kexec_file_load system call to s390.
> > > 
> > > Please note that I had to touch arch code for x86 and power a little. In
> > > theory this should not change the behavior but I don't have a way to test
> > > it. Cross-compiling with defconfig(*) works fine for both.
> > > 
> > > Thanks
> > > Philipp
> > > 
> > > (*) On x86 with the orc unwinder turned off. objtool SEGFAULTs on s390...
> > > 
> > > Philipp Rudo (17):
> > >   kexec_file: Silence compile warnings
> > >   kexec_file: Remove checks in kexec_purgatory_load
> > >   kexec_file: Make purgatory_info->ehdr const
> > >   kexec_file: Search symbols in read-only kexec_purgatory
> > >   kexec_file: Use read-only sections in arch_kexec_apply_relocations*
> > >   kexec_file: Split up __kexec_load_puragory
> > >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 1
> > >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 2
> > >   kexec_file: Remove mis-use of sh_offset field
> > >   kexec_file: Allow archs to set purgatory load address
> > >   kexec_file: Move purgatories sha256 to common code
> > >   s390/kexec_file: Prepare setup.h for kexec_file_load
> > >   s390/kexec_file: Add purgatory
> > >   s390/kexec_file: Add kexec_file_load system call
> > >   s390/kexec_file: Add image loader
> > >   s390/kexec_file: Add crash support to image loader
> > >   s390/kexec_file: Add ELF loader
> > > 
> > >  arch/powerpc/kernel/kexec_elf_64.c |   9 +-
> > >  arch/s390/Kbuild   |   1 +
> > >  arch/s390/Kconfig  |   4 +
> > >  arch/s390/include/asm/kexec.h  |  23 ++
> > >  arch/s390/include/asm/purgatory.h  |  17 ++
> > >  arch/s390/include/asm/setup.h  |  40 ++-
> > >  arch/s390/kernel/Makefile  |   1 +
> > >  arch/s390/kernel/asm-offsets.c |   5 +
> > >  arch/s390/kernel/compat_wrapper.c  |   1 +
> > >  arch/s390/kernel/kexec_elf.c   | 149 ++
> > >  arch/s390/kernel/kexec_image.c |  78 +
> > >  arch/s390/kernel/machine_kexec_file.c  | 291 +++
> > >  arch/s390/kernel/syscalls/syscall.tbl  |   1 +
> > >  arch/s390/pu

Re: [PATCH] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

[kbuild test robot]

Hi Evgeniy,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Evgeniy-Didin/mmc-dw_mmc-Fix-the-DTO-timeout-overflow-calculation-for-32-bit-systems/20180223-054846
config: mips-pistachio_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/mmc/host/dw_mmc.o: In function `dw_mci_set_drto':
>> dw_mmc.c:(.text+0x176c): undefined reference to `__udivdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

答复: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

[liwei (CM)]

Hi, Arnd

Sorry late for you.
The following two suggestions we have really discussed
https://lkml.org/lkml/2017/11/30/1077

-邮件原件-
发件人: arndbergm...@gmail.com [mailto:arndbergm...@gmail.com] 代表 Arnd Bergmann
发送时间: 2018年2月19日 17:58
收件人: liwei (CM)
抄送: Rob Herring; Mark Rutland; xuwei (O); Catalin Marinas; Will Deacon; Vinayak 
Holikatti; James E.J. Bottomley; Martin K. Petersen; Kevin Hilman; Gregory 
CLEMENT; Thomas Petazzoni; Masahiro Yamada; Riku Voipio; Thierry Reding; 
Krzysztof Kozlowski; Eric Anholt; DTML; Linux Kernel Mailing List; Linux ARM; 
linux-scsi; zangleigang; Gengjianfeng; Guodong Xu; Zhangfei Gao; Fengbaopeng 
(kevin, Kirin Solution Dept)
主题: Re: [PATCH v8 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

On Tue, Feb 13, 2018 at 11:14 AM, Li Wei  wrote:
> add ufs node document for Hisilicon.
>
> Signed-off-by: Li Wei 
> ---
>  Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt


I'm pretty sure we've discussed it before, but can you make this so that the 
generic properties are part of the ufshcd binding, and you refer to it from 
here, only describing in what ways the hisi ufs binding differs from the 
standard?

> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt 
> b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> new file mode 100644
> index ..0d21b57496cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
> @@ -0,0 +1,37 @@
> +* Hisilicon Universal Flash Storage (UFS) Host Controller
> +
> +UFS nodes are defined to describe on-chip UFS hardware macro.
> +Each UFS Host Controller should have its own node.
> +
> +Required properties:
> +- compatible: compatible list, contains one of the following -
> +   "hisilicon,hi3660-ufs", 
> "jedec,ufs-1.1" for hisi ufs
> +   host controller present on Hi36xx 
> chipset.
> +- reg   : should contain UFS register address space & UFS SYS 
> CTRL register address,
> +- interrupt-parent  : interrupt device
> +- interrupts: interrupt number
> +- clocks   : List of phandle and clock specifier pairs
> +- clock-names   : List of clock input name strings sorted in the same
> +   order as the clocks property. 
> +"ref_clk", "phy_clk" is optional

The clock names sound generic enough, should we have both in the generic 
binding?

"ref_clk" is in the ufshcd-pltfrm binding, but "phy_clk" is not; what do you 
mean is that these two don't need to document here?

> +- resets: reset node register, one reset the clk and the other 
> reset the controller
> +- reset-names   : describe reset node register

This looks incomplete. What is the name of the reset line supposed to be?
I'd also suggest you document it in the ufshcd binding instead.

As discussed in https://lkml.org/lkml/2017/11/30/1077;
If document it in the ufshcd binding, I think it needs some codes to parse them 
in ufshcd.c/ufshcd-pltfrm.c, but I think these codes may not be applicable to 
other SOC manufacturers.

  Arnd

Re: [PATCH v8 01/13] resource: add walk_system_ram_res_rev()

[Dave Young]

Hi AKASHI,

On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> This function, being a variant of walk_system_ram_res() introduced in
> commit 8c86e70acead ("resource: provide new functions to walk through
> resources"), walks through a list of all the resources of System RAM
> in reversed order, i.e., from higher to lower.
> 
> It will be used in kexec_file implementation on arm64.

I remember there was an old discussion about this, it should be added
in patch log why this is needed.

> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Vivek Goyal 
> Cc: Andrew Morton 
> Cc: Linus Torvalds 
> ---
>  include/linux/ioport.h |  3 +++
>  kernel/resource.c  | 57 
> ++
>  2 files changed, 60 insertions(+)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index da0ebaec25f0..f12d95fe038b 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -277,6 +277,9 @@ extern int
>  walk_system_ram_res(u64 start, u64 end, void *arg,
>   int (*func)(struct resource *, void *));
>  extern int
> +walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> + int (*func)(struct resource *, void *));
> +extern int
>  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 
> end,
>   void *arg, int (*func)(struct resource *, void *));
>  
> diff --git a/kernel/resource.c b/kernel/resource.c
> index e270b5048988..bdaa93407f4c 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  
> @@ -486,6 +488,61 @@ int walk_mem_res(u64 start, u64 end, void *arg,
>arg, func);
>  }
>  
> +int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> + int (*func)(struct resource *, void *))
> +{
> + struct resource res, *rams;
> + int rams_size = 16, i;
> + int ret = -1;
> +
> + /* create a list */
> + rams = vmalloc(sizeof(struct resource) * rams_size);
> + if (!rams)
> + return ret;
> +
> + res.start = start;
> + res.end = end;
> + res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + i = 0;
> + while ((res.start < res.end) &&
> + (!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
> + if (i >= rams_size) {
> + /* re-alloc */
> + struct resource *rams_new;
> + int rams_new_size;
> +
> + rams_new_size = rams_size + 16;
> + rams_new = vmalloc(sizeof(struct resource)
> + * rams_new_size);
> + if (!rams_new)
> + goto out;
> +
> + memcpy(rams_new, rams,
> + sizeof(struct resource) * rams_size);
> + vfree(rams);
> + rams = rams_new;
> + rams_size = rams_new_size;
> + }
> +
> + rams[i].start = res.start;
> + rams[i++].end = res.end;
> +
> + res.start = res.end + 1;
> + res.end = end;
> + }
> +
> + /* go reverse */
> + for (i--; i >= 0; i--) {
> + ret = (*func)(&rams[i], arg);
> + if (ret)
> + break;
> + }
> +
> +out:
> + vfree(rams);
> + return ret;
> +}
> +
>  #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
>  
>  /*
> -- 
> 2.16.2
> 

Thanks
Dave

Re: [PATCH v2 1/2] irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

[Thomas Gleixner]

Radoslaw,

On Fri, 23 Feb 2018, Radoslaw Pietrzyk wrote:

> - discards setting handle_simple_irq handler for hierarchy interrupts
> - removes acking in chained irq handler as this is done by
> irq_chip itself inside handle_edge_irq
> - removes unneeded irq_domain_ops.xlate callback

if that's all functionally correct, then this is a nice cleanup. Though
from the above changelog its hard to tell because it merily tells WHAT the
patch does, but not WHY. The WHY is the important information for a
reviewer who is not familiar with the particular piece of code/hardware.

Can you please amend the changelog with proper explanations why a
particular piece of code is not needed or has to be changed to something
else?

Thanks,

tglx

Re: [PATCH v8 02/13] kexec_file: make an use of purgatory optional

[Dave Young]

Hi AKASHI,

On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> On arm64, no trampline code between old kernel and new kernel will be
> required in kexec_file implementation. This patch introduces a new
> configuration, ARCH_HAS_KEXEC_PURGATORY, and allows related code to be
> compiled in only if necessary.

Here also need the explanation about why no purgatory is needed, it would be
required for kexec if no strong reason.

> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Baoquan He 
> ---
>  arch/powerpc/Kconfig | 3 +++
>  arch/x86/Kconfig | 3 +++
>  kernel/kexec_file.c  | 6 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 73ce5dd07642..c32a181a7cbb 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -552,6 +552,9 @@ config KEXEC_FILE
> for kernel and initramfs as opposed to a list of segments as is the
> case for the older kexec call.
>  
> +config ARCH_HAS_KEXEC_PURGATORY
> + def_bool KEXEC_FILE
> +
>  config RELOCATABLE
>   bool "Build a relocatable kernel"
>   depends on PPC64 || (FLATMEM && (44x || FSL_BOOKE))
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c1236b187824..f031c3efe47e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2019,6 +2019,9 @@ config KEXEC_FILE
> for kernel and initramfs as opposed to list of segments as
> accepted by previous system call.
>  
> +config ARCH_HAS_KEXEC_PURGATORY
> + def_bool KEXEC_FILE
> +
>  config KEXEC_VERIFY_SIG
>   bool "Verify kernel signature during kexec_file_load() syscall"
>   depends on KEXEC_FILE
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index e5bcd94c1efb..990adae52151 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -26,7 +26,11 @@
>  #include 
>  #include "kexec_internal.h"
>  
> +#ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
>  static int kexec_calculate_store_digests(struct kimage *image);
> +#else
> +static int kexec_calculate_store_digests(struct kimage *image) { return 0; };
> +#endif
>  
>  /* Architectures can provide this probe function */
>  int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> @@ -520,6 +524,7 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>   return 0;
>  }
>  
> +#ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
>  /* Calculate and store the digest of segments */
>  static int kexec_calculate_store_digests(struct kimage *image)
>  {
> @@ -1022,3 +1027,4 @@ int kexec_purgatory_get_set_symbol(struct kimage 
> *image, const char *name,
>  
>   return 0;
>  }
> +#endif /* CONFIG_ARCH_HAS_KEXEC_PURGATORY */
> -- 
> 2.16.2
> 

Thanks
Dave

Re: [PATCH] firmware: qcom_scm: use correct parameter type for dma_alloc_coherent

[Benjamin Gaignard]

2018-02-08 15:26 GMT+01:00 Benjamin Gaignard :
> 2018-02-08 15:09 GMT+01:00 Arnd Bergmann :
>> On Thu, Feb 8, 2018 at 1:21 PM, Benjamin Gaignard
>>  wrote:
>>> dma_alloc_coherent expects it third argument type to be dma_addr_t and
>>> not phys_addr_t.
>>> When phys_addr_t is defined as u32 and dma_addr_t as u64 that generate
>>> a compilation issue.
>>> Change the variable name because dma_alloc_coherent returns a bus
>>> address not a physical address.
>>>
>>
>>> @@ -480,14 +480,14 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t 
>>> mem_sz,
>>>
>>> /* Fill details of mem buff to map */
>>> mem_to_map = ptr + ALIGN(src_sz, SZ_64);
>>> -   mem_to_map_phys = ptr_phys + ALIGN(src_sz, SZ_64);
>>> +   mem_to_map_phys = handle + ALIGN(src_sz, SZ_64);
>>> mem_to_map[0].mem_addr = cpu_to_le64(mem_addr);
>>> mem_to_map[0].mem_size = cpu_to_le64(mem_sz);
>>>
>>> next_vm = 0;
>>> /* Fill details of next vmid detail */
>>> destvm = ptr + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64);
>>> -   dest_phys = ptr_phys + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, 
>>> SZ_64);
>>> +   dest_phys = handle + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, 
>>> SZ_64);
>>
>> This still assigns from a 'dma' address to a 'phys' address without a
>> long comment
>> explaining why you do it. There is also another instance of the naming 
>> confusion
>> in qcom_scm_pas_init_image and __qcom_scm_pas_init_image, so maybe they
>> should be addressed at the same time.
>
> This patch just fix a compilation issue, nothing else.

Gentle ping on this patch since the problem still exist on 4.16-rc2

>
>>
>>Arnd

Re: [RFC tip/locking/lockdep v5 08/17] lockdep: Fix recursive read lock related safe->unsafe detection

[Boqun Feng]

On Fri, Feb 23, 2018 at 04:21:34PM +0800, Boqun Feng wrote:
> On Thu, Feb 22, 2018 at 06:46:54PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 22, 2018 at 03:08:55PM +0800, Boqun Feng wrote:
> > > There are four cases for recursive read lock realted deadlocks:
> > > 
> > > (--(X..Y)--> means a strong dependency path starts with a --(X*)-->
> > > dependency and ends with a --(*Y)-- dependency.)
> > > 
> > > 1.An irq-safe lock L1 has a dependency --(*..*)--> to an
> > >   irq-unsafe lock L2.
> > > 
> > > 2.An irq-read-safe lock L1 has a dependency --(N..*)--> to an
> > >   irq-unsafe lock L2.
> > > 
> > > 3.An irq-safe lock L1 has a dependency --(*..N)--> to an
> > >   irq-read-unsafe lock L2.
> > > 
> > > 4.An irq-read-safe lock L1 has a dependency --(N..N)--> to an
> > >   irq-read-unsafe lock L2.
> > > 
> > > The current check_usage() only checks 1) and 2), so this patch adds
> > > checks for 3) and 4) and makes sure when find_usage_{back,for}wards find
> > > an irq-read-{,un}safe lock, the traverse path should ends at a
> > > dependency --(*N)-->. Note when we search backwards, --(*N)--> indicates
> > > a real dependency --(N*)-->.
> > 
> > This adds 4 __bfs() searches for every new link.
> > 
> > Can't we make the existing traversals smarter?
> 
> Haven't really thought this one through, I will try. But as you said, we

Hmm... think again, maybe I can combine case 1 with 3, and case 2 with
4, because each of them could share the same find_usage_backwards(), and
find_usage_forwards() uses a usage_match_forwards() as follow for the
match function:

static inline int usage_match_forwards(struct lock_list *entry, void 
*bit)
{
enum lock_usage_bit ub = (enum lock_usage_bit)bit;
unsigned long mask;
unsigned long read_mask;

/* mask out the read bit */
ub &= ~1;

mask = 1ULL << ub;
read_mask = 1ULL << (ub + 1);

return (entry->class->usage_mask & mask) ||  // *-> L2 and L2 
is an irq-unsafe lock
   ((entry->class->usage_mask & read_mask) && 
!entry->is_rr); // N-> L2 and L2 is an irq-read-unsafe lock
}

Got a bus to catch, I can explain this later, if you need ;-)

Regards,
Boqun

> only need to do more searchs for _new_ links, so I think it's the slow
> path, would the performance matter that much?
> 
> Regards,
> Boqun




signature.asc
Description: PGP signature

Re: [PATCH v2 0/5] vfio, dax: prevent long term filesystem-dax pins and other fixes

[Haozhong Zhang]

On 02/22/18 23:17 -0800, Dan Williams wrote:
> Changes since v1 [1]:
> 
> * Fix the detection of device-dax file instances in vma_is_fsdax().
>   (Haozhong, Gerd)
> 
> * Fix compile breakage in the FS_DAX=n and DEV_DAX=y case. (0day robot)
> 
> [1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html
> 
> ---
> 
> The vfio interface, like RDMA, wants to setup long term (indefinite)
> pins of the pages backing an address range so that a guest or userspace
> driver can perform DMA to the with physical address. Given that this
> pinning may lead to filesystem operations deadlocking in the
> filesystem-dax case, the pinning request needs to be rejected.
> 
> The longer term fix for vfio, RDMA, and any other long term pin user, is
> to provide a 'pin with lease' mechanism. Similar to the leases that are
> hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
> to notify userspace that the block layout of the file is changing and
> the kernel is revoking access to pinned pages.
> 
> ---
> 
> Dan Williams (5):
>   dax: fix vma_is_fsdax() helper
>   dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
>   dax: fix S_DAX definition
>   dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
>   vfio: disable filesystem-dax page pinning
> 
> 
>  drivers/vfio/vfio_iommu_type1.c |   18 +++---
>  include/linux/dax.h |9 ++---
>  include/linux/fs.h  |6 --
>  3 files changed, 25 insertions(+), 8 deletions(-)

Tested on QEMU with fs-dax and device-dax as vNVDIMM backends
respectively with vfio passthrough. The fs-dax case fails QEMU as
expected, and the device-dax case works normally now.

Tested-by: Haozhong Zhang 

Re: [PATCH] lightnvm: fix memory leak in pblk_luns_init

[Javier González]

> On 23 Feb 2018, at 07.12, Matias Bjørling  wrote:
> 
> On 02/23/2018 12:03 AM, Huaicheng Li wrote:
>> Please ignore my previous email as I found the memory is free'ed at
>> pblk_init()'s error handling logic.
>> Sorry for the interruption.
>> On Thu, Feb 22, 2018 at 3:01 PM, Huaicheng Li 
>> wrote:
>>> Signed-off-by: Huaicheng Li 
>>> ---
>>> drivers/lightnvm/pblk-init.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
>>> index 93d671ca518e..330665d91d8d 100644
>>> --- a/drivers/lightnvm/pblk-init.c
>>> +++ b/drivers/lightnvm/pblk-init.c
>>> @@ -510,6 +510,7 @@ static int pblk_luns_init(struct pblk *pblk, struct
>>> ppa_addr *luns)
>>> if (ret) {
>>> while (--i >= 0)
>>> kfree(pblk->luns[i].bb_list);
>>> +   kfree(pblk->luns);
>>> return ret;
>>> }
>>> }
>>> --
>>> 2.13.6
> 
> No worries. The initialization part is pretty complex due to all the
> data structures being set up. I would love to have a clean
> initialization function, which cleans up after it self. But being able
> to share the "fail" bringup and tear-down code is very helpful and
> makes other parts easier.

As part of the 2.0 patches, I took a first try at refactoring the
init/exit sequences to maintain the same fail paths but minimizing
dependencies across structures. One of the big parts have been the bad
block initialization, which now is much cleaner, but still needs more
work to be as I would like it to. Patches are very welcome :)

Javier


signature.asc
Description: Message signed with OpenPGP

Re: [PATCH 5/6] mfd: cros_ec_dev: Check communication with ec at resume

[Gwendal Grignou]

On Thu, Feb 22, 2018 at 1:41 AM, Enric Balletbo i Serra
 wrote:
> Hi Gwendal,
>
> On 22/02/18 03:20, Gwendal Grignou wrote:
>> On Mon, Feb 19, 2018 at 2:41 PM, Enric Balletbo i Serra
>>  wrote:
>>> From: Gwendal Grignou 
>> This patch is not needed anymore. It was added to
>>>
>>> Send dummy command to EC at resume time, wait for status.
>>> If EC loses that command and return a status for the
>>> pre-suspend command, we will not interpret that status as an
>>> answer for an important command.
>>>
>>> Signed-off-by: Gwendal Grignou 
>>> Signed-off-by: Enric Balletbo i Serra 
>> Hold on for this commit. We have only used it in 3.14 kernels. It
>> looks like the issue has been addressed by a more elegant solution at
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0225a9de5971b99770344c04e0eba5b35ca68f71
>
> Just to make sure.
>
> I don't see this patch reverted in current chromeos-4.4, seems that both are
> applied. The patch is still there [1]. So, to double check, can I remove this
> patch from this series and add only the one that moves the system sleep pm ops
> to late?
You're right, it is still in chromeos-4.4. If it is still really
needed, we will apply it later.
Thanks,

Gwendal.
>
> [1]
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/platform/chrome/cros_ec_dev.c#782
>
>>> ---
>>>  drivers/mfd/cros_ec_dev.c | 10 ++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
>>> index fc98e0564061..c901839317ae 100644
>>> --- a/drivers/mfd/cros_ec_dev.c
>>> +++ b/drivers/mfd/cros_ec_dev.c
>>> @@ -553,6 +553,16 @@ static __maybe_unused int ec_device_suspend(struct 
>>> device *dev)
>>>  static __maybe_unused int ec_device_resume(struct device *dev)
>>>  {
>>> struct cros_ec_dev *ec = dev_get_drvdata(dev);
>>> +   char msg[sizeof(struct ec_response_get_version) +
>>> +sizeof(CROS_EC_DEV_VERSION)];
>>> +   int ret;
>>> +
>>> +   /* Be sure the communication with the EC is reestablished */
>>> +   ret = ec_get_version(ec, msg, sizeof(msg));
>>> +   if (ret < 0) {
>>> +   dev_err(ec->ec_dev->dev, "No EC response at resume: %d\n", 
>>> ret);
>>> +   return 0;
>> Besides, that looks wrong, we should try to resume the lightbar.
>>> +   }
>>>
>>> lb_resume(ec);
>>>
>>> --
>>> 2.16.1
>>>
>
> Thanks,
>   Enric

Re: [PATCH 5/6] mfd: cros_ec_dev: Check communication with ec at resume

[Enric Balletbo i Serra]

Hi Gwendal,

On 23/02/18 10:01, Gwendal Grignou wrote:
> On Thu, Feb 22, 2018 at 1:41 AM, Enric Balletbo i Serra
>  wrote:
>> Hi Gwendal,
>>
>> On 22/02/18 03:20, Gwendal Grignou wrote:
>>> On Mon, Feb 19, 2018 at 2:41 PM, Enric Balletbo i Serra
>>>  wrote:
 From: Gwendal Grignou 
>>> This patch is not needed anymore. It was added to

 Send dummy command to EC at resume time, wait for status.
 If EC loses that command and return a status for the
 pre-suspend command, we will not interpret that status as an
 answer for an important command.

 Signed-off-by: Gwendal Grignou 
 Signed-off-by: Enric Balletbo i Serra 
>>> Hold on for this commit. We have only used it in 3.14 kernels. It
>>> looks like the issue has been addressed by a more elegant solution at
>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0225a9de5971b99770344c04e0eba5b35ca68f71
>>
>> Just to make sure.
>>
>> I don't see this patch reverted in current chromeos-4.4, seems that both are
>> applied. The patch is still there [1]. So, to double check, can I remove this
>> patch from this series and add only the one that moves the system sleep pm 
>> ops
>> to late?
> You're right, it is still in chromeos-4.4. If it is still really
> needed, we will apply it later.
> Thanks,
> 
Sounds good, I'll resend another version removing this patch and adding the
other. Let's leave this patch in standby.

 Enric


> Gwendal.
>>
>> [1]
>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/platform/chrome/cros_ec_dev.c#782
>>
 ---
  drivers/mfd/cros_ec_dev.c | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
 index fc98e0564061..c901839317ae 100644
 --- a/drivers/mfd/cros_ec_dev.c
 +++ b/drivers/mfd/cros_ec_dev.c
 @@ -553,6 +553,16 @@ static __maybe_unused int ec_device_suspend(struct 
 device *dev)
  static __maybe_unused int ec_device_resume(struct device *dev)
  {
 struct cros_ec_dev *ec = dev_get_drvdata(dev);
 +   char msg[sizeof(struct ec_response_get_version) +
 +sizeof(CROS_EC_DEV_VERSION)];
 +   int ret;
 +
 +   /* Be sure the communication with the EC is reestablished */
 +   ret = ec_get_version(ec, msg, sizeof(msg));
 +   if (ret < 0) {
 +   dev_err(ec->ec_dev->dev, "No EC response at resume: %d\n", 
 ret);
 +   return 0;
>>> Besides, that looks wrong, we should try to resume the lightbar.
 +   }

 lb_resume(ec);

 --
 2.16.1

>>
>> Thanks,
>>   Enric
> 

Re: [PATCH v2] drm/stm: check pitch and size calculations even if !CONFIG_MMU

[Benjamin Gaignard]

2018-02-23 9:33 GMT+01:00 Philippe CORNU :
> Hi Benjamin,
>
> On 01/31/2018 09:05 AM, Benjamin Gaignard wrote:
>> In all cases we have to check pitch and size calculations to speed up
>> data transfer.
>>
>> Fixes: 21f815bf773c ("drm/stm: drv: Improve data transfers")
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>   drivers/gpu/drm/stm/drv.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
>> index 8bc7e8418b8d..9ab00a87f7cc 100644
>> --- a/drivers/gpu/drm/stm/drv.c
>> +++ b/drivers/gpu/drm/stm/drv.c
>> @@ -35,7 +35,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
>>  struct drm_device *dev,
>>  struct drm_mode_create_dumb *args)
>>   {
>> -#ifdef CONFIG_MMU
>>   unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>>
>>   /*
>> @@ -44,7 +43,6 @@ static int stm_gem_cma_dumb_create(struct drm_file *file,
>>*/
>>   args->pitch = roundup(min_pitch, 128);
>>   args->height = roundup(args->height, 4);
>> -#endif
>
> Reviewed-by: Philippe Cornu 

Applied on drm-misc-next.

Regards,
Benjamin

>
> Many thanks,
> Philippe :-)
>
>>
>>   return drm_gem_cma_dumb_create_internal(file, dev, args);
>>   }
>>

Re: [PATCH v2 1/2] irqchip: stm32: Optimizes and cleans up stm32-exti irq_domain

[Radosław Pietrzyk]

I think the HW is fairly simple and straightforward comparing to other
irq chips so it's rather a logic that concerned me the most i.e. why
gpio irqs were handled in a "simple" manner whereas the rest of
interrupts in "edge" manner. According to specification all interrupts
are edge driven and that's how are they treated in set_type callback.
First I thought that all can be handled as simple but then I realized
it makes more sense in handling all of them as edge as they should
according to specification. I will prepare a v3 series with more
detailed explanation in it.

2018-02-23 9:42 GMT+01:00 Thomas Gleixner :
> Radoslaw,
>
> On Fri, 23 Feb 2018, Radoslaw Pietrzyk wrote:
>
>> - discards setting handle_simple_irq handler for hierarchy interrupts
>> - removes acking in chained irq handler as this is done by
>> irq_chip itself inside handle_edge_irq
>> - removes unneeded irq_domain_ops.xlate callback
>
> if that's all functionally correct, then this is a nice cleanup. Though
> from the above changelog its hard to tell because it merily tells WHAT the
> patch does, but not WHY. The WHY is the important information for a
> reviewer who is not familiar with the particular piece of code/hardware.
>
> Can you please amend the changelog with proper explanations why a
> particular piece of code is not needed or has to be changed to something
> else?
>
> Thanks,
>
> tglx

Re: [0/8] target-iSCSI: Adjustments for several function implementations

[SF Markus Elfring]

> Calling crypto_free_shash(NULL) is actually fine.

Really?


> It doesn't dereference the parameter, it just does pointer math on it in
> crypto_shash_tfm() and returns if it's NULL in crypto_destroy_tfm().

Can a passed null pointer really work in this function?

https://elixir.bootlin.com/linux/v4.16-rc2/source/include/crypto/hash.h#L684
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/crypto/hash.h?id=0f9da844d87796ac31b04e81ee95e155e9043132#n751

static inline struct crypto_tfm *crypto_shash_tfm(struct crypto_shash *tfm)
{
return &tfm->base;
}


Regards,
Markus

Re: [PATCH] perf annotate: Support to display the LBR data in tui mode

[Jin, Yao]

On 2/23/2018 4:25 PM, Peter Zijlstra wrote:

On Fri, Feb 23, 2018 at 10:35:58PM +0800, Jin Yao wrote:

Unlike the perf report interactive annotate mode, the perf annotate
doesn't display the LBR data.

perf record -b ...
perf annotate function

It should show IPC/cycle, but it doesn't.


There is far more than IPC/cycle for the LBR data, so this Changelog is
misleading.



I will change the changelog to make it more clear.


Also, I think that this patch goes the wrong way, we should reduce the
divergence of the various modes, not make it worse.

I do plan to support stdio mode. While stdio mode needs more changes 
than tui mode, so I plan to do it in a follow-up patch.


Posting this patch now is because I want to listen from community first 
for this feature. If the tui patch could be accepted, then it's worth 
putting more efforts on stdio version. That's my thoughts.


Thanks
Jin Yao

Re: [PATCH V2 4/7] thermal/drivers/Kconfig: Convert the CPU cooling device to a choice

[Daniel Lezcano]

On 23/02/2018 06:24, Viresh Kumar wrote:
> On 21-02-18, 16:29, Daniel Lezcano wrote:
>> The next changes will add new way to cool down a CPU. In order to
>> sanitize and make the overall cpu cooling code consistent and robust
>> we must prevent the cpu cooling devices to co-exists with the same
>> purpose at the same time in the kernel.
>>
>> Make the CPU cooling device a choice in the Kconfig, so only one CPU
>> cooling strategy can be chosen.
> 
> Daniel T. already raised his concern (which I share too) about the
> multi-platform builds, where we would want this to be runtime
> selectable. I am fine with your approach of making that possible later
> on, but I would really like that to be merged before the combo thing
> comes in. So, I would suggest to merge stuff in this order:
> 
> - this series
> - runtime selectable strategy
> - combo stuff
> 
> I hope that would be fine ?

Yes, for me it is ok. So meanwhile we can also check the cpufreq cooling
device unregistering at suspend/resume/hotplug and hopefully that will
simplify the addition of the combo cooling device.


>> Signed-off-by: Daniel Lezcano 
>> ---
>>  drivers/thermal/Kconfig   | 20 +---
>>  drivers/thermal/cpu_cooling.c |  2 ++
>>  include/linux/cpu_cooling.h   |  6 +++---
>>  3 files changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b6adc54..5aaae1b 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -142,17 +142,31 @@ config THERMAL_GOV_POWER_ALLOCATOR
>>allocating and limiting power to devices.
>>  
>>  config CPU_THERMAL
>> -bool "generic cpu cooling support"
>> -depends on CPU_FREQ
>> +bool "Generic cpu cooling support"
>>  depends on THERMAL_OF
>>  help
>> +  Enable the CPU cooling features. If the system has no active
>> +  cooling device available, this option allows to use the CPU
>> +  as a cooling device.
>> +
>> +choice
>> +prompt "CPU cooling strategies"
>> +depends on CPU_THERMAL
>> +default CPU_FREQ_THERMAL
>> +help
>> +  Select the CPU cooling strategy.
>> +
>> +config CPU_FREQ_THERMAL
>> +bool "CPU frequency cooling strategy"
>> +depends on CPU_FREQ
>> +help
>>This implements the generic cpu cooling mechanism through frequency
>>reduction. An ACPI version of this already exists
>>(drivers/acpi/processor_thermal.c).
>>This will be useful for platforms using the generic thermal interface
>>and not the ACPI interface.
>>  
>> -  If you want this support, you should say Y here.
> 
> Should this line be moved to the CPU_THERMAL section above ?
> 

Probably, I will double check it.

[ ... ]

>> -#endif  /* CONFIG_CPU_THERMAL */
>> +#endif  /* CONFIG_CPU_FREQ_THERMAL */
>>  
>>  #endif /* __CPU_COOLING_H__ */
> 
> drivers/cpufreq/Kconfig:# if CPU_THERMAL is on and THERMAL=m, 
> CPUFREQ_DT cannot be =y:
> drivers/cpufreq/Kconfig:depends on !CPU_THERMAL || THERMAL
> drivers/cpufreq/Kconfig:depends on !CPU_THERMAL || THERMAL
> drivers/cpufreq/Kconfig.arm:# if CPU_THERMAL is on and THERMAL=m, 
> ARM_BIT_LITTLE_CPUFREQ cannot be =y
> drivers/cpufreq/Kconfig.arm:depends on !CPU_THERMAL || THERMAL
> drivers/cpufreq/Kconfig.arm:depends on !CPU_THERMAL || THERMAL
> 
> All of these need to use CPU_FREQ_THERMAL now>
> include/trace/events/thermal.h:#ifdef CONFIG_CPU_THERMAL
> include/trace/events/thermal.h:#endif /* CONFIG_CPU_THERMAL */

Ok.

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V2 0/7] CPU cooling device new strategies

[Daniel Lezcano]

On 23/02/2018 06:26, Viresh Kumar wrote:
> On Wed, Feb 21, 2018 at 8:59 PM, Daniel Lezcano
>  wrote:
>> Changelog:
>>   V2:
>>  - Dropped the cpu combo cooling device
>>  - Added the acked-by tags
>>  - Replaced task array by a percpu structure
>>  - Fixed the copyright dates
>>  - Fixed the extra lines
>>  - Fixed the compilation macros to be reused
>>  - Fixed the list node removal
>>  - Massaged a couple of function names
> 
> There are few patches in this series, including the cover-letter,
> where your script
> forgot to cc me and probably other cpu-cooling maintainers.
> 
> Maybe just explicitly cc us all next time :)

Ah, sorry for that. Will take care next time.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] media: imx274: fix typo in error message

[Luca Ceresoli]

Signed-off-by: Luca Ceresoli 
---
 drivers/media/i2c/imx274.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 664e8acdf2a0..daec33f4196a 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -1426,7 +1426,7 @@ static int imx274_set_vflip(struct stimx274 *priv, int 
val)
 
err = imx274_write_reg(priv, IMX274_VFLIP_REG, val);
if (err) {
-   dev_err(&priv->client->dev, "VFILP control error\n");
+   dev_err(&priv->client->dev, "VFLIP control error\n");
return err;
}
 
-- 
2.7.4

Re: linux-next: Signed-off-by missing for commits in the staging tree

[Greg KH]

On Wed, Nov 29, 2017 at 09:59:16AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Tue, 28 Nov 2017 20:41:39 +0100 Greg KH  wrote:
> >
> > I need to set up a git hook for this :(
> 
> I couldn't find an appropriate hook for fetching or merging other
> trees :-( Instead I run the attached script below after each fetch.

Ok, instead of just running this every so often (obviously I was
forgetting to), I've now added it to my main "commit this set of
patches" script so that I will be notified of any problems _before_ you
ever see them.

Sorry for taking so long with this, ugh.

greg k-h

Re: linux-next: Signed-off-by missing for commit in the staging tree

[Greg KH]

On Fri, Feb 23, 2018 at 08:51:37AM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Commit
> 
>   cc738c1a69da ("staging: lustre: opencode cfs_cap_{raise, lower, raised}")
> 
> is missing a Signed-off-by from its author.

Obviously I wasn't running your script very often, so I've now fixed my
workflow to always do that.  thanks for letting me know.

greg k-h

drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): undefined reference to `__tracepoint_vb2_buf_queue'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   0f9da844d87796ac31b04e81ee95e155e9043132
commit: 7952be9b6ece3d3c4d61f9811d7e5a984580064a media: 
drivers/media/common/videobuf2: rename from videobuf
date:   4 weeks ago
config: x86_64-randconfig-s1-02231552 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 7952be9b6ece3d3c4d61f9811d7e5a984580064a
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`__read_once_size':
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_queue'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
   include/linux/compiler.h:183: undefined reference to 
`__tracepoint_vb2_buf_done'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_qbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_qbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_dqbuf'
   include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_dqbuf'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
>> undefined reference to `__tracepoint_vb2_buf_queue'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
>> undefined reference to `__tracepoint_vb2_buf_done'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
>> undefined reference to `__tracepoint_vb2_qbuf'
>> drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
>> undefined reference to `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_poll':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:678: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.c:685: undefined reference to 
`v4l2_event_pending'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_reqbufs':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:714: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_create_bufs':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:733: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_prepare_buf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:759: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_querybuf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:769: undefined reference to 
`video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_qbuf':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:778: undefined reference to 
`video_devdata'
   
drivers/media/common/videobuf2/videobuf2-v4l2.o:drivers/media/common/videobuf2/videobuf2-v4l2.c:788:
 more undefined references to `video_devdata' follow
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`_vb2_fop_release':
   drivers/media/common/videobuf2/videobuf2-v4l2.c:848: undefined reference to 
`v4l2_fh_release'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/6] arm64: dts: renesas: r8a77965: Add "reg" properties

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "reg" properties to place-holder nodes with unit address defined for
> R-Car M3-N SoC.
>
> This silences the following DTC compiler warning:
> Warning (unit_address_vs_reg): Node /soc/... has a unit name,
> but no reg property
>
> Signed-off-by: Jacopo Mondi 

A few minor nits below...

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi

> @@ -520,130 +521,163 @@
> };
>
> avb: ethernet@e680 {
> +   reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 
> 0x1>;

The first reg part would be sufficient for a placeholder.
I think even setting the size to zero would work...

> du: display@feb0 {
> +   reg = <0 0xfeb0 0 0x7>,

Unlike M3-W, the M3-N DU has a third channel, so the size is too small.

> + <0 0xfeb9 0 0x14>;
> /* placeholder */

> @@ -703,38 +745,47 @@
> };
>
> usb2_phy1: usb-phy@ee0a0200 {
> +   reg = <0 0xee0a0200 0 0x700>;
> /* placeholder */
> };

To be moved up, next to the other usb2 devices?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] microblaze: Provide pgprot_device/writecombine macros for nommu

[Michal Simek]

These macros are required for generic mmap.c implementation created by:
commit f719582435af ("PCI: Add pci_mmap_resource_range() and use it for
ARM64") which Microblaze is going to use.

Reported-by: kbuild test robot 
Suggested-by: David Woodhouse 
Signed-off-by: Michal Simek 
---

 arch/microblaze/include/asm/pgtable.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/microblaze/include/asm/pgtable.h 
b/arch/microblaze/include/asm/pgtable.h
index e53b8532353c..db8b1fa83452 100644
--- a/arch/microblaze/include/asm/pgtable.h
+++ b/arch/microblaze/include/asm/pgtable.h
@@ -33,6 +33,8 @@
 #define PAGE_KERNEL__pgprot(0) /* these mean nothing to non MMU */
 
 #define pgprot_noncached(x)(x)
+#define pgprot_writecombinepgprot_noncached
+#define pgprot_device  pgprot_noncached
 
 #define __swp_type(x)  (0)
 #define __swp_offset(x)(0)
-- 
1.9.1

Re: [PATCH 2/6] arm64: dts: renesas: r8a77965: Add #address-cells and #size-cells

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#address-cells" and "#size-cells" properties to all place-holder nodes
> that have children nodes defined by salvator-x[s].dtsi device tree.
>
> This silences the following DTC compiler warnings:
> Warning (reg_format): "reg" property in /soc/.. has invalid length (4 bytes)
> (#address-cells == 2, #size-cells == 1)
> Warning (avoid_default_addr_size): Relying on default #address-cells
> value for /soc/...
> Warning (avoid_default_addr_size): Relying on default #size-cells value
> for /soc/...
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 3/6] arm64: dts: renesas: r8a77965: Remove stale reg property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Remove "reg" property from cache-controller-0 device node as it does not
> have any unit address.
>
> This silences the following DTC compiler warning:
> Warning (unit_address_vs_reg): Node /cpus/cache-controller-0 has a reg
> or ranges property, but no unit name
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 4/6] arm64: dts: renesas: r8a77965: Add #phy-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#phy-cells" property to "usb-phy@e65ee000" device node.
>
> This silences the following DTC compiler warning:
> Warning (phys_property): Missing property '#phy-cells' in node
> /soc/usb-phy@e65ee000 or bad phandle (referred from
> /soc/usb@ee02:phys[0])
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] [BUGFIX] arm: kprobes: Fix to use get_kprobe_ctlblk after irq-disabed

[Masami Hiramatsu]

Since get_kprobe_ctlblk() uses smp_processor_id() to access
per-cpu variable, it hits smp_processor_id sanity check as below.

[7.006928] BUG: using smp_processor_id() in preemptible [] code: 
swapper/0/1
[7.007859] caller is debug_smp_processor_id+0x20/0x24
[7.008438] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.16.0-rc1-00192-g4eb17253e4b5 #1
[7.008890] Hardware name: Generic DT based system
[7.009917] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[7.010473] [] (show_stack) from [] 
(dump_stack+0x84/0x98)
[7.010990] [] (dump_stack) from [] 
(check_preemption_disabled+0x138/0x13c)
[7.011592] [] (check_preemption_disabled) from [] 
(debug_smp_processor_id+0x20/0x24)
[7.012214] [] (debug_smp_processor_id) from [] 
(optimized_callback+0x2c/0xe4)
[7.013077] [] (optimized_callback) from [] (0xbf0021b0)

To fix this issue, call get_kprobe_ctlblk() right after
irq-disabled since that disables preemption.

Fixes: 0dc016dbd820 ("ARM: kprobes: enable OPTPROBES for ARM 32")
Signed-off-by: Masami Hiramatsu 
---
 arch/arm/probes/kprobes/opt-arm.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/probes/kprobes/opt-arm.c 
b/arch/arm/probes/kprobes/opt-arm.c
index bcdecc25461b..ddc5a82eb10d 100644
--- a/arch/arm/probes/kprobes/opt-arm.c
+++ b/arch/arm/probes/kprobes/opt-arm.c
@@ -165,13 +165,14 @@ optimized_callback(struct optimized_kprobe *op, struct 
pt_regs *regs)
 {
unsigned long flags;
struct kprobe *p = &op->kp;
-   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+   struct kprobe_ctlblk *kcb;
 
/* Save skipped registers */
regs->ARM_pc = (unsigned long)op->kp.addr;
regs->ARM_ORIG_r0 = ~0UL;
 
local_irq_save(flags);
+   kcb = get_kprobe_ctlblk();
 
if (kprobe_running()) {
kprobes_inc_nmissed_count(&op->kp);

Re: [PATCH v8 03/13] kexec_file,x86,powerpc: factor out kexec_file_ops functions

[Dave Young]

Hi AKASHI,

On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> As arch_kexec_kernel_*_{probe,load}(), arch_kimage_file_post_load_cleanup()
> and arch_kexec_kernel_verify_sg can be parameterized with a kexec_file_ops
> array and now duplicated among some architectures, let's factor them out.
> 
> Signed-off-by: AKASHI Takahiro 
> Cc: Dave Young 
> Cc: Vivek Goyal 
> Cc: Baoquan He 
> Cc: Michael Ellerman 
> Cc: Thiago Jung Bauermann 
> ---
>  arch/powerpc/include/asm/kexec.h|  2 +-
>  arch/powerpc/kernel/kexec_elf_64.c  |  2 +-
>  arch/powerpc/kernel/machine_kexec_file_64.c | 39 ++--
>  arch/x86/include/asm/kexec-bzimage64.h  |  2 +-
>  arch/x86/kernel/kexec-bzimage64.c   |  2 +-
>  arch/x86/kernel/machine_kexec_64.c  | 45 +--
>  include/linux/kexec.h   | 15 
>  kernel/kexec_file.c | 57 
> +++--
>  8 files changed, 70 insertions(+), 94 deletions(-)
> 

[snip]

> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 990adae52151..a6d14a768b3e 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -26,34 +26,83 @@
>  #include 
>  #include "kexec_internal.h"
>  
> +const __weak struct kexec_file_ops * const kexec_file_loaders[] = {NULL};
> +
>  #ifdef CONFIG_ARCH_HAS_KEXEC_PURGATORY
>  static int kexec_calculate_store_digests(struct kimage *image);
>  #else
>  static int kexec_calculate_store_digests(struct kimage *image) { return 0; };
>  #endif
>  
> +int _kexec_kernel_image_probe(struct kimage *image, void *buf,
> +  unsigned long buf_len)
> +{
> + const struct kexec_file_ops * const *fops;
> + int ret = -ENOEXEC;
> +
> + for (fops = &kexec_file_loaders[0]; *fops && (*fops)->probe; ++fops) {
> + ret = (*fops)->probe(buf, buf_len);
> + if (!ret) {
> + image->fops = *fops;
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
>  /* Architectures can provide this probe function */
>  int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
>unsigned long buf_len)
>  {
> - return -ENOEXEC;
> + return _kexec_kernel_image_probe(image, buf, buf_len);


I vaguely remember previously I suggest split the _kexec_kernel_image_probe
because arch code can call them, and common code also use it like above.
But in your new series I do not find where else calls this function
except the common code arch_kexec_kernel_image_probe.  If nobody use
them then it is not worth to split them out, it is better to just embed
them in the __weak functions.

Ditto for other similar functions.

[snip]

Thanks
Dave

RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Manish Narani]

> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, February 23, 2018 1:04 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
> ZynqMP Platform
> 
> On 23/02/18 09:29, Manish Narani wrote:
> >
> >
> >> -Original Message-
> >> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> >> Sent: Thursday, February 22, 2018 1:50 PM
> >> To: Manish Narani ; michal.si...@xilinx.com;
> >> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> >> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> devicet...@vger.kernel.org; mark.rutl...@arm.com;
> robh...@kernel.org
> >> Cc: Anirudha Sarangi ; Srinivas Goud
> >> 
> >> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> >> support for ZynqMP Platform
> >>
> >> On 21/02/18 17:00, Manish Narani wrote:
> >>> Hi Adrian,
> >>>
>  -Original Message-
>  From: Manish Narani
>  Sent: Wednesday, February 21, 2018 11:39 AM
>  To: Adrian Hunter ;
>  michal.si...@xilinx.com; ulf.hans...@linaro.org;
>  linux-arm-ker...@lists.infradead.org; linux- m...@vger.kernel.org;
>  linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
>  mark.rutl...@arm.com;
> >> robh...@kernel.org
>  Cc: Anirudha Sarangi ; Srinivas Goud
>  
>  Subject: RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
>  support for ZynqMP Platform
> 
>  Hi Adrian,
> 
> 
> > -Original Message-
> > From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> > Sent: Friday, February 16, 2018 7:37 PM
> > To: Manish Narani ;
> michal.si...@xilinx.com;
> > ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org;
> > linux- m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > devicet...@vger.kernel.org; mark.rutl...@arm.com;
> >> robh...@kernel.org
> > Cc: Anirudha Sarangi ; Srinivas Goud
> > ; Manish Narani 
> > Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> > support for ZynqMP Platform
> >
> > On 30/01/18 20:14, Manish Narani wrote:
> >> This patch adds support of SD auto tuning for ZynqMP platform.
> >> Auto tuning sequence sends tuning block to card when operating in
> >> UHS-1 modes. This resets the DLL and sends CMD19/CMD21 as a part
> >> of the auto tuning process. Once the auto tuning process gets
> >> completed, reset the DLL to load the newly obtained SDHC tuned tap
> value.
> >
> > How is this different from:
> > 1. reset the dll
> > 2. call sdhci_execute_tuning
> > 3. reset the dll
> >
> >>> Below is my take on your above comments:
> >>> - 'Reset the dll' is a platform specific call inside
> >>> 'arasan_zynqmp_execute_tuning' which is implemented in
> >>> sdhci-of-arasan.c
> >>> - 'arasan_zynqmp_execute_tuning' is called from
> 'sdhci_execute_tuning'
> >>> as a platform_execute_tuning routine
> >>> - So to keep 'DLL reset' routine called from sdhci-of-arasan.c, I
> >>> have implemented the execute_tuning in sdhci-of-arasan.c
> >>
> >> I meant something like:
> >>
> >>if (of_device_is_compatible(pdev->dev.of_node, "xlnx,zynqmp-
> >> 8.9a"))
> >>host->mmc_host_ops.execute_tuning =
> arasan_zynqmp_execute_tuning;
> >>
> > This will need the removal of 'const' from 'static const struct
> mmc_host_ops sdhci_ops = {}' in sdhci.c file. Please confirm.
> 
> No, it is not const.  You are not looking at the right place. i.e.
> 
> $ grep mmc_host_ops drivers/mmc/host/sdhci.h
> struct mmc_host_ops mmc_host_ops;   /* MMC host ops */
> 
[Manish] 
This looks fair. I got your point. I will send another patch for the same.
> >
> > Thanks,
> > Manish
> >>
> >> static int arasan_zynqmp_execute_tuning(struct mmc_host *mmc, u32
> >> opcode) {
> >>struct sdhci_host *host = mmc_priv(mmc);
> >>struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> >>struct sdhci_arasan_data *sdhci_arasan =
> >> sdhci_pltfm_priv(pltfm_host);
> >>int err;
> >>
> >>arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> >>
> >>err = sdhci_execute_tuning(mmc, opcode);
> >>if (err)
> >>return err;
> >>
> >>arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> >>
> >>return 0;
> >> }
> >>
> >>>
> >>> Alternative way (Please review):
> >>> - Define a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) in
> >>> sdhci-of-arasan.c indicating DLL reset needed while tuning operation
> >>> - Call 'dll reset' routine before and after __sdhci_execute_tuning()
> >>> in sdhci.c when a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED)
> >>> is set
> >>
> >> We should try t

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hi Frank,

On Friday, 23 February 2018 05:20:43 EET Frank Rowand wrote:
> On 02/22/18 02:25, Laurent Pinchart wrote:
> > On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote:
> >> On 02/20/18 15:10, Laurent Pinchart wrote:
> >>> Hello,
> >>> 
> >>> This patch series addresses a design mistake that dates back from the
> >>> initial DU support. Support for the LVDS encoders, which are IP cores
> >>> separate from the DU, was bundled in the DU driver. Worse, both the DU
> >>> and LVDS were described through a single DT node.
> >>> 
> >>> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
> >>> encoders, and deprecate their description inside the DU bindings. To
> >>> retain backward compatibility with existing DT, patches 03/16 to 08/16
> >>> then patch the device tree at runtime to convert the legacy bindings to
> >>> the new ones.
> >>> 
> >>> With the DT side addressed, patch 09/16 converts the LVDS support code
> >>> to a separate bridge driver. Patches 11/16 to 16/16 then update all the
> >>> device tree sources to the new DU and LVDS encoders bindings.
> >>> 
> >>> I decided to go for live DT patching in patch 08/16 because implementing
> >>> support for both the legacy and new bindings in the driver would have
> >>> been very intrusive, and prevented further cleanups. This version relies
> >>> more heavily on overlays to avoid touching the internals of the OF core
> >>> compared to v2, even if manual fixes to the device tree are still
> >>> needed.
> >>> 
> >>> Compared to v3, this series uses the OF changeset API to update
> >>> properties instead of accessing the internals of the property structure.
> >>> This removes the local implementation of functions to look up nodes by
> >>> path and update properties. In order to do this, I pulled in Pantelis'
> >>> patch series titled "[PATCH v2 0/5] of: dynamic: Changesets helpers &
> >>> fixes" at Rob's request, and rebased it while taking two small review
> >>> comments into account.
> >> 
> >> Wait a minute!  Why are you putting a patch set to modify core devicetree
> >> in the middle of a driver series.  Please pull it out to a separate
> >> series.
> > 
> > Because Rob asked for the driver-local implementation of the property add
> > function to be replaced by Pantelis' series. I want to get the LVDS
> > changes in v4.17 and asked Rob whether I could then take the OF changeset
> > patches merged through the DRM tree, and he didn't object. If that causes
> > an issue I'll switch back to the driver-local implementation to get the
> > driver changes merged, split the OF changeset series out, and then move
> > to the OF changeset API once merged. Would you prefer that ?
> 
> You have already created a new version of the R-Car patches without the
> set of patches that I was objecting to here.  So this is somewhat just
> an academic comment.
> 
> As I mentioned in the v6 thread, I am coming back here to clean up loose
> ends, and explain why I had the reaction I had.  Basically, this is a
> process issue to me.
> 
> (1) The patch set from Pantelis is "hidden" in the driver patch series.
> When viewing collapsed threads (which is my normal mode to avoid getting
> overwhelmed by the vast volume of email I scan), the Pantelis patch set
> is totally invisible.  If the R-Car driver patch series had not had me
> on the to: list, there is a very good chance I would not have noticed
> it.  Or noticed in a more delayed time frame.  And the same applies to
> anyone else who might be subscribed to the devicetree mail list.  If
> the Pantelis patch series was split out into a separate patch set then
> it would be more visible on the list.
> 
> (2) There is no good way to indicate in the email subject lines for
> the Pantelis patches that they are version 3 of the series, since
> they are also version 4 of the R-Car patch series.  If one reads the
> patch 0/0 header carefully, and/or the other Pantelis patch comment
> headers carefully, and then does a little detective work, it is
> possible to find version 2 of the Pantelis patch series, and thus
> be able to track the full history.  If just glancing at each
> individual patch email subject, scanning the patch comment, and
> spending more time reading the body of the patch, it would be
> very easy to overlook the existence of the previous versions on
> the mail list.
> 
> (2b) Small quibble:  if the Pantelis patches were in a separate series,
> with v3 in the subject header, then you would have normally put
> a "changes since v2" section in the patch comment header, which would
> have been more visible and less cryptic than what you wrote, which was:
> 
>...
> 
>Signed-off-by: Pantelis Antoniou 
>[Fixed memory leak in __of_changeset_add_update_property_copy()]
>Signed-off-by: Laurent Pinchart
> 
>---
> drivers/of/dynamic.c | 222 ++
> include/linux/of.h   | 328 +
> 2 files changed, 550 

Re: [PATCH 5/6] arm64: dts: renesas: r8a77965: Add #pwm-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#pwm-cells" property to "pwm@e6e31000" device node.
>
> This silences the following DTC compiler warning:
> Warning (pwms_property): Missing property '#pwm-cells' in node
> /soc/pwm@e6e31000 or bad phandle (referred from /backlight:pwms[0])
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 6/6] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[Geert Uytterhoeven]

On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  wrote:
> Add "#interrupt-cells" property and "interrupt-controller" label to
> "interrupt-controller@e61c" device node.
>
> This silences the following DTC compiler warnings:
> Warning (interrupts_property): Missing interrupt-controller or
> interrupt-map property in /soc/interrupt-controller@e61c
> Warning (interrupts_property): Missing #interrupt-cells in
> interrupt-parent /soc/interrupt-controller@e61c000
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 

> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -316,6 +316,8 @@
> };
>
> intc_ex: interrupt-controller@e61c {
> +   #interrupt-cells = <2>;
> +   interrupt-controller;
> reg = <0 0xe61c 0 0x200>;
> /* placeholder */

(bikeshedding) Should the placeholder be at the top of the node?

> };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem

[Keiji Hayashibara]

Hello Marcus,

I'm sorry that it became a different thread.
I'll be careful hereafter.

This mail is reply to here.
  https://patchwork.kernel.org/patch/10232065/


> diff --git a/drivers/watchdog/uniphier_wdt.c b/drivers/watchdog/uniphier_wdt.c
> index 0ea2339d9702..769d75344050 100644
> --- a/drivers/watchdog/uniphier_wdt.c
> +++ b/drivers/watchdog/uniphier_wdt.c
> @@ -1,18 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Watchdog driver for the UniPhier watchdog timer
>   *
>   * (c) Copyright 2014 Panasonic Corporation
>   * (c) Copyright 2016 Socionext Inc.
>   * All rights reserved.
> - *
> - * 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.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
>   */
> 
>  #include 

Acked-by: Keiji Hayashibara 

Thank you.


Best Regards,
Keiji Hayashibara

RE: [PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

[He, Roger]

looks good to me.  Reviewed-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Tuesday, February 20, 2018 8:58 PM
To: amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
linux-kernel@vger.kernel.org
Subject: [PATCH 4/4] drm/ttm: keep BOs reserved until end of eviction

This avoids problems when BOs are evicted but directly moved back into the 
domain from other threads.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
3a44c2ee4155..593a0216faff 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -742,7 +742,8 @@ static bool ttm_bo_evict_swapout_allowable(struct 
ttm_buffer_object *bo,  static int ttm_mem_evict_first(struct ttm_bo_device 
*bdev,
   uint32_t mem_type,
   const struct ttm_place *place,
-  struct ttm_operation_ctx *ctx)
+  struct ttm_operation_ctx *ctx,
+  struct list_head *evicted)
 {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = &bdev->man[mem_type]; @@ -792,17 
+793,28 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
ret = ttm_bo_evict(bo, ctx);
if (locked) {
-   ttm_bo_unreserve(bo);
+   list_add_tail(&bo->lru, evicted);
} else {
spin_lock(&glob->lru_lock);
ttm_bo_add_to_lru(bo);
spin_unlock(&glob->lru_lock);
+   kref_put(&bo->list_kref, ttm_bo_release_list);
}
 
-   kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
 }
 
+static void ttm_mem_evict_cleanup(struct list_head *evicted) {
+   struct ttm_buffer_object *bo, *tmp;
+
+   list_for_each_entry_safe(bo, tmp, evicted, lru) {
+   list_del_init(&bo->lru);
+   ttm_bo_unreserve(bo);
+   kref_put(&bo->list_kref, ttm_bo_release_list);
+   }
+}
+
 void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem)  {
struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type]; @@ 
-852,20 +864,26 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,  {
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
+   struct list_head evicted;
int ret;
 
+   INIT_LIST_HEAD(&evicted);
do {
ret = (*man->func->get_node)(man, bo, place, mem);
if (unlikely(ret != 0))
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx, &evicted);
if (unlikely(ret != 0))
-   return ret;
+   goto error;
} while (1);
mem->mem_type = mem_type;
-   return ttm_bo_add_move_fence(bo, man, mem);
+   ret = ttm_bo_add_move_fence(bo, man, mem);
+
+error:
+   ttm_mem_evict_cleanup(&evicted);
+   return ret;
 }
 
 static uint32_t ttm_bo_select_caching(struct ttm_mem_type_manager *man, @@ 
-1345,6 +1363,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
struct ttm_operation_ctx ctx = { false, false };
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_bo_global *glob = bdev->glob;
+   struct list_head evicted;
struct dma_fence *fence;
int ret;
unsigned i;
@@ -1352,18 +1371,20 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
/*
 * Can't use standard list traversal since we're unlocking.
 */
-
+   INIT_LIST_HEAD(&evicted);
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx,
+ &evicted);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
}
}
spin_unlock(&glob->lru_lock);
+   ttm_mem_evict_cleanup(&evicted);
 
spin_lock(&man->move_lock);
fence = dma_fence_get(man->move);
--
2.14.1

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

Re: [PATCH 1/2] pci: endpoint: Free func_name after last usage

[Lorenzo Pieralisi]

On Fri, Feb 23, 2018 at 11:40:49AM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On Thursday 22 February 2018 11:49 PM, Lorenzo Pieralisi wrote:
> > On Wed, Feb 21, 2018 at 01:47:06PM +0100, Rolf Evers-Fischer wrote:
> >> From: Rolf Evers-Fischer 
> >>
> >> This commit decreases the number of jump labels and ensures
> >> that the next commit doesn't increase the number of occurrences
> >> of 'kfree(func_name)'.
> >>
> >> Change-Id: I0d1b6fd652395b85f82b11c43bf9b7db512854d1
> >> Signed-off-by: Rolf Evers-Fischer 
> >> Signed-off-by: Rolf Evers-Fischer 
> >> ---
> >>  drivers/pci/endpoint/pci-epf-core.c | 7 ++-
> >>  1 file changed, 2 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
> >> b/drivers/pci/endpoint/pci-epf-core.c
> >> index 766ce1dca2ec..23d0e128d1a5 100644
> >> --- a/drivers/pci/endpoint/pci-epf-core.c
> >> +++ b/drivers/pci/endpoint/pci-epf-core.c
> >> @@ -220,9 +220,10 @@ struct pci_epf *pci_epf_create(const char *name)
> >>*buf = '\0';
> >>  
> >>epf->name = kstrdup(func_name, GFP_KERNEL);
> >> +  kfree(func_name);
> > 
> > I am certainly missing something but what if we reworked the code
> > and just:
> > 
> > kstrdup(name, GFP_KERNEL);
> > 
> > once instead of allocating another local copy (that we then have to
> > free) ?
> 
> name will be something like pci_epf_test.0 and in epf->name we want to just
> have pci_epf_test.
> > 
> > Reworded: why
> > 
> > epf->name = func_name;
> 
> memory should be allocated for epf->name before it can be initialized. IMO
> without kstrdup, there will be a null pointer exception.

I understand that but the point is that func_name *was* allocated with
kstrdup() already I would like to understand why we need to do it twice
(and kfree the first allocation).

Lorenzo

Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig

[Michal Hocko]

On Thu 22-02-18 09:30:35, Kees Cook wrote:
> On Thu, Feb 22, 2018 at 5:07 AM, Michal Hocko  wrote:
> > On Wed 14-02-18 09:14:47, Kees Cook wrote:
> > [...]
> >> I can send it through my seccomp tree via James Morris.
> >
> > Could you please do it?
> 
> Hi! Yes, sorry, this fell through the cracks. Now applied.

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL

[Paolo Bonzini]

On 22/02/2018 18:07, Konrad Rzeszutek Wilk wrote:
>> Having a paravirt indirect call in the IBRS restore path is not a
>> good idea, since we are trying to protect from speculative execution
>> of bogus indirect branch targets.  It is also slower, so use
>> native_wrmsrl on the vmentry path too.
> But it gets replaced during patching. As in once the machine boots
> the assembler changes from:
> 
>   callq   *0xlbah
> 
> to
>   wrmsr
> 
> ? I don't think you need this patch.

Why not be explicit?  According to the spec, PRED_CMD and SPEC_CTRL
should be passed down to the guest without interception so it's safe to
do this.  On the other hand, especially with nested virtualization, I
don't think you can absolutely guarantee that the paravirt call will be
patched to rdmsr/wrmsr.

Paolo

Re: [PATCH 3/3] auxdisplay: img-ascii-lcd: Silence 2 uninitialized warnings

[Miguel Ojeda]

Hi Geert,

On Mon, Feb 19, 2018 at 7:40 PM, Geert Uytterhoeven
 wrote:
> Hi Miguel,
>
> On Mon, Feb 19, 2018 at 5:09 PM, Miguel Ojeda
>  wrote:
>> The warnings are:
>>
>>   drivers/auxdisplay/img-ascii-lcd.c: warning: 'err' may be used
>>   uninitialized in this function [-Wuninitialized]
>>
>> At lines 109 and 207. Reported by Geert using the build service
>> several times, e.g.:
>>
>>   https://lkml.org/lkml/2018/2/19/303
>>
>> They are two false positives, since num_chars > 0 in the three present
>> configurations (boston, malta, sead3). Initializing to an error state by
>> default silences the warning and makes the code print an error in case a
>> num_chars == 0 happens in the future (unlikely, since it does not make
>> sense currently).
>>
>> The warnings seem to disappear starting with gcc >= 4.9
>>
>> Cc: Geert Uytterhoeven 
>> Cc: Paul Burton 
>> Signed-off-by: Miguel Ojeda 
>
> Thanks for your patch!
>
> I would initialize err to zero, though, as there is no real error condition if
> called with num_char == 0.

True, it also makes sense that way. Both are fine with me. I was
thinking more in the lines of "update() called for no reason (no
chars) is an error".

Since it will never happen anyway and = 0 is simpler to explain
(nothing to explain in the commit), I will change it for the queue.
Should I add your Ack?

Thanks for taking a look!
Miguel

>
>> ---
>> I will queue it up for 4.17.
>>
>> drivers/auxdisplay/img-ascii-lcd.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/auxdisplay/img-ascii-lcd.c 
>> b/drivers/auxdisplay/img-ascii-lcd.c
>> index d8133024fd5d..bd5ebb5c516c 100644
>> --- a/drivers/auxdisplay/img-ascii-lcd.c
>> +++ b/drivers/auxdisplay/img-ascii-lcd.c
>> @@ -97,7 +97,7 @@ static struct img_ascii_lcd_config boston_config = {
>>  static void malta_update(struct img_ascii_lcd_ctx *ctx)
>>  {
>> unsigned int i;
>> -   int err;
>> +   int err = 1;
>>
>> for (i = 0; i < ctx->cfg->num_chars; i++) {
>> err = regmap_write(ctx->regmap,
>> @@ -180,7 +180,7 @@ static int sead3_wait_lcd_idle(struct img_ascii_lcd_ctx 
>> *ctx)
>>  static void sead3_update(struct img_ascii_lcd_ctx *ctx)
>>  {
>> unsigned int i;
>> -   int err;
>> +   int err = 1;
>>
>> for (i = 0; i < ctx->cfg->num_chars; i++) {
>> err = sead3_wait_lcd_idle(ctx);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH v2 0/3] gpio-keys: Add support for specifying wakeup event action

[JeffyChen]

Hi Heiko,

Thanks for your reply :)

On 02/14/2018 09:39 PM, Heiko Stübner wrote:

Hi Jeffy,

Am Samstag, 10. Februar 2018, 12:09:04 CET schrieb Jeffy Chen:

On chromebook kevin, we are using gpio-keys for pen insert event. But
we only want it to wakeup the system when ejecting the pen.

So we may need to change the interrupt trigger type during suspending.

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

Jeffy Chen (3):
   Input: gpio-keys - add support for wakeup event action
   Input: gpio-keys - allow setting wakeup event action in DT
   arm64: dts: rockchip: Avoid wakeup when inserting the pen


The recipient-selection for the mail thread seems to be a bit off and
I only got the cover-letter and patch 3/3.
Therefore I won't really see if and when the Input-changes get
accepted. So please ping me once that has happened so I can pick up
the rockchip dts change for it.

oops, sorry, i'll add you to the CC list in the next version :)




Thanks
Heiko

Re: [PATCH v2 07/17] tracing: probeevent: Introduce new argument fetching code

[Masami Hiramatsu]

On Fri, 23 Feb 2018 13:30:03 +0900
Namhyung Kim  wrote:

> On Wed, Feb 21, 2018 at 11:57:36PM +0900, Masami Hiramatsu wrote:
> > Replace {k,u}probe event argument fetching framework
> > with switch-case based. Currently that is implemented
> > with structures, macros and chain of function-pointers,
> > which is more complicated than necessary and may get
> > a performance penalty by retpoline.
> > 
> > This simplify that with an array of "fetch_insn" (opcode
> > and oprands), and make process_fetch_insn() just
> > interprets it. No function pointers are used.
> 
> I think it'd be nice to split this commit to 3 parts:
> 
>  * convert to the fetch_insn
>  * remove fetch methods (now unused)

Hmm, I think we can do above 2 parts at a time, because fetch
methods are internal implementation, which is closed among
probe-event.

>  * unify fetch type table

Sure. this is an actual cleanup.

Thank you,

> 
> Thanks,
> Namhyung
> 
> 
> > 
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  Changes in v2:
> >   - Allow $comm:string.
> > ---
> >  kernel/trace/trace_kprobe.c |  314 +++-
> >  kernel/trace/trace_probe.c  |  441 
> > ---
> >  kernel/trace/trace_probe.h  |  232 -
> >  kernel/trace/trace_probe_tmpl.h |  120 +++
> >  kernel/trace/trace_uprobe.c |  150 +++--
> >  5 files changed, 517 insertions(+), 740 deletions(-)
> >  create mode 100644 kernel/trace/trace_probe_tmpl.h
> > 
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index a96328dfc012..5dd2d470cc7e 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  
> >  #include "trace_probe.h"
> > +#include "trace_probe_tmpl.h"
> >  
> >  #define KPROBE_EVENT_SYSTEM "kprobes"
> >  #define KRETPROBE_MAXACTIVE_MAX 4096
> > @@ -121,184 +122,6 @@ static int kprobe_dispatcher(struct kprobe *kp, 
> > struct pt_regs *regs);
> >  static int kretprobe_dispatcher(struct kretprobe_instance *ri,
> > struct pt_regs *regs);
> >  
> > -/* Memory fetching by symbol */
> > -struct symbol_cache {
> > -   char*symbol;
> > -   longoffset;
> > -   unsigned long   addr;
> > -};
> > -
> > -unsigned long update_symbol_cache(struct symbol_cache *sc)
> > -{
> > -   sc->addr = (unsigned long)kallsyms_lookup_name(sc->symbol);
> > -
> > -   if (sc->addr)
> > -   sc->addr += sc->offset;
> > -
> > -   return sc->addr;
> > -}
> > -
> > -void free_symbol_cache(struct symbol_cache *sc)
> > -{
> > -   kfree(sc->symbol);
> > -   kfree(sc);
> > -}
> > -
> > -struct symbol_cache *alloc_symbol_cache(const char *sym, long offset)
> > -{
> > -   struct symbol_cache *sc;
> > -
> > -   if (!sym || strlen(sym) == 0)
> > -   return NULL;
> > -
> > -   sc = kzalloc(sizeof(struct symbol_cache), GFP_KERNEL);
> > -   if (!sc)
> > -   return NULL;
> > -
> > -   sc->symbol = kstrdup(sym, GFP_KERNEL);
> > -   if (!sc->symbol) {
> > -   kfree(sc);
> > -   return NULL;
> > -   }
> > -   sc->offset = offset;
> > -   update_symbol_cache(sc);
> > -
> > -   return sc;
> > -}
> > -
> > -/*
> > - * Kprobes-specific fetch functions
> > - */
> > -#define DEFINE_FETCH_stack(type)   \
> > -static void FETCH_FUNC_NAME(stack, type)(struct pt_regs *regs, 
> > \
> > - void *offset, void *dest) \
> > -{  \
> > -   *(type *)dest = (type)regs_get_kernel_stack_nth(regs,   \
> > -   (unsigned int)((unsigned long)offset)); \
> > -}  \
> > -NOKPROBE_SYMBOL(FETCH_FUNC_NAME(stack, type));
> > -
> > -DEFINE_BASIC_FETCH_FUNCS(stack)
> > -/* No string on the stack entry */
> > -#define fetch_stack_string NULL
> > -#define fetch_stack_string_sizeNULL
> > -
> > -#define DEFINE_FETCH_memory(type)  \
> > -static void FETCH_FUNC_NAME(memory, type)(struct pt_regs *regs,
> > \
> > - void *addr, void *dest)   \
> > -{  \
> > -   type retval;\
> > -   if (probe_kernel_address(addr, retval)) \
> > -   *(type *)dest = 0;  \
> > -   else\
> > -   *(type *)dest = retval; \
> > -}  \
> > -NOKPROBE_SYMBOL(FETCH_FUNC_NAME(memory, type));
> > -
> > -DEFINE_BASIC_FETCH_FUNCS(memory)
> > -/*
> > - * Fetch a null-terminated string. Caller MUST set *(u32 *)dest with max
> > - * length and relative 

Re: [BUGFIX PATCH v2.1] tracing: probeevent: Fix to support minus offset from symbol

[Masami Hiramatsu]

On Fri, 23 Feb 2018 09:15:42 +0900
Namhyung Kim  wrote:

> Hi Masami,
> 
> On Thu, Feb 22, 2018 at 04:45:01PM +0900, Masami Hiramatsu wrote:
> > In Documentation/trace/kprobetrace.txt, it says
> > 
> >  @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
> > 
> > However, the parser doesn't parse minus offset correctly, since
> > commit 2fba0c8867af ("tracing/kprobes: Fix probe offset to be
> > unsigned") drops minus ("-") offset support for kprobe probe
> > address usage.
> > 
> > This fixes the traceprobe_split_symbol_offset() to parse minus
> > offset again with checking the offset range, and add a minus
> > offset check in kprobe probe address usage.
> > 
> > Fixes: 2fba0c8867af ("tracing/kprobes: Fix probe offset to be unsigned")
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >  Changes in v2.1:
> >   - Fix to ensure the offset value is less than LONG_MAX.
> >   - Fail if the offset is minus when traceprobe_split_symbol_offset()
> > is used for the probe address.
> >   - Add Fixes tag.
> > ---
> >  kernel/trace/trace_kprobe.c |4 ++--
> >  kernel/trace/trace_probe.c  |   15 ++-
> >  kernel/trace/trace_probe.h  |2 +-
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index 5ce9b8cf7be3..b5b1d8aa47d6 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -667,7 +667,7 @@ static int create_trace_kprobe(int argc, char **argv)
> > char *symbol = NULL, *event = NULL, *group = NULL;
> > int maxactive = 0;
> > char *arg;
> > -   unsigned long offset = 0;
> > +   long offset = 0;
> > void *addr = NULL;
> > char buf[MAX_EVENT_NAME_LEN];
> >  
> > @@ -755,7 +755,7 @@ static int create_trace_kprobe(int argc, char **argv)
> > symbol = argv[1];
> > /* TODO: support .init module functions */
> > ret = traceprobe_split_symbol_offset(symbol, &offset);
> > -   if (ret) {
> > +   if (ret || offset < 0) {
> > pr_info("Failed to parse either an address or a 
> > symbol.\n");
> > return ret;
> > }
> > diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> > index d59357308677..ec3856147fdd 100644
> > --- a/kernel/trace/trace_probe.c
> > +++ b/kernel/trace/trace_probe.c
> > @@ -320,21 +320,26 @@ static fetch_func_t get_fetch_size_function(const 
> > struct fetch_type *type,
> >  }
> >  
> >  /* Split symbol and offset. */
> > -int traceprobe_split_symbol_offset(char *symbol, unsigned long *offset)
> > +int traceprobe_split_symbol_offset(char *symbol, long *offset)
> >  {
> > +   unsigned long ul;
> > char *tmp;
> > int ret;
> >  
> > if (!offset)
> > return -EINVAL;
> >  
> > -   tmp = strchr(symbol, '+');
> > +   tmp = strpbrk(symbol, "+-");
> > if (tmp) {
> > -   /* skip sign because kstrtoul doesn't accept '+' */
> > -   ret = kstrtoul(tmp + 1, 0, offset);
> > +   ret = kstrtoul(tmp + 1, 0, &ul);
> 
> Why not just using kstrtol() which handles the sign correctly?

Oops, right!

Thank you!

> 
> Thanks,
> Namhyung
> 
> 
> > if (ret)
> > return ret;
> > -
> > +   if (ul > LONG_MAX)
> > +   return -E2BIG;
> > +   if (*tmp == '-')
> > +   *offset = -ul;
> > +   else
> > +   *offset = ul;
> > *tmp = '\0';
> > } else
> > *offset = 0;
> > diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> > index 0745f895f780..75daff22ccea 100644
> > --- a/kernel/trace/trace_probe.h
> > +++ b/kernel/trace/trace_probe.h
> > @@ -365,7 +365,7 @@ extern int traceprobe_conflict_field_name(const char 
> > *name,
> >  extern void traceprobe_update_arg(struct probe_arg *arg);
> >  extern void traceprobe_free_probe_arg(struct probe_arg *arg);
> >  
> > -extern int traceprobe_split_symbol_offset(char *symbol, unsigned long 
> > *offset);
> > +extern int traceprobe_split_symbol_offset(char *symbol, long *offset);
> >  
> >  /* Sum up total data length for dynamic arraies (strings) */
> >  static nokprobe_inline int
> > 


-- 
Masami Hiramatsu 

RE: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

[He, Roger]

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Tuesday, February 20, 2018 8:58 PM
To: amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
linux-kernel@vger.kernel.org
Subject: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and 
swapout.

This solves the problem that when we swapout a BO from a domain we sometimes 
couldn't make room for it because holding the lock blocks all other BOs with 
this reservation object.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
d90b1cf10b27..3a44c2ee4155 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -713,31 +713,30 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 /**
- * Check the target bo is allowable to be evicted or swapout, including cases:
- *
- * a. if share same reservation object with ctx->resv, have assumption
- * reservation objects should already be locked, so not lock again and
- * return true directly when either the opreation allow_reserved_eviction
- * or the target bo already is in delayed free list;
- *
- * b. Otherwise, trylock it.
+ * Check if the target bo is allowed to be evicted or swapedout.
  */
 static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
-   struct ttm_operation_ctx *ctx, bool *locked)
+  struct ttm_operation_ctx *ctx,
+  bool *locked)
 {
-   bool ret = false;
+   /* First check if we can lock it */
+   *locked = reservation_object_trylock(bo->resv);
+   if (*locked)
+   return true;
 
-   *locked = false;
+   /* Check if it's locked because it is part of the current operation */
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
-   if (ctx->allow_reserved_eviction || !list_empty(&bo->ddestroy))
-   ret = true;
-   } else {
-   *locked = reservation_object_trylock(bo->resv);
-   ret = *locked;
+   return ctx->allow_reserved_eviction ||
+   !list_empty(&bo->ddestroy);
}
 
-   return ret;
+   /* Check if it's locked because it was already evicted */
+   if (ww_mutex_is_owned_by(&bo->resv->lock, NULL))
+   return true;

For the special case: when command submission with Per-VM-BO enabled,
All BOs  a/b/c are always valid BO. After the validation of BOs a and b,  
when validation of BO c, is it possible to return true and then evict BO a and 
b by mistake ?
Because a/b/c share same task_struct.

Thanks
Roger(Hongbo.He)

+   /* Some other thread is using it, don't touch it */
+   return false;
 }
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
--
2.14.1

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

RE: [PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

[He, Roger]

Reviewed-by: Roger He 

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Tuesday, February 20, 2018 8:58 PM
To: amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
linux-kernel@vger.kernel.org
Subject: [PATCH 2/4] drm/amdgpu: use new ww_mutex_is_owned_by function

Instead of accessing ww_mutex internals directly use the provided function to 
check if the ww_mutex was indeed locked by the current command submission.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index eaa3cb0c3ad1..6db26a3144dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1594,7 +1594,7 @@ int amdgpu_cs_find_mapping(struct amdgpu_cs_parser 
*parser,
*map = mapping;
 
/* Double check that the BO is reserved by this CS */
-   if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != &parser->ticket)
+   if (!ww_mutex_is_owned_by(&(*bo)->tbo.resv->lock, &parser->ticket))
return -EINVAL;
 
if (!((*bo)->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)) {
--
2.14.1

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

Re: linux-next: manual merge of the staging tree with Linus' tree

[Greg KH]

On Fri, Feb 23, 2018 at 01:28:36PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/fsl-mc/bus/Kconfig
> 
> between commit:
> 
>   02b7b2844c2f ("staging: fsl-mc: fix build testing on x86")
> 
> from Linus' tree and commit:
> 
>   6bd067c48efe ("staging: fsl-mc: Move core bus out of staging")
> 
> from the staging tree.
> 
> I fixed it up (I used the latter version of that file and applied the
> followinf merge fix patch) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Fri, 23 Feb 2018 13:25:34 +1100
> Subject: [PATCH] staging: fsl-mc: merge fix for CONFIG_FSL_MC_BUS moving
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/bus/fsl-mc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig
> index bcca64486fd3..c23c77c9b705 100644
> --- a/drivers/bus/fsl-mc/Kconfig
> +++ b/drivers/bus/fsl-mc/Kconfig
> @@ -7,7 +7,7 @@
>  
>  config FSL_MC_BUS
>   bool "QorIQ DPAA2 fsl-mc bus driver"
> - depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM || ARM64 || 
> X86 || PPC)))
> + depends on OF && (ARCH_LAYERSCAPE || (COMPILE_TEST && (ARM || ARM64 || 
> X86_LOCAL_APIC || PPC)))
>   select GENERIC_MSI_IRQ_DOMAIN
>   help
> Driver to enable the bus infrastructure for the QorIQ DPAA2
> -- 
> 2.16.1

Thanks for this, I'll fix it up after 4.16-rc3 is out.

greg k-h

Re: [PATCH] MIPS: ath25: check for kzalloc allocation failure

[James Hogan]

On Thu, Feb 22, 2018 at 05:50:12PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Currently there is no null check on a failed allocation of board_data,
> and hence a null pointer dereference will occurr.  Fix this by checking
> for the out of memory null pointer.
> 
> Fixes: a7473717483e ("MIPS: ath25: add board configuration detection")
> Signed-off-by: Colin Ian King 

Applied to my fixes branch with 3.19+ stable tag.

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH] MIPS: OCTEON: irq: check for null return on kzalloc allocation

[James Hogan]

On Thu, Feb 22, 2018 at 10:10:30AM -0800, David Daney wrote:
> On 02/22/2018 10:08 AM, Colin King wrote:
> > From: Colin Ian King 
> > 
> > The allocation of host_data is not null checked, leading to a
> > null pointer dereference if the allocation fails. Fix this by
> > adding a null check and return with -ENOMEM.
> > 
> > Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
> > Signed-off-by: Colin Ian King 
> 
> Acked-by: David Daney 

Applied to my fixes branch with 4.0+ stable tag.

Thanks
James


signature.asc
Description: Digital signature

Re: [PATCH 3/3] ARM: davinci: mark spi_board_info arrays as const

[Sekhar Nori]

On Thursday 22 February 2018 10:13 PM, Arnd Bergmann wrote:
> On Tue, Feb 20, 2018 at 5:24 PM, Arnd Bergmann  wrote:
>> Building with LTO revealed that three spi_board_info arrays are marked
>> __initconst, but not const:
>>
>> arch/arm/mach-davinci/board-dm365-evm.c: In function 'dm365_evm_init':
>> arch/arm/mach-davinci/board-dm365-evm.c:729:30: error: 'dm365_evm_spi_info' 
>> causes a section type conflict with 'dm646x_edma_device'
>>  static struct spi_board_info dm365_evm_spi_info[] __initconst = {
>>   ^
>> arch/arm/mach-davinci/dm646x.c:603:42: note: 'dm646x_edma_device' was 
>> declared here
>>  static const struct platform_device_info dm646x_edma_device __initconst = {
>>
>> This marks them const as well, as was originally intended.
>>
>> Signed-off-by: Arnd Bergmann 
> 
> I applied this to the fixes branch now.

Thanks Arnd. FWIW now:

Acked-by: Sekhar Nori 

Regards,
Sekhar

Re: [PATCH 00/17] Add kexec_file_load support to s390

[Philipp Rudo]

Hi Dave

On Fri, 23 Feb 2018 16:34:05 +0800
Dave Young  wrote:

> On 02/14/18 at 10:54am, Philipp Rudo wrote:
> > Hi Dave,
> > 
> > I just browsed AKASHI's patches (v7). The way I see it the common code 
> > changes
> > are on different areas of kexec_file and shouldn't get in conflict. Only in 
> > the
> > arch code (s390 and arm64) some function calls might need an update. But I 
> > have
> > to take a closer look on the patches first.  
> 
> I'm tring both in local branch with both series (V8 from AKASHI and this 
> series),
> but there are indeed some conflicts, may because AKASHI factored out some arch
> code from ppc/x86 to common code.

I feared this would happen.  I didn't have time to look at AKASHI's v8
yesterday but hope to find some today. How do you think i should handle
conflicts with his patches? I don't think it is wise to include the changes
into my patches as that would make AKASHI's patches a prereq for mine. Is adding
one (multiple?) fixup patches on top of my series ok for you?

Thanks
Philipp

> > 
> > @AKASHI: Welcome to the list. While browsing I couldn't find any
> > arch_apply_relocation function for arm64. These require the biggest changes 
> > in
> > my patch set. Did I just miss it or does arm64 work differently?
> > 
> > @Dave: Happy holiday  
> 
> Thank you!
> 
> > 
> > Thanks
> > Philipp
> > 
> > On Wed, 14 Feb 2018 15:35:43 +0800
> > Dave Young  wrote:
> >   
> > > Hi Philipp,
> > > 
> > > I added AKASHI in cc, he posted arm64 kexec_file series previously.
> > > I would like to read both series especially the general part, but
> > > maybe at the end of this month because of a holiday..
> > > 
> > > From the patch log the cleanup looks nice, but still need read the
> > > details.
> > > 
> > > On 02/12/18 at 11:07am, Philipp Rudo wrote:  
> > > > Hi everybody
> > > > 
> > > > resending the series as there was no reaction, yet. Furthermore i was 
> > > > told
> > > > that Andrew and the x86 list should also be CCed, so welcome.
> > > > 
> > > > No changes made to the patches since first time i sent them. The patches
> > > > apply to the current master (v4.16-rc1).
> > > > 
> > > > Thanks
> > > > Philipp
> > > > 
> > > > ---
> > > > 
> > > > this series adds the kexec_file_load system call to s390. Before the 
> > > > system
> > > > call is added there are some preparations/clean ups to common
> > > > kexec_file_load. In detail this series contains:
> > > > 
> > > > Patch #1&2: Minor cleanups/fixes.
> > > > 
> > > > Patch #3-9: Clean up the purgatory load/relocation code. Especially 
> > > > remove
> > > > the mis-use of the purgatory_info->sechdrs->sh_offset field, currently
> > > > holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw)
> > > > depending on the section. With these patches the section address will be
> > > > calculated verbosely and sh_offset will contain the offset of the 
> > > > section
> > > > in the stripped purgatory binary (purgatory_buf).
> > > > 
> > > > Patch #10: Allows architectures to set the purgaory load address. This
> > > > patch is important for s390 as the kernel and purgatory have to be 
> > > > loaded
> > > > to fixed addresses. In current code this is impossible as the purgatory
> > > > load is opaque to the architecture.
> > > > 
> > > > Patch #11: Moves x86 purgatories sha implementation to common lib/
> > > > directory.
> > > > 
> > > > Patches #12-17 finally adds the kexec_file_load system call to s390.
> > > > 
> > > > Please note that I had to touch arch code for x86 and power a little. In
> > > > theory this should not change the behavior but I don't have a way to 
> > > > test
> > > > it. Cross-compiling with defconfig(*) works fine for both.
> > > > 
> > > > Thanks
> > > > Philipp
> > > > 
> > > > (*) On x86 with the orc unwinder turned off. objtool SEGFAULTs on 
> > > > s390...
> > > > 
> > > > Philipp Rudo (17):
> > > >   kexec_file: Silence compile warnings
> > > >   kexec_file: Remove checks in kexec_purgatory_load
> > > >   kexec_file: Make purgatory_info->ehdr const
> > > >   kexec_file: Search symbols in read-only kexec_purgatory
> > > >   kexec_file: Use read-only sections in arch_kexec_apply_relocations*
> > > >   kexec_file: Split up __kexec_load_puragory
> > > >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 1
> > > >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 2
> > > >   kexec_file: Remove mis-use of sh_offset field
> > > >   kexec_file: Allow archs to set purgatory load address
> > > >   kexec_file: Move purgatories sha256 to common code
> > > >   s390/kexec_file: Prepare setup.h for kexec_file_load
> > > >   s390/kexec_file: Add purgatory
> > > >   s390/kexec_file: Add kexec_file_load system call
> > > >   s390/kexec_file: Add image loader
> > > >   s390/kexec_file: Add crash support to image loader
> > > >   s390/kexec_file: Add ELF loader
> > > > 
> > > >  arch/powerpc/kernel/kexec_elf_64.c |   9 +-
> > > >  arch/s390/Kbuild   |   1 +
> > > >

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

[JeffyChen]

Hi Brian,

Thanks for your reply.

On 02/13/2018 06:13 AM, Brian Norris wrote:

>
>if (bdata->gpiod) {
>+   int active_low = gpiod_is_active_low(bdata->gpiod);
>+
>if (button->debounce_interval) {
>error = gpiod_set_debounce(bdata->gpiod,
>button->debounce_interval * 1000);
>@@ -568,6 +572,16 @@ static int gpio_keys_setup_key(struct platform_device 
*pdev,
>isr = gpio_keys_gpio_isr;
>irqflags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
>
>+   switch (button->wakeup_event_action) {
>+   case EV_ACT_ASSERTED:
>+   bdata->wakeup_trigger_type = active_low ?
>+   IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING;
>+   break;
>+   case EV_ACT_DEASSERTED:
>+   bdata->wakeup_trigger_type = active_low ?
>+   IRQF_TRIGGER_RISING : IRQF_TRIGGER_FALLING;
>+   break;

What about EV_ACT_ANY? And default case? I think for ANY, we're OK
letting suspend/resume not reconfigure the trigger type, but maybe a
comment here to note that?

right, will add comment in the next version.



>+   }
>} else {

What about the 'else' case? Shouldn't we try to handle that?
i think the else case is for irq key, which would generate down and up 
events in one irq, so it would use the same trigger type for all these 3 
cases.


i'll add comment in the next version too.


Brian

Re: [PATCH 6/6] arm64: dts: renesas: r8a77965: Add #interrupt-cells property

[jacopo mondi]

Hi Geert,

On Fri, Feb 23, 2018 at 10:27:16AM +0100, Geert Uytterhoeven wrote:
> On Thu, Feb 22, 2018 at 8:06 PM, Jacopo Mondi  
> wrote:
> > Add "#interrupt-cells" property and "interrupt-controller" label to
> > "interrupt-controller@e61c" device node.
> >
> > This silences the following DTC compiler warnings:
> > Warning (interrupts_property): Missing interrupt-controller or
> > interrupt-map property in /soc/interrupt-controller@e61c
> > Warning (interrupts_property): Missing #interrupt-cells in
> > interrupt-parent /soc/interrupt-controller@e61c000
> >
> > Signed-off-by: Jacopo Mondi 
>
> Reviewed-by: Geert Uytterhoeven 
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -316,6 +316,8 @@
> > };
> >
> > intc_ex: interrupt-controller@e61c {
> > +   #interrupt-cells = <2>;
> > +   interrupt-controller;
> > reg = <0 0xe61c 0 0x200>;
> > /* placeholder */
>
> (bikeshedding) Should the placeholder be at the top of the node?

I would like it more too, but in M3-W dtsi:

pciec0: pcie@fe00 {
reg = <0 0xfe00 0 0x8>;
/* placeholder */
};

So I kept using the same style everywhere here.

I can change it everywhere in this series to have placeholder at the
beginning of the node definition if you agree with that!

Thanks
   j

>
> > };
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

[GIT PULL] printk for 4.16-rc3

[Petr Mladek]

Linus,

please pull one printk-related fix for 4.16-rc3 from

  git://git.kernel.org/pub/scm/linux/kernel/git/pmladek/printk.git for-linus



- People expect to see the real pointer value for %px. Let's substitute
  "(null)" only for the other %p? format modifiers that need to deference
  the pointer.


Adam Borowski (1):
  vsprintf: avoid misleading "(null)" for %px

 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()

[Michal Hocko]

On Mon 19-02-18 14:30:36, Robert Harris wrote:
> 
> 
> > On 19 Feb 2018, at 12:39, Michal Hocko  wrote:
> > 
> > On Mon 19-02-18 12:14:26, Robert Harris wrote:
> >> 
> >> 
> >>> On 19 Feb 2018, at 08:26, Michal Hocko  wrote:
> >>> 
> >>> On Sun 18-02-18 16:47:55, robert.m.har...@oracle.com wrote:
>  From: "Robert M. Harris" 
>  
>  __fragmentation_index() calculates a value used to determine whether
>  compaction should be favoured over page reclaim in the event of 
>  allocation
>  failure.  The calculation itself is opaque and, on inspection, does not
>  match its existing description.  The function purports to return a value
>  between 0 and 1000, representing units of 1/1000.  Barring the case of a
>  pathological shortfall of memory, the lower bound is instead 500.  This 
>  is
>  significant because it is the default value of sysctl_extfrag_threshold,
>  i.e. the value below which compaction should be avoided in favour of page
>  reclaim for costly pages.
>  
>  This patch implements and documents a modified version of the original
>  expression that returns a value in the range 0 <= index < 1000.  It 
>  amends
>  the default value of sysctl_extfrag_threshold to preserve the existing
>  behaviour.
> >>> 
> >>> It is not really clear to me what is the actual problem you are trying
> >>> to solve by this patch. Is there any bug or are you just trying to
> >>> improve the current implementation to be more effective?
> >> 
> >> There is not a significant bug.
> >> 
> >> The first problem is that the mathematical expression in
> >> __fragmentation_index() is opaque, particularly given the lack of
> >> description in the comments or the original commit message.  This patch
> >> provides such a description.
> >> 
> >> Simply annotating the expression did not make sense since the formula
> >> doesn't work as advertised.  The fragmentation index is described as
> >> being in the range 0 to 1000 but the bounds of the formula are instead
> >> 500 to 1000.  This patch changes the formula so that its lower bound is
> >> 0.
> > 
> > But why do we want to fix that in the first place? Why don't we simply
> > deprecate the tunable and remove it altogether? Who is relying on tuning
> > this option. Considering how it doesn't work as advertised and nobody
> > complaining I have that feeling that it is not really used in wild…
> 
> I think it's a useful feature.  Ignoring any contrived test case, there
> will always be a lower limit on the degree of fragmentation that can be
> achieved by compaction.  If someone takes the trouble to measure this
> then it is entirely reasonable that he or she should be able to inhibit
> compaction for cases when fragmentation falls below some correspondingly
> sized threshold.

Do you have any practical examples?
-- 
Michal Hocko
SUSE Labs

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

[tip-bot for Jan Beulich]

Commit-ID:  6e558c9d10146ebe7f04917af2f8533b811f9c25
Gitweb: https://git.kernel.org/tip/6e558c9d10146ebe7f04917af2f8533b811f9c25
Author: Jan Beulich 
AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 09:51:38 +0100

x86/mm: Consider effective protection attributes in W+X check

Using just the leaf page table entry flags would cause a false warning
in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
Hand through both the current entry's flags as well as the accumulated
effective value (the latter as pgprotval_t instead of pgprot_t, as it's
not an actual entry's value).

This in particular eliminates the false W+X warning when running under
Xen, as commit:

  2cc42bac1c ("x86-64/Xen: eliminate W+X mappings")

had to make the necessary adjustment in L2 rather than L1 (the reason is
explained there). I.e. _PAGE_RW is clear there in L1, but _PAGE_NX is
set in L2.

Signed-off-by: Jan Beulich 
Reviewed-by: Juergen Gross 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Dmitry Vyukov 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/5a8fde890278001aa...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/dump_pagetables.c | 94 ++-
 1 file changed, 58 insertions(+), 36 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 0d6d67d18ad6..62a7e9f65dec 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -29,6 +29,7 @@
 struct pg_state {
int level;
pgprot_t current_prot;
+   pgprotval_t effective_prot;
unsigned long start_address;
unsigned long current_address;
const struct addr_marker *marker;
@@ -235,9 +236,9 @@ static unsigned long normalize_addr(unsigned long u)
  * print what we collected so far.
  */
 static void note_page(struct seq_file *m, struct pg_state *st,
- pgprot_t new_prot, int level)
+ pgprot_t new_prot, pgprotval_t new_eff, int level)
 {
-   pgprotval_t prot, cur;
+   pgprotval_t prot, cur, eff;
static const char units[] = "BKMGTPE";
 
/*
@@ -247,23 +248,24 @@ static void note_page(struct seq_file *m, struct pg_state 
*st,
 */
prot = pgprot_val(new_prot);
cur = pgprot_val(st->current_prot);
+   eff = st->effective_prot;
 
if (!st->level) {
/* First entry */
st->current_prot = new_prot;
+   st->effective_prot = new_eff;
st->level = level;
st->marker = address_markers;
st->lines = 0;
pt_dump_seq_printf(m, st->to_dmesg, "---[ %s ]---\n",
   st->marker->name);
-   } else if (prot != cur || level != st->level ||
+   } else if (prot != cur || new_eff != eff || level != st->level ||
   st->current_address >= st->marker[1].start_address) {
const char *unit = units;
unsigned long delta;
int width = sizeof(unsigned long) * 2;
-   pgprotval_t pr = pgprot_val(st->current_prot);
 
-   if (st->check_wx && (pr & _PAGE_RW) && !(pr & _PAGE_NX)) {
+   if (st->check_wx && (eff & _PAGE_RW) && !(eff & _PAGE_NX)) {
WARN_ONCE(1,
  "x86/mm: Found insecure W+X mapping at 
address %p/%pS\n",
  (void *)st->start_address,
@@ -317,21 +319,30 @@ static void note_page(struct seq_file *m, struct pg_state 
*st,
 
st->start_address = st->current_address;
st->current_prot = new_prot;
+   st->effective_prot = new_eff;
st->level = level;
}
 }
 
-static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t 
addr, unsigned long P)
+static inline pgprotval_t effective_prot(pgprotval_t prot1, pgprotval_t prot2)
+{
+   return (prot1 & prot2 & (_PAGE_USER | _PAGE_RW)) |
+  ((prot1 | prot2) & _PAGE_NX);
+}
+
+static void walk_pte_level(struct seq_file *m, struct pg_state *st, pmd_t addr,
+  pgprotval_t eff_in, unsigned long P)
 {
int i;
pte_t *start;
-   pgprotval_t prot;
+   pgprotval_t prot, eff;
 
start = (pte_t *)pmd_page_vaddr(addr);
for (i = 0; i < PTRS_PER_PTE; i++) {
prot = pte_flags(*start);
+   eff = effective_prot(eff_in, prot);
st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
-   note_page(m, st, __pgprot(prot), 5);
+   note_page(m, st, __pgprot(prot), eff, 5);
start++;
}
 }
@@ -351,7 +362,7 @@ static inline bool kasan_

[PATCH] x86: mce: fix kernel panic when check_interval is changed

[Seunghun Han]

I am Seunghun Han and a senior security researcher at National Security
Research Institute of South Korea.

I found a critical security issue which can make kernel panic in userspace.
After analyzing the issue carefully, I found that MCE driver in the kernel
has a problem which can be occurred in SMP environment.

The check_interval file in
/sys/devices/system/machinecheck/machinecheck directory is a
global timer value for MCE polling. If it is changed by one CPU, MCE driver
in kernel calls mce_restart() function and broadcasts the event to other
CPUs to delete and restart MCE polling timer.

The __mcheck_cpu_init_timer() function which is called by mce_restart()
function initializes the mce_timer variable, and the "lock" in mce_timer is
also reinitialized. If more than one CPU write a specific value to
check_interval file concurrently, one can initialize the "lock" in mce_timer
while the others are handling "lock" in mce_timer. This problem causes some
synchronization errors such as kernel panic and kernel hang.

It is a critical security problem because the attacker can make kernel panic
by writing a value to the check_interval file in userspace, and it can be
used for Denial-of-Service (DoS) attack.

To fix this problem, I changed the __mcheck_cpu_init_timer() function to
reuse mce_timer instead of initializing it. The purpose of the function is
to restart the timer and it can be archived by calling

Signed-off-by: Seunghun Han 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 3d8c573a9a27..d72f2f74f4d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1771,7 +1771,6 @@ static void __mcheck_cpu_init_timer(void)
 {
struct timer_list *t = this_cpu_ptr(&mce_timer);
 
-   timer_setup(t, mce_timer_fn, TIMER_PINNED);
mce_start_timer(t);
 }
 
@@ -2029,8 +2028,10 @@ static void mce_enable_ce(void *all)
return;
cmci_reenable();
cmci_recheck();
-   if (all)
+   if (all) {
+   del_timer_sync(this_cpu_ptr(&mce_timer));
__mcheck_cpu_init_timer();
+   }
 }
 
 static struct bus_type mce_subsys = {
-- 
2.11.0

Re: [PATCH v2 1/3] Input: gpio-keys - add support for wakeup event action

[JeffyChen]

Hi Enric,

Thanks for your reply.

On 02/14/2018 06:25 AM, Enric Balletbo Serra wrote:

Hi,

2018-02-13 19:25 GMT+01:00 Brian Norris :

Hi Enric,

On Tue, Feb 13, 2018 at 11:40:44AM +0100, Enric Balletbo i Serra wrote:

On 12/02/18 23:13, Brian Norris wrote:

On Sat, Feb 10, 2018 at 07:09:05PM +0800, Jeffy Chen wrote:

Add support for specifying event actions to trigger wakeup when using
the gpio-keys input device as a wakeup source.

This would allow the device to configure when to wakeup the system. For
example a gpio-keys input device for pen insert, may only want to wakeup
the system when ejecting the pen.

Suggested-by: Brian Norris 
Signed-off-by: Jeffy Chen 
---

Changes in v2:
Specify wakeup event action instead of irq trigger type as Brian
suggested.

[...]

Not sure if you were aware but there is also some discussion related to this,
maybe we can join the efforts?

v1: https://patchwork.kernel.org/patch/10208261/
v2: https://patchwork.kernel.org/patch/10211147/


Thanks for the pointers. IIUC, that's talking about a different problem:
how to utilize a GPIO key in level-triggered mode. That touches similar
code, but it doesn't really have anything to do with configuring a
different wakeup trigger type.



Right, sorry. I see now what you are doing.


The two patches would need to be reconciled, if they both are going to
be merged. But otherwise, I think they're perfectly fine to be separate.



Yes, that's why I got confused, I had those patches applied on my tree
and when I tried to apply these failed and I wrongly assumed that were
doing the same. Waiting to test the third version ;)
right, they are not related, and i should add the level irq case after 
that series merged :)




Thanks,
  Enric


Brian

[PATCH v1 00/19] refactor dts and add support for more boards

[sean.wang]

From: Sean Wang 

The series is to refactor current .dts for allowing more boards can properly
join and reuse almost the same device node definitions.

Before we're doing that, some works about enhancements and fixups are being
made on the dt-binding document and .dts files. In addition, the series has to
depend on the patch [1][2]. Otherwise, certain build failure would have an
occurrence.

[1] arm: dts: mt7623: add PCIe related nodes
http://lists.infradead.org/pipermail/linux-mediatek/2018-February/012053.html

[2] dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding
http://lists.infradead.org/pipermail/linux-mediatek/2018-February/011930.html

Sean Wang (19):
  dt-bindings: pinctrl: mediatek: use - instead of _ in examples
  dt-bindings: cpufreq: mediatek: use - instead of _ in examples
  dt-bindings: pinctrl: mediatek: add bindings for I2C2 and SPI2 on
MT7623
  dt-bindings: arm: mediatek: add support for more mt7623 reference
boards
  arm: dts: mt7623: add BTIF, HSDMA and SPI-NOR device nodes
  arm: dts: mt7623: fix USB initialization fails on bananapi-r2
  arm: dts: mt7623: fix the regulators mmc should use on bananapi-r2
  arm: dts: mt7623: enable three available UARTs on bananapi-r2
  arm: dts: mt7623: add related clock properties to cpu[1-3] nodes
  arm: dts: mt7623: remove useless property pinctrl-names at node
switch@0
  arm: dts: mt7623: use - instead of _ in DT node name
  arm: dts: mt7623: fix all Warnings (unit_address_vs_reg)
  arm: dts: mt7623: move node mt6323 leds to mt6323.dtsi
  arm: dts: mt7623: extend common file to unify all boards with MT7623
SoCs
  arm: dts: mt7623: add SPI[1,2], I2C2 and sound related nodes to
reference board
  arm: dts: mt7623: fixup available memory size on bananapi-r2
  arm: dts: mt7623: add MT7623N reference board with eMMC
  arm: dts: mt7623: add MT7623A reference boards
  arm: dts: mediatek: converted to using SPDX identifiers

 Documentation/devicetree/bindings/arm/mediatek.txt |   9 +
 .../bindings/cpufreq/cpufreq-mediatek.txt  |   6 +-
 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |   4 +-
 arch/arm/boot/dts/Makefile |   3 +
 arch/arm/boot/dts/mt2701-evb.dts   |   9 +-
 arch/arm/boot/dts/mt2701.dtsi  |   9 +-
 arch/arm/boot/dts/mt6323.dtsi  |  34 +-
 arch/arm/boot/dts/mt6580-evbp1.dts |   9 +-
 arch/arm/boot/dts/mt6580.dtsi  |   9 +-
 arch/arm/boot/dts/mt6589-aquaris5.dts  |  10 +-
 arch/arm/boot/dts/mt6589.dtsi  |  12 +-
 arch/arm/boot/dts/mt6592-evb.dts   |   9 +-
 arch/arm/boot/dts/mt6592.dtsi  |   9 +-
 arch/arm/boot/dts/mt7623.dtsi  |  70 ++-
 arch/arm/boot/dts/mt7623a-rfb-emmc.dts |  22 +
 arch/arm/boot/dts/mt7623a-rfb-nand.dts |  26 +
 arch/arm/boot/dts/mt7623a-rfb.dtsi |  84 +++
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts  | 462 +--
 arch/arm/boot/dts/mt7623n-rfb-emmc.dts |  37 ++
 arch/arm/boot/dts/mt7623n-rfb-nand.dts | 100 +---
 arch/arm/boot/dts/mt7623n-rfb.dtsi | 652 -
 arch/arm/boot/dts/mt8127-moose.dts |   9 +-
 arch/arm/boot/dts/mt8127.dtsi  |   9 +-
 arch/arm/boot/dts/mt8135-evbp1.dts |   9 +-
 arch/arm/boot/dts/mt8135.dtsi  |   9 +-
 include/dt-bindings/pinctrl/mt7623-pinfunc.h   |  24 +
 26 files changed, 966 insertions(+), 679 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt7623a-rfb-emmc.dts
 create mode 100644 arch/arm/boot/dts/mt7623a-rfb-nand.dts
 create mode 100644 arch/arm/boot/dts/mt7623a-rfb.dtsi
 create mode 100644 arch/arm/boot/dts/mt7623n-rfb-emmc.dts

-- 
2.7.4