Re: [PATCH v2 1/3] Kconfig : Remove HAS_IOMEM dependency for Graphics support

[Christian Borntraeger]

On 02/01/2018 07:41 PM, Farhan Ali wrote:
> The 'commit e25df1205f37 ("[S390] Kconfig: menus with depends on HAS_IOMEM.")'
> added the HAS_IOMEM dependecy for "Graphics support". This disabled the
> "Graphics support" menu for S390. But if we enable VT layer for S390,
> we would also need to enable the dummy console. So let's remove the
> HAS_IOMEM dependency.
> 
> Move this dependency to Opencores framebuffer driver which would fail to build
> with CONFIG_HAS_IOMEM disabled:
> 
> ERROR: "devm_ioremap_resource" [drivers/video/fbdev/ocfb.ko] undefined!
> 
> Signed-off-by: Farhan Ali 
> Tested-by: Dong Jia Shi 

This also enables several PCI based graphic device driver on s390.
This makes no sense but they all compile fine so I guess this is ok.

I think patch 2 and 3 are clearly for the s390 tree, patch 1 seems trivial
Also ccing Bart. Can we maybe get an ack to carry this patch also via the s390
tree?


> ---
>  drivers/video/Kconfig   | 1 -
>  drivers/video/fbdev/Kconfig | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..41e7ba9 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -3,7 +3,6 @@
>  #
> 
>  menu "Graphics support"
> - depends on HAS_IOMEM
> 
>  config HAVE_FB_ATMEL
>   bool
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 2f615b7..ec9c9ce 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -966,7 +966,7 @@ config FB_PVR2
> 
>  config FB_OPENCORES
>   tristate "OpenCores VGA/LCD core 2.0 framebuffer support"
> - depends on FB && HAS_DMA
> + depends on FB && HAS_DMA && HAS_IOMEM
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
>   select FB_CFB_IMAGEBLIT
> 

Re: [RFC PATCH 1/9] media: add request API core and UAPI

[Hans Verkuil]

On 02/02/2018 08:33 AM, Sakari Ailus wrote:



 +struct media_request_entity_data *
 +media_request_get_entity_data(struct media_request *req,
 +   struct media_entity *entity, void *fh)
>>>
>>> This makes the assumption that request data is bound to entities. How does
>>> this work with links?
>>>
>>> I wonder if it should rather be bound to graph objects, or certain graph
>>> objects. Having a standard way to bind request specific information e.g. to
>>> entities is definitely worth having, though.
>>>
>>> V4L2 framework specific information would be needed across the media graph
>>> and it'd be good to store it in a non-driver specific way. What I think
>>> you'd need is an interface that allows storing information based on two
>>> keys --- the request and e.g. a pointer provided by the caller. The V4L2
>>> framework would have one key, e.g. a pointer to an empty struct defined
>>> somewhere in the V4L2 framework could be used for the purpose.
>>>
>>> Going forward, the entire media graph state will be subject to changing
>>> through requests. This includes link state, media bus and pixel formats,
>>> cropping and scaling configurations, everything. Let's not try to go there
>>> yet in this patchset, but what I'm asking is to keep the goal in mind when
>>> implementating the request API.
>>
>> Yeah, I think a similar idea is brought up in the cover letter of the
>> next revision (although for different reasons). Entities are probably
>> not a one-fit for all use-cases.
>>
>> For the case of links though, I believe that the "entity" that would
>> control them would be the media controller itself, since it is the one
>> that takes the MEDIA_IOC_SETUP_LINK ioctl. But even for this case, we
>> cannot use an entity to look up the media_device, so something more
>> generic like an opaque key would probably be needed.
> 
> Perhaps in the near future we still need a little less than that. Changing
> something that has a state in V4L2 will be troublesome and will require
> managing state of what is now stream centric.
> 
> I still think that the framework would need to do the job of managing the
> video buffers related to a request as well as controls without necessarily
> trying to generalise that right now. But how to store these in a meaningful
> way? Putting them to the request itself would be one option: you'll need to
> dig the request up anyway when things are associated to it, and the driver
> needs it when it is queued.
> 
> I wonder what Hans and Laurent think.

I think this is something for the future. I want to avoid delaying the Request
API for endless internal design discussions. The public API should be solid,
but the internal framework will undoubtedly need to change in the future.

That's OK. The reality is that there is a lot of demand for the Request API for
stateless codecs, and that is what we should concentrate on.

Should the framework manage the buffers? I don't even know what is meant with
that exactly, let alone that I can give an answer.

Let's stay focused: 1) solid uAPI, 2) stateless codec support. The internal
framework shouldn't of course make it harder than it needs to to later extend
the support to camera pipelines, but neither should we spend much time on it
or we will never get this in.

Regards,

Hans

Re: [PATCH v2] buffer: Avoid setting buffer bits that are already set

[kemi]

Hi, Jens
  Could you help to merge this patch to your tree? Thanks

On 2017年11月03日 10:29, kemi wrote:
> 
> 
> On 2017年10月24日 09:16, Kemi Wang wrote:
>> It's expensive to set buffer flags that are already set, because that
>> causes a costly cache line transition.
>>
>> A common case is setting the "verified" flag during ext4 writes.
>> This patch checks for the flag being set first.
>>
>> With the AIM7/creat-clo benchmark testing on a 48G ramdisk based-on ext4
>> file system, we see 3.3%(15431->15936) improvement of aim7.jobs-per-min on
>> a 2-sockets broadwell platform.
>>
>> What the benchmark does is: it forks 3000 processes, and each  process do
>> the following:
>> a) open a new file
>> b) close the file
>> c) delete the file
>> until loop=100*1000 times.
>>
>> The original patch is contributed by Andi Kleen.
>>
>> Signed-off-by: Andi Kleen 
>> Signed-off-by: Kemi Wang 
>> Tested-by: Kemi Wang 
>> Reviewed-by: Jens Axboe 
>> ---
> 
> Seems that this patch is still not merged. Anything wrong with that? thanks
> 
>>  include/linux/buffer_head.h | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
>> index c8dae55..211d8f5 100644
>> --- a/include/linux/buffer_head.h
>> +++ b/include/linux/buffer_head.h
>> @@ -80,11 +80,14 @@ struct buffer_head {
>>  /*
>>   * macro tricks to expand the set_buffer_foo(), clear_buffer_foo()
>>   * and buffer_foo() functions.
>> + * To avoid reset buffer flags that are already set, because that causes
>> + * a costly cache line transition, check the flag first.
>>   */
>>  #define BUFFER_FNS(bit, name)   
>> \
>>  static __always_inline void set_buffer_##name(struct buffer_head *bh)   
>> \
>>  {   \
>> -set_bit(BH_##bit, &(bh)->b_state);  \
>> +if (!test_bit(BH_##bit, &(bh)->b_state))\
>> +set_bit(BH_##bit, &(bh)->b_state);  \
>>  }   \
>>  static __always_inline void clear_buffer_##name(struct buffer_head *bh) 
>> \
>>  {   \
>>

Re: [PATCH] extcon: int3496: process id-pin first so that we start with the right status

[Hans de Goede]

Hi,

On 02-02-18 01:32, Chanwoo Choi wrote:

On 2018년 01월 26일 04:39, Hans de Goede wrote:

Some other drivers may be waiting for our extcon to show-up (exiting their
probe methods with -EPROBE_DEFER until we show up).

These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to process the id-pin
before registering the extcon, so that other drivers see the correct state
right away.

Signed-off-by: Hans de Goede 
---
  drivers/extcon/extcon-intel-int3496.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/extcon/extcon-intel-int3496.c 
b/drivers/extcon/extcon-intel-int3496.c
index c8691b5a9cb0..b23ee9d993a3 100644
--- a/drivers/extcon/extcon-intel-int3496.c
+++ b/drivers/extcon/extcon-intel-int3496.c
@@ -131,6 +131,10 @@ static int int3496_probe(struct platform_device *pdev)
if (IS_ERR(data->gpio_usb_mux))
dev_info(dev, "can't request USB MUX GPIO\n");
  
+	/* process id-pin first so that we start with the right status */

+   queue_delayed_work(system_wq, >work, 0);
+   flush_delayed_work(>work);
+
/* register extcon device */
data->edev = devm_extcon_dev_allocate(dev, int3496_cable);
if (IS_ERR(data->edev))
@@ -153,9 +157,6 @@ static int int3496_probe(struct platform_device *pdev)
return ret;
}
  
-	/* queue initial processing of id-pin */

-   queue_delayed_work(system_wq, >work, 0);
-
platform_set_drvdata(pdev, data);
  
  	return 0;




Looks good to me.
How about adding the 'Fixes' commit id on patch description?


Right, this could use a:

Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI device extcon 
driver")

tag.


I think that your revert patch of axp288 and this patch
should be included in extcon-fixes branch.


Ack.

Regards,

Hans

drivers/infiniband/hw/bnxt_re/qplib_fp.c:335:4: note: in expansion of macro 'if'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   4bf772b14675411a69b3c807f73006de0fe4b649
commit: 37cb11acf1f72a007a85894a6dd2ec93932bde46 RDMA/bnxt_re: Add SRQ support 
for Broadcom adapters
date:   2 weeks ago
config: i386-randconfig-sb0-02021411 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 37cb11acf1f72a007a85894a6dd2ec93932bde46
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 
'bnxt_qplib_service_nq':
   drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,
  ^
   In file included from include/linux/kernel.h:10:0,
from include/linux/interrupt.h:6,
from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:
   drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   (struct bnxt_qplib_srq *)q_handle,
   ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:335:4: note: in expansion of macro 
>> 'if'
   if (!nq->srqn_handler(nq,
   ^
   drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   (struct bnxt_qplib_srq *)q_handle,
   ^
   include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:335:4: note: in expansion of macro 
>> 'if'
   if (!nq->srqn_handler(nq,
   ^
   drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
   (struct bnxt_qplib_srq *)q_handle,
   ^
   include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^
>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:335:4: note: in expansion of macro 
>> 'if'
   if (!nq->srqn_handler(nq,
   ^
   In file included from include/linux/byteorder/little_endian.h:5:0,
from arch/x86/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/x86/include/asm/bitops.h:518,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/interrupt.h:6,
from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:
   drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 
'bnxt_qplib_create_srq':
   include/uapi/linux/byteorder/little_endian.h:31:43: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
#define __cpu_to_le64(x) ((__force __le64)(__u64)(x))
  ^
   include/linux/byteorder/generic.h:86:21: note: in expansion of macro 
'__cpu_to_le64'
#define cpu_to_le64 __cpu_to_le64
^
   drivers/infiniband/hw/bnxt_re/qplib_fp.c:567:19: note: in expansion of macro 
'cpu_to_le64'
 req.srq_handle = cpu_to_le64(srq);
  ^

vim +/if +335 drivers/infiniband/hw/bnxt_re/qplib_fp.c

   274  
   275  static void bnxt_qplib_service_nq(unsigned long data)
   276  {
   277  struct bnxt_qplib_nq *nq = (struct bnxt_qplib_nq *)data;
   278  struct bnxt_qplib_hwq *hwq = >hwq;
   279  struct nq_base *nqe, **nq_ptr;
   280  struct bnxt_qplib_cq *cq;
   281  int num_cqne_processed = 0;
   282  int num_srqne_processed = 0;
   283  u32 sw_cons, raw_cons;
   284  u16 type;
   285  int budget = nq->budget;
   286  u64 q_handle;
   287  
   288  /* Service the NQ until empty */
   289  raw_cons = hwq->cons;
   290  while (budget--) {
   291  sw_cons = HWQ_CMP(raw_cons, hwq);
   292  nq_ptr = (struct nq_base **)hwq->pbl_ptr;
   293  nqe = _ptr[NQE_PG(sw_cons)][NQE_IDX(sw_cons)];
   294  if (!NQE_CMP_VALID(nqe, raw_cons, hwq->max_elements))
   295  break;
   296  
   297  /*
   298   * The valid test of the entry must be done first before
   299   * reading any further.
   300   */
   301  dma_rmb();
   302  
   303  type = le16_to_cpu(nqe->info10_type) & 
NQ_BASE_TYPE_MASK;
   304  switch 

Re: [PATCH v6 02/41] clk: davinci: New driver for davinci PLL clocks

[Sekhar Nori]

On Friday 02 February 2018 12:27 AM, David Lechner wrote:
> On 02/01/2018 02:01 AM, Sekhar Nori wrote:
>> On Saturday 20 January 2018 10:43 PM, David Lechner wrote:
>>> This adds a new driver for mach-davinci PLL clocks. This is porting the
>>> code from arch/arm/mach-davinci/clock.c to the common clock framework.
>>> Additionally, it adds device tree support for these clocks.
>>>
>>> The ifeq ($(CONFIG_COMMON_CLK), y) in the Makefile is needed to prevent
>>> compile errors until the clock code in arch/arm/mach-davinci is removed.
>>>
>>> Note: although there are similar clocks for TI Keystone we are not able
>>> to share the code for a few reasons. The keystone clocks are device tree
>>> only and use legacy one-node-per-clock bindings. Also the register
>>> layouts are a bit different, which would add even more if/else mess
>>> to the keystone clocks. And the keystone PLL driver doesn't support
>>> setting clock rates.
>>>
>>> Signed-off-by: David Lechner 
>>
>> Looks nice and clean to me. There is still some feedback though.
>>
>> One thing missing is DIV4.5 clock. It will be nice to add that too,
>> mostly just because it will make the binding complete.
>>
>>> +void of_davinci_pll_init(struct device_node *node,
>>> + const struct davinci_pll_clk_info *info,
>>> + const struct davinci_pll_obsclk_info *obsclk_info,
>>> + const struct davinci_pll_sysclk_info *div_info,
>>> + u8 max_sysclk_id)
>>> +{
>>> +    struct device_node *child;
>>> +    const char *parent_name;
>>> +    void __iomem *base;
>>> +    struct clk *clk;
>>> +
>>> +    base = of_iomap(node, 0);
>>> +    if (!base) {
>>> +    pr_err("ioremap failed");
>>> +    return;
>>> +    }
>>> +
>>> +    if (info->flags & PLL_HAS_OSCIN)
>>> +    parent_name = of_clk_get_parent_name(node, 0);
>>> +    else
>>> +    parent_name = OSCIN_CLK_NAME;
>>
>> I don't think the reference clock input handling is fully
>> correct/flexible.
>>
>> There are two ways to provide input clock (ref_clk) to PLL. Either use
>> the internal oscillator with a crystal connected between OSCIN and
>> OSCOUT (CLKMODE = 0) or a clean clock input (CLKMODE = 1) connected to
>> OSCIN (OSCOUT disconnected).
>>
>> This is a board specific decision. On the LogicPD EVM, the former option
>> is used, on the LCDK board, the later.
>>
>> So, I think what we need is a DT property like
>> "ti,davinci-use-internal-osc" for the PLL. Boards can set or ignore it
>> and you can switch CLKMODE on or off based on that.
>>
>> Setting CLKMODE = 1 will switch off the internal oscillator (and
>> presumably save power), but it does not act as a mux. This explains why
>> not worrying about setting this correctly in current mainline still
>> works.
>>
>> I am also not sure if we really need PLL_HAS_OSCIN since all DaVinci
>> SoCs set it anyway.
> 
> 
> I realize this is a bit confusing. I think that part of this comes from
> the fact that OSCIN is not used consistently in the TRMs. It is used as

Thats right, I noticed that too. But all SoC datasheets I looked at
supported both internal oscillator and external clock input. Also, no
SoC had different reference clocks for its PLLs (DM355 has two crystal
inputs, but one of them goes only to the video peripheral).

So I still think there is benefit in standardizing on a single name in
kernel/DT (I was hoping it can be "ref_clk").

> the name of the actual pin on the SoC for connecting an external clock
> signal or crystal. It is also used as an input to CLKMODE where it means
> the output of the internal oscillator rather than the external pin (some
> SoCs show CLKMODE as a mux with OSCIN and CLKIN, but I agree that it is
> not really a mux since OSCIN and CLKIN are the same external pin on the
> SoC - then other SoCs show OSCIN meaning only the external pin here).
> Furthermore, OSCIN is listed as one of the inputs of EXTCLKSRC also as
> one of the inputs of OBSCLK on da850-type SoCs.

Right.

> So, the option I went with here is that "ref_clk" is the external clock
> connected to the OSCIN pin and that the "oscin" clock is the clock domain
> _after_ CLKMODE. This matches the use of OSCIN in the TRMs where "OSCIN"
> is used as an input for EXTCLKSRC and OBSCLK. Also the fact that the
> external reference clock is sometimes called CLKSRC instead of OSCIN
> influenced the decision go with "oscin" being the internal (to the PLL)
> clock domain.

Okay, I think we need some comments in code to make this distinction clear.

I do not yet understand why we need to differentiate between the
external-to-chip clock domain from internal "after CLKMODE" domain.
OTOH, I don't see a big harm in doing it either (as long as the
distinction is clear).

> 
> I think what I should have done, though, is named PLL_HAS_OSCIN as
> PLL_HAS_CLKMODE instead. I think what you are missing here is that
> PLL_HAS_OSCIN (or PLL_HAS_CLKMODE) only means that the PLL _has_
> PLLCTL[CLKMODE]. It does _not_ mean that we set (or 

Re: [PATCH v8 00/20] ILP32 for ARM64

[Yury Norov]

Hi Catalin, all

(Exclude Bamvor as his email became invalid)

This is 4.15-based kernel.
https://github.com/norov/linux/commits/ilp32-4.15

I tested it with LTP, no regressions found.

Kernel v4.15 incorporates SVE series from Dave Martin, so I updated ILP32
patches to agree with it. SVE-related changes are mostly in patches:
arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext
arm64: signal32: move ilp32 and aarch32 common code to separated file
arm64: signal: share lp64 signal structures and routines to ilp32
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Dave kindly reviewed that patches and proposed improvements:
https://www.spinics.net/lists/arm-kernel/msg629221.html

There's no ABI-related changes proposed, or urgent fixes; so I'll rework
signal subsystem during 4.16 cycle.

Are there any news with upstreaming this series?

Thanks,
Yury

On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> This series enables aarch64 with ilp32 mode.
> 
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t userspace type is used by new userspace).
> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
> 
> This version is based on linux-next from 2017-06-16. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
> 
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
> 
> Kernel, GLIBC and OpenSUSE-based distro:
> https://github.com/norov/linux/tree/ilp32-20170616.0
> https://github.com/norov/glibc/tree/dev9
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
> 
> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
> reference.)
> 
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: https://lkml.org/lkml/2017/1/9/213
> v8: - off_t referred in patches 2 and 13 stands for userspace type which is
>   underlined in corresponding patch comments and ARCH_32BIT_OFF_T config
>   option description;
> - __IGNORE_getrlimit and __IGNORE_setrlimit are added to
>   scripts/checksyscalls.sh (patch 3);
> - for CONFIG_COMPAT, bool changed to def_bool y and 'select COMPAT' is
>   dropped for AARCH32_EL0 and ARM64_ILP32 optiond (patches 5 and 20);
> - x19 register is used to load TSK_TI_FLAGS in svc path in
>   arch/arm64/kernel/entry.S to avoid register clobbering (patch 14).
> - ilp32 vdso-related files are syncronized wirh lp64 ones, mostly 
> Makefiles
>   (patch 19);
> - in arch/arm64/mm/mmap.c, arch_mmap_rnd() swithed to use is_compat_task()
>   (patch 9);
> - rebased on next-20170616.
> 
> Andrew Pinski (6):
>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>   arm64: ensure the kernel is compiled for LP64
>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
>   arm64:ilp32: add ARM64_ILP32 to Kconfig
> 
> Philipp Tomsich (1):
>   arm64:ilp32: add vdso-ilp32 and use for signal return
> 
> Yury Norov (13):
>   compat ABI: use non-compat openat and open_by_handle_at variants
>   32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>   thread: move thread bits accessors to separated file
>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>   arm64: introduce binfmt_elf32.c
>   arm64: ilp32: introduce binfmt_ilp32.c
>   arm64: ilp32: share aarch32 syscall handlers
>   arm64: signal: share lp64 signal routines to ilp32
>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
> 
>  Documentation/arm64/ilp32.txt |  45 +++
>  arch/Kconfig  |  15 +++
>  arch/arc/Kconfig  |   1 +
>  arch/arc/include/uapi/asm/unistd.h|   1 +
>  arch/arm/Kconfig  |   1 +
>  arch/arm64/Kconfig|  17 ++-
>  arch/arm64/Makefile   |   8 ++
>  arch/arm64/include/asm/compat.h   |  19 +--
>  arch/arm64/include/asm/elf.h  |  40 ++
>  arch/arm64/include/asm/fpsimd.h   |   2 +-
>  arch/arm64/include/asm/ftrace.h   |   2 +-
>  arch/arm64/include/asm/hwcap.h|   6 +-
>  arch/arm64/include/asm/is_compat.h|  90 ++
>  

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (4)

[Dmitry Vyukov]

On Fri, Feb 2, 2018 at 8:22 AM, Steffen Klassert
 wrote:
> On Thu, Feb 01, 2018 at 11:30:00AM +0100, Dmitry Vyukov wrote:
>> On Thu, Feb 1, 2018 at 9:34 AM, Steffen Klassert
>>
>> Hi Steffen,
>>
>> Please see the email footer:
>>
>> > If you want to test a patch for this bug, please reply with:
>> > #syz test: git://repo/address.git branch
>> > and provide the patch inline or as an attachment.
>
> Thanks for the hint, I've overlooked this. This is very usefull
> for the case that I can not reproduce the bug, but I think I know
> how to fix it.
>
> There are two more cases that come to my mind where syzbot could
> help.
>
> 1. I can not reproduce the bug and I don't know how to fix it,
>but some debug output would be helpfull:
>
>syz test-debug-patch-and-send-dmesg-output: git://repo/address.git branch

This is supported by "syz test", see:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot


> 2. I can not reproduce the bug and I have absolutely no idea what it
>could be:
>
>syz bisect: git://repo/address.git branch commit a commit b
>
> I don't know if this is possible, but it would bring the bugfixing
> process a bit coser to the case where a real user does a bug report.

This is on my plate:
https://github.com/google/syzkaller/issues/501
I think we probably will do bisection always without user request, and
then just post an additional email with results.


> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
>
>
> Subject: [PATCH RFC] xfrm: Refuse to insert 32 bit userspace socket policies 
> on 64 bit systems
>
> We don't have compat layer for xfrm, so userspace and kernel
> structures have different sizes in this case. This results in
> a broken confuguration, so refuse to configure socket policies
> when trying to insert from 32 bit userspace as we do it already
> with policies inserted via netlink.
>
> Reported-by: syzbot+e1a1577ca8bcb47b7...@syzkaller.appspotmail.com
> Signed-off-by: Steffen Klassert 
> ---
>  net/xfrm/xfrm_state.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index a3785f538018..25861a4ef872 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -2056,6 +2056,11 @@ int xfrm_user_policy(struct sock *sk, int optname, u8 
> __user *optval, int optlen
> struct xfrm_mgr *km;
> struct xfrm_policy *pol = NULL;
>
> +#ifdef CONFIG_COMPAT
> +   if (in_compat_syscall())
> +   return -EOPNOTSUPP;
> +#endif
> +
> if (optlen <= 0 || optlen > PAGE_SIZE)
> return -EMSGSIZE;
>
> --
> 2.14.1
>

Re: [PATCH v6 04/41] clk: davinci: Add platform information for TI DA850 PLL

[Sekhar Nori]

On Friday 02 February 2018 12:34 AM, David Lechner wrote:
> On 02/01/2018 02:58 AM, Sekhar Nori wrote:
>> On Saturday 20 January 2018 10:43 PM, David Lechner wrote:
>>> This adds platform-specific declarations for the PLL clocks on TI DA850/
>>> OMAP-L138/AM18XX SoCs.
>>>
>>> Signed-off-by: David Lechner 
>>
>>> +static const struct davinci_pll_clk_info da850_pll1_info __initconst
>>> = {
>>> +    .name = "pll1",
>>> +    .unlock_reg = CFGCHIP(3),
>>> +    .unlock_mask = CFGCHIP3_PLL1_MASTER_LOCK,
>>
>> I guess this will change with the cfgchip handling discussion last week.
> 
> Actually no, there really weren't any changes to the clock drivers because
> of this change. Only a small change in mach-davinci.
> 
>>
>>> +    .pllm_mask = GENMASK(4, 0),
>>> +    .pllm_min = 4,
>>> +    .pllm_max = 32,
>>> +    .pllout_min_rate = 3,
>>> +    .pllout_max_rate = 6,
>>> +    .flags = PLL_HAS_POSTDIV,
>>> +};
>>> +
>>
>> [...]
>>
>>> +void __init da850_pll_clk_init(void __iomem *pll0, void __iomem *pll1)
>>> +{
>>> +    const struct davinci_pll_sysclk_info *info;
>>> +
>>> +    davinci_pll_clk_register(_pll0_info, "ref_clk", pll0);
>>> +
>>> +    davinci_pll_auxclk_register("pll0_auxclk", pll0);
>>> +
>>> +    for (info = da850_pll0_sysclk_info; info->name; info++)
>>> +    davinci_pll_sysclk_register(info, pll0);
>>> +
>>> +    davinci_pll_obsclk_register(_pll0_obsclk_info, pll0);
>>> +
>>> +    davinci_pll_clk_register(_pll1_info, "oscin", pll1);
>>
>> Both PLL0 and PLL1 use the same reference clock. So this should be
>> "ref_clk". I dont think we ever need to register a clock called oscin
>> along with "ref_clk". There is only one reference clock. It can either
>> be obtained using internal oscillator or external oscillator.
>>
> 
> As per my response to the previous path, this depends on which both
> which SoC and which diagram in the TRM for that SoC you are looking at.
> It works either way.

I see the distinction you are making between clock inputs to the two
PLLs now. A comment somewhere (probably in pll.c) should do it.

Thanks,
Sekhar

Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces

[Aishwarya Pant]

On Thu, Feb 01, 2018 at 03:08:11PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 01, 2018 at 07:02:33PM +0530, Aishwarya Pant wrote:
> > Add documentation for core and hardware specific infiniband interfaces.
> > The descriptions have been collected from git commit logs, reading
> > through code and data sheets. Some drivers have incomplete doc and are
> > annotated with the comment '[to be documented]'.
> > 
> > Signed-off-by: Aishwarya Pant 
> >  Documentation/ABI/testing/sysfs-class-infiniband | 755 
> > +++
> >  1 file changed, 755 insertions(+)
> 
> Wow this looks really great
> 
> Should this patch delete some of the old documentation?

Yeah, I should do that because the documentation in
Documentation/infiniband/sysfs.txt is out of date.

> 
> > diff --git a/Documentation/ABI/testing/sysfs-class-infiniband 
> > b/Documentation/ABI/testing/sysfs-class-infiniband
> 
> Lots, maybe even all of of this is considered stable..

Okay, I guess it should belong to the stable directory then.

> 
> > +sysfs interface for Broadcom NetXtreme-E RoCE driver
> > +
> > +
> > +What:  /sys/class/infiniband/bnxt_reX/fw_rev
> > +What:  /sys/class/infiniband/bnxt_reX/hw_rev
> > +What:  /sys/class/infiniband/bnxt_reX/hca_type
> 
> These are actually common to all drivers
> 
>  /sys/class/infiniband/XXX/fw_rev, etc

Would make sense to define these at one place- hw_rev, hca_type, board_id are
common to a lot of the drivers.

Aishwarya

> 
> Jason

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Jani Nikula]

On Thu, 01 Feb 2018, Lukas Bulwahn  wrote:
> Hi Greg,
>
> On Thu, 1 Feb 2018, Greg KH wrote:
>
>> On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
>> > Dear Rodrigo Vivi, Ville Syrjälä,
>> > 
>> > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We 
>> > intend to use static analysis tools on the kernel source to identify, 
>> > analyze and report issues. As a very first step, we are looking into 
>> > clang compiler warnings and will then move to more sophisticated tools. 
>> >
>> > [...]
>> >
>> > Linux 4.15 is shipped with this clang warning, but we don't see the 
>> > crucial need to provide a backport commit to the stable branch for 4.15. 
>> > We just wanted to inform you about our analysis of this clang warning. 
>> > Ultimately the final call if you would like to address this clang warning 
>> > in 4.15 is yours.
>> 
>> Note, I have not taken "clang warning fixes" for stable kernel updates
>> in the past, and I doubt I will in the future, unless the tree "builds
>> clean" with clang.  If it eventually gets there, then yes, I will do
>> that.
>> 
>> Note, if you are going to email this out to everyone who fixes a warning
>> message, you might want to reconsider it.  That's going to be a lot of
>> work, and for people who have already fixed an issue, it's kind of
>> pointless to just remind them of work they have done in the past, right?
>> 
>> What is the goal of these types of emails?
>> 
>
> We are interested in providing useful information on potential bugs or bug 
> patterns that we get from static analysis tools, after we pre-assess them 
> and manually select them to send to the review process of the patch 
> submission.
>
> For me, the clang warnings were an easy starting point for a student to 
> set up and look at, compared to much more sophisticated tools, such as 
> coccinelle, sparse or new tools for the kernel development, such as CMBC 
> or facebook's Infer.
>
> Once we really understand which tools are useful and which information can 
> be quickly pre-assessed and sent out in a useful way without just creating 
> more noise in the discussion, I would have contacted the 0-day 
> infrastructure team or the kernelci.org team to continue the discussion 
> how to include our first setup into a proper semi-automated service.
>
> Using the clang warnings, I wanted to explore how this would even 
> potentially work.
>
> Considering clang, of course, currently, we cannot compile the whole 
> kernel with all possible kernel configurations with clang, but I believe 
> Nick Desaulniers, Matthias Kaehlcke and others are already working on 
> that and are getting close to this goal. Hence, assuming they will be 
> successful soon, I wanted to explore the next step of using static 
> analysis tools around the clang/LLVM compiler.
>
> Actually, v4.15 builds almost "cleanly" with clang: For defconfig, there 
> are only two clang compiler warnings and the one that we looked into 
> deeper here is already resolved in linux-next, so chances are actually 
> high that we might get to this "builds clean" soon-ish, at least for 
> defconfig.
>
> Concerning clang warnings and how to progress towards that goal of 
> building cleanly, my strategy is to identify when new clang compiler
> warnings are introduced and just point these warnings out as code smells 
> during the review discussion before they are merged into the 
> first maintainer tree. If we manually inspect these clang warnings
> to make sure that they are genuine code smells of some "imprecise 
> implementation" before we send them to the mailing list, I would hope that 
> they are of some value for the developer in the submission process and 
> he/she could address the warning in a patch v2 while he/she is reacting to 
> the other review comments from the human reviewers.
>
> At best, I always considered them as useful information during the review 
> process, but I certainly DO NOT want to start patching the kernel due to 
> clang warnings. The chances/risk that we just break more due to naively 
> fixing warnings without proper understanding is much higher than the  
> benefit of actually improving the situation. If I recall correctly, I 
> think this is also one of the lessons learned from motivating newcomers 
> to address warnings in previous kernel newbies activities.
>
> Greg, do you think it is worthwhile to invest some effort to move 
> towards the goal "kernel builds cleanly with clang"?
> Would you agree that providing information during the patch review is a 
> good way to move forward to this goal if we find a suitable manner to 
> provide this feedback quickly and cleanly at this very early stage of 
> development?
>
> If not, we will immediately stop to move in this direction and this is the 
> first and last email that you have seen of this kind, and we will have to 
> come up with better/other ideas around work on the Linux kernel.
>
> If so, we will continue in the direction sketched above, and I 

Re: [PATCH v6 04/41] clk: davinci: Add platform information for TI DA850 PLL

[Sekhar Nori]

On Friday 02 February 2018 12:52 AM, David Lechner wrote:

>> +static const char * const da850_pll1_obsclk_parent_names[]
>> __initconst = {
>> +    "oscin",
> 
> Re: the issue of "ref_clk" vs. "oscin"...
> 
> This is one of the places where having the otherwise unnecessary "oscin"
> clock
> really helps out. The PLL driver doesn't control "ref_clk" - it comes
> from somewhere
> else. And in the case of DT, it may not even be named "ref_clk", so we
> really
> don't want to hard-code the name "ref_clk" here.

TBH, I don't really see what is wrong with mandating the name "ref_clk"
as the reference clock name to be provided. And for all board-files and
DTs to supply the same name.

> If we have to allow a variable name here, it just makes more work in the
> driver
> shuffling names around.
> 
> And the name "oscin" totally makes sense here because the TRM lists this
> input to the
> mux as "OSCIN".

Fine with me if you feel it simplifies implementation for you (and also
because of the distinction you want to make between the external "before
CLKMODE" clock and internal "after CLKMODE" clock). What I do care about
though is:

a) In the DT case, ability for different boards to provide different
   ref_clk frequencies. We never really had this in the legacy board
   file way (except some rudimentary support on DM6467T). And its fine
   to continue with status quo for board files.

b) In the DT case, ability for board to specify whether it uses the
   on-chip oscillator or has an external clean clock provider.

>> +void __init da850_pll_clk_init(void __iomem *pll0, void __iomem *pll1)
>> +{
>> +    const struct davinci_pll_sysclk_info *info;
>> +
>> +    davinci_pll_clk_register(_pll0_info, "ref_clk", pll0);
> 
> And really, we probably shouldn't be hard-coding "ref_clk" here either.
> Basically, we are making the assumption that the board file has registered
> a clock named "ref_clk". It would probably be better to pass the name
> as a parameter.

As I noted before, I am not sure if this level of naming flexibility is
needed. Every board needs to have one anyway. They might as well call it
by the same name.

That said, I wont oppose it either if you decide to have that flexibility.

Thanks,
Sekhar

[PATCH] libnvdimm, namespace: make min namespace size 4K

[Dan Williams]

The arbitrary 4MB minimum namespace size turns out to be too large for
some environments. Quoting Cheng-mean Liu:

In the case of emulated NVDIMM devices in the VM environment, there
are scenarios that NVDIMM device with much smaller sizes are
desired, for example, we might use a single enumerated NVDIMM DAX
device for representing each container layer, which in some cases
could be just a few KBs size.

PAGE_SIZE is the minimum where we can still support DAX of at least
a single page.

Cc: Matthew Wilcox 
Reported-by: Cheng-mean Liu 
Signed-off-by: Dan Williams 
---
 include/uapi/linux/ndctl.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
index 30ef1236aafa..7e27070b9440 100644
--- a/include/uapi/linux/ndctl.h
+++ b/include/uapi/linux/ndctl.h
@@ -209,7 +209,7 @@ enum nd_driver_flags {
 };
 
 enum {
-   ND_MIN_NAMESPACE_SIZE = 0x0040,
+   ND_MIN_NAMESPACE_SIZE = PAGE_SIZE,
 };
 
 enum ars_masks {

Re: [GIT PULL tools] Linux kernel memory model

[Paul E. McKenney]

On Thu, Feb 01, 2018 at 07:57:42AM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:
> 
> > > I believe these additional improvements (to the extent you agree with 
> > > doing them!) 
> > > could/should be done as add-on commits on top of this existing commit.
> > 
> > Sounds good!
> > 
> > Would you prefer a pull request or a patch series for these?
> 
> Patch series would be nice, for review and later application to the locking 
> tree.

Works for me!

I will curate the series on branch lkmm in my -rcu tree, and send the
series out non-RFC when I believe that it is ready for you.

Thanx, Paul

Re: [PATCH 1/2] tools/memory-model: clarify the origin/scope of the tool name

[Paul E. McKenney]

On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> On Thu, 1 Feb 2018, Andrea Parri wrote:
> 
> > Ingo pointed out that:
> > 
> >   "The "memory model" name is overly generic, ambiguous and somewhat
> >misleading, as we usually mean the virtual memory layout/model
> >when we say "memory model". GCC too uses it in that sense [...]"
> > 
> > Make it clearer that, in the context of tools/memory-model/, the term
> > "memory-model" is used as shorthand for "memory consistency model" by
> > calling out this convention in tools/memory-model/README.
> > 
> > Stick to the full name in sources' headers and for the subsystem name.
> > 
> > Suggested-by: Ingo Molnar 
> > Signed-off-by: Andrea Parri 
> 
> For both patches:
> 
> Acked-by: Alan Stern 

Thank you all -- I have queued this and pushed it to my RCU tree on
branch lkmm.  I did reword the commit log a bit, please see below and
please let me know if any of my rewordings need halp.

Andrea, when you resend your second patch, could you please add Alan's
Acked-by?

Thanx, Paul



commit de175b697f71b8e3e6d980b7186b909fee0c4378
Author: Andrea Parri 
Date:   Thu Feb 1 13:03:29 2018 +0100

tools/memory-model: Clarify the origin/scope of the tool name

Ingo pointed out that:

  "The "memory model" name is overly generic, ambiguous and somewhat
   misleading, as we usually mean the virtual memory layout/model
   when we say "memory model". GCC too uses it in that sense [...]"

Make it clearer that tools/memory-model/ uses the term "memory model"
is used as shorthand for "memory consistency model" by calling out this
convention in tools/memory-model/README.

Stick to the original "memory model" term in sources' headers and for
the subsystem name.

Suggested-by: Ingo Molnar 
Signed-off-by: Andrea Parri 
Acked-by: Will Deacon 
Acked-by: Alan Stern 
Signed-off-by: Paul E. McKenney 

diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
index 711cbe72d606..db3bd3fc0435 100644
--- a/tools/memory-model/MAINTAINERS
+++ b/tools/memory-model/MAINTAINERS
@@ -1,4 +1,4 @@
-LINUX KERNEL MEMORY MODEL
+LINUX KERNEL MEMORY CONSISTENCY MODEL
 M: Alan Stern 
 M: Andrea Parri 
 M: Will Deacon 
diff --git a/tools/memory-model/README b/tools/memory-model/README
index 43ba49492111..91414a49fac5 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -1,15 +1,15 @@
-   =
-   LINUX KERNEL MEMORY MODEL
-   =
+   =
+   LINUX KERNEL MEMORY CONSISTENCY MODEL
+   =
 
 
 INTRODUCTION
 
 
-This directory contains the memory model of the Linux kernel, written
-in the "cat" language and executable by the (externally provided)
-"herd7" simulator, which exhaustively explores the state space of
-small litmus tests.
+This directory contains the memory consistency model (memory model, for
+short) of the Linux kernel, written in the "cat" language and executable
+by the externally provided "herd7" simulator, which exhaustively explores
+the state space of small litmus tests.
 
 In addition, the "klitmus7" tool (also externally provided) may be used
 to convert a litmus test to a Linux kernel module, which in turn allows
diff --git a/tools/memory-model/linux-kernel.bell 
b/tools/memory-model/linux-kernel.bell
index 57112505f5e0..b984bbda01a5 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -11,7 +11,7 @@
  * which is to appear in ASPLOS 2018.
  *)
 
-"Linux kernel memory model"
+"Linux-kernel memory consistency model"
 
 enum Accesses = 'once (*READ_ONCE,WRITE_ONCE,ACCESS_ONCE*) ||
'release (*smp_store_release*) ||
diff --git a/tools/memory-model/linux-kernel.cat 
b/tools/memory-model/linux-kernel.cat
index 15b7a5dd8a9a..babe2b3b0bb3 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -11,7 +11,7 @@
  * which is to appear in ASPLOS 2018.
  *)
 
-"Linux kernel memory model"
+"Linux-kernel memory consistency model"
 
 (*
  * File "lock.cat" handles locks and is experimental.

Re: [GIT PULL tools] Linux kernel memory model

[Paul E. McKenney]

On Fri, Feb 02, 2018 at 12:46:03PM +0800, Boqun Feng wrote:
> On Wed, Jan 31, 2018 at 05:17:28PM -0800, Paul E. McKenney wrote:
> [...]
> > > - A long term question: have you considered and would it make sense to 
> > > generate a
> > >   memory-barriers.txt like file directly into Documentation/locking/, 
> > > using the
> > >   formal description? That way any changes/extensions/fixes to the model 
> > > could be
> > >   tracked on a high level, without readers having to understand the formal
> > >   representation.
> > 
> > I hadn't considered this at all, actually.  ;-)
> > 
> > The sections of memory-barriers.txt dealing with MMIO ordering would need
> > to stay hand-generated, but they are a very small fraction of the total.
> > The herd7 tool is capable of generating cool diagrams sort of like
> > this one: https://static.lwn.net/images/2017/mm-model/rmo-acyclic.png,
> > which might replace at least some of the hand-generated ASCII-art
> > diagrams.
> 
> Which reminds me, one thing we could start with is to try to convert all
> the examples with litmus tests. Has this been done somewhere (e.g. in
> your litmus github repo)? If not, I can try if you think that's a good
> idea.

That would be very helpful, thank you!

There are probably some that are already in the litmus-tests directory,
but I suspect that most are not yet converted.  So please do!

Thanx, Paul

> Regards,
> Boqun
> 
> > Although I do confess harboring some skepticism about being able to
> > generated high-quality text, there is no denying that it would be
> > valuable to be able to do so.
> > 
> > > In any case, the base commit is certainly nice and clean and I've pulled 
> > > it into 
> > > tip:locking/core for a v4.17 merge.
> > 
> > Very good!
> > 
> > > I believe these additional improvements (to the extent you agree with 
> > > doing them!) 
> > > could/should be done as add-on commits on top of this existing commit.
> > 
> > Sounds good!
> > 
> > Would you prefer a pull request or a patch series for these?
> > 
> > Thanx, Paul
> > 

[PATCH net 2/2] r8152: set rx mode early when linking on

[Hayes Wang]

Set rx mode before calling netif_wake_queue() when linking on to avoid
the device missing the receiving packets.

The transmission may start after calling netif_wake_queue(), and the
packets of resopnse may reach before calling rtl8152_set_rx_mode()
which let the device could receive packets. Then, the packets of
response would be missed.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 756de9ea8d2e..958b2e8b90f6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3795,11 +3795,12 @@ static void set_carrier(struct r8152 *tp)
if (speed & LINK_STATUS) {
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
-   set_bit(RTL8152_SET_RX_MODE, >flags);
netif_stop_queue(netdev);
napi_disable(napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
+   clear_bit(RTL8152_SET_RX_MODE, >flags);
+   _rtl8152_set_rx_mode(netdev);
napi_enable(>napi);
netif_wake_queue(netdev);
netif_info(tp, link, netdev, "carrier on\n");
@@ -4259,7 +4260,7 @@ static int rtl8152_post_reset(struct usb_interface *intf)
mutex_lock(>control);
tp->rtl_ops.enable(tp);
rtl_start_rx(tp);
-   rtl8152_set_rx_mode(netdev);
+   _rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
}
 
-- 
2.13.6

[PATCH net 1/2] r8152: fix wrong checksum status for received IPv4 packets

[Hayes Wang]

The device could only check the checksum of TCP and UDP packets. Therefore,
for the IPv4 packets excluding TCP and UDP, the check of checksum is necessary,
even though the IP checksum is correct.

Take ICMP for example, The IP checksum may be correct, but the ICMP checksum
may be wrong.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0657203ffb91..756de9ea8d2e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1848,11 +1848,9 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc 
*rx_desc)
if (opts2 & RD_IPV4_CS) {
if (opts3 & IPF)
checksum = CHECKSUM_NONE;
-   else if ((opts2 & RD_UDP_CS) && (opts3 & UDPF))
-   checksum = CHECKSUM_NONE;
-   else if ((opts2 & RD_TCP_CS) && (opts3 & TCPF))
-   checksum = CHECKSUM_NONE;
-   else
+   else if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
+   checksum = CHECKSUM_UNNECESSARY;
+   else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))
checksum = CHECKSUM_UNNECESSARY;
} else if (opts2 & RD_IPV6_CS) {
if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
-- 
2.13.6

[PATCH net 0/2] r8152: fix rx issues

[Hayes Wang]

The two patched are used to fix rx issues.

Hayes Wang (2):
  r8152: fix wrong checksum status for received IPv4 packets
  r8152: set rx mode early when linking on

 drivers/net/usb/r8152.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.13.6

[RFC net 0/1] rtnetlink: require unique netns identifier

[Christian Brauner]

Hey,

Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK
it is possible for userspace to send us requests with three different
properties to identify a target network namespace. This affects at least
RTM_{NEW,SET}LINK. Each of them could potentially refer to a different
network namespace which is confusing. For legacy reasons the kernel will
pick the IFLA_NET_NS_PID property first and then look for the
IFLA_NET_NS_FD property but there is no reason to extend this type of
behavior to network namespace ids. The regression potential is quite
minimal since the rtnetlink requests in question either won't allow
IFLA_IF_NETNSID requests before 4.16 is out (RTM_{NEW,SET}LINK) or don't
support IFLA_NET_NS_{PID,FD} (RTM_{DEL,GET}LINK) in the first place. But
maybe I'm missing a reason for allowing multiple properties in the request.

We obviously cannot prevent users from passing both IFLA_NET_NS_PID and
IFLA_NET_NS_FD since we have supported this somehow for a long time. So
the check I'm proposing is to only fail when both IFLA_IF_NETNSID, and
IFLA_NET_NS_PID or IFLA_NET_NS_FD are passed.

Thanks!
Christian

Christian Brauner (1):
  rtnetlink: require unique netns identifier

 net/core/rtnetlink.c | 28 
 1 file changed, 28 insertions(+)

-- 
2.14.1

[RFC net 1/1] rtnetlink: require unique netns identifier

[Christian Brauner]

Since we've added support for IFLA_IF_NETNSID for RTM_{DEL,GET,SET,NEW}LINK
it is possible for userspace to send us requests with three different
properties to identify a target network namespace. This affects at least
RTM_{NEW,SET}LINK. Each of them could potentially refer to a different
network namespace which is confusing. For legacy reasons the kernel will
pick the IFLA_NET_NS_PID property first and then look for the
IFLA_NET_NS_FD property but there is no reason to extend this type of
behavior to network namespace ids. The regression potential is quite
minimal since the rtnetlink requests in question either won't allow
IFLA_IF_NETNSID requests before 4.16 is out (RTM_{NEW,SET}LINK) or don't
support IFLA_NET_NS_{PID,FD} (RTM_{DEL,GET}LINK) in the first place.

Signed-off-by: Christian Brauner 
---
 net/core/rtnetlink.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 56af8e41abfc..d0b7ab22eff4 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1951,6 +1951,18 @@ static struct net *rtnl_link_get_net_capable(const 
struct sk_buff *skb,
return net;
 }
 
+/* Verify that rtnetlink requests that support network namespace ids do not 
pass
+ * additional properties that allow to identify a network namespace as they
+ * might conflict.
+ */
+static int rtnl_ensure_unique_netns_attr(struct nlattr *tb[])
+{
+   if (tb[IFLA_IF_NETNSID] && (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD]))
+   return -EINVAL;
+
+   return 0;
+}
+
 static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
 {
if (dev) {
@@ -2553,6 +2565,10 @@ static int rtnl_setlink(struct sk_buff *skb, struct 
nlmsghdr *nlh,
if (err < 0)
goto errout;
 
+   err = rtnl_ensure_unique_netns_attr(tb);
+   if (err < 0)
+   goto errout;
+
if (tb[IFLA_IFNAME])
nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
else
@@ -2649,6 +2665,10 @@ static int rtnl_dellink(struct sk_buff *skb, struct 
nlmsghdr *nlh,
if (err < 0)
return err;
 
+   err = rtnl_ensure_unique_netns_attr(tb);
+   if (err < 0)
+   return err;
+
if (tb[IFLA_IFNAME])
nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
 
@@ -2802,6 +2822,10 @@ static int rtnl_newlink(struct sk_buff *skb, struct 
nlmsghdr *nlh,
if (err < 0)
return err;
 
+   err = rtnl_ensure_unique_netns_attr(tb);
+   if (err < 0)
+   return err;
+
if (tb[IFLA_IFNAME])
nla_strlcpy(ifname, tb[IFLA_IFNAME], IFNAMSIZ);
else
@@ -3045,6 +3069,10 @@ static int rtnl_getlink(struct sk_buff *skb, struct 
nlmsghdr *nlh,
if (err < 0)
return err;
 
+   err = rtnl_ensure_unique_netns_attr(tb);
+   if (err < 0)
+   return err;
+
if (tb[IFLA_IF_NETNSID]) {
netnsid = nla_get_s32(tb[IFLA_IF_NETNSID]);
tgt_net = get_target_net(NETLINK_CB(skb).sk, netnsid);
-- 
2.14.1

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

[Eduardo Otubo]

On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:
> Hi, Eduardo!
> 
> I am working on a frontend driver (PV DRM) and also seeing some strange
> 
> things on driver unloading:
> 
> xt# rmmod -f drm_xen_front.ko
> [ 3236.462497] [drm] Unregistering XEN PV vdispl
> [ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend state is
> InitWait while removing driver
> [ 3236.486950] vdispl vdispl-0: 22 freeing event channel 11
> [ 3236.496123] vdispl vdispl-0: failed to write error node for
> device/vdispl/0 (22 freeing event channel 11)
> [ 3236.496271] vdispl vdispl-0: 22 freeing event channel 12
> [ 3236.501633] vdispl vdispl-0: failed to write error node for
> device/vdispl/0 (22 freeing event channel 12)
> 
> These are somewhat different from your use-case with grant references, but I
> have a question:
> 
> do you really see that XenbusStateClosed and XenbusStateClosing are
> 
> called? In my driver I can't see those and once I tried to dig deeper into
> the problem
> 
> I saw that on driver removal it is disconnected from XenBus, so no backend
> state
> 
> change events come in via .otherend_changed callback.
> 
> The only difference I see here is that the backend is a user-space
> application
> 
> Thank you,
> Oleksandr

To be honest, most of the things I assumed were true, according to some talks on
IRC with maintainers. Since I assumed it was true I started to write code based
on that and all the behaviors that followed were correct according to my
assumptions (and discussions).

But if you find something else weird, please let me know and we can fix it.

> 
> On 11/23/2017 04:18 PM, Eduardo Otubo wrote:
> > v2:
> >   * Replace busy wait with wait_event()/wake_up_all()
> >   * Cannot garantee that at the time xennet_remove is called, the
> > xen_netback state will not be XenbusStateClosed, so added a
> > condition for that
> >   * There's a small chance for the xen_netback state is
> > XenbusStateUnknown by the time the xen_netfront switches to Closed,
> > so added a condition for that.
> > 
> > When unloading module xen_netfront from guest, dmesg would output
> > warning messages like below:
> > 
> >[  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
> >[  105.236839] deferring g.e. 0x903 (pfn 0x35805)
> > 
> > This problem relies on netfront and netback being out of sync. By the time
> > netfront revokes the g.e.'s netback didn't have enough time to free all of
> > them, hence displaying the warnings on dmesg.
> > 
> > The trick here is to make netfront to wait until netback frees all the 
> > g.e.'s
> > and only then continue to cleanup for the module removal, and this is done 
> > by
> > manipulating both device states.
> > 
> > Signed-off-by: Eduardo Otubo 
> > ---
> >   drivers/net/xen-netfront.c | 18 ++
> >   1 file changed, 18 insertions(+)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 8b8689c6d887..391432e2725d 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -87,6 +87,8 @@ struct netfront_cb {
> >   /* IRQ name is queue name with "-tx" or "-rx" appended */
> >   #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
> > +static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
> > +
> >   struct netfront_stats {
> > u64 packets;
> > u64 bytes;
> > @@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbus_device 
> > *dev,
> > break;
> > case XenbusStateClosed:
> > +   wake_up_all(_unload_q);
> > if (dev->state == XenbusStateClosed)
> > break;
> > /* Missed the backend's CLOSING state -- fallthrough */
> > case XenbusStateClosing:
> > +   wake_up_all(_unload_q);
> > xenbus_frontend_closed(dev);
> > break;
> > }
> > @@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_device *dev)
> > dev_dbg(>dev, "%s\n", dev->nodename);
> > +   if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
> > +   xenbus_switch_state(dev, XenbusStateClosing);
> > +   wait_event(module_unload_q,
> > +  xenbus_read_driver_state(dev->otherend) ==
> > +  XenbusStateClosing);
> > +
> > +   xenbus_switch_state(dev, XenbusStateClosed);
> > +   wait_event(module_unload_q,
> > +  xenbus_read_driver_state(dev->otherend) ==
> > +  XenbusStateClosed ||
> > +  xenbus_read_driver_state(dev->otherend) ==
> > +  XenbusStateUnknown);
> > +   }
> > +
> > xennet_disconnect_backend(info);
> > unregister_netdev(info->netdev);
> 

-- 
Eduardo Otubo

Re: [PATCH 1/2] tools/memory-model: clarify the origin/scope of the tool name

[Andrea Parri]

On Thu, Feb 01, 2018 at 03:09:41PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> > On Thu, 1 Feb 2018, Andrea Parri wrote:
> > 
> > > Ingo pointed out that:
> > > 
> > >   "The "memory model" name is overly generic, ambiguous and somewhat
> > >misleading, as we usually mean the virtual memory layout/model
> > >when we say "memory model". GCC too uses it in that sense [...]"
> > > 
> > > Make it clearer that, in the context of tools/memory-model/, the term
> > > "memory-model" is used as shorthand for "memory consistency model" by
> > > calling out this convention in tools/memory-model/README.
> > > 
> > > Stick to the full name in sources' headers and for the subsystem name.
> > > 
> > > Suggested-by: Ingo Molnar 
> > > Signed-off-by: Andrea Parri 
> > 
> > For both patches:
> > 
> > Acked-by: Alan Stern 
> 
> Thank you all -- I have queued this and pushed it to my RCU tree on
> branch lkmm.  I did reword the commit log a bit, please see below and
> please let me know if any of my rewordings need halp.
> 
> Andrea, when you resend your second patch, could you please add Alan's
> Acked-by?

You mean in order to integrate Will's suggestion? I was planning to send
that as a separate patch, as suggested by Will: the patch is on its way,
IAC, please let me know if you'd prefer a V2 merging the two changes.

  Andrea


> 
>   Thanx, Paul
> 
> 
> 
> commit de175b697f71b8e3e6d980b7186b909fee0c4378
> Author: Andrea Parri 
> Date:   Thu Feb 1 13:03:29 2018 +0100
> 
> tools/memory-model: Clarify the origin/scope of the tool name
> 
> Ingo pointed out that:
> 
>   "The "memory model" name is overly generic, ambiguous and somewhat
>misleading, as we usually mean the virtual memory layout/model
>when we say "memory model". GCC too uses it in that sense [...]"
> 
> Make it clearer that tools/memory-model/ uses the term "memory model"
> is used as shorthand for "memory consistency model" by calling out this
> convention in tools/memory-model/README.
> 
> Stick to the original "memory model" term in sources' headers and for
> the subsystem name.
> 
> Suggested-by: Ingo Molnar 
> Signed-off-by: Andrea Parri 
> Acked-by: Will Deacon 
> Acked-by: Alan Stern 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
> index 711cbe72d606..db3bd3fc0435 100644
> --- a/tools/memory-model/MAINTAINERS
> +++ b/tools/memory-model/MAINTAINERS
> @@ -1,4 +1,4 @@
> -LINUX KERNEL MEMORY MODEL
> +LINUX KERNEL MEMORY CONSISTENCY MODEL
>  M:   Alan Stern 
>  M:   Andrea Parri 
>  M:   Will Deacon 
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index 43ba49492111..91414a49fac5 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -1,15 +1,15 @@
> - =
> - LINUX KERNEL MEMORY MODEL
> - =
> + =
> + LINUX KERNEL MEMORY CONSISTENCY MODEL
> + =
>  
>  
>  INTRODUCTION
>  
>  
> -This directory contains the memory model of the Linux kernel, written
> -in the "cat" language and executable by the (externally provided)
> -"herd7" simulator, which exhaustively explores the state space of
> -small litmus tests.
> +This directory contains the memory consistency model (memory model, for
> +short) of the Linux kernel, written in the "cat" language and executable
> +by the externally provided "herd7" simulator, which exhaustively explores
> +the state space of small litmus tests.
>  
>  In addition, the "klitmus7" tool (also externally provided) may be used
>  to convert a litmus test to a Linux kernel module, which in turn allows
> diff --git a/tools/memory-model/linux-kernel.bell 
> b/tools/memory-model/linux-kernel.bell
> index 57112505f5e0..b984bbda01a5 100644
> --- a/tools/memory-model/linux-kernel.bell
> +++ b/tools/memory-model/linux-kernel.bell
> @@ -11,7 +11,7 @@
>   * which is to appear in ASPLOS 2018.
>   *)
>  
> -"Linux kernel memory model"
> +"Linux-kernel memory consistency model"
>  
>  enum Accesses = 'once (*READ_ONCE,WRITE_ONCE,ACCESS_ONCE*) ||
>   'release (*smp_store_release*) ||
> diff --git a/tools/memory-model/linux-kernel.cat 
> b/tools/memory-model/linux-kernel.cat
> index 15b7a5dd8a9a..babe2b3b0bb3 100644
> --- a/tools/memory-model/linux-kernel.cat
> +++ b/tools/memory-model/linux-kernel.cat
> @@ -11,7 +11,7 @@
>   * which is to appear in ASPLOS 2018.
>   *)
>  
> -"Linux kernel memory model"
> +"Linux-kernel memory consistency model"
>  
>  (*
>   * File "lock.cat" handles locks and is experimental.
> 

Re: [PATCH 1/2] ARM: dts: sunxi: Switch MMC nodes away from cd-inverted property

[Maxime Ripard]

Hi,

On Thu, Feb 01, 2018 at 05:16:00PM +0200, Tuomas Tynkkynen wrote:
> Hi Maxime,
> 
> On Thu, 2018-01-04 at 16:03 +0100, Maxime Ripard wrote:
> > On Fri, Dec 22, 2017 at 10:57:37PM +0200, Tuomas Tynkkynen wrote:
> > > Using the cd-inverted property is not useful when GPIOs are used as
> > > card
> > > detects since the polarity can be specified with the usual
> > > GPIO_ACTIVE_(HIGH|LOW) GPIO flags. It has also caused confusion for
> > > U-Boot developers, so migrate all sunxi boards away from cd-
> > > inverted.
> > > 
> > > Signed-off-by: Tuomas Tynkkynen 
> > 
> > Acked-by: Maxime Ripard 
> 
> I was assuming these patches will go in through the sunxi tree but I
> don't see them applied anywhere, have these patches fallen through the
> cracks perhaps?

It did, sorry.

I queued both for 4.17, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


signature.asc
Description: PGP signature

Re: possible deadlock in get_user_pages_unlocked

[Dmitry Vyukov]

On Fri, Feb 2, 2018 at 7:20 AM, Al Viro  wrote:
> On Fri, Feb 02, 2018 at 05:46:26AM +, Al Viro wrote:
>> On Thu, Feb 01, 2018 at 09:35:02PM -0800, Eric Biggers wrote:
>>
>> > Try starting up multiple instances of the program; that sometimes helps 
>> > with
>> > these races that are hard to hit (since you may e.g. have a different 
>> > number of
>> > CPUs than syzbot used).  If I start up 4 instances I see the lockdep splat 
>> > after
>> > around 2-5 seconds.
>>
>> 5 instances in parallel, 10 minutes into the run...
>>
>> >  This is on latest Linus tree (4bf772b1467).  Also note the
>> > reproducer uses KVM, so if you're running it in a VM it will only work if 
>> > you've
>> > enabled nested virtualization on the host (kvm_intel.nested=1).
>>
>> cat /sys/module/kvm_amd/parameters/nested
>> 1
>>
>> on host
>>
>> > Also it appears to go away if I revert ce53053ce378c21 ("kvm: switch
>> > get_user_page_nowait() to get_user_pages_unlocked()").
>>
>> That simply prevents this reproducer hitting get_user_pages_unlocked()
>> instead of grab mmap_sem/get_user_pages/drop mmap_sem.  I.e. does not
>> allow __get_user_pages_locked() to drop/regain ->mmap_sem.
>>
>> The bug may be in the way we call get_user_pages_unlocked() in that
>> commit, but it might easily be a bug in __get_user_pages_locked()
>> exposed by that reproducer somehow.
>
> I think I understand what's going on.  FOLL_NOWAIT handling is a serious
> mess ;-/  I'll probably have something to test tomorrow - I still can't
> reproduce it here, unfortunately.

Hi Al,

syzbot tests for up to 5 minutes. However, if there is a race involved
then you may need more time because the crash is probabilistic.
But from what I see most of the time, if one can't reproduce it
easily, it's usually due to some differences in setup that just don't
allow the crash to happen at all.
FWIW syzbot re-runs each reproducer on a freshly booted dedicated VM
and what it provided is the kernel output it got during run of the
provided program. So we have reasonably high assurance that this
reproducer worked in at least one setup.

Even if you can't reproduce it locally, you can use syzbot testing
service, see "syz test" here:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot

We also try to collect known causes of non-working reproducers, so if
you get any hints as to why it does not reproduce for you, we can add
it here:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
Since kvm/ept are present in the stacks, I suspect that it may be due
to a different host CPU unfortunately.

Re: [PATCH v8 00/20] ILP32 for ARM64

[Bamvor Zhang]

Hi, Yury

As I left huawei few month ago. My account of linaro is invalid. You
could send to my personal email(bamv2...@gmail.com).

Sorry for inconvenience.

Regards

Bamvor

On Fri, Feb 2, 2018 at 4:16 PM, Yury Norov  wrote:
> Hi Catalin, all
>
> (Exclude Bamvor as his email became invalid)
>
> This is 4.15-based kernel.
> https://github.com/norov/linux/commits/ilp32-4.15
>
> I tested it with LTP, no regressions found.
>
> Kernel v4.15 incorporates SVE series from Dave Martin, so I updated ILP32
> patches to agree with it. SVE-related changes are mostly in patches:
> arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext
> arm64: signal32: move ilp32 and aarch32 common code to separated file
> arm64: signal: share lp64 signal structures and routines to ilp32
> arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
>
> Dave kindly reviewed that patches and proposed improvements:
> https://www.spinics.net/lists/arm-kernel/msg629221.html
>
> There's no ABI-related changes proposed, or urgent fixes; so I'll rework
> signal subsystem during 4.16 cycle.
>
> Are there any news with upstreaming this series?
>
> Thanks,
> Yury
>
> On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
>> This series enables aarch64 with ilp32 mode.
>>
>> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
>> option that is enabled for existing 32-bit architectures but disabled
>> for new arches (so 64-bit off_t userspace type is used by new userspace).
>> Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>>
>> This version is based on linux-next from 2017-06-16. It works with
>> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
>> CPUSpec.
>>
>> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>>
>> Kernel, GLIBC and OpenSUSE-based distro:
>> https://github.com/norov/linux/tree/ilp32-20170616.0
>> https://github.com/norov/glibc/tree/dev9
>> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:ILP32
>>
>> (GLIBC patches are managed by Steve Ellcey, so my tree is only for
>> reference.)
>>
>> Changes:
>> v3: https://lkml.org/lkml/2014/9/3/704
>> v4: https://lkml.org/lkml/2015/4/13/691
>> v5: https://lkml.org/lkml/2015/9/29/911
>> v6: https://lkml.org/lkml/2016/5/23/661
>> v7: https://lkml.org/lkml/2017/1/9/213
>> v8: - off_t referred in patches 2 and 13 stands for userspace type which is
>>   underlined in corresponding patch comments and ARCH_32BIT_OFF_T config
>>   option description;
>> - __IGNORE_getrlimit and __IGNORE_setrlimit are added to
>>   scripts/checksyscalls.sh (patch 3);
>> - for CONFIG_COMPAT, bool changed to def_bool y and 'select COMPAT' is
>>   dropped for AARCH32_EL0 and ARM64_ILP32 optiond (patches 5 and 20);
>> - x19 register is used to load TSK_TI_FLAGS in svc path in
>>   arch/arm64/kernel/entry.S to avoid register clobbering (patch 14).
>> - ilp32 vdso-related files are syncronized wirh lp64 ones, mostly 
>> Makefiles
>>   (patch 19);
>> - in arch/arm64/mm/mmap.c, arch_mmap_rnd() swithed to use 
>> is_compat_task()
>>   (patch 9);
>> - rebased on next-20170616.
>>
>> Andrew Pinski (6):
>>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>>   arm64: ensure the kernel is compiled for LP64
>>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
>> it
>>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
>> ucontext
>>   arm64:ilp32: add ARM64_ILP32 to Kconfig
>>
>> Philipp Tomsich (1):
>>   arm64:ilp32: add vdso-ilp32 and use for signal return
>>
>> Yury Norov (13):
>>   compat ABI: use non-compat openat and open_by_handle_at variants
>>   32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
>>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>>   thread: move thread bits accessors to separated file
>>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>>   arm64: introduce binfmt_elf32.c
>>   arm64: ilp32: introduce binfmt_ilp32.c
>>   arm64: ilp32: share aarch32 syscall handlers
>>   arm64: signal: share lp64 signal routines to ilp32
>>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>>
>>  Documentation/arm64/ilp32.txt |  45 +++
>>  arch/Kconfig  |  15 +++
>>  arch/arc/Kconfig  |   1 +
>>  arch/arc/include/uapi/asm/unistd.h|   1 +
>>  arch/arm/Kconfig  |   1 +
>>  arch/arm64/Kconfig|  17 ++-
>>  arch/arm64/Makefile   |   8 ++
>>  arch/arm64/include/asm/compat.h   

[PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

Recent efforts led to the specification of a memory consistency model
for the Linux kernel [1], which "can (roughly speaking) be thought of
as an automated version of memory-barriers.txt" and which is (in turn)
"accompanied by extensive documentation on its use and its design".

Make sure that the (occasional) reader of memory-barriers.txt will be
aware of these developments.

[1] https://marc.info/?l=linux-kernel=151687290114799=2

Signed-off-by: Andrea Parri 
---
 Documentation/memory-barriers.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index a863009849a3b..8cc3f098f4a7d 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
provided by Linux, but
 in case of any doubt (and there are many) please ask.
 
 To repeat, this document is not a specification of what Linux expects from
-hardware.
+hardware.  For such a specification, in the form of a memory consistency
+model, and for documentation about its usage and its design, the reader is
+referred to "tools/memory-model/".
 
 The purpose of this document is twofold:
 
-- 
2.7.4

[PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

Now that a formal specification of the LKMM has become available to
the developer, some concern about how to track changes to the model
on the level of the "high-level documentation" was raised.

A first "mitigation" to this issue, suggested by Will, is to assign
maintainership (and responsibility!!)  of such documentation (here,
memory-barriers.txt) to the maintainers of the LKMM themselves.

Suggested-by: Will Deacon 
Signed-off-by: Andrea Parri 
---
 On top of: https://marc.info/?l=linux-kernel=151748668632046=2 

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08454be9237d7..9466907aa4db1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8106,6 +8106,7 @@ L:linux-kernel@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
 F: tools/memory-model/
+F: Documentation/memory-barriers.txt
 
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M: Chris Wright 
-- 
2.7.4

[PATCH] mm/migrate: Change migration reason MR_CMA as MR_CONTIG_RANGE

[Anshuman Khandual]

alloc_contig_range() initiates compaction and eventual migration for
the purpose of either CMA or HugeTLB allocation. At present, reason
code remains the same MR_CMA for either of these cases. Lets make it
MR_CONTIG_RANGE which will appropriately reflect reason code in both
these cases.

Signed-off-by: Anshuman Khandual 
---
 arch/powerpc/mm/mmu_context_iommu.c | 2 +-
 include/linux/migrate.h | 2 +-
 include/trace/events/migrate.h  | 2 +-
 mm/page_alloc.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/mmu_context_iommu.c 
b/arch/powerpc/mm/mmu_context_iommu.c
index 91ee2231c527..4c615fcb0cf0 100644
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -111,7 +111,7 @@ static int mm_iommu_move_page_from_cma(struct page *page)
put_page(page); /* Drop the gup reference */
 
ret = migrate_pages(_migrate_pages, new_iommu_non_cma_page,
-   NULL, 0, MIGRATE_SYNC, MR_CMA);
+   NULL, 0, MIGRATE_SYNC, MR_CONTIG_RANGE);
if (ret) {
if (!list_empty(_migrate_pages))
putback_movable_pages(_migrate_pages);
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index a732598fcf83..7e7e2606bb4c 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -25,7 +25,7 @@ enum migrate_reason {
MR_SYSCALL, /* also applies to cpusets */
MR_MEMPOLICY_MBIND,
MR_NUMA_MISPLACED,
-   MR_CMA,
+   MR_CONTIG_RANGE,
MR_TYPES
 };
 
diff --git a/include/trace/events/migrate.h b/include/trace/events/migrate.h
index bcf4daccd6be..711372845945 100644
--- a/include/trace/events/migrate.h
+++ b/include/trace/events/migrate.h
@@ -20,7 +20,7 @@
EM( MR_SYSCALL, "syscall_or_cpuset")\
EM( MR_MEMPOLICY_MBIND, "mempolicy_mbind")  \
EM( MR_NUMA_MISPLACED,  "numa_misplaced")   \
-   EMe(MR_CMA, "cma")
+   EMe(MR_CONTIG_RANGE,"contig_range")
 
 /*
  * First define the enums in the above macros to be exported to userspace
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 242565855d05..b9a22e16b4cf 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7622,7 +7622,7 @@ static int __alloc_contig_migrate_range(struct 
compact_control *cc,
cc->nr_migratepages -= nr_reclaimed;
 
ret = migrate_pages(>migratepages, new_page_alloc_contig,
-   NULL, 0, cc->mode, MR_CMA);
+   NULL, 0, cc->mode, MR_CONTIG_RANGE);
}
if (ret < 0) {
putback_movable_pages(>migratepages);
-- 
2.11.0

Re: [PATCH v3 19/21] fpga: dfl: afu: add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support

[Wu Hao]

On Thu, Feb 01, 2018 at 04:13:09PM +0100, Moritz Fischer wrote:
> On Thu, Feb 01, 2018 at 01:16:25PM +0800, Wu Hao wrote:
> > On Wed, Jan 31, 2018 at 08:52:36AM -0600, Alan Tull wrote:
> > > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> > > 
> > > Hi Hao,
> > > 
> > > I'm adding my "Acked-by' below.  When you post v4, please add it so
> > > that we can keep track of what got acked.
> > 
> > Sure, thanks a lot for the code review. :)
> > 
> > Hao
> > 
> > > 
> > > Thanks,
> > > Alan
> > > 
> > > > FPGA_GET_API_VERSION and FPGA_CHECK_EXTENSION ioctls are common ones 
> > > > which
> > > > need to be supported by all feature devices drivers including FME and 
> > > > AFU.
> > > > This patch implements above 2 ioctls in FPGA Accelerated Function Unit
> > > > (AFU) driver.
> > > >
> > > > Signed-off-by: Tim Whisonant 
> > > > Signed-off-by: Enno Luebbers 
> > > > Signed-off-by: Shiva Rao 
> > > > Signed-off-by: Christopher Rauer 
> > > > Signed-off-by: Xiao Guangrong 
> > > > Signed-off-by: Wu Hao 
> > > Acked-by: Alan Tull 
> Acked-by: Moritz Fischer 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Looks good,

Thanks a lot for the code review. :)

Hao

> 
> Moritz

Re: [PATCH] drm/panel: lvds: tidyup header explanation

[Laurent Pinchart]

Hi Morimoto-san,

Thank you for your patch.

On Thursday, 1 February 2018 09:45:36 EET Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
> 
> panel-lvds.c is for LVDS Panel Driver,
> not R-Car Display Unit CRTCs
> 
> Reported-by: Koji Matsuoka 
> Signed-off-by: Kuninori Morimoto 

A similar patch has been posted already:

https://patchwork.freedesktop.org/series/36953/

> ---
>  drivers/gpu/drm/panel/panel-lvds.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c index b5e3994..c8075a8 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -1,5 +1,5 @@
>  /*
> - * rcar_du_crtc.c  --  R-Car Display Unit CRTCs
> + * panel-lvds.c  --  LVDS Panel Driver
>   *
>   * Copyright (C) 2016 Laurent Pinchart
>   * Copyright (C) 2016 Renesas Electronics Corporation


-- 
Regards,

Laurent Pinchart

Re: [PATCH 4/8] i2c: ov9650: fix potential integer overflow in __ov965x_set_frame_interval

[Sakari Ailus]

On Mon, Jan 29, 2018 at 06:32:01PM -0600, Gustavo A. R. Silva wrote:
> Cast fi->interval.numerator to u64 in order to avoid a potential integer
> overflow. This variable is being used in a context that expects an
> expression of type u64.
> 
> Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/media/i2c/ov9650.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index e519f27..c674a49 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -1130,7 +1130,7 @@ static int __ov965x_set_frame_interval(struct ov965x 
> *ov965x,
>   if (fi->interval.denominator == 0)
>   return -EINVAL;
>  
> - req_int = (u64)(fi->interval.numerator * 1) /
> + req_int = (u64)fi->interval.numerator * 1 /
>   fi->interval.denominator;

This requires do_div(). I've applied the patch with this change:

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 88276dba828d..5bea31cd41aa 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -1136,8 +1136,8 @@ static int __ov965x_set_frame_interval(struct ov965x 
*ov965x,
if (fi->interval.denominator == 0)
return -EINVAL;
 
-   req_int = (u64)fi->interval.numerator * 1 /
-   fi->interval.denominator;
+   req_int = (u64)fi->interval.numerator * 1;
+   do_div(req_int, fi->interval.denominator);
 
for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
const struct ov965x_interval *iv = _intervals[i];

>  
>   for (i = 0; i < ARRAY_SIZE(ov965x_intervals); i++) {
> -- 
> 2.7.4
> 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] firmware: dmi_scan: avoid printing error on non-efi systems

[Jean Delvare]

Hi Martin,

On Thu, 1 Feb 2018 09:08:05 +0100, Martin Hundebøll wrote:
> dmi_init() rightfully checks if dmi is available at all, and errors out
> if not. This leads to harmless errors being printed during boot on
> non-efi systems, even when these are booted quietly.
> 
> Avoid this error-print by returning directly from dmi_init() if dmi
> isn't available, instead of jumping to the err-label.
> 
> Signed-off-by: Martin Hundebøll 
> ---
>  drivers/firmware/dmi_scan.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 783041964439..86c5e0625a08 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -715,10 +715,8 @@ static int __init dmi_init(void)
>   u8 *dmi_table;
>   int ret = -ENOMEM;
>  
> - if (!dmi_available) {
> - ret = -ENODATA;
> - goto err;
> - }
> + if (!dmi_available)
> + return -ENODATA;
>  
>   /*
>* Set up dmi directory at /sys/firmware/dmi. This entry should stay

I already have a similar patch by Ard Biesheuvel in my dmi tree:

http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/firmware-dmi-handle-missing-dmi-data-gracefully.patch

Does it work for you?

I'll send a pull request to Linus later today.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit

[kbuild test robot]

Hi Gustavo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v4.15 next-20180202]
[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/Gustavo-A-R-Silva/tcp_lp-use-64-bit-arithmetic-instead-of-32-bit/20180202-135349
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/auxdisplay/img-ascii-lcd.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in drivers/iio/accel/kxsd9-i2c.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/iio/adc/qcom-vadc-common.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/media/platform/mtk-vcodec/mtk-vcodec-common.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/media/platform/soc_camera/soc_scale_crop.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/media/platform/tegra-cec/tegra_cec.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in 
drivers/pinctrl/pxa/pinctrl-pxa2xx.o
   see include/linux/module.h for more information
>> ERROR: "__divdi3" [net/ipv4/tcp_lp.ko] undefined!
>> ERROR: "__udivdi3" [net/ipv4/tcp_lp.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [Xen-devel] [PATCH v2] x86/xen: init %gs very early to avoid page faults with stack protector

[Juergen Gross]

On 02/02/18 01:36, Chris Patterson wrote:
> Works great, tested it and it fixes booting Linux v4.15 kernel for me :)

Can I add your "Tested-by:" to the patch when committing it?


Juergen

> 
> Cheers!
> 
> On Thu, Feb 1, 2018 at 3:17 PM, Boris Ostrovsky
>  wrote:
>> On 02/01/2018 07:40 AM, Juergen Gross wrote:
>>> When running as Xen pv guest %gs is initialized some time after
>>> C code is started. Depending on stack protector usage this might be
>>> too late, resulting in page faults.
>>>
>>> So setup %gs and MSR_GS_BASE in assembly code already.
>>>
>>> Cc: sta...@vger.kernel.org
>>> Signed-off-by: Juergen Gross 
>>
>> Reviewed-by: Boris Ostrovsky 
>>
>>
>>
>> ___
>> Xen-devel mailing list
>> xen-de...@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel
> 

[PATCH/resend] constify more dcache.h inlined helpers.

[NeilBrown]

Many of the inlines in dcache.h were changed to accept
const struct pointers in commit f0d3b3ded999 ("constify dcache.c
inlined helpers where possible").
This patch allows 'const' in a couple that were added since then.

Signed-off-by: NeilBrown 
---

Hi Al,
 I still don't see this in your tree, despite you saying on Oct 20th
 that it had been applied.  So I thought it might be a good time to
 resend.

Thanks,
NeilBrown


 include/linux/dcache.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index 65cd8ab60b7a..5b336f9faf01 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -359,7 +359,7 @@ static inline void dont_mount(struct dentry *dentry)
 
 extern void __d_lookup_done(struct dentry *);
 
-static inline int d_in_lookup(struct dentry *dentry)
+static inline int d_in_lookup(const struct dentry *dentry)
 {
return dentry->d_flags & DCACHE_PAR_LOOKUP;
 }
@@ -487,7 +487,7 @@ static inline bool d_really_is_positive(const struct dentry 
*dentry)
return dentry->d_inode != NULL;
 }
 
-static inline int simple_positive(struct dentry *dentry)
+static inline int simple_positive(const struct dentry *dentry)
 {
return d_really_is_positive(dentry) && !d_unhashed(dentry);
 }
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: [RFC] mm/migrate: Consolidate page allocation helper functions

[Anshuman Khandual]

On 01/31/2018 09:56 AM, Hugh Dickins wrote:
> On Wed, 31 Jan 2018, Anshuman Khandual wrote:
>> On 01/30/2018 08:06 PM, Michal Hocko wrote:
>>> On Tue 30-01-18 10:36:42, Anshuman Khandual wrote:
 Allocation helper functions for migrate_pages() remmain scattered with
 similar names making them really confusing. Rename these functions based
 on the context for the migration and move them all into common migration
 header. Functionality remains unchanged.
> 
> I agree that their names could be made less confusing (though didn't
> succeed very well when I tried); and maybe a couple of them are general
> enough to be used from more than one callsite, and could well live in
> mm/migrate.c.
> 
> But moving all of page migration's (currently static) new_page allocator
> functions away from the code that relies on their special characteristics
> (probably relayed to them through a private argument), and into a single
> header file, just seems perverse to me.  And likely to be a nuisance when
> adding more in future: private structures having to be made public just
> to make them visible in that shared header file.
> 
> Would it make sense to keep the various functions that may be called by
> rmap_walk() together in one rmap_walk.h?  The different filesystems'
> writepage methods together in one writepage.h?  I don't think so.

Makes sense. Will probably just change the helper names to something
more meaningful (from previous suggestions in this thread) next around.

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Ryder Lee]

On Wed, 2018-01-31 at 10:02 -0600, Rob Herring wrote:
> On Wed, Jan 31, 2018 at 1:41 AM, Ryder Lee  wrote:
> > A root complex usually consist of a host bridge and multiple P2P bridges,
> > and someone may express that in the form of a root node with many subnodes
> > and list all four interrupts for each slot (child node) in the root node
> > like this:
> >
> > pcie-controller {
> > ...
> > interrupt-map-mask = <0xf800 0 0 7>;
> > interrupt-map = <0x 0 0 {INTx} &{interrupt parent} ...>
> >  0x0800 0 0 {INTx} &{interrupt parent} ...>;
> >
> > pcie@0,0 {
> > reg = <0x 0 0 0 0>;
> > ...
> > };
> >
> > pcie@1,0 {
> > reg = <0x0800 0 0 0 0>;
> > ...
> > };
> > };
> >
> > As shown above, we'd like to propagate IRQs from a root port to the devices
> > in the hierarchy below it in this way.  However, it seems that the current
> > parser couldn't handle such cases and will get something unexpected below:
> >
> > pcieport :00:01.0: assign IRQ: got 213
> > igb :01:00.0: assign IRQ: got 212
> >
> > There is a device which is connected to 2nd slot, but the port doesn't share
> > the same IRQ with its downstream devices.  The problem here is that, if the
> > loop found a P2P bridge, it wouldn't check whether the reg property exists
> > in ppnode or not but just pass the subordinate devfn to of_irq_parse_raw(),
> > thus the subsequent flow couldn't correctly resolve them.
> >
> > Fix this by adding a check to fallback to standard device tree parsing.
> >
> > Signed-off-by: Ryder Lee 
> > ---
> > Please refer to the previous discussion thread: 
> > https://patchwork.ozlabs.org/patch/829108/
> > ---
> >  drivers/of/of_pci_irq.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
> > index 3a05568..e445866 100644
> > --- a/drivers/of/of_pci_irq.c
> > +++ b/drivers/of/of_pci_irq.c
> > @@ -86,8 +86,18 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> > of_phandle_args *out_irq
> > out_irq->np = ppnode;
> > out_irq->args_count = 1;
> > out_irq->args[0] = pin;
> > -   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 
> > 8));
> > -   laddr[1] = laddr[2] = cpu_to_be32(0);
> > +
> > +   if (!dn && ppnode) {
> 
> I would think whether you have a child device in DT or not is
> irrelevant. If it's the bridge address you need to look at for
> resolving interrupts, that would be true regardless.
> 
> > +   const __be32 *addr;
> > +
> > +   addr = of_get_property(ppnode, "reg", NULL);
> > +   if (addr)
> > +   memcpy(laddr, addr, 3);
> 
> Can't you just adjust pdev to be ppdev in this case and then use the
> existing code to set laddr?

Okay, I will try it out and and see if the code gets better or worse.
 
> Please copy the powerpc list on this. I worry that touching this
> function will break something.
> BTW, this code is moving to drivers/pci/ in 4.16.

Sure. I will loop more people in next version.

Thanks

> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH] mm/migrate: Change migration reason MR_CMA as MR_CONTIG_RANGE

[Michal Hocko]

On Fri 02-02-18 14:45:18, Anshuman Khandual wrote:
> alloc_contig_range() initiates compaction and eventual migration for
> the purpose of either CMA or HugeTLB allocation. At present, reason
> code remains the same MR_CMA for either of these cases. Lets make it
> MR_CONTIG_RANGE which will appropriately reflect reason code in both
> these cases.

It is not very specific but I guess this is better than inventing a code
for each source. If we ever get to need distinguish all of them then we
should better mark a function which calls the allocator or something
like that.

> Signed-off-by: Anshuman Khandual 

Acked-by: Michal Hocko 

> ---
>  arch/powerpc/mm/mmu_context_iommu.c | 2 +-
>  include/linux/migrate.h | 2 +-
>  include/trace/events/migrate.h  | 2 +-
>  mm/page_alloc.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/mm/mmu_context_iommu.c 
> b/arch/powerpc/mm/mmu_context_iommu.c
> index 91ee2231c527..4c615fcb0cf0 100644
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@ -111,7 +111,7 @@ static int mm_iommu_move_page_from_cma(struct page *page)
>   put_page(page); /* Drop the gup reference */
>  
>   ret = migrate_pages(_migrate_pages, new_iommu_non_cma_page,
> - NULL, 0, MIGRATE_SYNC, MR_CMA);
> + NULL, 0, MIGRATE_SYNC, MR_CONTIG_RANGE);
>   if (ret) {
>   if (!list_empty(_migrate_pages))
>   putback_movable_pages(_migrate_pages);
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index a732598fcf83..7e7e2606bb4c 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -25,7 +25,7 @@ enum migrate_reason {
>   MR_SYSCALL, /* also applies to cpusets */
>   MR_MEMPOLICY_MBIND,
>   MR_NUMA_MISPLACED,
> - MR_CMA,
> + MR_CONTIG_RANGE,
>   MR_TYPES
>  };
>  
> diff --git a/include/trace/events/migrate.h b/include/trace/events/migrate.h
> index bcf4daccd6be..711372845945 100644
> --- a/include/trace/events/migrate.h
> +++ b/include/trace/events/migrate.h
> @@ -20,7 +20,7 @@
>   EM( MR_SYSCALL, "syscall_or_cpuset")\
>   EM( MR_MEMPOLICY_MBIND, "mempolicy_mbind")  \
>   EM( MR_NUMA_MISPLACED,  "numa_misplaced")   \
> - EMe(MR_CMA, "cma")
> + EMe(MR_CONTIG_RANGE,"contig_range")
>  
>  /*
>   * First define the enums in the above macros to be exported to userspace
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 242565855d05..b9a22e16b4cf 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7622,7 +7622,7 @@ static int __alloc_contig_migrate_range(struct 
> compact_control *cc,
>   cc->nr_migratepages -= nr_reclaimed;
>  
>   ret = migrate_pages(>migratepages, new_page_alloc_contig,
> - NULL, 0, cc->mode, MR_CMA);
> + NULL, 0, cc->mode, MR_CONTIG_RANGE);
>   }
>   if (ret < 0) {
>   putback_movable_pages(>migratepages);
> -- 
> 2.11.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v11 4/4] fw_cfg: write vmcoreinfo details

[Marc-Andre Lureau]

Hi

On Fri, Feb 2, 2018 at 3:44 AM, Michael S. Tsirkin  wrote:
> On Thu, Feb 01, 2018 at 02:03:00PM +0100, Marc-André Lureau wrote:
>> @@ -314,6 +359,37 @@ struct fw_cfg_sysfs_entry {
>>   struct device *dev;
>>  };
>>
>> +#ifdef CONFIG_CRASH_CORE
>> +static ssize_t write_vmcoreinfo(struct device *dev, const struct 
>> fw_cfg_file *f)
>> +{
>> + struct vmci {
>> + __le16 host_format;
>> + __le16 guest_format;
>> + __le32 size;
>> + __le64 paddr;
>> + } __packed;
>> + static struct vmci *data;
>> + ssize_t ret;
>> +
>> + data = kmalloc(sizeof(struct vmci), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + *data = (struct vmci) {
>> + .guest_format = cpu_to_le16(VMCOREINFO_FORMAT_ELF),
>> + .size = cpu_to_le32(VMCOREINFO_NOTE_SIZE),
>> + .paddr = cpu_to_le64(paddr_vmcoreinfo_note())
>> + };
>> + /* spare ourself reading host format support for now since we
>> +  * don't know what else to format - host may ignore ours
>> +  */
>> + ret = fw_cfg_write_blob(dev, f->select, data, 0, sizeof(struct vmci));
>> +
>> + kfree(data);
>> + return ret;
>> +}
>> +#endif /* CONFIG_CRASH_CORE */
>> +
>>  /* get fw_cfg_sysfs_entry from kobject member */
>>  static inline struct fw_cfg_sysfs_entry *to_entry(struct kobject *kobj)
>>  {
>
> kmalloc during crash is I think a bad idea.
> How about preallocating on probe?

It doesn't kmalloc during crash, it kmalloc during boot. As such, I
don't see a reason to change it.

>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
> index 33e0256..ffd81d1 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -363,22 +363,33 @@ struct fw_cfg_sysfs_entry {
>  };
>
>  #ifdef CONFIG_CRASH_CORE
> +
> +struct vmci {
> +   __le16 host_format;
> +   __le16 guest_format;
> +   __le32 size;
> +   __le64 paddr;
> +} *fw_cfg_vmcore_data;
> +
> +static int fw_cfg_vmcore_init(void)
> +{
> +   fw_cfg_vmcore_data = kmalloc(sizeof(*fw_cfg_vmcore_data), GFP_KERNEL);
> +   if (!fw_cfg_vmcore_data)
> +   return -ENOMEM;
> +   return 0;
> +}
> +
> +static int fw_cfg_vmcore_cleanup(void)
> +{
> +   kfree(fw_cfg_vmcore_data);
> +}
> +
>  static ssize_t write_vmcoreinfo(struct device *dev, const struct fw_cfg_file 
> *f)
>  {
> -   struct vmci {
> -   __le16 host_format;
> -   __le16 guest_format;
> -   __le32 size;
> -   __le64 paddr;
> -   } __packed;
> static struct vmci *data;
> ssize_t ret;
>
> -   data = kmalloc(sizeof(struct vmci), GFP_KERNEL);
> -   if (!data)
> -   return -ENOMEM;
> -
> -   *data = (struct vmci) {
> +   *fw_cfg_vmcore_data = (struct vmci) {
> .guest_format = cpu_to_le16(VMCOREINFO_FORMAT_ELF),
> .size = cpu_to_le32(VMCOREINFO_NOTE_SIZE),
> .paddr = cpu_to_le64(paddr_vmcoreinfo_note())
> @@ -386,11 +397,23 @@ static ssize_t write_vmcoreinfo(struct device *dev, 
> const struct fw_cfg_file *f)
> /* spare ourself reading host format support for now since we
>  * don't know what else to format - host may ignore ours
>  */
> -   ret = fw_cfg_write_blob(dev, f->select, data, 0, sizeof(struct vmci));
> +   ret = fw_cfg_write_blob(dev, f->select, fw_cfg_vmcore_data, 0,
> +   sizeof(*fw_cfg_vmcore_data));
>
> -   kfree(data);
> return ret;
>  }
> +
> +#else
> +
> +static int fw_cfg_vmcore_init(void)
> +{
> +   return 0;
> +}
> +
> +static int fw_cfg_vmcore_cleanup(void)
> +{
> +}
> +
>  #endif /* CONFIG_CRASH_CORE */
>
>  /* get fw_cfg_sysfs_entry from kobject member */
> @@ -725,11 +748,15 @@ static int fw_cfg_sysfs_probe(struct platform_device 
> *pdev)
> if (fw_cfg_sel_ko)
> return -EBUSY;
>
> +   err = fw_cfg_vmcore_init();
> +   if (err)
> +   goto err_sel;
> +
> /* create by_key and by_name subdirs of /sys/firmware/qemu_fw_cfg/ */
> err = -ENOMEM;
> fw_cfg_sel_ko = kobject_create_and_add("by_key", fw_cfg_top_ko);
> if (!fw_cfg_sel_ko)
> -   goto err_sel;
> +   goto err_vmcore;
> fw_cfg_fname_kset = kset_create_and_add("by_name", NULL, 
> fw_cfg_top_ko);
> if (!fw_cfg_fname_kset)
> goto err_name;
> @@ -764,6 +791,8 @@ static int fw_cfg_sysfs_probe(struct platform_device 
> *pdev)
> fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
>  err_name:
> fw_cfg_kobj_cleanup(fw_cfg_sel_ko);
> +err_vmcore:
> +   fw_cfg_vmcore_cleanup();
>  err_sel:
> return err;
>  }
> @@ -776,6 +805,7 @@ static int fw_cfg_sysfs_remove(struct platform_device 
> *pdev)
> fw_cfg_io_cleanup();
> fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
>   

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

[Oleksandr Andrushchenko]

On 02/02/2018 10:54 AM, Eduardo Otubo wrote:

On Wed, Jan 31, 2018 at 05:00:23PM +0200, Oleksandr Andrushchenko wrote:

Hi, Eduardo!

I am working on a frontend driver (PV DRM) and also seeing some strange

things on driver unloading:

xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm] Unregistering XEN PV vdispl
[ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend state is
InitWait while removing driver
[ 3236.486950] vdispl vdispl-0: 22 freeing event channel 11
[ 3236.496123] vdispl vdispl-0: failed to write error node for
device/vdispl/0 (22 freeing event channel 11)
[ 3236.496271] vdispl vdispl-0: 22 freeing event channel 12
[ 3236.501633] vdispl vdispl-0: failed to write error node for
device/vdispl/0 (22 freeing event channel 12)

These are somewhat different from your use-case with grant references, but I
have a question:

do you really see that XenbusStateClosed and XenbusStateClosing are

called? In my driver I can't see those and once I tried to dig deeper into
the problem

I saw that on driver removal it is disconnected from XenBus, so no backend
state

change events come in via .otherend_changed callback.

The only difference I see here is that the backend is a user-space
application

Thank you,
Oleksandr

To be honest, most of the things I assumed were true, according to some talks on
IRC with maintainers. Since I assumed it was true I started to write code based
on that and all the behaviors that followed were correct according to my
assumptions (and discussions).

But if you find something else weird, please let me know and we can fix it.

There is nothing wrong with the patch. One thing that
I cannot get in my driver is that .otherend_changed callback
is not called on .remove. Please see [1]

On 11/23/2017 04:18 PM, Eduardo Otubo wrote:

v2:
   * Replace busy wait with wait_event()/wake_up_all()
   * Cannot garantee that at the time xennet_remove is called, the
 xen_netback state will not be XenbusStateClosed, so added a
 condition for that
   * There's a small chance for the xen_netback state is
 XenbusStateUnknown by the time the xen_netfront switches to Closed,
 so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

[  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
[  105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo 
---
   drivers/net/xen-netfront.c | 18 ++
   1 file changed, 18 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8b8689c6d887..391432e2725d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,8 @@ struct netfront_cb {
   /* IRQ name is queue name with "-tx" or "-rx" appended */
   #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
+
   struct netfront_stats {
u64 packets;
u64 bytes;
@@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbus_device *dev,
break;
case XenbusStateClosed:
+   wake_up_all(_unload_q);
if (dev->state == XenbusStateClosed)
break;
/* Missed the backend's CLOSING state -- fallthrough */
case XenbusStateClosing:
+   wake_up_all(_unload_q);
xenbus_frontend_closed(dev);
break;
}
@@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_device *dev)
dev_dbg(>dev, "%s\n", dev->nodename);
+   if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {
+   xenbus_switch_state(dev, XenbusStateClosing);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosing);
+
+   xenbus_switch_state(dev, XenbusStateClosed);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosed ||
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateUnknown);
+   }
+
xennet_disconnect_backend(info);
unregister_netdev(info->netdev);

[1] https://patchwork.kernel.org/patch/10195163/

Re: [patches] [PATCH] RISC-V: Enable IRQ during exception handling

[Christoph Hellwig]

Looks fine:

Reviewed-by: Christoph Hellwig 

Re: [GIT PULL] leaking_addresses.pl changes for 4.16-rc1

[Tobin C. Harding]

On Thu, Feb 01, 2018 at 02:43:28PM -0800, Linus Torvalds wrote:
> On Thu, Feb 1, 2018 at 12:45 PM, Tobin C. Harding  wrote:
> >
> > It has just come to my attention that I should have pushed these changes
> > to Linux next before requesting you to pull them.  Please feel free to
> > drop this request, I can try again next merge window after going through
> > linux next.
> 
> For something like this, I don't think it's a big deal.
> 
> A bigger deal is that it now wants perl-bigint, as of commit
> 8d8a77fb99bd ("leaking_addresses: add range check for vsyscall
> memory").
> 
> And that is not apparently a common enough perl module to be installed
> by default.
> 
> Sure, I just ran
> 
> dnf install 'perl(bigint)'
> 
> and it did the right thing, but it does seem to be something of an
> inconvenience.

ok I'll try and find a work around so as not to use that.

> And things are *slow*, to the point of breakage. I get
> 
>   timed out parsing: /proc/kallsyms
>   timed out parsing: /proc/2177/smaps
>   timed out parsing: /proc/2238/smaps
>   timed out parsing: /proc/2336/smaps
>   ...

TL;DR it's working just not behaving very well.

I knew that was an issue, I've been running tests with 'smaps' included
in the skip files array.  However the patch I submitted to add this
included skipping /proc/kallsysms.  This got nacked.  I could not come
up with a _good_ solution before doing the pull request and thought it
better to have the 32-bit stuff in in light of all the drama this last
month.  The problem is that timeouts were added to catch binary files
choking the script but the default is too slow for large ASCII files.
Also we don't have a way to say 'scan this file once but not in every
processes sub directory' i.e smaps.  I needed feedback on this since I'm
not totally sure that all smaps files are generated the same.  Also I
think there may be a better way to not pass binary files than using the
timeout.

> and no actual output. I'm not sure what's up with that, and whether
> it's related. Probably not, but I didn't start bisecting.

No output is good - it means no leaks, though I'm still getting a bunch
from dmesg on the 3 machines I tested on.

> So I pulled it but then unpulled it due to issues during testing.

If it is not super important to have 32-bit scanning available then I'd
just as well see this wait until next merge window and getting it
running better.  In hindsight all of this should probably been in the
pull request message.

thanks for taking the time on this.

Tobin

[PATCH v3] dmaengine: dmatest: add norandom option

[Yang Shunyong]

Existing option noverify disables both random src/dst address offset
setup and data verification. Sometimes, we need to control random
src/dst address setup and verification separately, such as disabling
random to make sure that test covers addresses in all interleaving
banks, but data verification is still performed.

This patch adds option norandom to disable random offset setup. Option
noverify has been changed to disable data verification only.

Cc: Joey Zheng 
Signed-off-by: Yang Shunyong 
---

v3: new patch should be octal permissions.

v2: change to symbolic permissions.

---
 drivers/dma/dmatest.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index 80cc2be6483c..b9339524d5bd 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -74,7 +74,11 @@
 
 static bool noverify;
 module_param(noverify, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(noverify, "Disable random data setup and verification");
+MODULE_PARM_DESC(noverify, "Disable data verification (default: verify)");
+
+static bool norandom;
+module_param(norandom, bool, 0644);
+MODULE_PARM_DESC(norandom, "Disable random offset setup (default: random)");
 
 static bool verbose;
 module_param(verbose, bool, S_IRUGO | S_IWUSR);
@@ -103,6 +107,7 @@ struct dmatest_params {
unsigned intpq_sources;
int timeout;
boolnoverify;
+   boolnorandom;
 };
 
 /**
@@ -575,7 +580,7 @@ static int dmatest_func(void *data)
break;
}
 
-   if (params->noverify)
+   if (params->norandom)
len = params->buf_size;
else
len = dmatest_random() % params->buf_size + 1;
@@ -586,17 +591,19 @@ static int dmatest_func(void *data)
 
total_len += len;
 
-   if (params->noverify) {
+   if (params->norandom) {
src_off = 0;
dst_off = 0;
} else {
-   start = ktime_get();
src_off = dmatest_random() % (params->buf_size - len + 
1);
dst_off = dmatest_random() % (params->buf_size - len + 
1);
 
src_off = (src_off >> align) << align;
dst_off = (dst_off >> align) << align;
+   }
 
+   if (!params->noverify) {
+   start = ktime_get();
dmatest_init_srcs(thread->srcs, src_off, len,
  params->buf_size, is_memset);
dmatest_init_dsts(thread->dsts, dst_off, len,
@@ -975,6 +982,7 @@ static void run_threaded_test(struct dmatest_info *info)
params->pq_sources = pq_sources;
params->timeout = timeout;
params->noverify = noverify;
+   params->norandom = norandom;
 
request_channels(info, DMA_MEMCPY);
request_channels(info, DMA_MEMSET);
-- 
1.8.3.1

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

[Wu Hao]

On Thu, Feb 01, 2018 at 04:00:36PM -0600, Alan Tull wrote:
> On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> A few comments below.   Besides that, looks good.
> 
> > This patch adds fpga manager driver for FPGA Management Engine (FME). It
> > implements fpga_manager_ops for FPGA Partial Reconfiguration function.
> >
> > Signed-off-by: Tim Whisonant 
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Shiva Rao 
> > Signed-off-by: Christopher Rauer 
> > Signed-off-by: Kang Luwei 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > 
> > v3: rename driver to dfl-fpga-fme-mgr
> > implemented status callback for fpga manager
> > rebased due to fpga api changes
> > ---
> >  .../ABI/testing/sysfs-platform-fpga-dfl-fme-mgr|   8 +
> >  drivers/fpga/Kconfig   |   6 +
> >  drivers/fpga/Makefile  |   1 +
> >  drivers/fpga/fpga-dfl-fme-mgr.c| 318 
> > +
> >  drivers/fpga/fpga-dfl.h|  39 ++-
> >  5 files changed, 371 insertions(+), 1 deletion(-)
> >  create mode 100644 
> > Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> >  create mode 100644 drivers/fpga/fpga-dfl-fme-mgr.c
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr 
> > b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> > new file mode 100644
> > index 000..2d4f917
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-fpga-dfl-fme-mgr
> > @@ -0,0 +1,8 @@
> > +What:  /sys/bus/platform/devices/fpga-dfl-fme-mgr.0/interface_id
> > +Date:  November 2017
> > +KernelVersion:  4.15
> > +Contact:   Wu Hao 
> > +Description:   Read-only. It returns interface id of partial 
> > reconfiguration
> > +   hardware. Userspace could use this information to check if
> > +   current hardware is compatible with given image before FPGA
> > +   programming.
> 
> I'm a little confused by this.  I can understand that the PR bitstream
> has a dependency on the FPGA's static image, but I don't understand
> the dependency of the bistream on the hardware that is used to program
> the bitstream to the FPGA.

Sorry for the confusion, the interface_id is used to indicate the version of
the hardware for partial reconfiguration (it's part of the static image of
the FPGA device). Will improve the description on this.

> 
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 57da904..0171ecb 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -150,6 +150,12 @@ config FPGA_DFL_FME
> >   FPGA platform level management features. There shall be 1 FME
> >   per DFL based FPGA device.
> >
> > +config FPGA_DFL_FME_MGR
> > +   tristate "FPGA DFL FME Manager Driver"
> > +   depends on FPGA_DFL_FME
> > +   help
> > + Say Y to enable FPGA Manager driver for FPGA Management Engine.
> > +
> >  config INTEL_FPGA_DFL_PCI
> > tristate "Intel FPGA DFL PCIe Device Driver"
> > depends on PCI && FPGA_DFL
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index cc75bb3..6378580 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -31,6 +31,7 @@ obj-$(CONFIG_OF_FPGA_REGION)  += of-fpga-region.o
> >  # FPGA Device Feature List Support
> >  obj-$(CONFIG_FPGA_DFL) += fpga-dfl.o
> >  obj-$(CONFIG_FPGA_DFL_FME) += fpga-dfl-fme.o
> > +obj-$(CONFIG_FPGA_DFL_FME_MGR) += fpga-dfl-fme-mgr.o
> >
> >  fpga-dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
> >
> > diff --git a/drivers/fpga/fpga-dfl-fme-mgr.c 
> > b/drivers/fpga/fpga-dfl-fme-mgr.c
> > new file mode 100644
> > index 000..70356ce
> > --- /dev/null
> > +++ b/drivers/fpga/fpga-dfl-fme-mgr.c
> > @@ -0,0 +1,318 @@
> > +/*
> > + * FPGA Manager Driver for FPGA Management Engine (FME)
> > + *
> > + * Copyright (C) 2017 Intel Corporation, Inc.
> > + *
> > + * Authors:
> > + *   Kang Luwei 
> > + *   Xiao Guangrong 
> > + *   Wu Hao 
> > + *   Joseph Grecco 
> > + *   Enno Luebbers 
> > + *   Tim Whisonant 
> > + *   Ananda Ravuri 
> > + *   Christopher Rauer 
> > + *   Henry Mitchel 
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2.
> > + * SPDX-License-Identifier: GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "fpga-dfl.h"
> > +#include "dfl-fme.h"
> > +
> > +#define PR_WAIT_TIMEOUT   800
> > +#define PR_HOST_STATUS_IDLE0
> > +
> > +struct fme_mgr_priv {
> > +   void __iomem *ioaddr;
> > +   u64 pr_error;
> > +};
> > +
> > +static ssize_t interface_id_show(struct device *dev,
> > +struct device_attribute *attr, char *buf)
> > +{
> > +   struct fpga_manager *mgr = dev_get_drvdata(dev);
> > +   struct fme_mgr_priv *priv = mgr->priv;
> > +   u64 intfc_id_l, intfc_id_h;
> > +
> > 

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> ??? I did that: either one patch per directory with the same type of change,
> or one patch per driver combining all the changes for that driver.

Do any contributors get into the mood to take another look at software updates
from my selection of change possibilities in a more constructive way?

Do you need any additional development resources?

Regards,
Markus

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Lukas Bulwahn]

On Fri, 2 Feb 2018, Jani Nikula wrote:

> Being brutally honest, please write shorter reports and shorter emails
> to the lists.
> 
> The static analysis reports are welcome, but only when 1) we didn't
> already fix it in linux-next, or 2) it reveals an actual bug, not just a
> warning, warranting a backport.

That will be our policy.

Lukas

Re: [PATCH v2] KVM: x86: fix backward migration with async_PF

[David Hildenbrand]

On 01.02.2018 22:16, Radim Krčmář wrote:
> Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT
> bit when enabling async_PF, but this bit is reserved on old hypervisors,
> which results in a failure upon migration.
> 
> To avoid breaking different cases, we are checking for CPUID feature bit
> before enabling the feature and nothing else.
> 
> Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf 
> from guest mode")
> Cc: 
> Signed-off-by: Radim Krčmář 
> ---
> v2:
> * added documentation [Paolo]
> * retained compatibility recent kernels [Paolo]
> ---
>  Documentation/virtual/kvm/cpuid.txt  | 4 
>  Documentation/virtual/kvm/msr.txt| 3 ++-
>  arch/x86/include/uapi/asm/kvm_para.h | 1 +
>  arch/x86/kernel/kvm.c| 8 
>  arch/x86/kvm/cpuid.c | 3 ++-
>  5 files changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/cpuid.txt 
> b/Documentation/virtual/kvm/cpuid.txt
> index dcab6dc11e3b..87a7506f31c2 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -58,6 +58,10 @@ KVM_FEATURE_PV_TLB_FLUSH   || 9 || guest 
> checks this feature bit
> ||   || before enabling 
> paravirtualized
> ||   || tlb flush.
>  
> --
> +KVM_FEATURE_ASYNC_PF_VMEXIT||10 || paravirtualized async PF VM 
> exit
> +   ||   || can be enabled by setting bit 
> 2
> +   ||   || when writing to msr 0x4b564d02
> +--
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no 
> guest-side
> ||   || per-cpu warps are expected in
> ||   || kvmclock.
> diff --git a/Documentation/virtual/kvm/msr.txt 
> b/Documentation/virtual/kvm/msr.txt
> index 1ebecc115dc6..f3f0d57ced8e 100644
> --- a/Documentation/virtual/kvm/msr.txt
> +++ b/Documentation/virtual/kvm/msr.txt
> @@ -170,7 +170,8 @@ MSR_KVM_ASYNC_PF_EN: 0x4b564d02
>   when asynchronous page faults are enabled on the vcpu 0 when
>   disabled. Bit 1 is 1 if asynchronous page faults can be injected
>   when vcpu is in cpl == 0. Bit 2 is 1 if asynchronous page faults
> - are delivered to L1 as #PF vmexits.
> + are delivered to L1 as #PF vmexits.  Bit 2 can be set only if
> + KVM_FEATURE_ASYNC_PF_VMEXIT is present in CPUID.
>  
>   First 4 byte of 64 byte memory location will be written to by
>   the hypervisor at the time of asynchronous page fault (APF)
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> b/arch/x86/include/uapi/asm/kvm_para.h
> index 7a2ade4aa235..6cfa9c8cb7d6 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -26,6 +26,7 @@
>  #define KVM_FEATURE_PV_EOI   6
>  #define KVM_FEATURE_PV_UNHALT7
>  #define KVM_FEATURE_PV_TLB_FLUSH 9
> +#define KVM_FEATURE_ASYNC_PF_VMEXIT  10
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 4e37d1a851a6..971babe964d2 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -341,10 +341,10 @@ static void kvm_guest_cpu_init(void)
>  #endif
>   pa |= KVM_ASYNC_PF_ENABLED;
>  
> - /* Async page fault support for L1 hypervisor is optional */
> - if (wrmsr_safe(MSR_KVM_ASYNC_PF_EN,
> - (pa | KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT) & 0x, 
> pa >> 32) < 0)
> - wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
> + if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT))
> + pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT;
> +
> + wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
>   __this_cpu_write(apf_reason.enabled, 1);
>   printk(KERN_INFO"KVM setup async PF for cpu %d\n",
>  smp_processor_id());
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 20e491b94f44..7fc04a176c57 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -604,7 +604,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
> *entry, u32 function,
>(1 << KVM_FEATURE_PV_EOI) |
>(1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
>(1 << KVM_FEATURE_PV_UNHALT) |
> -  (1 << KVM_FEATURE_PV_TLB_FLUSH);
> +  (1 << KVM_FEATURE_PV_TLB_FLUSH) |
> +  (1 << KVM_FEATURE_ASYNC_PF_VMEXIT);
>  
>   if (sched_info_on())
>

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Greg KH]

On Fri, Feb 02, 2018 at 10:56:36AM +0100, Lukas Bulwahn wrote:
> On Fri, 2 Feb 2018, Jani Nikula wrote:
> 
> > Being brutally honest, please write shorter reports and shorter emails
> > to the lists.
> > 
> > The static analysis reports are welcome, but only when 1) we didn't
> > already fix it in linux-next, or 2) it reveals an actual bug, not just a
> > warning, warranting a backport.
> 
> That will be our policy.

Great!

Also a few other things to be aware of when working with the Linux
kernel community, and to try to answer some of your longer original
email querstions:

- don't scatter emails to tons of lists at the same time.  If
  you use scripts/get_maintainer.pl on a file, it will tell you
  exactly who and what list to notify of an issue found.

- when finding an issue, again, always check linux-next as that
  contains up to the past 3 months of work.  Don't duplicate
  stuff that others have already done, as that doesn't help
  anyone out.

- for stable kernel patches, please read:

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
  as to how to report a patch to be included in a stable kernel
  release (hint, just send the git hash to the list when it is
  in Linus's tree and ask for it to be included, as well as what
  trees you think it should be included in.)

- If clang now builds the kernel "cleanly", yes, I want to take
  warning fixes in the stable tree.  And even better yet, if you
  keep working to ensure the tree is "clean", that would be
  wonderful.

Hope this helps!

greg k-h

Re: [GIT PULL] IMA bug fixes for 4.16

[James Morris]

On Thu, 1 Feb 2018, Mimi Zohar wrote:

> Hi James,
> 
> Included in this pull request are three bug fixes, assuming the 2 FUSE
> patches are considered bugs and not new features, and a maintainer update.
> I'd appreciate your sending them to Linus for 4.16.

I'd like to see an acked-by or reviewed-by from the FUSE maintainer 
(cc'd), on the FUSE patches.



> 
> Mimi
> 
> The following changes since commit 36447456e1cca853188505f2a964dbbeacfc7a7a:
> 
>   ima/policy: fix parsing of fsuuid (2018-01-18 16:52:49 -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
> next-integrity
> 
> for you to fetch changes up to d56f30ac85c067d0d3a6c4f293f655dc298cb5ce:
> 
>   ima: force re-appraisal on filesystems with FS_IMA_NO_CACHE (2018-02-01 
> 12:38:31 -0500)
> 
> 
> Alban Crequy (2):
>   fuse: introduce new fs_type flag FS_IMA_NO_CACHE
>   ima: force re-appraisal on filesystems with FS_IMA_NO_CACHE
> 
> Mimi Zohar (2):
>   ima: re-initialize iint->atomic_flags
>   maintainers: update trusted keys
> 
>  MAINTAINERS   |  1 +
>  fs/fuse/inode.c   |  2 +-
>  include/linux/fs.h|  1 +
>  security/integrity/iint.c |  1 +
>  security/integrity/ima/ima_main.c | 15 +--
>  5 files changed, 17 insertions(+), 3 deletions(-)
> 

-- 
James Morris

Re: [PATCH 1/2] tools/memory-model: clarify the origin/scope of the tool name

[Andrea Parri]

On Thu, Feb 01, 2018 at 03:09:41PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> > On Thu, 1 Feb 2018, Andrea Parri wrote:
> > 
> > > Ingo pointed out that:
> > > 
> > >   "The "memory model" name is overly generic, ambiguous and somewhat
> > >misleading, as we usually mean the virtual memory layout/model
> > >when we say "memory model". GCC too uses it in that sense [...]"
> > > 
> > > Make it clearer that, in the context of tools/memory-model/, the term
> > > "memory-model" is used as shorthand for "memory consistency model" by
> > > calling out this convention in tools/memory-model/README.
> > > 
> > > Stick to the full name in sources' headers and for the subsystem name.
> > > 
> > > Suggested-by: Ingo Molnar 
> > > Signed-off-by: Andrea Parri 
> > 
> > For both patches:
> > 
> > Acked-by: Alan Stern 
> 
> Thank you all -- I have queued this and pushed it to my RCU tree on
> branch lkmm.  I did reword the commit log a bit, please see below and
> please let me know if any of my rewordings need halp.

Seems to me that your message has a leftover "is used".

  Andrea


> 
> Andrea, when you resend your second patch, could you please add Alan's
> Acked-by?
> 
>   Thanx, Paul
> 
> 
> 
> commit de175b697f71b8e3e6d980b7186b909fee0c4378
> Author: Andrea Parri 
> Date:   Thu Feb 1 13:03:29 2018 +0100
> 
> tools/memory-model: Clarify the origin/scope of the tool name
> 
> Ingo pointed out that:
> 
>   "The "memory model" name is overly generic, ambiguous and somewhat
>misleading, as we usually mean the virtual memory layout/model
>when we say "memory model". GCC too uses it in that sense [...]"
> 
> Make it clearer that tools/memory-model/ uses the term "memory model"
> is used as shorthand for "memory consistency model" by calling out this
> convention in tools/memory-model/README.
> 
> Stick to the original "memory model" term in sources' headers and for
> the subsystem name.
> 
> Suggested-by: Ingo Molnar 
> Signed-off-by: Andrea Parri 
> Acked-by: Will Deacon 
> Acked-by: Alan Stern 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
> index 711cbe72d606..db3bd3fc0435 100644
> --- a/tools/memory-model/MAINTAINERS
> +++ b/tools/memory-model/MAINTAINERS
> @@ -1,4 +1,4 @@
> -LINUX KERNEL MEMORY MODEL
> +LINUX KERNEL MEMORY CONSISTENCY MODEL
>  M:   Alan Stern 
>  M:   Andrea Parri 
>  M:   Will Deacon 
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index 43ba49492111..91414a49fac5 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -1,15 +1,15 @@
> - =
> - LINUX KERNEL MEMORY MODEL
> - =
> + =
> + LINUX KERNEL MEMORY CONSISTENCY MODEL
> + =
>  
>  
>  INTRODUCTION
>  
>  
> -This directory contains the memory model of the Linux kernel, written
> -in the "cat" language and executable by the (externally provided)
> -"herd7" simulator, which exhaustively explores the state space of
> -small litmus tests.
> +This directory contains the memory consistency model (memory model, for
> +short) of the Linux kernel, written in the "cat" language and executable
> +by the externally provided "herd7" simulator, which exhaustively explores
> +the state space of small litmus tests.
>  
>  In addition, the "klitmus7" tool (also externally provided) may be used
>  to convert a litmus test to a Linux kernel module, which in turn allows
> diff --git a/tools/memory-model/linux-kernel.bell 
> b/tools/memory-model/linux-kernel.bell
> index 57112505f5e0..b984bbda01a5 100644
> --- a/tools/memory-model/linux-kernel.bell
> +++ b/tools/memory-model/linux-kernel.bell
> @@ -11,7 +11,7 @@
>   * which is to appear in ASPLOS 2018.
>   *)
>  
> -"Linux kernel memory model"
> +"Linux-kernel memory consistency model"
>  
>  enum Accesses = 'once (*READ_ONCE,WRITE_ONCE,ACCESS_ONCE*) ||
>   'release (*smp_store_release*) ||
> diff --git a/tools/memory-model/linux-kernel.cat 
> b/tools/memory-model/linux-kernel.cat
> index 15b7a5dd8a9a..babe2b3b0bb3 100644
> --- a/tools/memory-model/linux-kernel.cat
> +++ b/tools/memory-model/linux-kernel.cat
> @@ -11,7 +11,7 @@
>   * which is to appear in ASPLOS 2018.
>   *)
>  
> -"Linux kernel memory model"
> +"Linux-kernel memory consistency model"
>  
>  (*
>   * File "lock.cat" handles locks and is experimental.
> 

Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali changing dclk frequency

[Giulio Benetti]

Il 02/02/2018 11:53, Maxime Ripard ha scritto:

Hi,

On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:

What kernel version did you use?


Latest mainline.


I guess this patch could fix it:
http://code.bulix.org/1kitrq-268936?raw


This should prevent from modifying parent clock. But my problem was
different.

On A20, gpu_clk can have different PLL, not I've found out the way
to choose right one with assigned-parent-clocks.

I have patchset ready for adding A20 mali node, but I need some more
time to complete with OPP, then I will submit entire patchset.

Now it works correctly, using right pll(dedicated PLL8), setting
right frequency.


The point is that we really don't care about which PLL is actually
being used, as long as the rate is correct and we don't break anything
else. If the GPU rate is accessible through one of the other PLL, it
makes even more sense to not use the GPU PLL and keep it disabled,
since it will result in some power savings.


Ah! I see the point now, very clever system for power saving.
I'm going to check if it's resolutive,
but it sounds good.




Btw, do I need to add a board using it, or can I add only Mali node
to sun7i-a20.dtsi(plus other little patches)?


You can add it to the DTSI without a board using it (and actually,
nothing should be in the board DTS, everything in the DT for the Mali
applies to all boards).


Sure. So I would also add the patch you've addressed me:
http://code.bulix.org/1kitrq-268936?raw
as a commit. Can I submit it in patchset to complete the whole job?



Maxime




--
Giulio Benetti
R Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

Re: [PATCH] firmware: dmi_scan: avoid printing error on non-efi systems

[Martin Hundebøll]

Hi,

Yeah, you can add my

Acked-by: Martin Hundebøll 

Thanks,
Martin

On February 2, 2018 8:00:27 AM GMT+01:00, Jean Delvare  wrote:
>Hi Martin,
>
>On Thu, 1 Feb 2018 09:08:05 +0100, Martin Hundebøll wrote:
>> dmi_init() rightfully checks if dmi is available at all, and errors
>out
>> if not. This leads to harmless errors being printed during boot on
>> non-efi systems, even when these are booted quietly.
>> 
>> Avoid this error-print by returning directly from dmi_init() if dmi
>> isn't available, instead of jumping to the err-label.
>> 
>> Signed-off-by: Martin Hundebøll 
>> ---
>>  drivers/firmware/dmi_scan.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/firmware/dmi_scan.c
>b/drivers/firmware/dmi_scan.c
>> index 783041964439..86c5e0625a08 100644
>> --- a/drivers/firmware/dmi_scan.c
>> +++ b/drivers/firmware/dmi_scan.c
>> @@ -715,10 +715,8 @@ static int __init dmi_init(void)
>>  u8 *dmi_table;
>>  int ret = -ENOMEM;
>>  
>> -if (!dmi_available) {
>> -ret = -ENODATA;
>> -goto err;
>> -}
>> +if (!dmi_available)
>> +return -ENODATA;
>>  
>>  /*
>>   * Set up dmi directory at /sys/firmware/dmi. This entry should
>stay
>
>I already have a similar patch by Ard Biesheuvel in my dmi tree:
>
>http://jdelvare.nerim.net/devel/linux/jdelvare-dmi/firmware-dmi-handle-missing-dmi-data-gracefully.patch
>
>Does it work for you?
>
>I'll send a pull request to Linus later today.
>
>Thanks,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[GIT PULL] RTC for 4.16

[Alexandre Belloni]

Hi Linus,

Here is the pull-request for the RTC subsystem for 4.16.

Not much this cycle. I've pushed the at32ap700x removal late but it is
unlikely to cause any issue.

The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:

  Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.16

for you to fetch changes up to 4402be2b4ca7f53b6213a9e6b3abe9cdcc683e9b:

  rtc: remove rtc-at32ap700x (2018-01-19 09:59:32 +0100)


RTC for 4.16

Subsystem:
 - Move ABI documentation to Documentation/ABI

New driver:
 - NXP i.MX53 SRTC
 - Chrome OS EC RTC

Drivers:
 - Remove at32ap700x
 - Many fixes in various error paths


Aishwarya Pant (2):
  Documentation: rtc: add sysfs file permissions
  Documentation: rtc: move iotcl interface documentation to ABI

Alexandre Belloni (2):
  rtc: ac100: Fix multiple race conditions
  Documentation: rtc: move sysfs documentation to ABI

Alexey Khoroshilov (1):
  rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe()

Andreas Platschek (1):
  rtc: omap: fix unbalanced clk_prepare_enable/clk_disable_unprepare

Arnd Bergmann (1):
  rtc: mxc_v2: remove __exit annotation

Benjamin Gaignard (1):
  rtc: stm32: Fix copyright

Cole Robinson (1):
  rtc: Remove unused RTC_DEVICE_NAME_SIZE

Colin Ian King (1):
  rtc: sun6i: ensure rtc is kfree'd on error

Corentin Labbe (1):
  rtc: remove rtc-at32ap700x

Fabio Estevam (1):
  rtc: mxc_v2: Remove unnecessary platform_get_resource() error check

Jia-Ju Bai (2):
  rtc: r7301: Fix a possible sleep-in-atomic bug in rtc7301_read_time
  rtc: r7301: Fix a possible sleep-in-atomic bug in rtc7301_set_time

Nobuhiro Iwamatsu (1):
  rtc: r9701: Remove r9701_remove function

Patrick Bruenn (2):
  dt-bindings: rtc: add bindings for i.MX53 SRTC
  rtc: add mxc driver for i.MX53 SRTC

Stephen Barber (2):
  mfd: cros_ec: Introduce RTC commands and events definitions.
  rtc: cros-ec: add cros-ec-rtc driver.

 Documentation/ABI/testing/rtc-cdev |  42 +++
 Documentation/ABI/testing/sysfs-class-rtc  |  91 +
 .../devicetree/bindings/rtc/rtc-mxc_v2.txt |  17 +
 Documentation/rtc.txt  |  81 +---
 drivers/rtc/Kconfig|  27 +-
 drivers/rtc/Makefile   |   3 +-
 drivers/rtc/rtc-ac100.c|  19 +-
 drivers/rtc/rtc-at32ap700x.c   | 287 --
 drivers/rtc/rtc-brcmstb-waketimer.c|  15 +-
 drivers/rtc/rtc-cros-ec.c  | 413 
 drivers/rtc/rtc-mxc_v2.c   | 419 +
 drivers/rtc/rtc-omap.c |   5 +-
 drivers/rtc/rtc-r7301.c|   4 +-
 drivers/rtc/rtc-r9701.c|   6 -
 drivers/rtc/rtc-stm32.c|   4 +-
 drivers/rtc/rtc-sun6i.c|   4 +-
 include/linux/mfd/cros_ec_commands.h   |   8 +
 include/linux/rtc.h|   1 -
 18 files changed, 1049 insertions(+), 397 deletions(-)
 create mode 100644 Documentation/ABI/testing/rtc-cdev
 create mode 100644 Documentation/ABI/testing/sysfs-class-rtc
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
 delete mode 100644 drivers/rtc/rtc-at32ap700x.c
 create mode 100644 drivers/rtc/rtc-cros-ec.c
 create mode 100644 drivers/rtc/rtc-mxc_v2.c

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

Re: [PATCH] clk: sunxi-ng: ccu-sun4i-a10: Fix mali changing dclk frequency

[Maxime Ripard]

Hi,

On Thu, Feb 01, 2018 at 05:17:11PM +0100, Giulio Benetti wrote:
> > > > What kernel version did you use?
> > > 
> > > Latest mainline.
> > 
> > I guess this patch could fix it:
> > http://code.bulix.org/1kitrq-268936?raw
> 
> This should prevent from modifying parent clock. But my problem was
> different.
>
> On A20, gpu_clk can have different PLL, not I've found out the way
> to choose right one with assigned-parent-clocks.
> 
> I have patchset ready for adding A20 mali node, but I need some more
> time to complete with OPP, then I will submit entire patchset.
>
> Now it works correctly, using right pll(dedicated PLL8), setting
> right frequency.

The point is that we really don't care about which PLL is actually
being used, as long as the rate is correct and we don't break anything
else. If the GPU rate is accessible through one of the other PLL, it
makes even more sense to not use the GPU PLL and keep it disabled,
since it will result in some power savings.

> Btw, do I need to add a board using it, or can I add only Mali node
> to sun7i-a20.dtsi(plus other little patches)?

You can add it to the DTSI without a board using it (and actually,
nothing should be in the board DTS, everything in the DT for the Mali
applies to all boards).

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


signature.asc
Description: PGP signature

Re: [RFC PATCH v1 00/13] lru_lock scalability

[Steven Whitehouse]

Hi,


On 02/02/18 04:18, Daniel Jordan wrote:



On 02/01/2018 10:54 AM, Steven Whitehouse wrote:

Hi,


On 31/01/18 23:04, daniel.m.jor...@oracle.com wrote:

lru_lock, a per-node* spinlock that protects an LRU list, is one of the
hottest locks in the kernel.  On some workloads on large machines, it
shows up at the top of lock_stat.

One way to improve lru_lock scalability is to introduce an array of 
locks,

with each lock protecting certain batches of LRU pages.

 *ooo**ooo**ooo** ...
 |   ||   ||   ||
  \ batch 1 /  \ batch 2 /  \ batch 3 /

In this ASCII depiction of an LRU, a page is represented with either 
'*'

or 'o'.  An asterisk indicates a sentinel page, which is a page at the
edge of a batch.  An 'o' indicates a non-sentinel page.

To remove a non-sentinel LRU page, only one lock from the array is
required.  This allows multiple threads to remove pages from different
batches simultaneously.  A sentinel page requires lru_lock in 
addition to

a lock from the array.

Full performance numbers appear in the last patch in this series, 
but this

prototype allows a microbenchmark to do up to 28% more page faults per
second with 16 or more concurrent processes.

This work was developed in collaboration with Steve Sistare.

Note: This is an early prototype.  I'm submitting it now to support my
request to attend LSF/MM, as well as get early feedback on the 
idea.  Any

comments appreciated.


* lru_lock is actually per-memcg, but without memcg's in the picture it
   becomes per-node.
GFS2 has an lru list for glocks, which can be contended under certain 
workloads. Work is still ongoing to figure out exactly why, but this 
looks like it might be a good approach to that issue too. The main 
purpose of GFS2's lru list is to allow shrinking of the glocks under 
memory pressure via the gfs2_scan_glock_lru() function, and it looks 
like this type of approach could be used there to improve the 
scalability,


Glad to hear that this could help in gfs2 as well.

Hopefully struct gfs2_glock is less space constrained than struct page 
for storing the few bits of metadata that this approach requires.


Daniel

We obviously want to keep gfs2_glock small, however within reason then 
yet we can add some additional fields as required. The use case is 
pretty much a standard LRU list, so items are added and removed, mostly 
at the active end of the list, and the inactive end of the list is 
scanned periodically by gfs2_scan_glock_lru()


Steve.

Re: [PATCH v6 3/5] KVM: VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

[Darren Kenny]

On Thu, Feb 01, 2018 at 10:59:44PM +0100, KarimAllah Ahmed wrote:

Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO
(bit 0) and IBRS_ALL (bit 1). This is a read-only MSR. By default the
contents will come directly from the hardware, but user-space can still
override it.

[dwmw2: The bit in kvm_cpuid_7_0_edx_x86_features can be unconditional]

Cc: Asit Mallick 
Cc: Dave Hansen 
Cc: Arjan Van De Ven 
Cc: Tim Chen 
Cc: Linus Torvalds 
Cc: Andrea Arcangeli 
Cc: Andi Kleen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Andy Lutomirski 
Cc: Greg KH 
Cc: Paolo Bonzini 
Cc: Ashok Raj 
Reviewed-by: Paolo Bonzini 
Signed-off-by: KarimAllah Ahmed 
Signed-off-by: David Woodhouse 


Reviewed-by: Darren Kenny 


---
arch/x86/kvm/cpuid.c |  2 +-
arch/x86/kvm/vmx.c   | 15 +++
arch/x86/kvm/x86.c   |  1 +
3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 033004d..1909635 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -394,7 +394,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,

/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
-   F(AVX512_4VNNIW) | F(AVX512_4FMAPS);
+   F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(ARCH_CAPABILITIES);

/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 263eb1f..b13314a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -593,6 +593,8 @@ struct vcpu_vmx {
u64   msr_guest_kernel_gs_base;
#endif

+   u64   arch_capabilities;
+
u32 vm_entry_controls_shadow;
u32 vm_exit_controls_shadow;
u32 secondary_exec_control;
@@ -3262,6 +3264,12 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_IA32_TSC:
msr_info->data = guest_read_tsc(vcpu);
break;
+   case MSR_IA32_ARCH_CAPABILITIES:
+   if (!msr_info->host_initiated &&
+   !guest_cpuid_has(vcpu, X86_FEATURE_ARCH_CAPABILITIES))
+   return 1;
+   msr_info->data = to_vmx(vcpu)->arch_capabilities;
+   break;
case MSR_IA32_SYSENTER_CS:
msr_info->data = vmcs_read32(GUEST_SYSENTER_CS);
break;
@@ -3397,6 +3405,11 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap, 
MSR_IA32_PRED_CMD,
  MSR_TYPE_W);
break;
+   case MSR_IA32_ARCH_CAPABILITIES:
+   if (!msr_info->host_initiated)
+   return 1;
+   vmx->arch_capabilities = data;
+   break;
case MSR_IA32_CR_PAT:
if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
if (!kvm_mtrr_valid(vcpu, MSR_IA32_CR_PAT, data))
@@ -5659,6 +5672,8 @@ static void vmx_vcpu_setup(struct vcpu_vmx *vmx)
++vmx->nmsrs;
}

+   if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
+   rdmsrl(MSR_IA32_ARCH_CAPABILITIES, vmx->arch_capabilities);

vm_exit_controls_init(vmx, vmcs_config.vmexit_ctrl);

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c53298d..4ec142e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1009,6 +1009,7 @@ static u32 msrs_to_save[] = {
#endif
MSR_IA32_TSC, MSR_IA32_CR_PAT, MSR_VM_HSAVE_PA,
MSR_IA32_FEATURE_CONTROL, MSR_IA32_BNDCFGS, MSR_TSC_AUX,
+   MSR_IA32_ARCH_CAPABILITIES
};

static unsigned num_msrs_to_save;
--
2.7.4

[PATCH v2] drm/bridge/sii8620: fix display modes validation

[Maciej Purski]

Current implementation of mode_valid() and mode_fixup() callbacks
handle packed pixel modes improperly.

Fix it by using proper maximum clock values from the documentation.

Signed-off-by: Maciej Purski 

---
Changes in v2:
- simplify is_packing_required() function
- fix uninitialized variable detected by kbuild robot in mode_valid()
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 81 +++-
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5168783..912d8c2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -34,8 +34,11 @@
 
 #define SII8620_BURST_BUF_LEN 288
 #define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
-#define MHL1_MAX_LCLK 225000
-#define MHL3_MAX_LCLK 60
+
+#define MHL1_MAX_PCLK 75000
+#define MHL1_MAX_PCLK_PP_MODE 15
+#define MHL3_MAX_PCLK 20
+#define MHL3_MAX_PCLK_PP_MODE 30
 
 enum sii8620_mode {
CM_DISCONNECTED,
@@ -2123,61 +2126,61 @@ static void sii8620_detach(struct drm_bridge *bridge)
rc_unregister_device(ctx->rc_dev);
 }
 
+static int sii8620_is_packing_required(struct sii8620 *ctx,
+const struct drm_display_mode *mode)
+{
+   int max_pclk, max_pclk_pp_mode;
+
+   if (sii8620_is_mhl3(ctx)) {
+   max_pclk = MHL3_MAX_PCLK;
+   max_pclk_pp_mode = MHL3_MAX_PCLK_PP_MODE;
+   } else {
+   max_pclk = MHL1_MAX_PCLK;
+   max_pclk_pp_mode = MHL1_MAX_PCLK_PP_MODE;
+   }
+
+   if (mode->clock < max_pclk)
+   return 0;
+   else if (mode->clock < max_pclk_pp_mode)
+   return 1;
+   else
+   return -1;
+}
+
 static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge,
 const struct drm_display_mode *mode)
 {
struct sii8620 *ctx = bridge_to_sii8620(bridge);
+   int pack_required = sii8620_is_packing_required(ctx, mode);
bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
MHL_DCAP_VID_LINK_PPIXEL;
-   unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
-  MHL1_MAX_LCLK;
-   max_pclk /= can_pack ? 2 : 3;
 
-   return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
+   switch (pack_required) {
+   case 0:
+   return MODE_OK;
+   case 1:
+   return (can_pack) ? MODE_OK : MODE_CLOCK_HIGH;
+   default:
+   return MODE_CLOCK_HIGH;
+   }
 }
 
+
 static bool sii8620_mode_fixup(struct drm_bridge *bridge,
   const struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode)
 {
struct sii8620 *ctx = bridge_to_sii8620(bridge);
-   int max_lclk;
-   bool ret = true;
 
mutex_lock(>lock);
 
-   max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
-   if (max_lclk > 3 * adjusted_mode->clock) {
-   ctx->use_packed_pixel = 0;
-   goto end;
-   }
-   if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & MHL_DCAP_VID_LINK_PPIXEL) &&
-   max_lclk > 2 * adjusted_mode->clock) {
-   ctx->use_packed_pixel = 1;
-   goto end;
-   }
-   ret = false;
-end:
-   if (ret) {
-   u8 vic = drm_match_cea_mode(adjusted_mode);
-
-   if (!vic) {
-   union hdmi_infoframe frm;
-   u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
-
-   /* FIXME: We need the connector here */
-   drm_hdmi_vendor_infoframe_from_display_mode(
-   , NULL, adjusted_mode);
-   vic = frm.vendor.hdmi.vic;
-   if (vic >= ARRAY_SIZE(mhl_vic))
-   vic = 0;
-   vic = mhl_vic[vic];
-   }
-   ctx->video_code = vic;
-   ctx->pixel_clock = adjusted_mode->clock;
-   }
+   ctx->use_packed_pixel = sii8620_is_packing_required(ctx, adjusted_mode);
+   ctx->video_code = drm_match_cea_mode(adjusted_mode);
+   ctx->pixel_clock = adjusted_mode->clock;
+
mutex_unlock(>lock);
-   return ret;
+
+   return true;
 }
 
 static const struct drm_bridge_funcs sii8620_bridge_funcs = {
-- 
2.7.4

Re: [PATCH] tcp_lp: use 64-bit arithmetic instead of 32-bit

[kbuild test robot]

Hi Gustavo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on net/master]
[also build test ERROR on v4.15 next-20180202]
[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/Gustavo-A-R-Silva/tcp_lp-use-64-bit-arithmetic-instead-of-32-bit/20180202-135349
config: i386-randconfig-i0-201804 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   net/ipv4/tcp_lp.o: In function `tcp_lp_remote_hz_estimator':
>> net/ipv4/tcp_lp.c:150: undefined reference to `__divdi3'

vim +150 net/ipv4/tcp_lp.c

   125  
   126  /**
   127   * tcp_lp_remote_hz_estimator
   128   *
   129   * Estimate remote HZ.
   130   * We keep on updating the estimated value, where original TCP-LP
   131   * implementation only guest it for once and use forever.
   132   */
   133  static u32 tcp_lp_remote_hz_estimator(struct sock *sk)
   134  {
   135  struct tcp_sock *tp = tcp_sk(sk);
   136  struct lp *lp = inet_csk_ca(sk);
   137  s64 rhz = (s64)lp->remote_hz << 6;  /* remote HZ << 6 */
   138  s64 m = 0;
   139  
   140  /* not yet record reference time
   141   * go away!! record it before come back!! */
   142  if (lp->remote_ref_time == 0 || lp->local_ref_time == 0)
   143  goto out;
   144  
   145  /* we can't calc remote HZ with no different!! */
   146  if (tp->rx_opt.rcv_tsval == lp->remote_ref_time ||
   147  tp->rx_opt.rcv_tsecr == lp->local_ref_time)
   148  goto out;
   149  
 > 150  m = (s64)TCP_TS_HZ *
   151  (tp->rx_opt.rcv_tsval - lp->remote_ref_time) /
   152  (tp->rx_opt.rcv_tsecr - lp->local_ref_time);
   153  if (m < 0)
   154  m = -m;
   155  
   156  if (rhz > 0) {
   157  m -= rhz >> 6;  /* m is now error in remote HZ est */
   158  rhz += m;   /* 63/64 old + 1/64 new */
   159  } else
   160  rhz = m << 6;
   161  
   162   out:
   163  /* record time for successful remote HZ calc */
   164  if ((rhz >> 6) > 0)
   165  lp->flag |= LP_VALID_RHZ;
   166  else
   167  lp->flag &= ~LP_VALID_RHZ;
   168  
   169  /* record reference time stamp */
   170  lp->remote_ref_time = tp->rx_opt.rcv_tsval;
   171  lp->local_ref_time = tp->rx_opt.rcv_tsecr;
   172  
   173  return rhz >> 6;
   174  }
   175  

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


.config.gz
Description: application/gzip

Re: [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS

[Rafael J. Wysocki]

On Thursday, February 1, 2018 2:18:12 PM CET Srinivas Pandruvada wrote:
> On Thu, 2018-02-01 at 10:11 +0100, Peter Zijlstra wrote:
> > On Thu, Feb 01, 2018 at 08:50:28AM +0100, Rafael J. Wysocki wrote:
> > > 
> > > On Wednesday, January 31, 2018 11:17:10 AM CET Peter Zijlstra
> > > wrote:
> > > > 
> > > > On Wed, Jan 31, 2018 at 10:22:49AM +0100, Rafael J. Wysocki
> > > > wrote:
> > > > > 
> > > > > On Tuesday, January 30, 2018 2:15:31 PM CET Peter Zijlstra
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > IA32_HWP_REQUEST has "Minimum_Performance",
> > > > > > "Maximum_Performance" and
> > > > > > "Desired_Performance" fields which can be used to give
> > > > > > explicit
> > > > > > frequency hints. And we really _should_ be doing that.
> > > > > > 
> > > > > > Because, esp. in this scenario; a task migrating; the
> > > > > > hardware really
> > > > > > can't do anything sensible, whereas the OS _knows_.
> > > > > But IA32_HWP_REQUEST is not a cheap MSR to write to.
> > > > That just means we might need to throttle writing to it, like it
> > > > already
> > > > does for the regular pstate (PERF_CTRL) msr in any case (also, is
> > > > that a
> > > > cheap msr?)
> > > > 
> > > > Not touching it at all seems silly.
> > > OK
> > > 
> > > So what field precisely would you touch?  "desired"?  If so, does
> > > that actually
> > > guarantee anything to happen?
> > No idea, desired would be the one I would start with, it matches with
> > the intent here. But I've no idea what our current HWP implementation
> > actually does with it.
> Desired !=0 will disable HWP autonomous mode of frequency selection.

But I don't think it will just run at "desired" then, will it?

Re: [PATCH V2 1/7] sched/topology: Adding function partition_sched_domains_locked()

[Juri Lelli]

Hi Mathieu,

On 01/02/18 09:51, Mathieu Poirier wrote:
> Introducing function partition_sched_domains_locked() by taking
> the mutex locking code out of the original function.  That way
> the work done by partition_sched_domains_locked() can be reused
> without dropping the mutex lock.
> 
> This patch doesn't change the functionality provided by the
> original code.
> 
> Signed-off-by: Mathieu Poirier 
> ---

[...]

> +/*
> + * Call with hotplug lock held

Is this the one that we can actually check if it's locked with

lockdep_assert_cpus_held()

?

> + */
> +void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
> +  struct sched_domain_attr *dattr_new)
> +{
> + mutex_lock(_domains_mutex);
> + partition_sched_domains_locked(ndoms_new, doms_new, dattr_new);
>   mutex_unlock(_domains_mutex);
>  }

Best,

- Juri

Re: [PATCH 4.9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

[Greg KH]

On Mon, Jan 29, 2018 at 01:13:32PM -0700, Shuah Khan wrote:
> On 01/28/2018 05:14 AM, Greg KH wrote:
> > On Fri, Jan 26, 2018 at 11:54:35AM -0700, Shuah Khan wrote:
> >> Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
> >> support")
> > 
> > Hm, I think you have the wrong commit id here.
> > 
> > I don't see any commit upstream with the Subject you have here, what are
> > you referring to?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> That is odd. Th commit went in a while back. Here are the details:
> 
> This is the commit from upstream:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/usbip/vhci_hcd.c?id=1c9de5bf428612458427943b724bea51abde520a
> 
> commit 1c9de5bf428612458427943b724bea51abde520a
> Author: Yuyang Du 
> Date:   Thu Jun 8 13:04:10 2017 +0800
> 
> usbip: vhci-hcd: Add USB3 SuperSpeed support
> 
> This patch adds a USB3 HCD to an existing USB2 HCD and provides
> the support of SuperSpeed, in case the device can only be enumerated
> with SuperSpeed.
> 
> The bulk of the added code in usb3_bos_desc and hub_control to support
> SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:
> dummy_hcd: add SuperSpeed support").
> 
> With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
> and VHCI_HC_PORTS SuperSpeed ports.
> 
> Suggested-by: Krzysztof Opasiak 
> Signed-off-by: Yuyang Du 
> Acked-by: Shuah Khan 
> Signed-off-by: Greg Kroah-Hartman 
> 
> 
> I isolated and backported a one line fix to the problem I saw in 4.9
> and 4.4 stables.

Ah, the "isolation" part is what I missed here, sorry about that.  You
are right, I'll go queue this up now, sorry for the noise.

greg k-h

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Jani Nikula]

+Knut, Fengguang

On Fri, 02 Feb 2018, Greg KH  wrote:
>   - If clang now builds the kernel "cleanly", yes, I want to take
> warning fixes in the stable tree.  And even better yet, if you
> keep working to ensure the tree is "clean", that would be
> wonderful.

So we can run sparse using 'make C=1' and friends, or other static
analysis tools using 'make CHECK=foo C=1', as long as the passed command
line params work. There was work by Knut to extend this make checker
stuff [1]. Since mixing different HOSTCC's in a single workdir seems
like a bad idea, I wonder how hard it would be to make clang work like
this:

$ make CHECK=clang C=1

Or using Knut's wrapper. Feels like that could increase the use of clang
for static analysis of patches.


BR,
Jani.


[1] 
http://mid.mail-archive.com/cover.5b56d020b8e826a7da33b1823c059acd0c123f8b.1515072782.git-series.knut.omang@oracle.com



-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] x86/retpoline: check CONFIG_RETPOLINE option when SPECTRE_V2_CMD_AUTO

[Thomas Gleixner]

On Fri, 2 Feb 2018, Chen Baozi wrote:

> Currently, if there is no spectre_v2= or nospectre_v2 specified in the boot
> parameter, the kernel will automatically choose mitigation by default.
> However, when selecting the auto mode, it doesn't check whether the
> retpoline has been built in the kernel. Thus, if someone built a kernel
> without CONFIG_RETPOLINE and booted the system without specifying any
> spectre_v2 kernel parameters, the kernel would still report that it has
> enabled a minimal retpoline mitigation which is not the case. This patch
> adds the checking of CONFIG_RETPOLINE option under the 'auto' mode to fix
> it.

Thanks for sending that patch, but its already fixed and queued for upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/pti=9471eee9186a46893726e22ebb54cade3f9bc043

Thanks,

tglx

[PATCH v3] ACPI / tables: Add IORT to injectable table list

[Yang Shunyong]

Loading IORT table from initrd is used to fix firmware IORT defects.
Moreover, it is very useful to debug SMMU node/device probe, MSI
allocation, stream id translation and IORT table from firmware. It
is also very useful to enable SMMU and devices behind SMMU before
firmware is ready.

This patch adds ACPI_SIG_IORT to the table, which enables IORT
from initrd to override which from firmware.

Signed-off-by: Yang Shunyong 
Cc: Joey Zheng 
Cc: Wang Dongsheng 
Cc: Jiang Yutang 
Cc: Hanjun Guo 
---

v3:
Add more detailed commit message according to Hanjun's suggestion.

v2:
Change typo ACPI_SIG_PPTT to ACPI_SIG_IORT in commit message.

---
 drivers/acpi/tables.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 80ce2a7d224b..7bcb66f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -456,7 +456,8 @@ static u8 __init acpi_table_checksum(u8 *buffer, u32 length)
ACPI_SIG_SLIC, ACPI_SIG_SPCR, ACPI_SIG_SPMI, ACPI_SIG_TCPA,
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
-   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, NULL };
+   ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
+   NULL };
 
 #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
 
-- 
1.8.3.1

Re: [RFC][PATCH] printk: do not flush printk_safe from irq_work

[Petr Mladek]

On Fri 2018-02-02 10:07:20, Sergey Senozhatsky wrote:
> On (02/01/18 13:00), Steven Rostedt wrote:
> > On Mon, 29 Jan 2018 11:29:18 +0900
> > Sergey Senozhatsky  wrote:
> [..]
> > > If the system is in "big troubles" then what makes irq_work more
> > > possible? Local IRQs can stay disabled, just like preemption. I
> > > guess when the troubles are really big our strategy is the same
> > > for both wq and irq_work solutions - we keep the printk_safe buffer
> > > and wait for panic()->flush.
> > 
> > Working on the RT kernel, I would tell you there's a huge difference
> > getting an irq_work to trigger than to expect something to schedule.

And this is not only about scheduling. It is also about having
a worker ready to handle the work. So, there is yet another
level that can eventually fail.


> > But if printk_safe() is just for recursion protection, how important is
> > it to get out?

Good question!

> Well, it depends. printk_safe can protect us against... what should I
> call it... let's call it first order, or direct, printk recursion. The
> one which involve locks internal to print. For instance,
> 
>   vprintk_emit()
>spin_lock_irqsave(_lock)
> spin_lock_debug(...)
>  spin_dump()
>   printk()
>vprintk_emit()
> spin_lock_irqsave(_lock)  << deadlock
> 
> printk_safe will save us by redirecting spin_dump()->printk().
> 
> So printk_safe output is in general of some interest, but we don't
> have guarantees that it will be printed: if it was the direct printk
> recursion - then it's all good, if indirect - then it may not be good.

IMHO, the question is if the information about printk recursion would
help to understand the situation on the system or if it would just
add a noise to the original problem.

I would personally prefer to know about it. But I do not feel
experienced enough to make a generic decision.

Best Regards,
Petr

Re: [PATCH 8/8] thermal/drivers/cpu_cooling: Add the combo cpu cooling device

[Viresh Kumar]

Hi Daniel,

I have gone through the other review comments, specially from Daniel T.. While I
share some of his concerns, I have few more of mine.

On 23-01-18, 16:34, Daniel Lezcano wrote:
> +late_initcall(cpu_cooling_init);

For example, this thing isn't going to fly nicely as you have assumed cpufreq
and cpuidle drivers are going to be part of the kernel itself. What if they are
modules and are inserted after late-init ? There are more cases like this where
the cpufreq driver may unregister the cpufreq cooling device on the fly and then
add it back. And so this stuff is a bit tricky.

Here is how I see the whole thing now:

- Yes we need individual support for both cpufreq and cpuidle cooling devices,
  and no one disagrees on that I believe.

- There is nothing in the thermal framework that disallows both cpufreq and
  cpuidle cooling devices to co-exist. Both would be part of the same thermal
  zone and so will get throttled with the same thermal sensor event. And so we
  will end up trying to cool down the SoC using both cpufreq and cpuidle
  technique.

- Now I am just wondering if we really need the "combo" functionality or not.
  Can we fine tune the DT cpu-cooling properties (existing ones) for a platform,
  so that it automatically acts as a combo cooling device? I am not 100% sure
  its gonna fly, but just wanted to make sure its not possible to work around
  with and then only try the combo device thing.

For example, suppose that with just cpufreq-cooling device we need to take the
CPU down to 1 GHz from 2 GHz if we cross temperature 'X'. What if we can change
this policy from DT and say the cpufreq-cooling device goes to 1.5 GHz and
cpuidle-cooling device takes us to idle for 'y' us, and the effect of
combination of these two is >= the effect of the 1 GHz for just the
cpufreq-cooling device.

Is there any possibility of this to work ?

-- 
viresh

[PATCH] ext4: report delalloc reserve as non-free in statfs mangled by project quota

[Konstantin Khlebnikov]

This reserved space isn't committed yet but cannot be used for allocations.
For userspace it has no difference from used space. XFS already does this.

Signed-off-by: Konstantin Khlebnikov 
Fixes: 689c958cbe6b ("ext4: add project quota support")
---
 fs/ext4/super.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 5de959fb0244..13ce97b9e820 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5227,7 +5227,8 @@ static int ext4_statfs_project(struct super_block *sb,
 dquot->dq_dqb.dqb_bsoftlimit :
 dquot->dq_dqb.dqb_bhardlimit) >> sb->s_blocksize_bits;
if (limit && buf->f_blocks > limit) {
-   curblock = dquot->dq_dqb.dqb_curspace >> sb->s_blocksize_bits;
+   curblock = (dquot->dq_dqb.dqb_curspace +
+   dquot->dq_dqb.dqb_rsvspace) >> sb->s_blocksize_bits;
buf->f_blocks = limit;
buf->f_bfree = buf->f_bavail =
(buf->f_blocks > curblock) ?

Re: Adjustments for a lot of function implementations

[Hans Verkuil]

On 02/02/18 10:55, SF Markus Elfring wrote:
>> ??? I did that: either one patch per directory with the same type of change,
>> or one patch per driver combining all the changes for that driver.
> 
> Do any contributors get into the mood to take another look at software updates
> from my selection of change possibilities in a more constructive way?
> 
> Do you need any additional development resources?

One last time: either post per-driver patches with all the cleanups for a driver
in a single patch, or a per-directory patch (drivers/media/pci, usb, etc) doing
the same cleanup for all drivers in that directory.

I prefer the first approach, but it's up to you.

We don't have the time to wade through dozens of one-liner cleanup patches.

I don't understand what is so difficult about this.

Regards,

Hans

Re: [PATCH v2] general protection fault in sock_has_perm

[Greg KH]

On Thu, Feb 01, 2018 at 07:37:04AM -0800, Mark Salyzyn wrote:
> In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket
> flag") and all the associated infrastructure changes to take advantage
> of a RCU grace period before freeing, there is a heightened
> possibility that a security check is performed while an ill-timed
> setsockopt call races in from user space.  It then is prudent to null
> check sk_security, and if the case, reject the permissions.
> 
> Because of the nature of this problem, hard to duplicate, no clear
> path, this patch is a simplified band-aid for stable trees lacking the
> infrastructure for the series of commits leading up to providing a
> suitable RCU grace period.  This adjustment is orthogonal to
> infrastructure improvements that may nullify the needed check, but
> could be added as good code hygiene in all trees.
> 
> general protection fault:  [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28
> task: 8801d1095f00 task.stack: 8800b595
> RIP: 0010:[]  [] 
> sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069
> RSP: 0018:8800b5957ce0  EFLAGS: 00010202
> RAX: dc00 RBX: 110016b2af9f RCX: 81b69b51
> RDX: 0002 RSI:  RDI: 0010
> RBP: 8800b5957de0 R08: 0001 R09: 0001
> R10:  R11: 110016b2af68 R12: 8800b5957db8
> R13:  R14: 8800b7259f40 R15: 00d7
> FS:  7f72f5ae2700() GS:8801db30() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 00a2fa38 CR3: 0001d798 CR4: 00160670
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Stack:
>  81b69a1f 8800b5957d58 8000b5957d30 41b58ab3
>  83fc82f2 81b69980 0246 8801d1096770
>  8801d3165668 8157844b 8801d1095f00
>  8801
> Call Trace:
> [] selinux_socket_setsockopt+0x4d/0x80 
> security/selinux/hooks.c:4338
> [] security_socket_setsockopt+0x7d/0xb0 
> security/security.c:1257
> [] SYSC_setsockopt net/socket.c:1757 [inline]
> [] SyS_setsockopt+0xe8/0x250 net/socket.c:1746
> [] entry_SYSCALL_64_fastpath+0x16/0x92
> Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8
> f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89
> fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00
> 00 41 8b 75 10 31
> RIP  [] sock_has_perm+0x1fe/0x3e0 
> security/selinux/hooks.c:4069
> RSP 
> ---[ end trace 7b5aaf788fef6174 ]---
> 
> Signed-off-by: Mark Salyzyn 
> Signed-off-by: Paul Moore 
> Signed-off-by: Greg KH 
> Cc: Eric Dumazet 
> Cc: Stephen Smalley 
> Cc: seli...@tycho.nsa.gov
> Cc: linux-security-mod...@vger.kernel.org
> Cc: Eric Paris 
> Cc: Serge E. Hallyn 
> Cc: stable  # 3.18, 4.4
> Cc: linux-kernel@vger.kernel.org
> ---
> v2: return -EFAULT for null sk_security instead of 0

Now queued up, thanks.

greg k-h

[PATCH v2] socket: Provide put_cmsg_whitelist() for constant size copies

[Kees Cook]

Most callers of put_cmsg() use a "sizeof(foo)" for the length argument.
But within put_cmsg(), the copy_to_user() call is made with a dynamic
length, as a result of the cmsg header calculations. This means that
hardened usercopy will examine the copy, even though it was technically
a fixed size and should be implicitly whitelisted.

Most callers of put_cmsg() are copying out of stack or kmalloc, so these
cases aren't a problem for hardened usercopy. However, some try to copy
out of the skbuff_head_cache slab, including the "cb" region. Since
whitelisting the slab area would leave other protocol definition of the
"cb" region exposed to usercopy bugs, this creates put_cmsg_whitelist(),
which internally uses sizeof() to provide a constant-sized length and
a stack bounce buffer, in order to explicitly whitelist an otherwise
disallowed slab region.

Original report was:

Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from 
SLAB object 'skbuff_head_cache' (offset 64, size 16)!
WARNING: CPU: 0 PID: 3663 at mm/usercopy.c:81 usercopy_warn+0xdb/0x100 
mm/usercopy.c:76
...
 __check_heap_object+0x89/0xc0 mm/slab.c:4426
 check_heap_object mm/usercopy.c:236 [inline]
 __check_object_size+0x272/0x530 mm/usercopy.c:259
 check_object_size include/linux/thread_info.h:112 [inline]
 check_copy_size include/linux/thread_info.h:143 [inline]
 copy_to_user include/linux/uaccess.h:154 [inline]
 put_cmsg+0x233/0x3f0 net/core/scm.c:242
 sock_recv_errqueue+0x200/0x3e0 net/core/sock.c:2913
 packet_recvmsg+0xb2e/0x17a0 net/packet/af_packet.c:3296
 sock_recvmsg_nosec net/socket.c:803 [inline]
 sock_recvmsg+0xc9/0x110 net/socket.c:810
 ___sys_recvmsg+0x2a4/0x640 net/socket.c:2179
 __sys_recvmmsg+0x2a9/0xaf0 net/socket.c:2287
 SYSC_recvmmsg net/socket.c:2368 [inline]
 SyS_recvmmsg+0xc4/0x160 net/socket.c:2352
 entry_SYSCALL_64_fastpath+0x29/0xa0

Reported-by: syzbot+e2d6cfb305e9f3911...@syzkaller.appspotmail.com
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Kees Cook 
---
 include/linux/socket.h   | 8 
 net/core/sock.c  | 4 +---
 net/iucv/af_iucv.c   | 5 ++---
 net/netlink/af_netlink.c | 4 ++--
 net/socket.c | 4 ++--
 5 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 9286a5a8c60c..1f52e998068b 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -343,6 +343,14 @@ struct ucred {
 
 extern int move_addr_to_kernel(void __user *uaddr, int ulen, struct 
sockaddr_storage *kaddr);
 extern int put_cmsg(struct msghdr*, int level, int type, int len, void *data);
+/*
+ * Provide a bounce buffer for copying cmsg data to userspace when the
+ * target memory isn't already whitelisted for hardened usercopy.
+ */
+#define put_cmsg_whitelist(_msg, _level, _type, _ptr) ({   \
+   typeof(*(_ptr)) _val = *(_ptr); \
+   put_cmsg(_msg, _level, _type, sizeof(_val), &_val); \
+   })
 
 struct timespec;
 
diff --git a/net/core/sock.c b/net/core/sock.c
index f39206b41b32..d8a3228acfd0 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2879,7 +2879,6 @@ void sock_enable_timestamp(struct sock *sk, int flag)
 int sock_recv_errqueue(struct sock *sk, struct msghdr *msg, int len,
   int level, int type)
 {
-   struct sock_exterr_skb *serr;
struct sk_buff *skb;
int copied, err;
 
@@ -2899,8 +2898,7 @@ int sock_recv_errqueue(struct sock *sk, struct msghdr 
*msg, int len,
 
sock_recv_timestamp(msg, sk, skb);
 
-   serr = SKB_EXT_ERR(skb);
-   put_cmsg(msg, level, type, sizeof(serr->ee), >ee);
+   put_cmsg_whitelist(msg, level, type, _EXT_ERR(skb)->ee);
 
msg->msg_flags |= MSG_ERRQUEUE;
err = copied;
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index 148533169b1d..676c019ba357 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1407,9 +1407,8 @@ static int iucv_sock_recvmsg(struct socket *sock, struct 
msghdr *msg,
/* create control message to store iucv msg target class:
 * get the trgcls from the control buffer of the skb due to
 * fragmentation of original iucv message. */
-   err = put_cmsg(msg, SOL_IUCV, SCM_IUCV_TRGCLS,
-  sizeof(IUCV_SKB_CB(skb)->class),
-  (void *)_SKB_CB(skb)->class);
+   err = put_cmsg_whitelist(msg, SOL_IUCV, SCM_IUCV_TRGCLS,
+_SKB_CB(skb)->class);
if (err) {
if (!(flags & MSG_PEEK))
skb_queue_head(>sk_receive_queue, skb);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index b9e0ee4e22f5..4420dba35a44 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1781,8 +1781,8 @@ static void netlink_cmsg_listen_all_nsid(struct sock *sk, 
struct msghdr *msg,
if (!NETLINK_CB(skb).nsid_is_set)
return;
 

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

[Darren Kenny]

On Thu, Feb 01, 2018 at 10:59:45PM +0100, KarimAllah Ahmed wrote:

[ Based on a patch from Ashok Raj  ]

Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
be using a retpoline+IBPB based approach.

To avoid the overhead of saving and restoring the MSR_IA32_SPEC_CTRL for
guests that do not actually use the MSR, only start saving and restoring
when a non-zero is written to it.

No attempt is made to handle STIBP here, intentionally. Filtering STIBP
may be added in a future patch, which may require trapping all writes
if we don't want to pass it through directly to the guest.

[dwmw2: Clean up CPUID bits, save/restore manually, handle reset]

Cc: Asit Mallick 
Cc: Arjan Van De Ven 
Cc: Dave Hansen 
Cc: Andi Kleen 
Cc: Andrea Arcangeli 
Cc: Linus Torvalds 
Cc: Tim Chen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Paolo Bonzini 
Cc: David Woodhouse 
Cc: Greg KH 
Cc: Andy Lutomirski 
Cc: Ashok Raj 
Signed-off-by: KarimAllah Ahmed 
Signed-off-by: David Woodhouse 


Reviewed-by: Darren Kenny 


---
v6:
- got rid of save_spec_ctrl_on_exit
- introduce msr_write_intercepted
v5:
- Also check for X86_FEATURE_SPEC_CTRL for the msr reads/writes
v4:
- Add IBRS to kvm_cpuid_8000_0008_ebx_x86_features
- Handling nested guests
v3:
- Save/restore manually
- Fix CPUID handling
- Fix a copy & paste error in the name of SPEC_CTRL MSR in
 disable_intercept.
- support !cpu_has_vmx_msr_bitmap()
v2:
- remove 'host_spec_ctrl' in favor of only a comment (dwmw@).
- special case writing '0' in SPEC_CTRL to avoid confusing live-migration
 when the instance never used the MSR (dwmw@).
- depend on X86_FEATURE_IBRS instead of X86_FEATURE_SPEC_CTRL (dwmw@).
- add MSR_IA32_SPEC_CTRL to the list of MSRs to save (dropped it by accident).
---
arch/x86/kvm/cpuid.c |   9 +++--
arch/x86/kvm/vmx.c   | 105 ++-
arch/x86/kvm/x86.c   |   2 +-
3 files changed, 110 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1909635..13f5d42 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -367,7 +367,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,

/* cpuid 0x8008.ebx */
const u32 kvm_cpuid_8000_0008_ebx_x86_features =
-   F(IBPB);
+   F(IBPB) | F(IBRS);

/* cpuid 0xC001.edx */
const u32 kvm_cpuid_C000_0001_edx_x86_features =
@@ -394,7 +394,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,

/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
-   F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(ARCH_CAPABILITIES);
+   F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
+   F(ARCH_CAPABILITIES);

/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
@@ -630,9 +631,11 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
g_phys_as = phys_as;
entry->eax = g_phys_as | (virt_as << 8);
entry->edx = 0;
-   /* IBPB isn't necessarily present in hardware cpuid */
+   /* IBRS and IBPB aren't necessarily present in hardware cpuid */
if (boot_cpu_has(X86_FEATURE_IBPB))
entry->ebx |= F(IBPB);
+   if (boot_cpu_has(X86_FEATURE_IBRS))
+   entry->ebx |= F(IBRS);
entry->ebx &= kvm_cpuid_8000_0008_ebx_x86_features;
cpuid_mask(>ebx, CPUID_8000_0008_EBX);
break;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b13314a..5d8a6a91 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -594,6 +594,7 @@ struct vcpu_vmx {
#endif

u64   arch_capabilities;
+   u64   spec_ctrl;

u32 vm_entry_controls_shadow;
u32 vm_exit_controls_shadow;
@@ -1913,6 +1914,29 @@ static void update_exception_bitmap(struct kvm_vcpu 
*vcpu)
}

/*
+ * Check if MSR is intercepted for currently loaded MSR bitmap.
+ */
+static bool msr_write_intercepted(struct kvm_vcpu *vcpu, u32 msr)
+{
+   unsigned long *msr_bitmap;
+   int f = sizeof(unsigned long);
+
+   if (!cpu_has_vmx_msr_bitmap())
+   return true;
+
+   msr_bitmap = to_vmx(vcpu)->loaded_vmcs->msr_bitmap;
+
+   if (msr <= 0x1fff) {
+   return !!test_bit(msr, msr_bitmap + 0x800 / f);
+   } else if ((msr >= 0xc000) && (msr <= 0xc0001fff)) {
+   msr &= 0x1fff;
+   return !!test_bit(msr, msr_bitmap + 0xc00 / f);
+   }
+
+   return true;
+}
+
+/*
 * Check if MSR is intercepted for L01 MSR bitmap.
 */
static bool msr_write_intercepted_l01(struct kvm_vcpu *vcpu, u32 msr)
@@ -3264,6 +3288,14 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct 

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 12:44 +0200, Jani Nikula wrote:
> +Knut, Fengguang
> 
> On Fri, 02 Feb 2018, Greg KH  wrote:
> > - If clang now builds the kernel "cleanly", yes, I want to take
> >   warning fixes in the stable tree.  And even better yet, if you
> >   keep working to ensure the tree is "clean", that would be
> >   wonderful.
> 
> So we can run sparse using 'make C=1' and friends, or other static
> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> line params work. There was work by Knut to extend this make checker
> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> like a bad idea, I wonder how hard it would be to make clang work like
> this:
> 
> $ make CHECK=clang C=1
> 
> Or using Knut's wrapper. Feels like that could increase the use of clang
> for static analysis of patches.

Yes, definitely a natural addition to the set of tools supported by
runchecks to also support using alternate compiler(s) as "checkers" - I guess
the same would apply for people compiling with clang - that they don't 
accidentally
generate warnings with gcc..

Thanks,
Knut

> BR,
> Jani.
> 
> 
> [1] 
> http://mid.mail-archive.com/cover.5b56d020b8e826a7da33b1823c059acd0c123f8b.151507278
> 2.git-series.knut.om...@oracle.com
> 
> 
> 

Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc

[Mark Rutland]

On Thu, Feb 01, 2018 at 12:39:09PM -0800, Channa wrote:
> On 2018-02-01 02:44, Mark Rutland wrote:
> > On Thu, Jan 25, 2018 at 03:55:12PM -0800, Channagoud Kadabi wrote:
> > > Documentation for last level cache controller device tree bindings,
> > > client bindings usage examples.
> > > 
> > > Signed-off-by: Channagoud Kadabi 
> > > ---
> > >  .../devicetree/bindings/arm/msm/qcom,llcc.txt  | 93
> > > ++
> > >  1 file changed, 93 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> > > b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> > > new file mode 100644
> > > index 000..d433b0c
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> > > @@ -0,0 +1,93 @@
> > > +* LLCC (Last Level Cache Controller)
> > > +
> > > +Properties:
> > > +- compatible:
> > > + Usage: required
> > > + Value type: 
> > > + Definition: must be "qcom,llcc-core"
> > > +
> > > +- reg:
> > > + Usage: required
> > > + Value Type: 
> > > + Definition: must be addresses and sizes of the LLCC registers
> > > +
> > > +- llcc-bank-off:
> > > + Usage: required
> > > + Value Type: 
> > > + Definition: Offsets of llcc banks from llcc base address starting
> > > from
> > > + LLCC bank0.
> > > +
> > > +- llcc-broadcast-off:
> > > + Usage: required
> > > + Value Type: 
> > > + Definition: Offset of broadcast register from LLCC bank0 address.
> > 
> > Please could we use "offset" rather than "off" for both of these? That
> > way it's obvious these aren't properties for disabling some feature.
> > 
> > How variable are these offsets in practice? Is the memory map not fixed?
> 
> The offsets depends on the number of LLCC HW blocks. These number of HW
> blocks vary from
> chipset to chipset and new registers could be added that changes the offset.

Surely if new registers are added, we need a new compatible string?

Can't we encode the number of LLCC HW blocks, instead? Presumably that
would give enough information to cover both llcc-bank-off and
llcc-broadcast-off.

[...]

> > > +
> > > +compatible devices:
> > > + qcom,sdm845-llcc
> > 
> > Huh? The "qcom,sdm845-llcc" bindings wasn't described above, and it's
> > not clear what this means.
> > 
> > > +
> > > +Example:
> > > +
> > > + qcom,system-cache@130 {
> > > + compatible = "qcom,llcc-core", "syscon", "simple-mfd";
> > 
> > This looks very wrong. Why do you need syscon and simple-mfd?
> 
> LLCC HW block has 3 functionalities:
> System cache core, ECC & AMON drivers for debugging.
> All three drivers use the same register space for configuration, status etc.
> In order to avoid remapping the same address region across multiple drivers,
> I have implemented this driver as a syncon and simple-mfd.

Please don't do that; that's completely dependent on Linux
implementation details.

Have one top level driver for the whole LLCC block, which maps the
registers, and provides an API for accessing them. When that probes, it
can cause the other drivers to be probed (e.g. with a platform device),
and those can access the LLCC registers via that API.

> > > + reg = <0x130 0x5>;
> > > + reg-names = "llcc_base";
> > > +
> > > + llcc: qcom,sdm845-llcc {
> > > + compatible = "qcom,sdm845-llcc";
> > 
> > Why is this a sub-node?
> qcom,sdm845-llcc: This core driver as mentioned in the list above.
> > 
> > Why isn't the top-level node just "qcom,sdm845-llcc" ?
> > 
> > > + #cache-cells = <1>;
> > > + max-slices = <32>;
> > > + };
> > > +
> > > + qcom,llcc-ecc {
> > > + compatible = "qcom,llcc-ecc";
> > > + };
> 
> qcom,llcc-ecc: Driver #2 for ECC
> 
> > > +
> > > + qcom,llcc-amon {
> > > + compatible = "qcom,llcc-amon";
> > > + qcom,fg-cnt = <0x7>;
> > > + };
> > > +
> 
> qcom,llcc-amon: Driver #3 for AMON

Please describe the HW, not the drivers.

As above, I don't believe you need multiple nodes here. Linux can
instantiate the drivers as necessary.

[...]

> > > +- cache-slices:
> > > + Usage: required
> > > + Value type: 
> > > + Definition: The tuple has phandle to llcc device as the first
> > > argument and the
> > > + second argument is the usecase id of the client.
> > 
> > What is a "usecase id" ?
> 
> Usecase id for use case that wants to use system cache for eg: video-encode
> and video-decode

Sure, but how is the value used? Is it the index of a slice? Or
something more abstract?

Thanks,
Mark.

Re: [PATCH v6 5/5] KVM: SVM: Allow direct access to MSR_IA32_SPEC_CTRL

[Darren Kenny]

On Thu, Feb 01, 2018 at 10:59:46PM +0100, KarimAllah Ahmed wrote:

[ Based on a patch from Paolo Bonzini  ]

... basically doing exactly what we do for VMX:

- Passthrough SPEC_CTRL to guests (if enabled in guest CPUID)
- Save and restore SPEC_CTRL around VMExit and VMEntry only if the guest
 actually used it.

Cc: Asit Mallick 
Cc: Arjan Van De Ven 
Cc: Dave Hansen 
Cc: Andi Kleen 
Cc: Andrea Arcangeli 
Cc: Linus Torvalds 
Cc: Tim Chen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Paolo Bonzini 
Cc: David Woodhouse 
Cc: Greg KH 
Cc: Andy Lutomirski 
Cc: Ashok Raj 
Signed-off-by: KarimAllah Ahmed 
Signed-off-by: David Woodhouse 


Reviewed-by: Darren Kenny 


---
v5:
- Add SPEC_CTRL to direct_access_msrs.
---
arch/x86/kvm/svm.c | 59 ++
1 file changed, 59 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 254eefb..c6ab343 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -184,6 +184,9 @@ struct vcpu_svm {
u64 gs_base;
} host;

+   u64 spec_ctrl;
+   bool save_spec_ctrl_on_exit;
+
u32 *msrpm;

ulong nmi_iret_rip;
@@ -249,6 +252,7 @@ static const struct svm_direct_access_msrs {
{ .index = MSR_CSTAR,   .always = true  },
{ .index = MSR_SYSCALL_MASK,.always = true  },
#endif
+   { .index = MSR_IA32_SPEC_CTRL,  .always = false },
{ .index = MSR_IA32_PRED_CMD,   .always = false },
{ .index = MSR_IA32_LASTBRANCHFROMIP,   .always = false },
{ .index = MSR_IA32_LASTBRANCHTOIP, .always = false },
@@ -1584,6 +1588,8 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool 
init_event)
u32 dummy;
u32 eax = 1;

+   svm->spec_ctrl = 0;
+
if (!init_event) {
svm->vcpu.arch.apic_base = APIC_DEFAULT_PHYS_BASE |
   MSR_IA32_APICBASE_ENABLE;
@@ -3605,6 +3611,13 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_VM_CR:
msr_info->data = svm->nested.vm_cr_msr;
break;
+   case MSR_IA32_SPEC_CTRL:
+   if (!msr_info->host_initiated &&
+   !guest_cpuid_has(vcpu, X86_FEATURE_IBRS))
+   return 1;
+
+   msr_info->data = svm->spec_ctrl;
+   break;
case MSR_IA32_UCODE_REV:
msr_info->data = 0x0165;
break;
@@ -3696,6 +3709,30 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct 
msr_data *msr)
case MSR_IA32_TSC:
kvm_write_tsc(vcpu, msr);
break;
+   case MSR_IA32_SPEC_CTRL:
+   if (!msr->host_initiated &&
+   !guest_cpuid_has(vcpu, X86_FEATURE_IBRS))
+   return 1;
+
+   /* The STIBP bit doesn't fault even if it's not advertised */
+   if (data & ~(SPEC_CTRL_IBRS | SPEC_CTRL_STIBP))
+   return 1;
+
+   svm->spec_ctrl = data;
+
+   /*
+* When it's written (to non-zero) for the first time, pass
+* it through. This means we don't have to take the perf
+* hit of saving it on vmexit for the common case of guests
+* that don't use it.
+*/
+   if (data && !svm->save_spec_ctrl_on_exit) {
+   svm->save_spec_ctrl_on_exit = true;
+   if (is_guest_mode(vcpu))
+   break;
+   set_msr_interception(svm->msrpm, MSR_IA32_SPEC_CTRL, 1, 
1);
+   }
+   break;
case MSR_IA32_PRED_CMD:
if (!msr->host_initiated &&
!guest_cpuid_has(vcpu, X86_FEATURE_IBPB))
@@ -4964,6 +5001,15 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)

local_irq_enable();

+   /*
+* If this vCPU has touched SPEC_CTRL, restore the guest's value if
+* it's non-zero. Since vmentry is serialising on affected CPUs, there
+* is no need to worry about the conditional branch over the wrmsr
+* being speculatively taken.
+*/
+   if (svm->spec_ctrl)
+   wrmsrl(MSR_IA32_SPEC_CTRL, svm->spec_ctrl);
+
asm volatile (
"push %%" _ASM_BP "; \n\t"
"mov %c[rbx](%[svm]), %%" _ASM_BX " \n\t"
@@ -5056,6 +5102,19 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
#endif
);

+   /*
+* We do not use IBRS in the kernel. If this vCPU has used the
+* SPEC_CTRL MSR it may have left it on; save the value and
+* turn it off. This is much more efficient than blindly adding
+* it to the atomic save/restore list. Especially as the former
+* (Saving guest MSRs on vmexit) doesn't even exist in KVM.
+   

Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc

[Mark Rutland]

On Thu, Feb 01, 2018 at 12:47:01PM -0800, Channa wrote:
> On 2018-02-01 02:48, Mark Rutland wrote:
> > On Thu, Jan 25, 2018 at 03:55:12PM -0800, Channagoud Kadabi wrote:
> > > Documentation for last level cache controller device tree bindings,
> > > client bindings usage examples.
> > > 
> > > Signed-off-by: Channagoud Kadabi 
> > > ---
> > >  .../devicetree/bindings/arm/msm/qcom,llcc.txt  | 93
> > > ++
> > >  1 file changed, 93 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> > > 
> > > +Example:
> > > +
> > > + qcom,system-cache@130 {
> > > + compatible = "qcom,llcc-core", "syscon", "simple-mfd";
> > > + reg = <0x130 0x5>;
> > > + reg-names = "llcc_base";
> > > +
> > > + llcc: qcom,sdm845-llcc {
> > > + compatible = "qcom,sdm845-llcc";
> > > + #cache-cells = <1>;
> > > + max-slices = <32>;
> > > + };
> > > +
> > > + qcom,llcc-ecc {
> > > + compatible = "qcom,llcc-ecc";
> > > + };
> > > +
> > > + qcom,llcc-amon {
> > > + compatible = "qcom,llcc-amon";
> > > + qcom,fg-cnt = <0x7>;
> > > + };
> > > +
> > > + };
> > 
> > The "qcom,llcc-ecc" and "qcom,llcc-amon" bindings doesn't seem to be
> > used by the driver in patch 2, and it's not clear how they are intended
> > to be used, so I think they should go from the binding for now.
> 
> Sure I can remove them for now and add them when the I push other drivers
> for review.
> 
> > I don't think you need syscon and simple-mfd, and I think you can
> 
> I used syscon and simple-mfd because three drivers touch the same address
> space.

As in my other reply, I don't think that's the right way to solve the
problem.

Please have one top-level driver and associated binding. That driver can
carve up the functional units and allow other drivers to access the
registers as necessary.

Thanks,
Mark.

Re: [PATCH] ARM: dts: imx6q-bx50v3: Enable secure-reg-access

[Sebastian Reichel]

Hi,

On Fri, Feb 02, 2018 at 03:18:20PM +0800, Shawn Guo wrote:
> + Frank
> 
> On Mon, Jan 15, 2018 at 05:07:22PM +0100, Sebastian Reichel wrote:
> > From: Peter Senna Tschudin 
> > 
> > Add secure-reg-access on device tree include file for Bx50 devices
> > to enable PMU and hardware counters for perf.
> > 
> > Signed-off-by: Peter Senna Tschudin 
> > Signed-off-by: Sebastian Reichel 
> > ---
> >  arch/arm/boot/dts/imx6q-bx50v3.dtsi | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi 
> > b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > index 86cfd4481e72..ccaaee83e2fa 100644
> > --- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> > @@ -43,6 +43,13 @@
> >  #include "imx6q-ba16.dtsi"
> >  
> >  / {
> > +   soc {
> > +   pmu {
> > +   compatible = "arm,cortex-a9-pmu";
> > +   secure-reg-access;
> 
> I'm not sure this could be a board level configuration.  Shouldn't this
> property just be added into pmu node in imx6qdl.dtsi?

This cannot become part of imx6qdl.dtsi for two reasons:

1. It's not safe to be enabled on imx6qdl in secure state, see
   excerpt from DT binding documentation below
2. We cannot enable it by default, since DTS format does not provide
   a method to unset it in board files using a imx6qdl in secure
   mode.

Here is an extract from the DT documentation for the PMU node:

- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
  (SDER) is accessible. This will cause the driver to do
  any setup required that is only possible in ARMv7 secure
  state. If not present the ARMv7 SDER will not be touched,
  which means the PMU may fail to operate unless external
  code (bootloader or security monitor) has performed the
  appropriate initialisation. Note that this property is
  not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
  in Non-secure state.

For B450v3, B650v3 and B850v3 it's safe to enable the bit and it
improves debugging capabilities a lot.

-- Sebastian

> 
> Shawn
> 
> > +   };
> > +   };
> > +
> > clocks {
> > mclk: clock@0 {
> > compatible = "fixed-clock";
> > -- 
> > 2.15.1
> > 


signature.asc
Description: PGP signature

Re: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is already initialized

[Bryan O'Donoghue]

On 01/02/18 12:16, Horia Geantă wrote:

If the loop cannot exit based on value of "ret" != -EAGAIN, then it means
caam_probe() will eventually fail due to ret == -EAGAIN:
if (ret) {
dev_err(dev, "failed to instantiate RNG");
goto caam_remove;
}


For me it's an endless loop applying the first two

https://patchwork.ozlabs.org/patch/866460/
https://patchwork.ozlabs.org/patch/866462/

but not this one

https://patchwork.ozlabs.org/patch/865890/


Please provide more details, so that the root cause is found and fixed.


np

---
bod

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

[David Woodhouse]

On Thu, 2018-02-01 at 22:59 +0100, KarimAllah Ahmed wrote:

> [ Based on a patch from Ashok Raj  ]
> 
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based approach.
> 
> To avoid the overhead of saving and restoring the MSR_IA32_SPEC_CTRL for
> guests that do not actually use the MSR, only start saving and restoring
> when a non-zero is written to it.
> 
> No attempt is made to handle STIBP here, intentionally. Filtering STIBP
> may be added in a future patch, which may require trapping all writes
> if we don't want to pass it through directly to the guest.
> 
> [dwmw2: Clean up CPUID bits, save/restore manually, handle reset]
> 
> Cc: Asit Mallick 
> Cc: Arjan Van De Ven 
> Cc: Dave Hansen 
> Cc: Andi Kleen 
> Cc: Andrea Arcangeli 
> Cc: Linus Torvalds 
> Cc: Tim Chen 
> Cc: Thomas Gleixner 
> Cc: Dan Williams 
> Cc: Jun Nakajima 
> Cc: Paolo Bonzini 
> Cc: David Woodhouse 
> Cc: Greg KH 
> Cc: Andy Lutomirski 
> Cc: Ashok Raj 
> Signed-off-by: KarimAllah Ahmed 
> Signed-off-by: David Woodhouse 
> ---
> v6:
> - got rid of save_spec_ctrl_on_exit
> - introduce msr_write_intercepted
> v5:
> - Also check for X86_FEATURE_SPEC_CTRL for the msr reads/writes
> v4:
> - Add IBRS to kvm_cpuid_8000_0008_ebx_x86_features
> - Handling nested guests
> v3:
> - Save/restore manually
> - Fix CPUID handling
> - Fix a copy & paste error in the name of SPEC_CTRL MSR in
>   disable_intercept.
> - support !cpu_has_vmx_msr_bitmap()
> v2:
> - remove 'host_spec_ctrl' in favor of only a comment (dwmw@).
> - special case writing '0' in SPEC_CTRL to avoid confusing live-migration
>   when the instance never used the MSR (dwmw@).
> - depend on X86_FEATURE_IBRS instead of X86_FEATURE_SPEC_CTRL (dwmw@).
> - add MSR_IA32_SPEC_CTRL to the list of MSRs to save (dropped it by accident).

This looks very good to me now, and the comments are helpful. Thank you
for your persistence with getting the details right. If we make the SVM
one look like this, as you mentioned, I think we ought finally be ready
to merge it.

Good work ;)


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v6 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

[Robin Murphy]

On 02/02/18 05:40, Sricharan R wrote:

Hi Robin/Vivek,

On 2/1/2018 2:23 PM, Vivek Gautam wrote:

Hi,


On 1/31/2018 6:39 PM, Robin Murphy wrote:

On 19/01/18 11:43, Vivek Gautam wrote:

From: Sricharan R 

Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.


Don't we need to balance this with a device_link_del() in .remove_device (like 
exynos-iommu does)?


Right. Will add device_link_del() call. Thanks for pointing out.


  The reason for not adding device_link_del from .remove_device was, the core 
device_del
  which calls the .remove_device from notifier, calls device_links_purge before 
that.
  That does the same thing as device_link_del. So by the time .remove_device is 
called,
  device_links for that device is already cleaned up. Vivek, you may want to 
check once that
  calling device_link_del from .remove_device has no effect, just to confirm 
once more.


There is at least one path in which .remove_device is not called via the 
notifier from device_del(), which is in the cleanup path of 
iommu_bus_init(). AFAICS any links created by .add_device during that 
process would be left dangling, because the device(s) would be live but 
otherwise disassociated from the IOMMU afterwards.


From a maintenance perspective it's easier to have the call in its 
logical place even if it does nothing 99% of the time; that way we 
shouldn't have to keep an eye out for subtle changes in the power 
management code or driver core that might invalidate the device_del() 
reasoning above, and the power management guys shouldn't have to 
comprehend the internals of the IOMMU API to make sense of the 
unbalanced call if they ever want to change their API.


Thanks,
Robin.

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Pablo Neira Ayuso]

On Tue, Jan 30, 2018 at 03:39:58PM +0100, Michal Hocko wrote:
> On Tue 30-01-18 15:01:11, Florian Westphal wrote:
> > > From d48e950f1b04f234b57b9e34c363bdcfec10aeee Mon Sep 17 00:00:00 2001
> > > From: Michal Hocko 
> > > Date: Tue, 30 Jan 2018 14:51:07 +0100
> > > Subject: [PATCH] net/netfilter/x_tables.c: make allocation less aggressive
> > 
> > Acked-by: Florian Westphal 
> 
> Thanks! How should we route this change? Andrew, David?

I'll place this in the nf.git tree if everyone is happy with it.

Re: Is the hisilicon tree maintained ?

[Wei Xu]

Hi Daniel,

On 2018/2/2 6:59, Daniel Lezcano wrote:
> 
> Hi Wei Xu,
> 
> I found in the MAINTAINERS file the hisilicon tree is at:
> 
> https://github.com/hisilicon/linux-hisi
> 
> But, (except I missed it) I didn't find any update since Nov, 2017.
> 
> Is that tree maintained ?

Yes. It is still maintained.
You can find update from other branches or the tags like next/dt64.
I will update the master when every rc1 is released.

Best Regards,
Wei

> 
> Thanks?
> 
>   -- Daniel
> 
> 

Query related to usage of cpufreq_suspend() & cpufreq_resume

[Prateek Sood]

Hi Viresh,

One scenario is there where a kernel panic is observed in
cpufreq during suspend/resume.

pm_suspend()
  suspend_devices_and_enter()
dpm_suspend_start()
  dpm_prepare() 

Failure in dpm_prepare() happend with following dmesg:

[ 3746.316062] PM: Device xyz not prepared for power transition: code -16
[ 3746.316071] PM: Some devices failed to suspend, or early wake event detected


pm_suspend()
  suspend_devices_and_enter()
dpm_suspend_start()
  dpm_prepare() //failed
dpm_resume_end()
  dpm_resume()
cpufreq_resume()
  cpufreq_start_governor()
sugov_start()
  cpufreq_add_update_util_hook()

After failure in dpm_prepare(), dpm_resume() called
cpufreq_resume(). Corresponding cpufreq_suspend() was not
called due to failure of dpm_prepare(). 

This resulted in WARN_ON(per_cpu(cpufreq_update_util_data, cpu))
in cpufreq_add_update_util_hook() and cpufreq_add_update_util_hook->func
being inconsistent state. It caused crash in scheduler.

Following are some of the ways to mitigate this issue. Could
you please provide feedback on below two approaches or suugest
a better way to fix this problem.

---8<--

Co-developed-by: Gaurav Kohli 
Signed-off-by: Gaurav Kohli  
Signed-off-by: Prateek Sood 

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 02a497e..732e5a2 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1038,6 +1038,7 @@ void dpm_resume(pm_message_t state)
 {
struct device *dev;
ktime_t starttime = ktime_get();
+   bool valid_resume = false;

trace_suspend_resume(TPS("dpm_resume"), state.event, true);
might_sleep();
@@ -1055,6 +1056,7 @@ void dpm_resume(pm_message_t state)
}

while (!list_empty(_suspended_list)) {
+   valid_resume = true;
dev = to_device(dpm_suspended_list.next);
get_device(dev);
if (!is_async(dev)) {
@@ -1080,7 +1082,8 @@ void dpm_resume(pm_message_t state)
async_synchronize_full();
dpm_show_time(starttime, state, 0, NULL);

-   cpufreq_resume();
+   if (valid_resume)
+   cpufreq_resume();
trace_suspend_resume(TPS("dpm_resume"), state.event, false);
 }

8<--

Signed-off-by: Prateek Sood 

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 421f318..439eab8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1648,7 +1648,7 @@ void cpufreq_suspend(void)
 {
struct cpufreq_policy *policy;

-   if (!cpufreq_driver)
+   if (!cpufreq_driver || cpufreq_suspended)
return;

if (!has_target() && !cpufreq_driver->suspend)
@@ -1683,7 +1683,7 @@ void cpufreq_resume(void)
struct cpufreq_policy *policy;
int ret;

-   if (!cpufreq_driver)
+   if (!cpufreq_driver || !cpufreq_suspended)
return;

cpufreq_suspended = false;




Thanks

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

[PATCH] audit: update bugtracker and source URIs

[Richard Guy Briggs]

Since the Linux Audit project has transitioned completely over to
github, update the MAINTAINERS file and the primary audit source file to
reflect that reality.

Signed-off-by: Richard Guy Briggs 
---
 MAINTAINERS| 1 -
 kernel/audit.c | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 845fc25..fba4875 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2479,7 +2479,6 @@ M:Paul Moore 
 M: Eric Paris 
 L: linux-au...@redhat.com (moderated for non-subscribers)
 W: https://github.com/linux-audit
-W: https://people.redhat.com/sgrubb/audit
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
 S: Supported
 F: include/linux/audit.h
diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99..06964f1 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -38,7 +38,8 @@
  *   6) Support low-overhead kernel-based filtering to minimize the
  *  information that must be passed to user-space.
  *
- * Example user-space utilities: http://people.redhat.com/sgrubb/audit/
+ * Audit kernel, userspace, documentation and testsuite bugtrackers and
+ * repositories: https://github.com/linux-audit
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
1.8.3.1

Re: [PATCH 4/4] sched/fair: Use a recently used CPU as an idle candidate and the basis for SIS

[Rafael J. Wysocki]

On Thursday, February 1, 2018 10:11:04 AM CET Peter Zijlstra wrote:
> On Thu, Feb 01, 2018 at 08:50:28AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, January 31, 2018 11:17:10 AM CET Peter Zijlstra wrote:
> > > On Wed, Jan 31, 2018 at 10:22:49AM +0100, Rafael J. Wysocki wrote:
> > > > On Tuesday, January 30, 2018 2:15:31 PM CET Peter Zijlstra wrote:
> > > 
> > > > > IA32_HWP_REQUEST has "Minimum_Performance", "Maximum_Performance" and
> > > > > "Desired_Performance" fields which can be used to give explicit
> > > > > frequency hints. And we really _should_ be doing that.
> > > > > 
> > > > > Because, esp. in this scenario; a task migrating; the hardware really
> > > > > can't do anything sensible, whereas the OS _knows_.
> > > > 
> > > > But IA32_HWP_REQUEST is not a cheap MSR to write to.
> > > 
> > > That just means we might need to throttle writing to it, like it already
> > > does for the regular pstate (PERF_CTRL) msr in any case (also, is that a
> > > cheap msr?)
> > > 
> > > Not touching it at all seems silly.
> > 
> > OK
> > 
> > So what field precisely would you touch?  "desired"?  If so, does that 
> > actually
> > guarantee anything to happen?
> 
> No idea, desired would be the one I would start with, it matches with
> the intent here. But I've no idea what our current HWP implementation
> actually does with it.
> 
> > > But now that you made me look, intel_pstate_hwp_set() is horrible crap.
> > > You should _never_ do things like:
> > > 
> > >   rdmsr_on_cpu()
> > >   /* frob value */
> > >   wrmsr_on_cpu()
> > > 
> > > That's insane.
> > 
> > I guess you mean it does too many IPIs?  Or that it shouldn't do any IPIs
> > at all?
> 
> Yes, too many synchronous IPIs, which themselves are typically already
> more expensive than the MSR access.

We could do all of the updates in one IPI (as Srinivas said), but it would be
more code, and custom code for that matter.

Is this really worth it for a slow path like this one?

> At one point I looked to getting rid of the *msr_on_cpu() crud entirely,
> but there's just too much users out there I didn't feel like touching.
> 
> If you really care you can do async IPIs and do a custom serialization
> that only waits when you do back-to-back things, which should be fairly
> uncommon I'd think.

In this particular case we don't want to return to user space before the
MSR is actually written with the new value.

[tip:x86/pti] x86/retpoline: Avoid retpolines for built-in __init functions

[tip-bot for David Woodhouse]

Commit-ID:  66f793099a636862a71c59d4a6ba91387b155e0c
Gitweb: https://git.kernel.org/tip/66f793099a636862a71c59d4a6ba91387b155e0c
Author: David Woodhouse 
AuthorDate: Thu, 1 Feb 2018 11:27:20 +
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Feb 2018 12:28:27 +0100

x86/retpoline: Avoid retpolines for built-in __init functions

There's no point in building init code with retpolines, since it runs before
any potentially hostile userspace does. And before the retpoline is actually
ALTERNATIVEd into place, for much of it.

Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Cc: karah...@amazon.de
Cc: pet...@infradead.org
Cc: b...@alien8.de
Link: 
https://lkml.kernel.org/r/1517484441-1420-2-git-send-email-d...@amazon.co.uk

---
 include/linux/init.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index ea1b311..506a981 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -5,6 +5,13 @@
 #include 
 #include 
 
+/* Built-in __init functions needn't be compiled with retpoline */
+#if defined(RETPOLINE) && !defined(MODULE)
+#define __noretpoline __attribute__((indirect_branch("keep")))
+#else
+#define __noretpoline
+#endif
+
 /* These macros are used to mark some functions or 
  * initialized data (doesn't apply to uninitialized data)
  * as `initialization' functions. The kernel can take this
@@ -40,7 +47,7 @@
 
 /* These are for everybody (although not all archs will actually
discard it in modules) */
-#define __init __section(.init.text) __cold  __latent_entropy
+#define __init __section(.init.text) __cold  __latent_entropy 
__noretpoline
 #define __initdata __section(.init.data)
 #define __initconst__section(.init.rodata)
 #define __exitdata __section(.exit.data)

[tip:x86/pti] x86/spectre: Simplify spectre_v2 command line parsing

[tip-bot for KarimAllah Ahmed]

Commit-ID:  9005c6834c0ffdfe46afa76656bd9276cca864f6
Gitweb: https://git.kernel.org/tip/9005c6834c0ffdfe46afa76656bd9276cca864f6
Author: KarimAllah Ahmed 
AuthorDate: Thu, 1 Feb 2018 11:27:21 +
Committer:  Thomas Gleixner 
CommitDate: Fri, 2 Feb 2018 12:28:27 +0100

x86/spectre: Simplify spectre_v2 command line parsing

[dwmw2: Use ARRAY_SIZE]

Signed-off-by: KarimAllah Ahmed 
Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Cc: pet...@infradead.org
Cc: b...@alien8.de
Link: 
https://lkml.kernel.org/r/1517484441-1420-3-git-send-email-d...@amazon.co.uk

---
 arch/x86/kernel/cpu/bugs.c | 86 ++
 1 file changed, 56 insertions(+), 30 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index dd3a3cc..71949bf 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -119,13 +119,13 @@ static inline const char *spectre_v2_module_string(void) 
{ return ""; }
 static void __init spec2_print_if_insecure(const char *reason)
 {
if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
-   pr_info("%s\n", reason);
+   pr_info("%s selected on command line.\n", reason);
 }
 
 static void __init spec2_print_if_secure(const char *reason)
 {
if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
-   pr_info("%s\n", reason);
+   pr_info("%s selected on command line.\n", reason);
 }
 
 static inline bool retp_compiler(void)
@@ -140,42 +140,68 @@ static inline bool match_option(const char *arg, int 
arglen, const char *opt)
return len == arglen && !strncmp(arg, opt, len);
 }
 
+static const struct {
+   const char *option;
+   enum spectre_v2_mitigation_cmd cmd;
+   bool secure;
+} mitigation_options[] = {
+   { "off",   SPECTRE_V2_CMD_NONE,  false },
+   { "on",SPECTRE_V2_CMD_FORCE, true },
+   { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
+   { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
+   { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
+   { "auto",  SPECTRE_V2_CMD_AUTO,  false },
+};
+
 static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 {
char arg[20];
-   int ret;
-
-   ret = cmdline_find_option(boot_command_line, "spectre_v2", arg,
- sizeof(arg));
-   if (ret > 0)  {
-   if (match_option(arg, ret, "off")) {
-   goto disable;
-   } else if (match_option(arg, ret, "on")) {
-   spec2_print_if_secure("force enabled on command line.");
-   return SPECTRE_V2_CMD_FORCE;
-   } else if (match_option(arg, ret, "retpoline")) {
-   spec2_print_if_insecure("retpoline selected on command 
line.");
-   return SPECTRE_V2_CMD_RETPOLINE;
-   } else if (match_option(arg, ret, "retpoline,amd")) {
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
-   pr_err("retpoline,amd selected but CPU is not 
AMD. Switching to AUTO select\n");
-   return SPECTRE_V2_CMD_AUTO;
-   }
-   spec2_print_if_insecure("AMD retpoline selected on 
command line.");
-   return SPECTRE_V2_CMD_RETPOLINE_AMD;
-   } else if (match_option(arg, ret, "retpoline,generic")) {
-   spec2_print_if_insecure("generic retpoline selected on 
command line.");
-   return SPECTRE_V2_CMD_RETPOLINE_GENERIC;
-   } else if (match_option(arg, ret, "auto")) {
+   int ret, i;
+   enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
+
+   if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
+   return SPECTRE_V2_CMD_NONE;
+   else {
+   ret = cmdline_find_option(boot_command_line, "spectre_v2", arg,
+ sizeof(arg));
+   if (ret < 0)
+   return SPECTRE_V2_CMD_AUTO;
+
+   for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
+   if (!match_option(arg, ret, 
mitigation_options[i].option))
+   continue;
+   cmd = mitigation_options[i].cmd;
+   break;
+   }
+
+   if (i >= ARRAY_SIZE(mitigation_options)) {
+   pr_err("unknown option (%s). Switching to AUTO 
select\n",
+  mitigation_options[i].option);
return SPECTRE_V2_CMD_AUTO;
}
}
 
-   if (!cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
+   if ((cmd == SPECTRE_V2_CMD_RETPOLINE ||
+cmd == SPECTRE_V2_CMD_RETPOLINE_AMD ||
+  

RE: r8169 take too long to complete driver initialization

[Hau]

> -Original Message-
> From: Chris Chiu [mailto:c...@endlessm.com]
> Sent: Friday, February 2, 2018 10:03 AM
> To: Hau 
> Cc: nic_swsd ; net...@vger.kernel.org; Linux
> Kernel ; Linux Upstreaming Team
> 
> Subject: Re: r8169 take too long to complete driver initialization
> 
> On Tue, Jan 30, 2018 at 8:07 PM, Chris Chiu  wrote:
> > On Mon, Jan 29, 2018 at 11:24 PM, Hau  wrote:
> >> Hi Chris,
> >>
> >> Could you test following patch?
> >>
> >>  DECLARE_RTL_COND(rtl_ocp_tx_cond)
> >>  {
> >> void __iomem *ioaddr = tp->mmio_addr;
> >>
> >> -   return RTL_R8(IBISR0) & 0x02;
> >> +   return RTL_R8(IBISR0) & 0x20;
> >>  }
> >>
> >>  static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)  {
> >> void __iomem *ioaddr = tp->mmio_addr;
> >>
> >> RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
> >> -   rtl_msleep_loop_wait_low(tp, _ocp_tx_cond, 50, 2000);
> >> +   rtl_msleep_loop_wait_high(tp, _ocp_tx_cond, 50, 2000);
> >> RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
> >> RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);  }
> >>
> >> Thanks.
> >>
> >
> > Yes. It completes the initialization in 70 ms. So it means the
> > rtl_ocp_tx_cond are waiting for incorrect register bit? Can you help work
> out a patch for this?
> >
> > Chris
> >
> >
> 
> Gentle ping,
> cheers.
> 
> Chris
> 

I have submitted the patch to kernel team.
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=086ca23d03c0d2f4088f472386778d293e15c5f6


--Please consider the environment before printing this e-mail.

> >>> -Original Message-
> >>> From: Chris Chiu [mailto:c...@endlessm.com]
> >>> Sent: Monday, January 29, 2018 6:12 PM
> >>> To: nic_swsd ; net...@vger.kernel.org; Linux
> >>> Kernel ; Linux Upstreaming Team
> >>> 
> >>> Subject: Re: r8169 take too long to complete driver initialization
> >>>
> >>> On Fri, Jan 5, 2018 at 10:17 AM, Chris Chiu  wrote:
> >>> > On Wed, Dec 20, 2017 at 4:41 PM, Chris Chiu 
> wrote:
> >>> >> Hi,
> >>> >> We've hit a suspend/resume issue on a Acer desktop caused by
> >>> >> r8169 driver. The dmseg
> >>> >>
> https://gist.github.com/mschiu77/b741849b5070281daaead8dfee312d1a
> >>> >> shows it's still in msleep() within a mutex lock.
> >>> >> After looking into the code, it's caused by the
> >>> >> rtl8168ep_stop_cmac() which is waiting 100 seconds for
> >>> >> rtl_ocp_tx_cond. The following dmesg states that the r8169 driver
> >>> >> is loaded.
> >>> >>
> >>> >> [   20.270526] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> >>> >>
> >>> >> But it takes > 100 seconds to get the following messages
> >>> >>
> >>> >> [  140.400223] r8169 :02:00.0 (unnamed net_device)
> >>> >> (uninitialized): rtl_ocp_tx_cond == 1 (loop: 2000, delay: 50).
> >>> >> [  140.413294] r8169 :02:00.0 eth0: RTL8168ep/8111ep at
> >>> >> 0xb16c80db1000, f8:0f:41:ea:74:0d, XID 10200800 IRQ 46 [
> >>> >> 140.413297] r8169 :02:00.0 eth0: jumbo features [frames: 9200
> >>> >> bytes, tx checksumming: ko]
> >>> >>
> >>> >> So any trial to suspend the machine during this period would
> >>> >> always get device/resource busy message then abort. Is this
> >>> >> rtl_ocp_tx_cond necessary? Because the ethernet is still working
> >>> >> and I don't see any problem. I don't know it should be considered
> >>> >> normal or not. Please let me know if any more information
> >>> >> required. Thanks
> >>> >>
> >>> >> Chris
> >>> >
> >>> > gentle ping,
> >>> >
> >>> > cheers.
> >>>
> >>> Hi,
> >>> Just found a r8168 driver which seems to be authrized by realtek
> >>> for cross comparison. I tried applying the patch to latest 4.15
> >>> kernel and the driver done it's initialization in faily short time. The 
> >>> patch
> file is here
> >>> https://gist.github.com/mschiu77/fcf406e64a1a437f46cf2be643f1057d.
> >>>
> >>> In mainline r8169.c, the IBISR0 register need to be polled in
> >>> the rtl8168ep_stop_cmac().
> >>> In the patch file, there's also the same IBISR0 polling code in
> >>> Dash2DisableTx(), but it's been bypassed since the chipset maches
> >>> HW_DASH_SUPPORT_TYPE_2.
> >>> Per the rtl_chip_info[] in r8168_n.c, CFG_METHOD_23/27/28 are
> >>> HW_DASH_SUPPORT_TYPE_2, and they happens to be the only 3 named
> >>> RTL8168EP/8111EP in the rtl_chip_info[].
> >>>
> >>> To find the same matches in r8169.c, RTL_GIGA_MAC_VER_49/50/51
> >>> seems share the same config. Can anyone clarify if the
> >>> rtl_ocp_tx_cond() really necessary for 8168EP/8111EP?
> >>> Or we can just ignore the condition check for
> RTL_GIGA_MAC_VER_49/50/51?
> >>>
> >>> Chris
> >>>
> >>> --Please consider the environment before printing this e-mail.

Re: Query related to usage of cpufreq_suspend() & cpufreq_resume

[Rafael J. Wysocki]

On Friday, February 2, 2018 12:41:58 PM CET Prateek Sood wrote:
> Hi Viresh,
> 
> One scenario is there where a kernel panic is observed in
> cpufreq during suspend/resume.
> 
> pm_suspend()
>   suspend_devices_and_enter()
> dpm_suspend_start()
>   dpm_prepare() 
> 
> Failure in dpm_prepare() happend with following dmesg:
> 
> [ 3746.316062] PM: Device xyz not prepared for power transition: code -16
> [ 3746.316071] PM: Some devices failed to suspend, or early wake event 
> detected
> 
> 
> pm_suspend()
>   suspend_devices_and_enter()
> dpm_suspend_start()
>   dpm_prepare() //failed
> dpm_resume_end()
>   dpm_resume()
> cpufreq_resume()
>   cpufreq_start_governor()
> sugov_start()
>   cpufreq_add_update_util_hook()
> 
> After failure in dpm_prepare(), dpm_resume() called
> cpufreq_resume(). Corresponding cpufreq_suspend() was not
> called due to failure of dpm_prepare(). 
> 
> This resulted in WARN_ON(per_cpu(cpufreq_update_util_data, cpu))
> in cpufreq_add_update_util_hook() and cpufreq_add_update_util_hook->func
> being inconsistent state. It caused crash in scheduler.
> 
> Following are some of the ways to mitigate this issue. Could
> you please provide feedback on below two approaches or suugest
> a better way to fix this problem.
> 
> ---8<--
> 
> Co-developed-by: Gaurav Kohli 
> Signed-off-by: Gaurav Kohli  
> Signed-off-by: Prateek Sood 
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 02a497e..732e5a2 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1038,6 +1038,7 @@ void dpm_resume(pm_message_t state)
>  {
> struct device *dev;
> ktime_t starttime = ktime_get();
> +   bool valid_resume = false;
> 
> trace_suspend_resume(TPS("dpm_resume"), state.event, true);
> might_sleep();
> @@ -1055,6 +1056,7 @@ void dpm_resume(pm_message_t state)
> }
> 
> while (!list_empty(_suspended_list)) {
> +   valid_resume = true;
> dev = to_device(dpm_suspended_list.next);
> get_device(dev);
> if (!is_async(dev)) {
> @@ -1080,7 +1082,8 @@ void dpm_resume(pm_message_t state)
> async_synchronize_full();
> dpm_show_time(starttime, state, 0, NULL);
> 
> -   cpufreq_resume();
> +   if (valid_resume)
> +   cpufreq_resume();
> trace_suspend_resume(TPS("dpm_resume"), state.event, false);
>  }
> 
> 8<--
> 
> Signed-off-by: Prateek Sood 
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 421f318..439eab8 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1648,7 +1648,7 @@ void cpufreq_suspend(void)
>  {
> struct cpufreq_policy *policy;
> 
> -   if (!cpufreq_driver)
> +   if (!cpufreq_driver || cpufreq_suspended)
> return;
> 
> if (!has_target() && !cpufreq_driver->suspend)
> @@ -1683,7 +1683,7 @@ void cpufreq_resume(void)
> struct cpufreq_policy *policy;
> int ret;
> 
> -   if (!cpufreq_driver)
> +   if (!cpufreq_driver || !cpufreq_suspended)
> return;
> 
> cpufreq_suspended = false;

Since we have cpufreq_suspended already, the second one is better.

Thanks,
Rafael

Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

[Hanjun Guo]

On 2018/2/2 18:25, Yang Shunyong wrote:
> Loading IORT table from initrd is used to fix firmware IORT defects.

I don't think this fix "firmware defects", it just for debug purpose,
we will not use that for production purpose, right? I think above line
can be removed.

> Moreover, it is very useful to debug SMMU node/device probe, MSI
> allocation, stream id translation and IORT table from firmware. It
> is also very useful to enable SMMU and devices behind SMMU before
> firmware is ready.
> 
> This patch adds ACPI_SIG_IORT to the table, which enables IORT
> from initrd to override which from firmware.
> 
> Signed-off-by: Yang Shunyong 
> Cc: Joey Zheng 
> Cc: Wang Dongsheng 
> Cc: Jiang Yutang 
> Cc: Hanjun Guo 

With that updated,

Acked-by: Hanjun Guo 

Thanks
Hanjun

Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended

[Rafael J. Wysocki]

On Wednesday, January 24, 2018 9:53:14 PM CET Bo Yan wrote:
> 
> On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote:
> > On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote:
> >>   drivers/cpufreq/cpufreq.c | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> index 41d148af7748..95b1c4afe14e 100644
> >> --- a/drivers/cpufreq/cpufreq.c
> >> +++ b/drivers/cpufreq/cpufreq.c
> >> @@ -1680,6 +1680,10 @@ void cpufreq_resume(void)
> >>if (!cpufreq_driver)
> >>return;
> >>   
> >> +  if (unlikely(!cpufreq_suspended)) {
> >> +  pr_warn("%s: resume after failing suspend\n", __func__);
> >> +  return;
> >> +  }
> >>cpufreq_suspended = false;
> >>   
> >>if (!has_target() && !cpufreq_driver->resume)
> >>
> > Good catch, but rather than doing this it would be better to avoid
> > calling cpufreq_resume() at all if cpufreq_suspend() has not been called.
> Yes, I thought about that, but there is no good way to skip over it 
> without introducing another flag. cpufreq_resume is called by 
> dpm_resume, cpufreq_suspend is called by dpm_suspend. In the failure 
> case, dpm_resume is called, but dpm_suspend is not. So on a higher level 
> it's already unbalanced.
> 
> One possibility is to rely on the pm_transition flag. So something like:
> 
> 
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index dc259d20c967..8469e6fc2b2c 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -842,6 +842,7 @@ static void async_resume(void *data, async_cookie_t 
> cookie)
>   void dpm_resume(pm_message_t state)
>   {
>  struct device *dev;
> +   bool suspended = (pm_transition.event != PM_EVENT_ON);
>  ktime_t starttime = ktime_get();
> 
>  trace_suspend_resume(TPS("dpm_resume"), state.event, true);
> @@ -885,7 +886,8 @@ void dpm_resume(pm_message_t state)
>  async_synchronize_full();
>  dpm_show_time(starttime, state, NULL);
> 
> -   cpufreq_resume();
> +   if (likely(suspended))
> +   cpufreq_resume();
>  trace_suspend_resume(TPS("dpm_resume"), state.event, false);
>   }

I was thinking about something else.

Anyway, I think your original patch is OK too, but without printing the
message.  Just combine the cpufreq_suspended check with the cpufreq_driver
one and the unlikely() thing is not necessary.

Thanks,
Rafael

Re: [PATCH 1/2] fbdev: don't select I2C directly

[Arnd Bergmann]

On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap  wrote:
> On 02/01/2018 08:14 AM, Bartlomiej Zolnierkiewicz wrote:
>> On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote:
>>> Using a Kconfig 'select' statement for a user-visible symbol that other
>>> drivers depend on often causes circular dependencies. A new one showed
>>> up when I wanted to add an NVMEM dependency to the DRM_MSM driver:
>>>
>>> drivers/i2c/Kconfig:7:error: recursive dependency detected!
>>> drivers/i2c/Kconfig:7:   symbol I2C is selected by FB_DDC
>>> drivers/video/fbdev/Kconfig:63:  symbol FB_DDC is selected by 
>>> FB_CYBER2000_DDC
>>> drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on 
>>> FB_CYBER2000
>>> drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB
>>> drivers/video/fbdev/Kconfig:5:   symbol FB is selected by 
>>> DRM_KMS_FB_HELPER
>>> drivers/gpu/drm/Kconfig:77:  symbol DRM_KMS_FB_HELPER depends on 
>>> DRM_KMS_HELPER
>>> drivers/gpu/drm/Kconfig:71:  symbol DRM_KMS_HELPER is selected by DRM_MSM
>>> drivers/gpu/drm/msm/Kconfig:2:   symbol DRM_MSM depends on NVMEM
>>> drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24
>>> drivers/misc/eeprom/Kconfig:3:   symbol EEPROM_AT24 depends on I2C
>>>
>>> Here, the problem is that many fbdev drivers have an i2c based interface
>>> and just 'select i2c' for that, while we also select the framebuffer
>>> subsystem indirectly from a DRM driver that now depends on i2c.
>>>
>>> This does away with the 'select' statement and instead uses 'depends on',
>>> like almost all I2C users.
>>
>> I worry that this change may cause various driver options to no longer
>> be visible to people configuring their kernels and not having I2C already
>> selected.
>>
>> DRM somehow manages to select I2C and I would prefer to be it the same
>> way for fbdev (also looking at the current next tree there are still
>> some drivers that 'select I2C')..
>
> a. Linus has stated that a driver should not enable an entire subsystem,
>so depends on would be better than select.
>If I had the email/patch, I would be glad to Ack it.
>
> b. DRM configuration is a mess. You shouldn't want to follow their model. :)

Right, that should also be fixed, so DRM no longer includes I2C ;-)

At the moment, DRM is the most common cause for circular dependencies
because it has a number of 'select' statements for symbols that otherwise
are used with 'depends on'. We should probably address the 'select I2C'
portion in there, but also some of the others like:

drivers/gpu/drm/Kconfig:select POWER_SUPPLY
drivers/gpu/drm/Kconfig:select HWMON
drivers/gpu/drm/Kconfig:select FB
drivers/gpu/drm/udl/Kconfig: select USB
drivers/gpu/drm/sti/Kconfig: select OF
drivers/gpu/drm/sti/Kconfig: select RESET_CONTROLLER
drivers/gpu/drm/etnaviv/Kconfig:select CMA if HAVE_DMA_CONTIGUOUS
drivers/gpu/drm/etnaviv/Kconfig:select TMPFS
drivers/gpu/drm/i915/Kconfig.debug:select DEBUG_FS
drivers/gpu/drm/i915/Kconfig.debug:select PREEMPT_COUNT
drivers/gpu/drm/i915/Kconfig.debug: select TRACING
drivers/gpu/drm/i915/Kconfig.debug: select FAULT_INJECTION
drivers/gpu/drm/mediatek/Kconfig:   select MEMORY
drivers/gpu/drm/mediatek/Kconfig:   select GENERIC_PHY
drivers/gpu/drm/msm/Kconfig:select REGULATOR

> c. If I2C is not enabled in the FB menu, someone could just add something 
> like this:
>
> comment "Enable I2C to see more driver choices"
> depends on !I2C

I don't think that would address the issue of 'defconfig' builds losing
I2C support when it's no longer automatically selection. On x86, this
is not an issue, as X86 always enables I2C. For the rest, we could
do a hack like this:

--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -8,6 +8,7 @@ config I2C
tristate "I2C support"
select RT_MUTEXES
select IRQ_DOMAIN
+   default DRM || FB
---help---
  I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
  many micro controller applications and developed by Philips.  SMBus,

which would let all 'defconfig' versions keep working. It's a bit ugly, but
at least wouldn't cause other circular dependencies.

 Arnd

Re: [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

[Rafael J. Wysocki]

On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko
 wrote:
> On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki  wrote:
>> On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
>>  wrote:
>>> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki  
>>> wrote:
 On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
  wrote:
>
>>> Instead of declaring function as __weak, establish a new struct for
>>> ACPI related stubs and incorporate it into x86_init.
>>>
>>> That is my proposal. I think I would go this way in my case where I
>>> need to treat differently ACPI HW reduced initialization of legacy
>>> devices.
>>
>> IOW you'd like to have a set of ACPI init callbacks that could be
>> defined by an arch, right?
>
> Correct!

OK

Re: Is the hisilicon tree maintained ?

[Daniel Lezcano]

On 02/02/2018 12:42, Wei Xu wrote:
> Hi Daniel,
> 
> On 2018/2/2 6:59, Daniel Lezcano wrote:
>>
>> Hi Wei Xu,
>>
>> I found in the MAINTAINERS file the hisilicon tree is at:
>>
>> https://github.com/hisilicon/linux-hisi
>>
>> But, (except I missed it) I didn't find any update since Nov, 2017.
>>
>> Is that tree maintained ?
> 
> Yes. It is still maintained.
> You can find update from other branches or the tags like next/dt64.
> I will update the master when every rc1 is released.

Is there a development branch for something else than the DT ?




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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFCv2 00/17] Request API, take three

[Sakari Ailus]

Hi Alexandre,

On Wed, Jan 31, 2018 at 07:24:18PM +0900, Alexandre Courbot wrote:
> This is a quickly-put together revision that includes and uses Hans' work to
> use v4l2_ctrl_handler as the request state holder for V4L2 devices. Although
> minor fixes have also been applied, there are still a few comments from the
> previous revision that are left unaddressed. I wanted to give Hans something
> to play with before he forgets what he had in mind for controls. ;)

Could you rebase this on the current media master, please?

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: Is the hisilicon tree maintained ?

[Wei Xu]

Hi Daniel,

On 2018/2/2 12:05, Daniel Lezcano wrote:
> On 02/02/2018 12:42, Wei Xu wrote:
>> Hi Daniel,
>>
>> On 2018/2/2 6:59, Daniel Lezcano wrote:
>>>
>>> Hi Wei Xu,
>>>
>>> I found in the MAINTAINERS file the hisilicon tree is at:
>>>
>>> https://github.com/hisilicon/linux-hisi
>>>
>>> But, (except I missed it) I didn't find any update since Nov, 2017.
>>>
>>> Is that tree maintained ?
>>
>> Yes. It is still maintained.
>> You can find update from other branches or the tags like next/dt64.
>> I will update the master when every rc1 is released.
> 
> Is there a development branch for something else than the DT ?

Sorry, no developing branch is there.
But we will create one if needed like the topic-acpi-mbigen branch.
And most of development branches are kept in another git repo.

Best Regards,
Wei

> 
> 
> 
> 

Re: Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

[Wang, Dongsheng]

Hey, Hanjun,

On 2018/2/2 19:54:24, "Hanjun Guo"  wrote:

>On 2018/2/2 18:25, Yang Shunyong wrote:
>>Loading IORT table from initrd is used to fix firmware IORT defects.
>
>I don't think this fix "firmware defects", it just for debug purpose,
>we will not use that for production purpose, right? I think above line
>can be removed.
>
I thinks the upgrade feature not only for debug. Here's an important
way to fix bugs that come from the firmware.

Documentation/acpi/initrd_table_override.txt


Cheers,
-Dongsheng

Re: [RFC][PATCH] printk: do not flush printk_safe from irq_work

[Petr Mladek]

On Thu 2018-02-01 11:46:47, Sergey Senozhatsky wrote:
> On (01/30/18 13:23), Petr Mladek wrote:
> [..]
> > > If the system is in "big troubles" then what makes irq_work more
> > > possible? Local IRQs can stay disabled, just like preemption. I
> > > guess when the troubles are really big our strategy is the same
> > > for both wq and irq_work solutions - we keep the printk_safe buffer
> > > and wait for panic()->flush.
> > 
> > But the patch still uses irq work because queue_work_on() could not
> > be safely called from printk_safe(). By other words, it requires
> > both irq_work and workqueues to be functional.
> 
> Right, that's all true. The reason it's done this way is because buffers can
> be big and we still flush under console_sem in console_unlock() loop, which
> can in theory be problematic. In other words, I wanted to remove the root
> cause - irq flush of printk_safe while we are still in printing
> loop.

Good point! We know that we would eventually push non-trivial amount
of messages and it would make sense to do it from non-atomic context.

On the other hand, this does not solve the same problem with printk
NMI buffer. And I guess that we do not want to risk offloading to
workqueues for NMI messages.


> > > I guess I'm OK with the wq dependency after all, but I may be mistaken.
> > > printk_safe was never about "immediately flush the buffer", it was about
> > > "avoid deadlocks", which was extended to "flush from any context which
> > > will let us to avoid deadlock". It just happened that it inherited
> > > irq_work dependency from printk_nmi.
> > 
> > I see the point. But if I remember correctly, it was also designed
> > before we started to be concerned about a sudden death and "get
> > printks out ASAP" mantra.
> 
> Can you elaborate a bit?

The pull request with printk_safe was sent on February 22, 2017, see
https://lkml.kernel.org/r/20170222114705.ga30...@linux.suse

The printk softlockup was still being solved by an immediate offload
from vprintk_emit() on March 29, 2017, see
https://lkml.kernel.org/r/20170329092511.3958-3-sergey.senozhat...@gmail.com

I believe that it was the mail from Pavel Machek that made us
thinking about the sudden death. It was sent on April 7, 2017,
see https://lkml.kernel.org/r/20170407120642.GB4756@amd

The first version with the offload from console_unlock was
sent on May 9, 2017, see
https://lkml.kernel.org/r/20170509082859.854-3-sergey.senozhat...@gmail.com

I am not exactly sure when the "get printks out ASAP" mantra started
but I cannot forget the mail from June 30, 2017, see
https://lkml.kernel.org/r/20170630070131.GA474@jagdpanzerIV.localdomain

Best Regards,
Petr

Re: Adjustments for a lot of function implementations

[SF Markus Elfring]

> One last time: either post per-driver patches with all the cleanups for a 
> driver
> in a single patch,

I preferred to offer source code adjustments according to specific 
transformation
patterns mostly for each software module separately (also in small patch 
series).


> or a per-directory patch (drivers/media/pci, usb, etc) doing the same cleanup
> for all drivers in that directory.

I am curious if bigger patch packages would be easier to get accepted.

Or would you get frightened still by any other change combination?



> I prefer the first approach,

We have got different preferences for a safe patch granularity.


> but it's up to you.

I imagine that there are more development factors involved.


> We don't have the time to wade through dozens of one-liner cleanup patches.

It is usual that integration of update suggestions will take some time.
How would the situation change if I would dare to regroup possible update steps?


> I don't understand what is so difficult about this.

There are communication difficulties to consider since your terse information
from your conference meeting.

If you would insist on patch squashing, would you dare to use a development tool
like “quilt fold” also on your own once more?

Regards,
Markus

[PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

_minor_ is being dereferenced before it is null checked, hence there
is a potential null pointer dereference. Fix this by moving the pointer
dereference after _minor_ has been null checked.

Fixes: 024ad8df763f ("drm/msm: add a5xx specific debugfs")
Signed-off-by: Gustavo A. R. Silva 
---

I wonder if a better solution for this would be to WARN_ON in case _minor_
happens to be NULL and return -EINVAL, instead of just returning zero.

Something like:

struct drm_device *dev;

if (WARN_ON(!minor)
return -EINVAL;

dev = minor->dev;

What do you think?

Thanks


 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c 
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index 6b27941..059ec7d 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -159,13 +159,15 @@ DEFINE_SIMPLE_ATTRIBUTE(reset_fops, NULL, reset_set, 
"%llx\n");
 
 int a5xx_debugfs_init(struct msm_gpu *gpu, struct drm_minor *minor)
 {
-   struct drm_device *dev = minor->dev;
+   struct drm_device *dev;
struct dentry *ent;
int ret;
 
if (!minor)
return 0;
 
+   dev = minor->dev;
+
ret = drm_debugfs_create_files(a5xx_debugfs_list,
ARRAY_SIZE(a5xx_debugfs_list),
minor->debugfs_root, minor);
-- 
2.7.4