Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted

[Christoph Hellwig]

On Tue, Sep 03, 2019 at 10:46:18PM +0200, Thomas Hellström (VMware) wrote:
> What I mean with "from an engineering perspective" is that drivers would end
> up with a non-trivial amount of code supporting purely academic cases:
> Setups where software rendering would be faster than gpu accelerated, and
> setups on platforms where the driver would never run anyway because the
> device would never be supported on that platform...

And actually work on cases you previously called academic and which now
matter to you because your employer has a suddent interest in SEV.
Academic really is in the eye of the beholder (and of those who pay
the bills).

> That is not really true. The dma API can't handle faulting of coherent pages
> which is what this series is really all about supporting also with SEV
> active. To handle the case where we move graphics buffers or send them to
> swap space while user-space have them mapped.

And the only thing we need to support the fault handler is to add an
offset to the dma_mmap_* APIs.  Which I had planned to do for Christian
(one of the few grapics developers who actually tries to play well
with the rest of the kernel instead of piling hacks over hacks like
many others) anyway, but which hasn't happened yet.

> Still, I need a way forward and my questions weren't really answered by
> this.

This is pretty demanding.  If you "need" a way forward just work with
all the relevant people instead of piling ob local hacks.

linux-next: manual merge of the amdgpu tree with the kbuild tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/display/dc/dml/Makefile

between commit:

  30851871d5ab ("kbuild: change *FLAGS_.o to take the path relative 
to $(obj)")

from the kbuild tree and commit:

  b04641a3f4c5 ("drm/amd/display: Add Renoir DML")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/display/dc/dml/Makefile
index 289261b0de50,af2a864a6da0..
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@@ -36,16 -36,25 +36,20 @@@ ifdef CONFIG_CC_IS_CLAN
  dml_ccflags += -msse2
  endif
  
 -CFLAGS_display_mode_lib.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
  
  ifdef CONFIG_DRM_AMD_DC_DCN2_0
 -CFLAGS_display_mode_vba.o := $(dml_ccflags)
 -CFLAGS_display_mode_vba_20.o := $(dml_ccflags)
 -CFLAGS_display_rq_dlg_calc_20.o := $(dml_ccflags)
 -CFLAGS_display_mode_vba_20v2.o := $(dml_ccflags)
 -CFLAGS_display_rq_dlg_calc_20v2.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
  endif
+ ifdef CONFIG_DRM_AMD_DC_DCN2_1
 -CFLAGS_display_mode_vba_21.o := $(dml_ccflags)
 -CFLAGS_display_rq_dlg_calc_21.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
++CFLAGS_$(AMDDALPATH)dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
+ endif
 -ifdef CONFIG_DRM_AMD_DCN3AG
 -CFLAGS_display_mode_vba_3ag.o := $(dml_ccflags)
 -endif
 -CFLAGS_dml1_display_rq_dlg_calc.o := $(dml_ccflags)
 -CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
 -CFLAGS_dml_common_defs.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/dml1_display_rq_dlg_calc.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/display_rq_dlg_helpers.o := $(dml_ccflags)
 +CFLAGS_$(AMDDALPATH)/dc/dml/dml_common_defs.o := $(dml_ccflags)
  
  DML = display_mode_lib.o display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
dml_common_defs.o


pgph_mWTopGqq.pgp
Description: OpenPGP digital signature

[PATCH 2/2] mm/page_owner: determine the last stack state of page with CONFIG_KASAN_DUMP_PAGE=y

[Walter Wu]

When enable CONFIG_KASAN_DUMP_PAGE, then page_owner will record last stack,
So we need to know the last stack is allocation or free state.

Signed-off-by: Walter Wu 
---
 mm/page_owner.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/page_owner.c b/mm/page_owner.c
index addcbb2ae4e4..2756adca250e 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -418,6 +418,12 @@ void __dump_page_owner(struct page *page)
nr_entries = stack_depot_fetch(handle, &entries);
pr_alert("page allocated via order %u, migratetype %s, gfp_mask 
%#x(%pGg)\n",
 page_owner->order, migratetype_names[mt], gfp_mask, &gfp_mask);
+#ifdef CONFIG_KASAN_DUMP_PAGE
+   if ((unsigned long)page->flags & PAGE_FLAGS_CHECK_AT_PREP)
+   pr_info("Allocation stack of page:\n");
+   else
+   pr_info("Free stack of page:\n");
+#endif
stack_trace_print(entries, nr_entries, 0);
 
if (page_owner->last_migrate_reason != -1)
-- 
2.18.0

Re: [PATCH 1/4] gpio/aspeed: Fix incorrect number of banks

[Bartosz Golaszewski]

śr., 4 wrz 2019 o 08:13 Rashmica Gupta  napisał(a):
>
> Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
>

Please, add a proper commit description. Checkpatch should have warned
you about it.

Bart

> Signed-off-by: Rashmica Gupta 
> ---
>  drivers/gpio/gpio-aspeed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 9defe25d4721..77752b2624e8 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct 
> platform_device *pdev)
> gpio->chip.base = -1;
>
> /* Allocate a cache of the output registers */
> -   banks = gpio->config->nr_gpios >> 5;
> +   banks = (gpio->config->nr_gpios >> 5) + 1;
> gpio->dcache = devm_kcalloc(&pdev->dev,
> banks, sizeof(u32), GFP_KERNEL);
> if (!gpio->dcache)
> --
> 2.20.1
>

RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode

[Kobayashi, Kento (Sony)]

Hi,

>> Hi,
>>
>> My company's member, Mr.Jacky, sent patch in June 26th.
>> But we didn't receive comment about our patch.
>> Could you confirm and tell us this patch is needed or not?
>
>I can't find the original patch in my inbox, could you resend it using git 
>send-email?
>
>Patch seems necessary, indeed.
>
>best regards
>
>--
>balbi

Thank you for replying.
My company member, Mr.Jacky(jacky@sony.com) sent again patch at Sep. 4th 
15:48(JST).
So could you confirm?
And in our environment,we can't send mail by git send mail.
So he sent by another mail application.

Regards,
Kento Kobayashi 

-Original Message-
From: Felipe Balbi  
Sent: Wednesday, September 4, 2019 3:20 PM
To: Kobayashi, Kento (Sony) ; 
gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Cao, Jacky 

Subject: RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode


Hi,

"Kobayashi, Kento (Sony)"  writes:

> Hi,
>
> My company's member, Mr.Jacky, sent patch in June 26th.
> But we didn't receive comment about our patch.
> Could you confirm and tell us this patch is needed or not?

I can't find the original patch in my inbox, could you resend it using git 
send-email?

Patch seems necessary, indeed.

best regards

--
balbi

Re: [PATCH 2/2] sched/debug: add sched_update_nr_running tracepoint

[chengjian (D)]

On 2019/9/4 0:05, Valentin Schneider wrote:

On 03/09/2019 16:43, Radim Krčmář wrote:

The paper "The Linux Scheduler: a Decade of Wasted Cores" used several
custom data gathering points to better understand what was going on in
the scheduler.
Red Hat adapted one of them for the tracepoint framework and created a
tool to plot a heatmap of nr_running, where the sched_update_nr_running
tracepoint is being used for fine grained monitoring of scheduling
imbalance.
The tool is available from https://github.com/jirvoz/plot-nr-running.

The best place for the tracepoints is inside the add/sub_nr_running,
which requires some shenanigans to make it work as they are defined
inside sched.h.
The tracepoints have to be included from sched.h, which means that
CREATE_TRACE_POINTS has to be defined for the whole header and this
might cause problems if tree-wide headers expose tracepoints in sched.h
dependencies, but I'd argue it's the other side's misuse of tracepoints.

Moving the import sched.h line lower would require fixes in s390 and ppc
headers, because they don't include dependecies properly and expect
sched.h to do it, so it is simpler to keep sched.h there and
preventively undefine CREATE_TRACE_POINTS right after.

Exports of the pelt tracepoints remain because they don't need to be
protected by CREATE_TRACE_POINTS and moving them closer would be
unsightly.


Pure trace events are frowned upon in scheduler world, try going with
trace points. Qais did something very similar recently:

https://lore.kernel.org/lkml/20190604111459.2862-1-qais.you...@arm.com/

You'll have to implement the associated trace events in a module, which
lets you define your own event format and doesn't form an ABI :).

.



Hi Radim,


Why not try Chrome Tracing

1--Record trace data, scheduling, irq, etc.
    You can Produce a JSON file with the format expected by Chrome
    OR
    just save the captured data directly as "xxx.html", it can still work.
    cat /sys/kernel/debug/tracing/trace > trace.html
2--Go to chrome://tracing in Chrome,
3--Click "Load" and open your file, or alternatively drag the file into 
Chrome,

4--Profit!


Systrace (Android System Trace) captures and displays execution times of 
your app's
processes and other Android system processes, fortunately, there are 
some ported

versions for Linux Desktop/Server.

https://github.com/gatieme/systrace



references--
https://www.chromium.org/developers/how-tos/trace-event-profiling-tool
https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/trace-event-reading


Thanks,
    - Cheng Jian.

Re: Re: Re: Re: [PATCH] mm: Add nr_free_highatomimic to fix incorrect watermatk routine

[Park Sangwoo]

> On Tue 03-09-19 18:59:59, Park Sangwoo wrote:
> > On Mon 02-09-19 13:34:54, Sangwoo� wrote:
> >>> On Fri 30-08-19 18:25:53, Sangwoo wrote:
>  The highatomic migrate block can be increased to 1% of Total memory.
>  And, this is for only highorder ( > 0 order). So, this block size is
>  excepted during check watermark if allocation type isn't alloc_harder.
> 
>  It has problem. The usage of highatomic is already calculated at
> >>> NR_FREE_PAGES.
> > So, if we except total block size of highatomic, it's twice minus size 
> > of
> >>> allocated
> > highatomic.
> > It's cause allocation fail although free pages enough.
> >
> > We checked this by random test on my target(8GB RAM).
> >
> >  Binder:6218_2: page allocation failure: order:0, mode:0x14200ca
> >>> (GFP_HIGHUSER_MOVABLE), nodemask=(null)
> >  Binder:6218_2 cpuset=background mems_allowed=0
> 
>  How come this order-0 sleepable allocation fails? The upstream kernel
>  doesn't fail those allocations unless the process context is killed by
>  the oom killer.
> >>> 
> >>> Most calltacks are zsmalloc, as shown below.
> >>
> >> What makes those allocations special so that they fail unlike any other
> >> normal order-0 requests? Also do you see the same problem with the
> >> current upstream kernel? Is it possible this is an Android specific
> >> issue?
> >
> > There is the other case of fail order-0 fail.
> > 
> > hvdcp_opti: page allocation failure: order:0, 
> > mode:0x1004000(GFP_NOWAIT|__GFP_COMP), nodemask=(null)
> 
> This is an atomic allocation and failing that one is not a problem
> usually. High atomic reservations might prevent GFP_NOWAIT allocation
> from suceeding but I do not see that as a problem. This is the primary
> purpose of the reservation. 

Thanks, your answer helped me. However, my suggestion is not to modify the use 
and management of the high atomic region,
but to calculate the exact free size of the highatomic so that fail does not 
occur for previously shared cases.

In __zone_water_mark_ok(...) func, if it is not atomic allocation, high atomic 
size is excluded.

bool __zone_watermark_ok(struct zone *z,
...
{
...
if (likely(!alloc_harder)) {
free_pages -= z->nr_reserved_highatomic;
...
}

However, free_page excludes the size already allocated by hiahtomic.
If highatomic block is small(Under 4GB RAM), it could be no problem.
But, the larger the memory size, the greater the chance of problems.
(Becasue highatomic size can be increased up to 1% of memory)

> [...]
> > In my test, most case are using camera. So, memory usage is increased 
> > momentarily,
> > it cause free page go to under low value of watermark.
> > If free page is under low and 0-order fail is occured, its normal operation.
> > But, although free page is higher than min, fail is occurred.
> > After fix routin for checking highatomic size, it's not reproduced.
> 
> But you are stealing from the atomic reserves and thus defeating the
> purpose of it.

Re: [PATCH] net/skbuff: silence warnings under memory pressure

[Michal Hocko]

On Wed 04-09-19 15:41:44, Sergey Senozhatsky wrote:
> On (09/04/19 08:15), Michal Hocko wrote:
> > > If you look at the original report, the failed allocation dump_stack() is,
> > > 
> > >  
> > >  warn_alloc.cold.43+0x8a/0x148
> > >  __alloc_pages_nodemask+0x1a5c/0x1bb0
> > >  alloc_pages_current+0x9c/0x110
> > >  allocate_slab+0x34a/0x11f0
> > >  new_slab+0x46/0x70
> > >  ___slab_alloc+0x604/0x950
> > >  __slab_alloc+0x12/0x20
> > >  kmem_cache_alloc+0x32a/0x400
> > >  __build_skb+0x23/0x60
> > >  build_skb+0x1a/0xb0
> > >  igb_clean_rx_irq+0xafc/0x1010 [igb]
> > >  igb_poll+0x4bb/0xe30 [igb]
> > >  net_rx_action+0x244/0x7a0
> > >  __do_softirq+0x1a0/0x60a
> > >  irq_exit+0xb5/0xd0
> > >  do_IRQ+0x81/0x170
> > >  common_interrupt+0xf/0xf
> > >  
> > > 
> > > Since it has no __GFP_NOWARN to begin with, it will call,
> 
> I think that DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST
> are good when we ratelimit just a single printk() call, so the ratelimit
> is "max 10 kernel log lines in 5 seconds".

I am sorry, I could have been more explicit when CCing you. Sure the
ratelimit is part of the problem. But I was more interested in the
potential livelock (infinite loop) mentioned by Qian Cai. It is not
important whether we generate one or more lines of output from the
softirq context as long as the printk generates more irq processing
which might end up doing the same. Is this really possible?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q

[Marco Felsch]

Hi Robin,

thanks for the patch it looks quite good, just two minor nitpicks.

On 19-09-04 06:23, Robin van der Gracht wrote:
> The first generation i.MX6 processors does not send an interrupt when the
> power key is pressed. It sends a power down request interrupt if the key is
> released before a hard shutdown (5 second press). This should allow
> software to bring down the SoC safely.
> 
> For this driver to work as a regular power key with the older SoCs, we need
> to send a keypress AND release when we get the power down request irq.
> 
> Signed-off-by: Robin van der Gracht 
> ---
> 
> Changes v2 -> v3:
>  - Drop alt compatible string for identifying first revision snvs hardware,
>read minor revision from register instead.
>  - Drop imx6qdl.dtsi modification and device-tree binding documentation.
>  - Add an additional input_sync() to create 2 seperate input reports for press
>and release.
> 
>  drivers/input/keyboard/Kconfig   |  2 +-
>  drivers/input/keyboard/snvs_pwrkey.c | 28 ++--
>  2 files changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 7c4f19dab34f..937e58da5ce1 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
>   depends on OF
>   help
> This is the snvs powerkey driver for the Freescale i.MX application
> -   processors that are newer than i.MX6 SX.
> +   processors.
>  
> To compile this driver as a module, choose M here; the
> module will be called snvs_pwrkey.
> diff --git a/drivers/input/keyboard/snvs_pwrkey.c 
> b/drivers/input/keyboard/snvs_pwrkey.c
> index 5342d8d45f81..828580eee0d2 100644
> --- a/drivers/input/keyboard/snvs_pwrkey.c
> +++ b/drivers/input/keyboard/snvs_pwrkey.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  
> +#define SNVS_HPVIDR1_REG 0xF8
>  #define SNVS_LPSR_REG0x4C/* LP Status Register */
>  #define SNVS_LPCR_REG0x38/* LP Control Register */
>  #define SNVS_HPSR_REG0x14
> @@ -37,6 +38,7 @@ struct pwrkey_drv_data {
>   int wakeup;
>   struct timer_list check_timer;
>   struct input_dev *input;
> + u8 minor_rev;
>  };
>  
>  static void imx_imx_snvs_check_for_events(struct timer_list *t)
> @@ -45,6 +47,20 @@ static void imx_imx_snvs_check_for_events(struct 
> timer_list *t)
>   struct input_dev *input = pdata->input;
>   u32 state;
>  
> + if (pdata->minor_rev == 0) {

Should we use a define here and ..

> + /*
> +  * The first generation i.MX6 SoCs only sends an interrupt on
> +  * button release. To mimic power-key usage, we'll prepend a
> +  * press event.
> +  */
> + input_report_key(input, pdata->keycode, 1);
> + input_sync(input);
> + input_report_key(input, pdata->keycode, 0);
> + input_sync(input);
> + pm_relax(input->dev.parent);
> + return;
> + }
> +
>   regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
>   state = state & SNVS_HPSR_BTN ? 1 : 0;
>  
> @@ -67,13 +83,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, 
> void *dev_id)
>  {
>   struct platform_device *pdev = dev_id;
>   struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> + unsigned long expire = jiffies;
>   u32 lp_status;
>  
>   pm_wakeup_event(pdata->input->dev.parent, 0);
>  
>   regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> - if (lp_status & SNVS_LPSR_SPO)
> - mod_timer(&pdata->check_timer, jiffies + 
> msecs_to_jiffies(DEBOUNCE_TIME));
> + if (lp_status & SNVS_LPSR_SPO) {
> + if (pdata->minor_rev > 0)

here? Just a nitpick, feel free to add/drop it.

> + expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
> + mod_timer(&pdata->check_timer, expire);
> + }
>  
>   /* clear SPO status */
>   regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
> @@ -94,6 +114,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device 
> *pdev)
>   struct input_dev *input = NULL;
>   struct device_node *np;
>   int error;
> + u32 vid;
>  
>   /* Get SNVS register Page */
>   np = pdev->dev.of_node;
> @@ -123,6 +144,9 @@ static int imx_snvs_pwrkey_probe(struct platform_device 
> *pdev)
>   return -EINVAL;
>   }
>  
> + regmap_read(pdata->snvs, SNVS_HPVIDR1_REG, &vid);

Should we check the return val here?

Regards,
  Marco

> + pdata->minor_rev = vid & 0xff;
> +
>   regmap_update_bits(pdata->snvs, SNVS_LPCR_REG, SNVS_LPCR_DEP_EN, 
> SNVS_LPCR_DEP_EN);
>  
>   /* clear the unexpected interrupt before driver ready */
> -- 
> 2.20.1
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.

Re: [PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops

[Christoph Hellwig]

On Tue, Sep 03, 2019 at 11:58:49AM -0700, Mike Travis wrote:
> Those ifdefs are not dead code and are being actively used.  Plus UV1
> support is dead and I think the last running system died about a year ago
> and no support or parts are available.  So undef'ing these macros will
> simplify and reduce the size of the object code.

I'm not complaining about removing some ifdefs, that is always good.
I complain about keeping the others that are dead.  And if Hub 1 is
dead please drop all the checks and support code for it.

A patch against current mainline to show what I mean is below.

---
>From e84506399fa9436d47b33491d3e38e9dc3c718c7 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig 
Date: Tue, 3 Sep 2019 18:05:37 +0200
Subject: x86/uv: Remove the dead UV?_HUB_IS_SUPPORTED defines

These are always set, so remove them and the dead code for the case
where they are not defined.

Signed-off-by: Christoph Hellwig 
---
 arch/x86/include/asm/uv/uv_hub.h  | 38 ---
 arch/x86/include/asm/uv/uv_mmrs.h |  7 --
 2 files changed, 45 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 6eed0b379412..f71eb659f0de 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -229,68 +229,33 @@ static inline struct uv_hub_info_s *uv_cpu_hub_info(int 
cpu)
 #define UV4_HUB_REVISION_BASE  7
 #define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
-#ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
 {
return uv_hub_info->hub_revision < UV2_HUB_REVISION_BASE;
 }
-#else
-static inline int is_uv1_hub(void)
-{
-   return 0;
-}
-#endif
 
-#ifdef UV2_HUB_IS_SUPPORTED
 static inline int is_uv2_hub(void)
 {
return ((uv_hub_info->hub_revision >= UV2_HUB_REVISION_BASE) &&
(uv_hub_info->hub_revision < UV3_HUB_REVISION_BASE));
 }
-#else
-static inline int is_uv2_hub(void)
-{
-   return 0;
-}
-#endif
 
-#ifdef UV3_HUB_IS_SUPPORTED
 static inline int is_uv3_hub(void)
 {
return ((uv_hub_info->hub_revision >= UV3_HUB_REVISION_BASE) &&
(uv_hub_info->hub_revision < UV4_HUB_REVISION_BASE));
 }
-#else
-static inline int is_uv3_hub(void)
-{
-   return 0;
-}
-#endif
 
 /* First test "is UV4A", then "is UV4" */
-#ifdef UV4A_HUB_IS_SUPPORTED
 static inline int is_uv4a_hub(void)
 {
return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
 }
-#else
-static inline int is_uv4a_hub(void)
-{
-   return 0;
-}
-#endif
 
-#ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
return uv_hub_info->hub_revision >= UV4_HUB_REVISION_BASE;
 }
-#else
-static inline int is_uv4_hub(void)
-{
-   return 0;
-}
-#endif
 
 static inline int is_uvx_hub(void)
 {
@@ -302,10 +267,7 @@ static inline int is_uvx_hub(void)
 
 static inline int is_uv_hub(void)
 {
-#ifdef UV1_HUB_IS_SUPPORTED
return uv_hub_info->hub_revision;
-#endif
-   return is_uvx_hub();
 }
 
 union uvh_apicid {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 62c79e26a59a..9ee5ed6e8b34 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,13 +99,6 @@
 #define UV3_HUB_PART_NUMBER_X  0x4321
 #define UV4_HUB_PART_NUMBER0x99a1
 
-/* Compat: Indicate which UV Hubs are supported. */
-#define UV1_HUB_IS_SUPPORTED   1
-#define UV2_HUB_IS_SUPPORTED   1
-#define UV3_HUB_IS_SUPPORTED   1
-#define UV4_HUB_IS_SUPPORTED   1
-#define UV4A_HUB_IS_SUPPORTED  1
-
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
 
-- 
2.20.1

[PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator

[Walter Wu]

This patch is KASAN report adds the alloc/free stacks for page allocator
in order to help programmer to see memory corruption caused by page.

By default, KASAN doesn't record alloc/free stack for page allocator.
It is difficult to fix up page use-after-free issue.

This feature depends on page owner to record the last stack of pages.
It is very helpful for solving the page use-after-free or out-of-bound.

KASAN report will show the last stack of page, it may be:
a) If page is in-use state, then it prints alloc stack.
   It is useful to fix up page out-of-bound issue.

BUG: KASAN: slab-out-of-bounds in kmalloc_pagealloc_oob_right+0x88/0x90
Write of size 1 at addr ffc0d64ea00a by task cat/115
...
Allocation stack of page:
 prep_new_page+0x1a0/0x1d8
 get_page_from_freelist+0xd78/0x2748
 __alloc_pages_nodemask+0x1d4/0x1978
 kmalloc_order+0x28/0x58
 kmalloc_order_trace+0x28/0xe0
 kmalloc_pagealloc_oob_right+0x2c/0x90

b) If page is freed state, then it prints free stack.
   It is useful to fix up page use-after-free issue.

BUG: KASAN: use-after-free in kmalloc_pagealloc_uaf+0x70/0x80
Write of size 1 at addr ffc0d651c000 by task cat/115
...
Free stack of page:
 kasan_free_pages+0x68/0x70
 __free_pages_ok+0x3c0/0x1328
 __free_pages+0x50/0x78
 kfree+0x1c4/0x250
 kmalloc_pagealloc_uaf+0x38/0x80


This has been discussed, please refer below link.
https://bugzilla.kernel.org/show_bug.cgi?id=203967

Signed-off-by: Walter Wu 
---
 lib/Kconfig.kasan | 9 +
 mm/kasan/common.c | 6 ++
 2 files changed, 15 insertions(+)

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fafba1a923b..ba17f706b5f8 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -135,6 +135,15 @@ config KASAN_S390_4_LEVEL_PAGING
  to 3TB of RAM with KASan enabled). This options allows to force
  4-level paging instead.
 
+config KASAN_DUMP_PAGE
+   bool "Dump the page last stack information"
+   depends on KASAN && PAGE_OWNER
+   help
+ By default, KASAN doesn't record alloc/free stack for page allocator.
+ It is difficult to fix up page use-after-free issue.
+ This feature depends on page owner to record the last stack of page.
+ It is very helpful for solving the page use-after-free or 
out-of-bound.
+
 config TEST_KASAN
tristate "Module for testing KASAN for bug detection"
depends on m && KASAN
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2277b82902d8..2a32474efa74 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kasan.h"
 #include "../slab.h"
@@ -227,6 +228,11 @@ void kasan_alloc_pages(struct page *page, unsigned int 
order)
 
 void kasan_free_pages(struct page *page, unsigned int order)
 {
+#ifdef CONFIG_KASAN_DUMP_PAGE
+   gfp_t gfp_flags = GFP_KERNEL;
+
+   set_page_owner(page, order, gfp_flags);
+#endif
if (likely(!PageHighMem(page)))
kasan_poison_shadow(page_address(page),
PAGE_SIZE << order,
-- 
2.18.0

Re: [PATCH 2/8] x86/platform/uv: Return UV Hubless System Type

[Christoph Hellwig]

On Tue, Sep 03, 2019 at 11:49:53AM -0700, Mike Travis wrote:
> 
> That is always being considered for everything we include into the community
> kernel source.  The problem is a couple of the kernel modules (hwperf being
> the prime example) is much more tied to hardware and BIOS/FW updates so has
> to be updated much more often than the current submittal/acceptance process
> allows.  We do opensource these modules but they are built from single
> source directories and have to be released as a module into a package that
> can be installed on different distros. There is not a source version for
> each kernel version.

Well, tought luck then.  We do not support interface for out of tree
modules only.  I actually found a few in uv and will send patches to
drop that dead weight.

> I have seen this method (declare the function with a leading underscore and
> a #define for the function reference) which is why I'm assuming it's a
> standard kernel practice?  (I'll find some examples if necessary?)

No, it isn't.

[PATCH] mm,hugetlb_cgroup: Fix typo failcntfile in comment

[Odin Ugedal]

Change "failcntfile" to "failcnt file"

Signed-off-by: Odin Ugedal 
---
 mm/hugetlb_cgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 68c2f2f3c05b..3b004028c490 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -379,7 +379,7 @@ static void __init __hugetlb_cgroup_file_init(int idx)
cft->write = hugetlb_cgroup_reset;
cft->read_u64 = hugetlb_cgroup_read_u64;
 
-   /* Add the failcntfile */
+   /* Add the failcnt file */
cft = &h->cgroup_files[3];
snprintf(cft->name, MAX_CFTYPE_NAME, "%s.failcnt", buf);
cft->private  = MEMFILE_PRIVATE(idx, RES_FAILCNT);
-- 
2.23.0

[PATCH] ath9k: Remove unneeded variable to store return value

[zhong jiang]

ath9k_reg_rmw_single do not need return value to cope with different
cases. And change functon return type to void.

Signed-off-by: zhong jiang 
---
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c 
b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 214c682..d961095 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -463,7 +463,7 @@ static void ath9k_enable_rmw_buffer(void *hw_priv)
atomic_inc(&priv->wmi->m_rmw_cnt);
 }
 
-static u32 ath9k_reg_rmw_single(void *hw_priv,
+static void ath9k_reg_rmw_single(void *hw_priv,
 u32 reg_offset, u32 set, u32 clr)
 {
struct ath_hw *ah = hw_priv;
@@ -471,7 +471,6 @@ static u32 ath9k_reg_rmw_single(void *hw_priv,
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
struct register_rmw buf, buf_ret;
int ret;
-   u32 val = 0;
 
buf.reg = cpu_to_be32(reg_offset);
buf.set = cpu_to_be32(set);
@@ -485,7 +484,6 @@ static u32 ath9k_reg_rmw_single(void *hw_priv,
ath_dbg(common, WMI, "REGISTER RMW FAILED:(0x%04x, %d)\n",
reg_offset, ret);
}
-   return val;
 }
 
 static u32 ath9k_reg_rmw(void *hw_priv, u32 reg_offset, u32 set, u32 clr)
-- 
1.7.12.4

Re: [LKP] [fs/namei.c] e013ec23b8: WARNING:at_fs/dcache.c:#dentry_free

[Oliver Sang]

On Sat, Aug 31, 2019 at 04:42:46PM +0100, Al Viro wrote:
> On Sat, Aug 31, 2019 at 09:09:17PM +0800, kernel test robot wrote:
> 
> > [   13.886602] WARNING: CPU: 0 PID: 541 at fs/dcache.c:338 
> > dentry_free+0x7f/0x90
> > [   13.889208] Modules linked in:
> > [   13.890276] CPU: 0 PID: 541 Comm: readlink Not tainted 
> > 5.3.0-rc1-8-ge013ec23b8231 #1
> > [   13.892699] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.10.2-1 04/01/2014
> > [   13.895419] RIP: 0010:dentry_free+0x7f/0x90
> > [   13.896739] Code: f0 75 cb 48 8d be b0 00 00 00 48 83 c4 08 48 c7 c6 60 
> > 8d cd a5 e9 51 69 e4 ff 48 89 3c 24 48 c7 c7 f8 a9 cb a6 e8 7f 37 e3 ff 
> > <0f> 0b 48 8b 34 24 eb 8f 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90
> > [   13.901957] RSP: 0018:b5524063fe38 EFLAGS: 00010282
> > [   13.903527] RAX: 0024 RBX: 9941878040c0 RCX: 
> > a706aa08
> > [   13.905566] RDX:  RSI: 0096 RDI: 
> > 0246
> > [   13.907612] RBP:  R08: 0280 R09: 
> > 0033
> > [   13.909664] R10:  R11: b5524063fce8 R12: 
> > 994187804118
> > [   13.911711] R13: 99427a81 R14: 994187d7c8f0 R15: 
> > 99427a810b80
> > [   13.913753] FS:  () GS:9942bfc0() 
> > knlGS:
> > [   13.916187] CS:  0010 DS: 002b ES: 002b CR0: 80050033
> > [   13.917892] CR2: 0937458b CR3: 6800a000 CR4: 
> > 06f0
> > [   13.919925] Call Trace:
> > [   13.920840]  __dentry_kill+0x13c/0x1a0
> > [   13.922076]  path_put+0x12/0x20
> > [   13.923148]  free_fs_struct+0x1b/0x30
> > [   13.924346]  do_exit+0x304/0xc40
> > [   13.925438]  ? __schedule+0x25d/0x670
> > [   13.926642]  do_group_exit+0x3a/0xa0
> > [   13.927817]  __ia32_sys_exit_group+0x14/0x20
> > [   13.929160]  do_fast_syscall_32+0xa9/0x340
> > [   13.930565]  entry_SYSENTER_compat+0x7f/0x91
> > [   13.931924] ---[ end trace 02c6706eb2c2ebf2 ]---
> > 
> > 
> > To reproduce:
> > 
> > # build kernel
> > cd linux
> > cp config-5.3.0-rc1-8-ge013ec23b8231 .config
> > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare 
> > modules_prepare bzImage
> > 
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp qemu -k  job-script # job-script is attached in 
> > this email
> 
> Can't reproduce here...

any detail failure by using this reproducer?

> 
> I see one potential problem in there, but I would expect it to have the
> opposite effect (I really don't believe that it's a ->d_count wraparound -
> that would've taken much longer than a minute, if nothing else).
> 
> How reliably is it reproduced on your setup and does the following have
> any impact, one way or another?

It is always reproduced. We noticed that your branch was rebased. If it's still 
with problem, will let you know.

> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 412479e4c258..671c3c1a3425 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -643,10 +643,8 @@ static bool legitimize_root(struct nameidata *nd)
>  {
>   if (!nd->root.mnt || (nd->flags & LOOKUP_ROOT))
>   return true;
> - if (unlikely(!legitimize_path(nd, &nd->root, nd->root_seq)))
> - return false;
>   nd->flags |= LOOKUP_ROOT_GRABBED;
> - return true;
> + return legitimize_path(nd, &nd->root, nd->root_seq);
>  }
>  
>  /*
> ___
> LKP mailing list
> l...@lists.01.org
> https://lists.01.org/mailman/listinfo/lkp

Re: [PATCH 09/15] sched,fair: refactor enqueue/dequeue_entity

[Vincent Guittot]

On Tue, 3 Sep 2019 at 22:27, Rik van Riel  wrote:
>
> On Tue, 2019-09-03 at 17:38 +0200, Vincent Guittot wrote:
> > Hi Rik,
> >
> > On Thu, 22 Aug 2019 at 04:18, Rik van Riel  wrote:
> > > Refactor enqueue_entity, dequeue_entity, and update_load_avg, in
> > > order
> > > to split out the things we still want to happen at every level in
> > > the
> > > cgroup hierarchy with a flat runqueue from the things we only need
> > > to
> > > happen once.
> > >
> > > No functional changes.
> > >
> > > Signed-off-by: Rik van Riel 
> > > ---
> > >  kernel/sched/fair.c | 64 +--
> > > --
> > >  1 file changed, 42 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 74ee22c59d13..7b0d95f2e3a8 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -3502,7 +3502,7 @@ static void detach_entity_load_avg(struct
> > > cfs_rq *cfs_rq, struct sched_entity *s
> > >  #define DO_ATTACH  0x4
> > >
> > >  /* Update task and its cfs_rq load average */
> > > -static inline void update_load_avg(struct cfs_rq *cfs_rq, struct
> > > sched_entity *se, int flags)
> > > +static inline bool update_load_avg(struct cfs_rq *cfs_rq, struct
> > > sched_entity *se, int flags)
> > >  {
> > > u64 now = cfs_rq_clock_pelt(cfs_rq);
> > > int decayed;
> > > @@ -3531,6 +3531,8 @@ static inline void update_load_avg(struct
> > > cfs_rq *cfs_rq, struct sched_entity *s
> > >
> > > } else if (decayed && (flags & UPDATE_TG))
> > > update_tg_load_avg(cfs_rq, 0);
> > > +
> > > +   return decayed;
> >
> > This is a functional change, isn't it ?
> > update_cfs_group is now called only if decayed but we can we attach a
> > task during the enqueue and there is no decay
>
> Yes, it is, and patch 11 changes the way this functional
> change is done.
>
> If you want, I can change this patch to not have the
> functional change, though in the end it should not make
> any difference.

It's mainly that the code is not aligned with the commit message

I will continue to review other patch and will come back to this one
after reviewing patch 11

Thanks
Vincent
>
> --
> All Rights Reversed.

[PATCH v2] platform/x86: pmc_atom: Add Siemens SIMATIC IPC227E to critclk_systems DMI table

[Jan Kiszka]

From: Jan Kiszka 

The SIMATIC IPC227E uses the PMC clock for on-board components and gets
stuck during boot if the clock is disabled. Therefore, add this device
to the critical systems list.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: Jan Kiszka 
---

Changes in v2:
 - fixed cut-off subject line (local tooling bug...)

Should go into stable as well, down to 4.19.

 drivers/platform/x86/pmc_atom.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index aa53648a2214..9aca5e7ce6d0 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -415,6 +415,13 @@ static const struct dmi_system_id critclk_systems[] = {
DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
},
},
+   {
+   .ident = "SIMATIC IPC227E",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
+   },
+   },
{ /*sentinel*/ }
 };
 
-- 

2.16.4


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] net/skbuff: silence warnings under memory pressure

[Sergey Senozhatsky]

On (09/04/19 08:15), Michal Hocko wrote:
> > If you look at the original report, the failed allocation dump_stack() is,
> > 
> >  
> >  warn_alloc.cold.43+0x8a/0x148
> >  __alloc_pages_nodemask+0x1a5c/0x1bb0
> >  alloc_pages_current+0x9c/0x110
> >  allocate_slab+0x34a/0x11f0
> >  new_slab+0x46/0x70
> >  ___slab_alloc+0x604/0x950
> >  __slab_alloc+0x12/0x20
> >  kmem_cache_alloc+0x32a/0x400
> >  __build_skb+0x23/0x60
> >  build_skb+0x1a/0xb0
> >  igb_clean_rx_irq+0xafc/0x1010 [igb]
> >  igb_poll+0x4bb/0xe30 [igb]
> >  net_rx_action+0x244/0x7a0
> >  __do_softirq+0x1a0/0x60a
> >  irq_exit+0xb5/0xd0
> >  do_IRQ+0x81/0x170
> >  common_interrupt+0xf/0xf
> >  
> > 
> > Since it has no __GFP_NOWARN to begin with, it will call,

I think that DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST
are good when we ratelimit just a single printk() call, so the ratelimit
is "max 10 kernel log lines in 5 seconds".

But the thing is different in case of dump_stack() + show_mem() +
some other output. Because now we ratelimit not a single printk() line,
but hundreds of them. The ratelimit becomes - 10 * $$$ lines in 5 seconds
(IOW, now we talk about thousands of lines). Significantly more permissive
ratelimiting.

-ss

Re: [PATCH 1/1] mm/migrate: fix list corruption in migration of non-LRU movable pages

[Michal Hocko]

On Wed 04-09-19 02:18:38, sunqiuyang wrote:
> The isolate path of non-lru movable pages:
> 
> isolate_migratepages_block
>   isolate_movable_page
>   trylock_page
>   // if PageIsolated, goto out_no_isolated
>   a_ops->isolate_page
>   __SetPageIsolated
>   unlock_page
>   list_add(&page->lru, &cc->migratepages)
> 
> The migration path:
> 
> unmap_and_move
>   __unmap_and_move
>   lock_page
>   move_to_new_page
>   a_ops->migratepage
>   __ClearPageIsolated
>   unlock_page
>   /* here, the page could be isolated again by another thread, and added 
> into another cc->migratepages,
>   since PG_Isolated has been cleared, and not protected by page_lock */
>   list_del(&page->lru)

But the page has been migrated already and not freed yet because there
is still a pin on it. So nobody should be touching it at this stage.
Or do I still miss something?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] soundwire: bus: set initial value to port_status

[Vinod Koul]

On 30-08-19, 02:11, Bard liao wrote:
> From: Bard Liao 
> 
> port_status[port_num] are assigned for each port_num in some if
> conditions. So some of the port_status may not be initialized.

Applied, thanks

-- 
~Vinod

Re: [PATCH v3] mmc: sdhci-of-aspeed: Depend on CONFIG_OF_ADDRESS

[Ulf Hansson]

On Wed, 4 Sep 2019 at 04:20, Andrew Jeffery  wrote:
>
> Resolves the following build error reported by the 0-day bot:
>
> ERROR: "of_platform_device_create" [drivers/mmc/host/sdhci-of-aspeed.ko] 
> undefined!
>
> SPARC does not set CONFIG_OF_ADDRESS so the symbol is missing. Depend on
> CONFIG_OF_ADDRESS to ensure the driver is only built for supported
> configurations.
>
> Fixes: 2d28dbe042f4 ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD 
> controller")
> Reported-by: kbuild test robot 
> Signed-off-by: Andrew Jeffery 

Applied for next, thanks!

Kind regards
Uffe


> ---
> v2 was a series of 4 patches, three of which were applied leaving this build
> fix to be reworked. The v2 series can be found here:
>
> https://patchwork.ozlabs.org/cover/1156457/
>
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 0f8a230de2f3..3a52f5703286 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -157,7 +157,7 @@ config MMC_SDHCI_OF_ARASAN
>  config MMC_SDHCI_OF_ASPEED
> tristate "SDHCI OF support for the ASPEED SDHCI controller"
> depends on MMC_SDHCI_PLTFM
> -   depends on OF
> +   depends on OF && OF_ADDRESS
> help
>   This selects the ASPEED Secure Digital Host Controller Interface.
>
> --
> 2.20.1
>

[PATCH v3 1/2] dt-bindings: phy: intel-sdxc-phy: Add YAML schema for LGM SDXC PHY

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add a YAML schema to use the host controller driver with the
SDXC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
 changes in v3:
   - Rob's review comments addressed and updated the patch
   - merged syscon and sdxc yaml file as single file after discussion

 changes in v2:
   - As per Rob's review comment syscon node entry added instead of reference
   - splitted two patches one for syscon and another for sdxc phy
---
 .../bindings/phy/intel,lgm-sdxc-phy.yaml   | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
new file mode 100644
index ..dfdedcf10f3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-sdxc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) SDXC PHY Device Tree Bindings
+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+description: Bindings for SDXC PHY on Intel's Lightning Mountain SoC, syscon
+  node is used to reference the base address of SDXC phy registers.
+
+select:
+  properties:
+compatible:
+  contains:
+const: intel,lgm-syscon
+
+reg:
+  maxItems: 1
+
+  required:
+- compatible
+- reg
+
+properties:
+  "#phy-cells":
+const: 0
+
+  compatible:
+contains:
+  const: intel,lgm-sdxc-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+maxItems: 1
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+examples:
+  - |
+sysconf: chiptop@e020 {
+  compatible = "intel,lgm-syscon";
+  reg = <0xe020 0x100>;
+
+  sdxc-phy: sdxc-phy {
+compatible = "intel,lgm-sdxc-phy";
+reg = <0x0080 0x4>,
+  <0x0084 0x4>,
+  <0x0088 0x4>,
+  <0x008c 0x4>;
+clocks = <&sdxc>;
+clock-names = "sdxcclk";
+#phy-cells = <0>;
+  };
+};
+...
-- 
2.11.0

[PATCH v3 2/2] phy: intel-lgm-sdxc: Add support for SDXC PHY

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add support for SDXC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
 drivers/phy/intel/Kconfig  |   6 ++
 drivers/phy/intel/Makefile |   1 +
 drivers/phy/intel/phy-intel-sdxc.c | 144 +
 3 files changed, 151 insertions(+)
 create mode 100644 drivers/phy/intel/phy-intel-sdxc.c

diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 4ea6a8897cd7..d6356c762a6b 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -7,3 +7,9 @@ config PHY_INTEL_EMMC
select GENERIC_PHY
help
  Enable this to support the Intel EMMC PHY
+
+config PHY_INTEL_SDXC
+   tristate "Intel SDXC PHY driver"
+   select GENERIC_PHY
+   help
+ Enable this to support the Intel SDXC PHY driver
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 6b876a75599d..3c6e7523200c 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
+obj-$(CONFIG_PHY_INTEL_SDXC)+= phy-intel-sdxc.o
diff --git a/drivers/phy/intel/phy-intel-sdxc.c 
b/drivers/phy/intel/phy-intel-sdxc.c
new file mode 100644
index ..7e13fd9ced5b
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-sdxc.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel SDXC PHY driver
+ * Copyright (C) 2019 Intel, Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* SDXC PHY register definitions */
+#define SDXC_PHYCTRL_REG   0x88
+#define OTAPDLYENA_MASKBIT(14)
+#define OTAPDLYSEL(x)  ((x) << 10)
+#define OTAPDLYSEL_ALL OTAPDLYSEL(GENMASK(3, 0))
+
+struct intel_sdxc_phy {
+   struct regmap *syscfg;
+   struct clk *sdxcclk;
+};
+
+static int intel_sdxc_phy_init(struct phy *phy)
+{
+   struct intel_sdxc_phy *priv = phy_get_drvdata(phy);
+
+   /*
+* We purposely get the clock here and not in probe to avoid the
+* circular dependency problem.  We expect:
+* - PHY driver to probe
+* - SDHCI driver to start probe
+* - SDHCI driver to register it's clock
+* - SDHCI driver to get the PHY
+* - SDHCI driver to init the PHY
+*
+* The clock is optional, so upon any error just return it like
+* any other error to user.
+*/
+   priv->sdxcclk = clk_get_optional(&phy->dev, "sdxcclk");
+   if (IS_ERR(priv->sdxcclk)) {
+   dev_err(&phy->dev, "Error getting sdxcclk\n");
+   return PTR_ERR(priv->sdxcclk);
+   }
+
+   return 0;
+}
+
+static int intel_sdxc_phy_exit(struct phy *phy)
+{
+   struct intel_sdxc_phy *priv = phy_get_drvdata(phy);
+
+   clk_put(priv->sdxcclk);
+
+   return 0;
+}
+
+static int intel_sdxc_phy_power_on(struct phy *phy)
+{
+   struct intel_sdxc_phy *priv = phy_get_drvdata(phy);
+
+   /* Output tap delay: disable */
+   regmap_update_bits(priv->syscfg, SDXC_PHYCTRL_REG, OTAPDLYENA_MASK, 0);
+
+   /* Output tap delay */
+   regmap_update_bits(priv->syscfg, SDXC_PHYCTRL_REG, OTAPDLYSEL_ALL,
+  OTAPDLYSEL_ALL);
+
+   return 0;
+}
+
+static int intel_sdxc_phy_power_off(struct phy *phy)
+{
+   /* Do nothing */
+   return 0;
+}
+
+static const struct phy_ops ops = {
+   .init   = intel_sdxc_phy_init,
+   .exit   = intel_sdxc_phy_exit,
+   .power_on   = intel_sdxc_phy_power_on,
+   .power_off  = intel_sdxc_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
+static int intel_sdxc_phy_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct intel_sdxc_phy *priv;
+   struct phy *generic_phy;
+   struct phy_provider *phy_provider;
+
+   if (!dev->parent || !dev->parent->of_node)
+   return -ENODEV;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   /* Get SDXC phy (accessed via chiptop) regmap */
+   priv->syscfg = syscon_regmap_lookup_by_phandle(dev->of_node,
+  "intel,syscon");
+   if (IS_ERR(priv->syscfg)) {
+   dev_err(dev, "No syscon phandle for chiptop\n");
+   return PTR_ERR(priv->syscfg);
+   }
+
+   generic_phy = devm_phy_create(dev, dev->of_node, &ops);
+   if (IS_ERR(generic_phy)) {
+   dev_err(dev, "failed to create PHY\n");
+   return PTR_ERR(generic_phy);
+   }
+
+   phy_set_drvdata(generic_phy, priv);
+   phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+   return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id intel_sdxc_phy_dt_ids[]

Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

[Feng Tang]

Hi Thomas,

On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 28.08.19 um 11:37 schrieb Rong Chen:
> > Hi Thomas,
> > 
> > On 8/28/19 1:16 AM, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 27.08.19 um 14:33 schrieb Chen, Rong A:
> >>> Both patches have little impact on the performance from our side.
> >> Thanks for testing. Too bad they doesn't solve the issue.
> >>
> >> There's another patch attached. Could you please tests this as well?
> >> Thanks a lot!
> >>
> >> The patch comes from Daniel Vetter after discussing the problem on IRC.
> >> The idea of the patch is that the old mgag200 code might display much
> >> less frames that the generic code, because mgag200 only prints from
> >> non-atomic context. If we simulate this with the generic code, we should
> >> see roughly the original performance.
> >>
> >>
> > 
> > It's cool, the patch "usecansleep.patch" can fix the issue.
> 
> Thank you for testing. But don't get too excited, because the patch
> simulates a bug that was present in the original mgag200 code. A
> significant number of frames are simply skipped. That is apparently the
> reason why it's faster.

Thanks for the detailed info, so the original code skips time-consuming
work inside atomic context on purpose. Is there any space to optmise it?
If 2 scheduled update worker are handled at almost same time, can one be
skipped?

Thanks,
Feng

> 
> Best regards
> Thomas

[PATCH] platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.

[Pi-Hsun Shih]

Since the rpmsg_endpoint is created before probe is called, it's
possible that a host event is received during cros_ec_register, and
there would be some pending work in the host_event_work workqueue while
cros_ec_register is called.

If cros_ec_register fails, when the leftover work in host_event_work
run, the ec_dev from the drvdata of the rpdev could be already set to
NULL, causing kernel crash when trying to run cros_ec_get_next_event.

Fix this by creating the rpmsg_endpoint by ourself, and when
cros_ec_register fails (or on remove), destroy the endpoint first (to
make sure there's no more new calls to cros_ec_rpmsg_callback), and then
cancel all works in the host_event_work workqueue.

Fixes: 2de89fd98958 ("platform/chrome: cros_ec: Add EC host command support 
using rpmsg")
Signed-off-by: Pi-Hsun Shih 
---
 drivers/platform/chrome/cros_ec_rpmsg.c | 33 +
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c 
b/drivers/platform/chrome/cros_ec_rpmsg.c
index 8b6bd775cc9a..0c3738c3244d 100644
--- a/drivers/platform/chrome/cros_ec_rpmsg.c
+++ b/drivers/platform/chrome/cros_ec_rpmsg.c
@@ -41,6 +41,7 @@ struct cros_ec_rpmsg {
struct rpmsg_device *rpdev;
struct completion xfer_ack;
struct work_struct host_event_work;
+   struct rpmsg_endpoint *ept;
 };
 
 /**
@@ -72,7 +73,6 @@ static int cros_ec_pkt_xfer_rpmsg(struct cros_ec_device 
*ec_dev,
  struct cros_ec_command *ec_msg)
 {
struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
-   struct rpmsg_device *rpdev = ec_rpmsg->rpdev;
struct ec_host_response *response;
unsigned long timeout;
int len;
@@ -85,7 +85,7 @@ static int cros_ec_pkt_xfer_rpmsg(struct cros_ec_device 
*ec_dev,
dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
 
reinit_completion(&ec_rpmsg->xfer_ack);
-   ret = rpmsg_send(rpdev->ept, ec_dev->dout, len);
+   ret = rpmsg_send(ec_rpmsg->ept, ec_dev->dout, len);
if (ret) {
dev_err(ec_dev->dev, "rpmsg send failed\n");
return ret;
@@ -196,11 +196,24 @@ static int cros_ec_rpmsg_callback(struct rpmsg_device 
*rpdev, void *data,
return 0;
 }
 
+static struct rpmsg_endpoint *
+cros_ec_rpmsg_create_ept(struct rpmsg_device *rpdev)
+{
+   struct rpmsg_channel_info chinfo = {};
+
+   strscpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
+   chinfo.src = rpdev->src;
+   chinfo.dst = RPMSG_ADDR_ANY;
+
+   return rpmsg_create_ept(rpdev, cros_ec_rpmsg_callback, NULL, chinfo);
+}
+
 static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev)
 {
struct device *dev = &rpdev->dev;
struct cros_ec_rpmsg *ec_rpmsg;
struct cros_ec_device *ec_dev;
+   int ret;
 
ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
if (!ec_dev)
@@ -225,7 +238,18 @@ static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev)
INIT_WORK(&ec_rpmsg->host_event_work,
  cros_ec_rpmsg_host_event_function);
 
-   return cros_ec_register(ec_dev);
+   ec_rpmsg->ept = cros_ec_rpmsg_create_ept(rpdev);
+   if (!ec_rpmsg->ept)
+   return -ENOMEM;
+
+   ret = cros_ec_register(ec_dev);
+   if (ret < 0) {
+   rpmsg_destroy_ept(ec_rpmsg->ept);
+   cancel_work_sync(&ec_rpmsg->host_event_work);
+   return ret;
+   }
+
+   return 0;
 }
 
 static void cros_ec_rpmsg_remove(struct rpmsg_device *rpdev)
@@ -234,7 +258,7 @@ static void cros_ec_rpmsg_remove(struct rpmsg_device *rpdev)
struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
 
cros_ec_unregister(ec_dev);
-
+   rpmsg_destroy_ept(ec_rpmsg->ept);
cancel_work_sync(&ec_rpmsg->host_event_work);
 }
 
@@ -271,7 +295,6 @@ static struct rpmsg_driver cros_ec_driver_rpmsg = {
},
.probe  = cros_ec_rpmsg_probe,
.remove = cros_ec_rpmsg_remove,
-   .callback   = cros_ec_rpmsg_callback,
 };
 
 module_rpmsg_driver(cros_ec_driver_rpmsg);
-- 
2.23.0.187.g17f5b7556c-goog

[PATCH] perf record: fix priv level with branch sampling for paranoid=2

[Stephane Eranian]

Now that the default perf_events paranoid level is set to 2, a regular user
cannot monitor kernel level activity anymore. As such, with the following
cmdline:

$ perf record -e cycles date

The perf tool first tries cycles:uk but then falls back to cycles:u
as can be seen in the perf report --header-only output:

  cmdline : /export/hda3/tmp/perf.tip record -e cycles ls
  event : name = cycles:u, , id = { 436186, ... }

This is okay as long as there is way to learn the priv level was changed
internally by the tool.

But consider a similar example:

$ perf record -b -e cycles date
Error:
You may not have permission to collect stats.

Consider tweaking /proc/sys/kernel/perf_event_paranoid,
which controls use of the performance events system by
unprivileged users (without CAP_SYS_ADMIN).
...

Why is that treated differently given that the branch sampling inherits the
priv level of the first event in this case, i.e., cycles:u? It turns out
that the branch sampling code is more picky and also checks exclude_hv.

In the fallback path, perf record is setting exclude_kernel = 1, but it
does not change exclude_hv. This does not seem to match the restriction
imposed by paranoid = 2.

This patch fixes the problem by forcing exclude_hv = 1 in the fallback
for paranoid=2. With this in place:

$ perf record -b -e cycles date
  cmdline : /export/hda3/tmp/perf.tip record -b -e cycles ls
  event : name = cycles:u, , id = { 436847, ... }

And the command succeeds as expected.

Signed-off-by: Stephane Eranian 
---
 tools/perf/util/evsel.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 85825384f9e8..3cbe06fdf7f7 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -2811,9 +2811,11 @@ bool perf_evsel__fallback(struct evsel *evsel, int err,
if (evsel->name)
free(evsel->name);
evsel->name = new_name;
-   scnprintf(msg, msgsize,
-"kernel.perf_event_paranoid=%d, trying to fall back to excluding kernel 
samples", paranoid);
+   scnprintf(msg, msgsize, "kernel.perf_event_paranoid=%d, trying "
+ "to fall back to excluding kernel and hypervisor "
+ " samples", paranoid);
evsel->core.attr.exclude_kernel = 1;
+   evsel->core.attr.exclude_hv = 1;
 
return true;
}
-- 
2.23.0.187.g17f5b7556c-goog

Re: Tweak I2C SDA hold time on GemniLake to make touchpad work

[Chris Chiu]

On Wed, Sep 4, 2019 at 1:54 PM Jarkko Nikula
 wrote:
>
> On 9/4/19 7:38 AM, Chris Chiu wrote:
> > On Tue, Sep 3, 2019 at 8:03 PM Jarkko Nikula
> >  wrote:
> >>
> >> Hi Chris
> >>
> >> On 9/3/19 11:18 AM, Mika Westerberg wrote:
> >>> +Jarkko
> >>>
> >>> On Tue, Sep 03, 2019 at 04:10:27PM +0800, Chris Chiu wrote:
>  Hi,
> 
>  We're working on the acer Gemnilake laptop TravelMate B118-M for
>  touchpad not working issue. The touchpad fails to bring up and the
>  i2c-hid ouput the message as follows
>    [8.317293] i2c_hid i2c-ELAN0502:00: hid_descr_cmd failed
>  We tried on latest linux kernel 5.3.0-rc6 and it reports the same.
> 
>  We then look into I2C signal level measurement to find out why.
>  The following is the signal output from LA for the SCL/SDA.
>  https://imgur.com/sKcpvdo
>  The SCL frequency is ~400kHz from the SCL period, but the SDA
>  transition is quite weird. Per the I2C spec, the data on the SDA line
>  must be stable during the high period of the clock. The HIGH or LOW
>  state of the data line can only change when the clock signal on the
>  SCL line is LOW. The SDA period span across 2 SCL high, I think
>  that's the reason why the I2C read the wrong data and fail to initialize.
> 
>  Thus, we treak the SDA hold time by the following modification.
> 
>  --- a/drivers/mfd/intel-lpss-pci.c
>  +++ b/drivers/mfd/intel-lpss-pci.c
>  @@ -97,7 +97,8 @@ static const struct intel_lpss_platform_info 
>  bxt_uart_info = {
> };
> 
> static struct property_entry bxt_i2c_properties[] = {
>  -   PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
>  +   PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
>    PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
>    PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
>    { },
> 
>  The reason why I choose sda hold time is by the Table 10 of
>  https://www.nxp.com/docs/en/user-guide/UM10204.pdf, the device
>  must provide a hold time at lease 300ns and and 42 here is relatively
>  too small. The signal measurement result for the same pin on Windows
>  is as follows.
>  https://imgur.com/BtKUIZB
>  Comparing to the same result running Linux
>  https://imgur.com/N4fPTYN
> 
>  After applying the sda hold time tweak patch above, the touchpad can
>  be correctly initialized and work. The LA signal is shown as down below.
>  https://imgur.com/B3PmnIp
> 
> >> Could you try does attached patch work for you?
> >>
> >> It's from last year for another related issue but there platform was
> >> actually Apollo Lake instead of Gemini Lake but anyway it was found out
> >> that Windows uses different timing parameters than Linux on Gemini Lake.
> >>
> >> I didn't take patch forward back then due known Gemini Lake machines
> >> were working with the Broxton I2C timing parameters but now it's time if
> >> attached patch fixes the issue on your machine.
> >>
> >> Patch is from top of v5.3-rc7 but should probably apply also to older
> >> kernels.
> >>
> >> --
> >> Jarkko
> >
> > Thanks, Jarkko, the patche works on my acer laptops.
> >
> Thanks. I'll send the patch out with Cc'ing you. I took the freedom to
> add your Tested-by tag if you don't mind :-)
>
> --
> Jarkko

No problem. Thanks

Re: [PATCH 1/2] Fix a NULL-ptr-deref bug in ath6kl_usb_alloc_urb_from_pipe

[Kalle Valo]

Hui Peng  wrote:

> The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects
> are initialized to point to the containing `ath6kl_usb` object
> according to endpoint descriptors read from the device side, as shown
> below in `ath6kl_usb_setup_pipe_resources`:
> 
> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
>   endpoint = &iface_desc->endpoint[i].desc;
> 
>   // get the address from endpoint descriptor
>   pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb,
>   endpoint->bEndpointAddress,
>   &urbcount);
>   ..
>   // select the pipe object
>   pipe = &ar_usb->pipes[pipe_num];
> 
>   // initialize the ar_usb field
>   pipe->ar_usb = ar_usb;
> }
> 
> The driver assumes that the addresses reported in endpoint
> descriptors from device side  to be complete. If a device is
> malicious and does not report complete addresses, it may trigger
> NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and
> `ath6kl_usb_free_urb_to_pipe`.
> 
> This patch fixes the bug by preventing potential NULL-ptr-deref
> (CVE-2019-15098).
> 
> Signed-off-by: Hui Peng 
> Reported-by: Hui Peng 
> Reported-by: Mathias Payer 
> Reviewed-by: Greg Kroah-Hartman 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

39d170b3cb62 ath6kl: fix a NULL-ptr-deref bug in 
ath6kl_usb_alloc_urb_from_pipe()

-- 
https://patchwork.kernel.org/patch/11074655/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

[PATCH v3] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q

[Robin van der Gracht]

The first generation i.MX6 processors does not send an interrupt when the
power key is pressed. It sends a power down request interrupt if the key is
released before a hard shutdown (5 second press). This should allow
software to bring down the SoC safely.

For this driver to work as a regular power key with the older SoCs, we need
to send a keypress AND release when we get the power down request irq.

Signed-off-by: Robin van der Gracht 
---

Changes v2 -> v3:
 - Drop alt compatible string for identifying first revision snvs hardware,
   read minor revision from register instead.
 - Drop imx6qdl.dtsi modification and device-tree binding documentation.
 - Add an additional input_sync() to create 2 seperate input reports for press
   and release.

 drivers/input/keyboard/Kconfig   |  2 +-
 drivers/input/keyboard/snvs_pwrkey.c | 28 ++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 7c4f19dab34f..937e58da5ce1 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
depends on OF
help
  This is the snvs powerkey driver for the Freescale i.MX application
- processors that are newer than i.MX6 SX.
+ processors.
 
  To compile this driver as a module, choose M here; the
  module will be called snvs_pwrkey.
diff --git a/drivers/input/keyboard/snvs_pwrkey.c 
b/drivers/input/keyboard/snvs_pwrkey.c
index 5342d8d45f81..828580eee0d2 100644
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 
+#define SNVS_HPVIDR1_REG 0xF8
 #define SNVS_LPSR_REG  0x4C/* LP Status Register */
 #define SNVS_LPCR_REG  0x38/* LP Control Register */
 #define SNVS_HPSR_REG  0x14
@@ -37,6 +38,7 @@ struct pwrkey_drv_data {
int wakeup;
struct timer_list check_timer;
struct input_dev *input;
+   u8 minor_rev;
 };
 
 static void imx_imx_snvs_check_for_events(struct timer_list *t)
@@ -45,6 +47,20 @@ static void imx_imx_snvs_check_for_events(struct timer_list 
*t)
struct input_dev *input = pdata->input;
u32 state;
 
+   if (pdata->minor_rev == 0) {
+   /*
+* The first generation i.MX6 SoCs only sends an interrupt on
+* button release. To mimic power-key usage, we'll prepend a
+* press event.
+*/
+   input_report_key(input, pdata->keycode, 1);
+   input_sync(input);
+   input_report_key(input, pdata->keycode, 0);
+   input_sync(input);
+   pm_relax(input->dev.parent);
+   return;
+   }
+
regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
state = state & SNVS_HPSR_BTN ? 1 : 0;
 
@@ -67,13 +83,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void 
*dev_id)
 {
struct platform_device *pdev = dev_id;
struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
+   unsigned long expire = jiffies;
u32 lp_status;
 
pm_wakeup_event(pdata->input->dev.parent, 0);
 
regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
-   if (lp_status & SNVS_LPSR_SPO)
-   mod_timer(&pdata->check_timer, jiffies + 
msecs_to_jiffies(DEBOUNCE_TIME));
+   if (lp_status & SNVS_LPSR_SPO) {
+   if (pdata->minor_rev > 0)
+   expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
+   mod_timer(&pdata->check_timer, expire);
+   }
 
/* clear SPO status */
regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
@@ -94,6 +114,7 @@ static int imx_snvs_pwrkey_probe(struct platform_device 
*pdev)
struct input_dev *input = NULL;
struct device_node *np;
int error;
+   u32 vid;
 
/* Get SNVS register Page */
np = pdev->dev.of_node;
@@ -123,6 +144,9 @@ static int imx_snvs_pwrkey_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
+   regmap_read(pdata->snvs, SNVS_HPVIDR1_REG, &vid);
+   pdata->minor_rev = vid & 0xff;
+
regmap_update_bits(pdata->snvs, SNVS_LPCR_REG, SNVS_LPCR_DEP_EN, 
SNVS_LPCR_DEP_EN);
 
/* clear the unexpected interrupt before driver ready */
-- 
2.20.1

Re: linux-next: build warnings after merge of the kbuild tree

[Masahiro Yamada]

On Wed, Sep 4, 2019 at 10:00 AM Masahiro Yamada
 wrote:
>
> Hi Stephen,
>
> On Wed, Sep 4, 2019 at 9:13 AM Stephen Rothwell  wrote:
> >

For today's linux-next, please squash the following too.

(This is my fault, since scripts/mkuboot.sh is a bash script)


diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 41c50f9461e5..2d72327417a9 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -374,7 +374,7 @@ UIMAGE_ENTRYADDR ?= $(UIMAGE_LOADADDR)
 UIMAGE_NAME ?= 'Linux-$(KERNELRELEASE)'

 quiet_cmd_uimage = UIMAGE  $@
-  cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \
+  cmd_uimage = $(BASE) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \
-C $(UIMAGE_COMPRESSION) $(UIMAGE_OPTS-y) \
-T $(UIMAGE_TYPE) \
-a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \





-- 
Best Regards
Masahiro Yamada

Re: [Linux-kernel-mentees] [PATCH v2 2/3] PCI: sysfs: Change permissions from symbolic to octal

[Kelsey Skunberg]

On Thu, Aug 15, 2019 at 10:37:13AM -0400, Don Dutile wrote:
> On 08/14/2019 01:38 AM, Bjorn Helgaas wrote:
> > [+cc Bodong, Don, Greg for permission question]
> > 
> > On Tue, Aug 13, 2019 at 02:45:12PM -0600, Kelsey Skunberg wrote:
> > > Symbolic permissions such as "(S_IWUSR | S_IWGRP)" are not
> > > preferred and octal permissions should be used instead. Change all
> > > symbolic permissions to octal permissions.
> > > 
> > > Example of old:
> > > 
> > > "(S_IWUSR | S_IWGRP)"
> > > 
> > > Example of new:
> > > 
> > > "0220"
> > 
> > 
> > >   static DEVICE_ATTR_RO(sriov_totalvfs);
> > > -static DEVICE_ATTR(sriov_numvfs, (S_IRUGO | S_IWUSR | S_IWGRP),
> > > -   sriov_numvfs_show, sriov_numvfs_store);
> > > +static DEVICE_ATTR(sriov_numvfs, 0664, sriov_numvfs_show, 
> > > sriov_numvfs_store);
> > >   static DEVICE_ATTR_RO(sriov_offset);
> > >   static DEVICE_ATTR_RO(sriov_stride);
> > >   static DEVICE_ATTR_RO(sriov_vf_device);
> > > -static DEVICE_ATTR(sriov_drivers_autoprobe, (S_IRUGO | S_IWUSR | 
> > > S_IWGRP),
> > > -sriov_drivers_autoprobe_show, sriov_drivers_autoprobe_store);
> > > +static DEVICE_ATTR(sriov_drivers_autoprobe, 0664, 
> > > sriov_drivers_autoprobe_show,
> > > +sriov_drivers_autoprobe_store);
> > 
> > Greg noticed that sriov_numvfs and sriov_drivers_autoprobe have
> > "unusual" permissions.  These were added by:
> > 
> >0e7df22401a3 ("PCI: Add sysfs sriov_drivers_autoprobe to control VF 
> > driver binding")
> >1789382a72a5 ("PCI: SRIOV control and status via sysfs")
> > 
> > Kelsey's patch correctly preserves the existing permissions, but we
> > should double-check that they are the permissions they want, and
> > possibly add a comment about why they're different from the rest.
> > 
> > Bjorn
> > 

Hi Don,

> The rest being? ... 0644 vs 0664 ?
> The file is read & written, thus the (first) 6; I'll have to dig through very 
> old (7 yr) notes to see if the second 6 is needed for libvirt (so it doesn't 
> have to be root to enable).
> 
> -dd
>

Were you able to see if the unusual permissions (0664) are needed for
libvirt? I appreciate your help!

-Kelsey

Re: [PATCH] wcn36xx: use dynamic allocation for large variables

[Kalle Valo]

Arnd Bergmann  wrote:

> clang triggers a warning about oversized stack frames that gcc does not
> notice because of slightly different inlining decisions:
> 
> ath/wcn36xx/smd.c:1409:5: error: stack frame size of 1040 bytes in function 
> 'wcn36xx_smd_config_bss' [-Werror,-Wframe-larger-than=]
> ath/wcn36xx/smd.c:640:5: error: stack frame size of 1032 bytes in function 
> 'wcn36xx_smd_start_hw_scan' [-Werror,-Wframe-larger-than=]
> 
> Basically the wcn36xx_hal_start_scan_offload_req_msg,
> wcn36xx_hal_config_bss_req_msg_v1, and wcn36xx_hal_config_bss_req_msg
> structures are too large to be put on the kernel stack, but small
> enough that gcc does not warn about them.
> 
> Use kzalloc() to allocate them all. There are similar structures in other
> parts of this driver, but they are all smaller, with the next largest
> stack frame at 480 bytes for wcn36xx_smd_send_beacon.
> 
> Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 
> hardware")
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

355cf3191201 wcn36xx: use dynamic allocation for large variables

-- 
https://patchwork.kernel.org/patch/11052589/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] ath6kl: Fix a possible null-pointer dereference in ath6kl_htc_mbox_create()

[Kalle Valo]

Jia-Ju Bai  wrote:

> In ath6kl_htc_mbox_create(), when kzalloc() on line 2855 fails,
> target->dev is assigned to NULL, and ath6kl_htc_mbox_cleanup(target) is
> called on line 2885.
> 
> In ath6kl_htc_mbox_cleanup(), target->dev is used on line 2895:
> ath6kl_hif_cleanup_scatter(target->dev->ar);
> 
> Thus, a null-pointer dereference may occur.
> 
> To fix this bug, kfree(target) is called and NULL is returned when
> kzalloc() on line 2855 fails.
> 
> This bug is found by a static analysis tool STCheck written by us.
> 
> Signed-off-by: Jia-Ju Bai 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

0e7bf23e4967 ath6kl: Fix a possible null-pointer dereference in 
ath6kl_htc_mbox_create()

-- 
https://patchwork.kernel.org/patch/11063157/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode

[Felipe Balbi]

Hi,

"Kobayashi, Kento (Sony)"  writes:

> Hi,
>
> My company's member, Mr.Jacky, sent patch in June 26th.
> But we didn't receive comment about our patch.
> Could you confirm and tell us this patch is needed or not?

I can't find the original patch in my inbox, could you resend it using
git send-email?

Patch seems necessary, indeed.

best regards

-- 
balbi


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Masahiro Yamada]

On Wed, Sep 4, 2019 at 3:00 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> scripts/link-vmlinux.sh: 74: Bad substitution
>
> Caused by commit
>
>   341dfcf8d78e ("btf: expose BTF info through sysfs")
>
> interacting with commit
>
>   1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension")
>
> from the kbuild tree.


I knew that they were using bash-extension
in the #!/bin/sh script.  :-D


In fact, I wrote my patch in order to break their code
and  make btf people realize that they were doing wrong.



> The change in the net-next tree turned link-vmlinux.sh into a bash script
> (I think).
>
> I have applied the following patch for today:


But, this is a temporary fix only for linux-next.

scripts/link-vmlinux.sh does not need to use the
bash-extension ${@:2} in the first place.

I hope btf people will write the correct code.

Thanks.




> From: Stephen Rothwell 
> Date: Wed, 4 Sep 2019 15:43:41 +1000
> Subject: [PATCH] link-vmlinux.sh is now a bash script
>
> Signed-off-by: Stephen Rothwell 
> ---
>  Makefile| 4 ++--
>  scripts/link-vmlinux.sh | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ac97fb282d99..523d12c5cebe 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard 
> $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
>
>  # Final link of vmlinux with optional arch pass after final link
>  cmd_link-vmlinux = \
> -   $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
> +   $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
>  vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
> @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES)
>  PHONY += archclean vmlinuxclean
>
>  vmlinuxclean:
> -   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean
> +   $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean
> $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean)
>
>  clean: archclean vmlinuxclean
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index f7edb75f9806..ea1f8673869d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -1,4 +1,4 @@
> -#!/bin/sh
> +#!/bin/bash
>  # SPDX-License-Identifier: GPL-2.0
>  #
>  # link vmlinux
> --
> 2.23.0.rc1
>
> --
> Cheers,
> Stephen Rothwell



--
Best Regards
Masahiro Yamada

Re: [PATCH v2 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext Milbeaut HDMAC bindings

[Jassi Brar]

On Wed, Sep 4, 2019 at 12:51 AM Vinod Koul  wrote:
>
> On 18-08-19, 00:17, jassisinghb...@gmail.com wrote:
> > From: Jassi Brar 
> >
> > Document the devicetree bindings for Socionext Milbeaut HDMAC
> > controller. Controller has upto 8 floating channels, that need
> > a predefined slave-id to work from a set of slaves.
> >
> > Signed-off-by: Jassi Brar 
> > ---
> >  .../bindings/dma/milbeaut-m10v-hdmac.txt  | 32 +++
> >  1 file changed, 32 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt 
> > b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > new file mode 100644
> > index ..f0960724f1c7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > @@ -0,0 +1,32 @@
> > +* Milbeaut AHB DMA Controller
> > +
> > +Milbeaut AHB DMA controller has transfer capability bellow.
>
> s/bellow/below:
>
> > + - device to memory transfer
> > + - memory to device transfer
> > +
> > +Required property:
> > +- compatible:   Should be  "socionext,milbeaut-m10v-hdmac"
> > +- reg:  Should contain DMA registers location and length.
> > +- interrupts:   Should contain all of the per-channel DMA interrupts.
> > + Number of channels is configurable - 2, 4 or 8, so
> > + the number of interrupts specfied should be {2,4,8}.
>
> s/specfied/specified
>
Hi Vinod,
  Do you want me to spin yet another revision for the two types in text?

thnx

[PATCH] platform/x86: pmc_atom: Add Siemens SIMATIC IPC227E to

[Jan Kiszka]

From: Jan Kiszka 

The SIMATIC IPC227E uses the PMC clock for on-board components and gets
stuck during boot if the clock is disabled. Therefore, add this device
to the critical systems list.

Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: Jan Kiszka 
---

Should go into stable as well, down to 4.19.

 drivers/platform/x86/pmc_atom.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index aa53648a2214..9aca5e7ce6d0 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -415,6 +415,13 @@ static const struct dmi_system_id critclk_systems[] = {
DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
},
},
+   {
+   .ident = "SIMATIC IPC227E",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "SIEMENS AG"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "6ES7647-8B"),
+   },
+   },
{ /*sentinel*/ }
 };
 
-- 

2.16.4


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[PATCH v17 3/5] remoteproc: mt8183: add reserved memory manager API

[Pi-Hsun Shih]

From: Erin Lo 

Add memory table mapping API for other driver to lookup
reserved physical and virtual memory

Signed-off-by: Erin Lo 
Signed-off-by: Pi-Hsun Shih 
---
Changes from v16, v15:
 - No change.

Changes from v14:
 - Fix a typo in variable name in DEBUG section.

Changes from v13:
 - Add one more reserved region.
 - Rename scp_get_reserve_* to scp_get_reserved_*.
 - Minor fixes addressing comment.

Changes from v12:
 - Reformat a line to fit 80 character width.

Changes from v11:
 - No change.

Changes from v10:
 - Fix some type mismatch warnings when printing debug messages.

Changes from v9:
 - No change.

Changes from v8:
 - Add more reserved regions for camera ISP.

Changes from v7, v6, v5:
 - No change.

Changes from v4:
 - New patch.
---
 drivers/remoteproc/mtk_scp.c   | 145 +
 include/linux/remoteproc/mtk_scp.h |  25 +
 2 files changed, 170 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 99e226f38ca4..ce4acffbb115 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -374,11 +374,142 @@ void *scp_mapping_dm_addr(struct platform_device *pdev, 
u32 mem_addr)
 }
 EXPORT_SYMBOL_GPL(scp_mapping_dm_addr);
 
+#if SCP_RESERVED_MEM
+static phys_addr_t scp_mem_base_phys;
+static phys_addr_t scp_mem_base_virt;
+static size_t scp_mem_size;
+
+static struct scp_reserve_mblock scp_reserve_mblock[] = {
+   {
+   .num = SCP_ISP_MEM_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x20, /*2MB*/
+   },
+   {
+   .num = SCP_ISP_MEM2_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x80, /*8MB*/
+   },
+   {
+   .num = SCP_MDP_MEM_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x60, /*6MB*/
+   },
+   {
+   .num = SCP_DIP_MEM_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x90, /*9MB*/
+   },
+   {
+   .num = SCP_FD_MEM_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x10, /*1MB*/
+   },
+   {
+   .num = SCP_FD_MEM2_ID,
+   .start_phys = 0x0,
+   .start_virt = 0x0,
+   .size = 0x10, /*1MB*/
+   },
+};
+
+static int scp_reserve_mem_init(struct mtk_scp *scp)
+{
+   enum scp_reserve_mem_id_t id;
+   phys_addr_t accumlate_memory_size = 0;
+
+   scp_mem_base_phys = (phys_addr_t) (scp->phys_addr + MAX_CODE_SIZE);
+   scp_mem_size = scp->dram_size - MAX_CODE_SIZE;
+
+   dev_info(scp->dev,
+"phys:0x%llx - 0x%llx (0x%llx)\n",
+(unsigned long long)scp_mem_base_phys,
+(unsigned long long)(scp_mem_base_phys + scp_mem_size),
+(unsigned long long)scp_mem_size);
+   accumlate_memory_size = 0;
+   for (id = 0; id < SCP_NUMS_MEM_ID; id++) {
+   scp_reserve_mblock[id].start_phys =
+   scp_mem_base_phys + accumlate_memory_size;
+   accumlate_memory_size += scp_reserve_mblock[id].size;
+   dev_info(
+   scp->dev,
+   "[reserve_mem:%d]: phys:0x%llx - 0x%llx (0x%llx)\n", id,
+   (unsigned long long)scp_reserve_mblock[id].start_phys,
+   (unsigned long long)(scp_reserve_mblock[id].start_phys +
+scp_reserve_mblock[id].size),
+   (unsigned long long)scp_reserve_mblock[id].size);
+   }
+   return 0;
+}
+
+static int scp_reserve_memory_ioremap(struct mtk_scp *scp)
+{
+   enum scp_reserve_mem_id_t id;
+   phys_addr_t accumlate_memory_size = 0;
+
+   scp_mem_base_virt = (phys_addr_t)(size_t)ioremap_wc(scp_mem_base_phys,
+   scp_mem_size);
+
+   dev_info(scp->dev,
+"virt:0x%llx - 0x%llx (0x%llx)\n",
+   (unsigned long long)scp_mem_base_virt,
+   (unsigned long long)(scp_mem_base_virt + scp_mem_size),
+   (unsigned long long)scp_mem_size);
+   for (id = 0; id < SCP_NUMS_MEM_ID; id++) {
+   scp_reserve_mblock[id].start_virt =
+   scp_mem_base_virt + accumlate_memory_size;
+   accumlate_memory_size += scp_reserve_mblock[id].size;
+   }
+   /* the reserved memory should be larger then expected memory
+* or scp_reserve_mblock does not match dts
+*/
+   WARN_ON(accumlate_memory_size > scp_mem_size);
+   return 0;
+}
+phys_addr_t scp_get_reserved_mem_phys(enum scp_reserve_mem_id_t id)
+{
+   if (id >= SCP_NUMS_MEM_ID) {
+   pr_err("[SCP] no reserve memory for %d", id);
+   return 0;
+   }
+   

[PATCH v17 4/5] rpmsg: add rpmsg support for mt8183 SCP.

[Pi-Hsun Shih]

Add a simple rpmsg support for mt8183 SCP, that use IPI / IPC directly.

Signed-off-by: Pi-Hsun Shih 
---
Changes from v16:
 - Change year on another Copyright header to 2019.

Changes from v15:
 - No change.

Changes from v14:
 - Change year on Copyright header to 2019.

Changes from v13:
 - No change.

Changes from v12:
 - Use strscpy instead of strncpy.

Changes from v11:
 - Fix a bug that when rproc_boot fails, the ns_ept won't be properly
   destroyed, causing memory leak.
 - Add documentation for mtk_rpmsg_info.

Changes from v10, v9, v8, v7:
 - No change.

Changes from v6:
 - Decouple mtk_rpmsg from mtk_scp by putting all necessary informations
   (name service IPI id, register/unregister/send functions) into a
   struct, and pass it to the mtk_rpmsg_create_rproc_subdev function.

Changes from v5:
 - CONFIG_MTK_SCP now selects CONFIG_RPMSG_MTK_SCP, and the dummy
   implementation for mtk_rpmsg_{create,destroy}_rproc_subdev when
   CONFIG_RPMSG_MTK_SCP is not defined is removed.

Changes from v4:
 - Match and fill the device tree node to the created rpmsg subdevice,
   so the rpmsg subdevice can utilize the properties and subnodes on
   device tree (This is similar to what drivers/rpmsg/qcom_smd.c does).

Changes from v3:
 - Change from unprepare to stop, to stop the rpmsg driver before the
   rproc is stopped, avoiding problem that some rpmsg would fail after
   rproc is stopped.
 - Add missing spin_lock_init, and use destroy_ept instead of kref_put.

Changes from v2:
 - Unregiser IPI handler on unprepare.
 - Lock the channel list on operations.
 - Move SCP_IPI_NS_SERVICE to 0xFF.

Changes from v1:
 - Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
   short-lived work items.
 - Fix several issues checkpatch found.
---
 drivers/remoteproc/Kconfig |   1 +
 drivers/remoteproc/mtk_common.h|   2 +
 drivers/remoteproc/mtk_scp.c   |  38 ++-
 drivers/remoteproc/mtk_scp_ipi.c   |   1 +
 drivers/rpmsg/Kconfig  |   9 +
 drivers/rpmsg/Makefile |   1 +
 drivers/rpmsg/mtk_rpmsg.c  | 414 +
 include/linux/remoteproc/mtk_scp.h |   4 +-
 include/linux/rpmsg/mtk_rpmsg.h|  38 +++
 9 files changed, 503 insertions(+), 5 deletions(-)
 create mode 100644 drivers/rpmsg/mtk_rpmsg.c
 create mode 100644 include/linux/rpmsg/mtk_rpmsg.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index ea71cad399f7..cff3a9fa817b 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -26,6 +26,7 @@ config IMX_REMOTEPROC
 config MTK_SCP
tristate "Mediatek SCP support"
depends on ARCH_MEDIATEK
+   select RPMSG_MTK_SCP
help
  Say y here to support Mediatek's System Companion Processor (SCP) via
  the remote processor framework.
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 622e9aebe9ab..40fa890e6d60 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -69,6 +69,8 @@ struct mtk_scp {
void __iomem *cpu_addr;
phys_addr_t phys_addr;
size_t dram_size;
+
+   struct rproc_subdev *rpmsg_subdev;
 };
 
 /**
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ce4acffbb115..92657acc5e70 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_common.h"
 #include "remoteproc_internal.h"
@@ -549,6 +550,31 @@ static int scp_map_memory_region(struct mtk_scp *scp)
return 0;
 }
 
+static struct mtk_rpmsg_info mtk_scp_rpmsg_info = {
+   .send_ipi = scp_ipi_send,
+   .register_ipi = scp_ipi_register,
+   .unregister_ipi = scp_ipi_unregister,
+   .ns_ipi_id = SCP_IPI_NS_SERVICE,
+};
+
+static void scp_add_rpmsg_subdev(struct mtk_scp *scp)
+{
+   scp->rpmsg_subdev =
+   mtk_rpmsg_create_rproc_subdev(to_platform_device(scp->dev),
+ &mtk_scp_rpmsg_info);
+   if (scp->rpmsg_subdev)
+   rproc_add_subdev(scp->rproc, scp->rpmsg_subdev);
+}
+
+static void scp_remove_rpmsg_subdev(struct mtk_scp *scp)
+{
+   if (scp->rpmsg_subdev) {
+   rproc_remove_subdev(scp->rproc, scp->rpmsg_subdev);
+   mtk_rpmsg_destroy_rproc_subdev(scp->rpmsg_subdev);
+   scp->rpmsg_subdev = NULL;
+   }
+}
+
 static int scp_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -632,22 +658,25 @@ static int scp_probe(struct platform_device *pdev)
init_waitqueue_head(&scp->run.wq);
init_waitqueue_head(&scp->ack_wq);
 
+   scp_add_rpmsg_subdev(scp);
+
ret = devm_request_threaded_irq(dev, platform_get_irq(pdev, 0), NULL,
scp_irq_handler, IRQF_ONESHOT,
pdev->name, scp);
 
if (ret) {
dev_err(dev, "fail

[PATCH v17 2/5] remoteproc/mediatek: add SCP support for mt8183

[Pi-Hsun Shih]

From: Erin Lo 

Provide a basic driver to control Cortex M4 co-processor

Signed-off-by: Erin Lo 
Signed-off-by: Nicolas Boichat 
Signed-off-by: Pi-Hsun Shih 
---
Changes from v16:
 - Change the desc_lock mutex to be a per-id lock.
 - Put the execution of handler inside the per-id lock, to prevent race
   between scp_ipi_unregister and handler being run.
 - Move the initialization of mutex to before scp_ipi_register.

Changes from v15:
 - Fix a bug on incorrect usage of wait_event_timeout return value.

Changes from v14:
 - No change.

Changes from v13:
 - Move include/linux/platform_data/mtk_scp.h to
   include/linux/remoteproc/mtk_scp.h.
 - Add lock for access of scp->ipi_desc.
 - Lock the whole ipi_send function.
 - Move more setting of cache size from SCP firmware to kernel driver,
   to prevent problem while loading firmware onto DRAM.
 - Cleanup and remove unused branch in scp_da_to_va.
 - Minor fixes addressing comment.

Changes from v12:
 - Initialize cache before firmware load, to avoid problem while loading
   large firmware.
 - Disable watchdog before stopping SCP, to avoid extra warning message.
 - Use strscpy instead of strncpy.

Changes from v11:
 - No change.

Changes from v10:
 - Add a clock reset before loading firmware.

Changes from v9:
 - No change.

Changes from v8:
 - Add a missing space.

Changes from v7:
 - Moved the location of shared SCP buffer.
 - Fix clock enable/disable sequence.
 - Add more IPI ID that would be used.

Changes from v6:
 - No change.

Changes from v5:
 - Changed some space to tab.

Changes from v4:
 - Rename most function from mtk_scp_* to scp_*.
 - Change the irq to threaded handler.
 - Load ELF file instead of plain binary file as firmware by default
   (Squashed patch 6 in v4 into this patch).

Changes from v3:
 - Fix some issue found by checkpatch.
 - Make writes aligned in scp_ipi_send.

Changes from v2:
 - Squash patch 3 from v2 (separate the ipi interface) into this patch.
 - Remove unused name argument from scp_ipi_register.
 - Add scp_ipi_unregister for proper cleanup.
 - Move IPI ids in sync with firmware.
 - Add mb() in proper place, and correctly clear the run->signaled.

Changes from v1:
 - Extract functions and rename variables in mtk_scp.c.
---
 drivers/remoteproc/Kconfig |   9 +
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/mtk_common.h|  92 +
 drivers/remoteproc/mtk_scp.c   | 547 +
 drivers/remoteproc/mtk_scp_ipi.c   | 176 ++
 include/linux/remoteproc/mtk_scp.h | 141 
 6 files changed, 966 insertions(+)
 create mode 100644 drivers/remoteproc/mtk_common.h
 create mode 100644 drivers/remoteproc/mtk_scp.c
 create mode 100644 drivers/remoteproc/mtk_scp_ipi.c
 create mode 100644 include/linux/remoteproc/mtk_scp.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28ed306982f7..ea71cad399f7 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -23,6 +23,15 @@ config IMX_REMOTEPROC
 
  It's safe to say N here.
 
+config MTK_SCP
+   tristate "Mediatek SCP support"
+   depends on ARCH_MEDIATEK
+   help
+ Say y here to support Mediatek's System Companion Processor (SCP) via
+ the remote processor framework.
+
+ It's safe to say N here.
+
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on ARCH_OMAP4 || SOC_OMAP5
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 00f09e658cb3..e30a1b15fbac 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -10,6 +10,7 @@ remoteproc-y  += remoteproc_sysfs.o
 remoteproc-y   += remoteproc_virtio.o
 remoteproc-y   += remoteproc_elf_loader.o
 obj-$(CONFIG_IMX_REMOTEPROC)   += imx_rproc.o
+obj-$(CONFIG_MTK_SCP)  += mtk_scp.o mtk_scp_ipi.o
 obj-$(CONFIG_OMAP_REMOTEPROC)  += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
new file mode 100644
index ..622e9aebe9ab
--- /dev/null
+++ b/drivers/remoteproc/mtk_common.h
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ */
+
+#ifndef __RPROC_MTK_COMMON_H
+#define __RPROC_MTK_COMMON_H
+
+#include 
+#include 
+#include 
+#include 
+
+#define MT8183_SW_RSTN 0x0
+#define MT8183_SW_RSTN_BIT BIT(0)
+#define MT8183_SCP_TO_HOST 0x1C
+#define MT8183_SCP_IPC_INT_BIT BIT(0)
+#define MT8183_SCP_WDT_INT_BIT BIT(8)
+#define MT8183_HOST_TO_SCP 0x28
+#define MT8183_HOST_IPC_INT_BITBIT(0)
+#define MT8183_WDT_CFG 0x84
+#define MT8183_SCP_CLK_SW_SEL  0x4000
+#define MT8183_SCP_CLK_DIV_SEL 0x4024
+#define MT8

[PATCH v17 5/5] arm64: dts: mt8183: add scp node

[Pi-Hsun Shih]

From: Eddie Huang 

Add scp node to mt8183 and mt8183-evb

Signed-off-by: Erin Lo 
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Eddie Huang 
---
Changes from v16, v15, v14:
 - No change.

Changes from v13:
 - Change the size of the cfg register region.

Changes from v12, v11, v10:
 - No change.

Changes from v9:
 - Remove extra reserve-memory-vpu_share node.

Changes from v8:
 - New patch.
---
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi| 12 
 2 files changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 1fb195c683c3..ddb7a7ac9655 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -24,6 +24,17 @@
chosen {
stdout-path = "serial0:921600n8";
};
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   scp_mem_reserved: scp_mem_region {
+   compatible = "shared-dma-pool";
+   reg = <0 0x5000 0 0x290>;
+   no-map;
+   };
+   };
 };
 
 &auxadc {
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 97f84aa9fc6e..3dd1b76bbaf5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -269,6 +269,18 @@
clock-names = "spi", "wrap";
};
 
+   scp: scp@1050 {
+   compatible = "mediatek,mt8183-scp";
+   reg = <0 0x1050 0 0x8>,
+ <0 0x105c 0 0x19080>;
+   reg-names = "sram", "cfg";
+   interrupts = ;
+   clocks = <&infracfg CLK_INFRA_SCPSYS>;
+   clock-names = "main";
+   memory-region = <&scp_mem_reserved>;
+   status = "disabled";
+   };
+
auxadc: auxadc@11001000 {
compatible = "mediatek,mt8183-auxadc",
 "mediatek,mt8173-auxadc";
-- 
2.23.0.187.g17f5b7556c-goog

[PATCH v17 1/5] dt-bindings: Add a binding for Mediatek SCP

[Pi-Hsun Shih]

From: Erin Lo 

Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.

Signed-off-by: Erin Lo 
Signed-off-by: Pi-Hsun Shih 
Reviewed-by: Rob Herring 
---
Changes from v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6:
 - No change.

Changes from v5:
 - Remove dependency on CONFIG_RPMSG_MTK_SCP.

Changes from v4:
 - Add detail of more properties.
 - Document the usage of mtk,rpmsg-name in subnode from the new design.

Changes from v3:
 - No change.

Changes from v2:
 - No change. I realized that for this patch series, there's no need to
   add anything under the mt8183-scp node (neither the mt8183-rpmsg or
   the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
   directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
   created by SCP name service.

Changes from v1:
 - No change.
---
 .../bindings/remoteproc/mtk,scp.txt   | 36 +++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt 
b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index ..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible   Should be "mediatek,mt8183-scp"
+- reg  Should contain the address ranges for the two memory
+   regions, SRAM and CFG.
+- reg-namesContains the corresponding names for the two memory
+   regions. These should be named "sram" & "cfg".
+- clocks   Clock for co-processor (See: 
../clock/clock-bindings.txt)
+- clock-names  Contains the corresponding name for the clock. This
+   should be named "main".
+
+Subnodes
+
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name   Contains the name for the rpmsg device. Used to match
+   the subnode to rpmsg device announced by SCP.
+
+Example:
+
+   scp: scp@1050 {
+   compatible = "mediatek,mt8183-scp";
+   reg = <0 0x1050 0 0x8>,
+ <0 0x105c 0 0x5000>;
+   reg-names = "sram", "cfg";
+   clocks = <&infracfg CLK_INFRA_SCPSYS>;
+   clock-names = "main";
+   };
-- 
2.23.0.187.g17f5b7556c-goog

[PATCH v17 0/5] Add support for mt8183 SCP.

[Pi-Hsun Shih]

Add support for controlling and communicating with mt8183's system
control processor (SCP), using the remoteproc & rpmsg framework.
And also add a cros_ec driver for CrOS EC host command over rpmsg.

The overall structure of the series is:
* remoteproc/mtk_scp.c: Control the start / stop of SCP (Patch 2, 3).
* remoteproc/mtk_scp_ipi.c: Communicates to SCP using inter-processor
  interrupt (IPI) and shared memory (Patch 2, 3).
* rpmsg/mtk_rpmsg.c: Wrapper to wrap the IPI communication into a rpmsg
  device. Supports name service for SCP firmware to
  announce channels (Patch 4).
* add scp dts node to mt8183 platform (Patch 5).

Changes from v16:
 - Change the desc_lock mutex to be a per-id lock.
 - Put the execution of handler inside the per-id lock, to prevent race
   between scp_ipi_unregister and handler being run.
 - Move the initialization of mutex to before scp_ipi_register.

Changes from v15:
 - Fix a bug on incorrect usage of wait_event_timeout return value.

Changes from v14:
 - Fix a typo on variable in DEBUG section.

Changes from v13:
 - Move include/linux/platform_data/mtk_scp.h to
   include/linux/remoteproc/mtk_scp.h.
 - Rename scp_get_reserve_* to scp_get_reserved_*.
 - Add lock for access of scp->ipi_desc.
 - Lock the whole ipi_send function.
 - Move more setting of cache size from SCP firmware to kernel driver,
   to prevent problem while loading firmware onto DRAM.
 - Minor fixes addressing comment.

Changes from v12:
 - Initialize cache before firmware load, to avoid problem while loading
   large firmware.
 - Disable watchdog before stopping SCP, to avoid extra warning message.
 - Fix new warnings by checkpatch.

Changes from v11:
 - Fixed a bug that mtk_rpmsg_endpoint is not properly cleaned up if
   rproc_boot fails.
 - Add missing documentation in comment.

Changes from v10:
 - Drop applied cros_ec_rpmsg patches.
 - Add clock reset before loading SCP firmware.
 - Fix some type mismatch warnings when printing debug messages.

Changes from v9:
 - Remove reserve-memory-vpu_share node.
 - Remove change to cros_ec_commands.h (That is already in
   https://lore.kernel.org/lkml/20190518063949.GY4319@dell/T/)

Changes from v8:
 - Rebased onto https://patchwork.kernel.org/cover/10962385/.
 - Drop merged cros_ec_rpmsg patch, and add scp dts node patch.
 - Add more reserved memory region.

Changes from v7:
 - Rebase onto https://lore.kernel.org/patchwork/patch/1059196/.
 - Fix clock enable/disable timing for SCP driver.
 - Add more SCP IPI ID.

Changes from v6:
 - Decouple mtk_rpmsg from mtk_scp.
 - Change data of EC response to be aligned to 4 bytes.

Changes from v5:
 - Add device tree binding document for cros_ec_rpmsg.
 - Better document in comments for cros_ec_rpmsg.
 - Remove dependency on CONFIG_ in binding tree document.

Changes from v4:
 - Merge patch 6 (Load ELF firmware) into patch 2, so the driver loads
   ELF firmware by default, and no longer accept plain binary.
 - rpmsg_device listed in device tree (as a child of the SCP node) would
   have it's device tree node mapped to the rpmsg_device, so the rpmsg
   driver can use the properties on device tree.

Changes from v3:
 - Make writing to SCP SRAM aligned.
 - Add a new patch (Patch 6) to load ELF instead of bin firmware.
 - Add host event support for EC driver.
 - Fix some bugs found in testing (missing spin_lock_init,
   rproc_subdev_unprepare to rproc_subdev_stop).
 - Fix some coding style issue found by checkpatch.pl.

Changes from v2:
 - Fold patch 3 into patch 2 in v2.
 - Move IPI id around to support cross-testing for old and new firmware.
 - Finish more TODO items.

Changes from v1:
 - Extract functions and rename variables in mtk_scp.c.
 - Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
   short-lived work items.
 - Code format fix based on feedback for cros_ec_rpmsg.c.
 - Extract feature detection for SCP into separate patch (Patch 6).

Eddie Huang (1):
  arm64: dts: mt8183: add scp node

Erin Lo (3):
  dt-bindings: Add a binding for Mediatek SCP
  remoteproc/mediatek: add SCP support for mt8183
  remoteproc: mt8183: add reserved memory manager API

Pi-Hsun Shih (1):
  rpmsg: add rpmsg support for mt8183 SCP.

 .../bindings/remoteproc/mtk,scp.txt   |  36 +
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |  11 +
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  |  12 +
 drivers/remoteproc/Kconfig|  10 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/mtk_common.h   |  94 +++
 drivers/remoteproc/mtk_scp.c  | 722 ++
 drivers/remoteproc/mtk_scp_ipi.c  | 177 +
 drivers/rpmsg/Kconfig |   9 +
 drivers/rpmsg/Makefile|   1 +
 drivers/rpmsg/mtk_rpmsg.c | 414 ++
 include/linux/remoteproc/mtk_scp.h| 168 
 include/linux/rpmsg/mtk_rpmsg.h   |  38 +
 13 files changed, 1693 insertions(+)
 create mode 100

[PATCH v2] doc: kvm: Fix return description of KVM_SET_MSRS

[Xiaoyao Li]

Userspace can use ioctl KVM_SET_MSRS to update a set of MSRs of guest.
This ioctl sets specified MSRs one by one. Once it fails to set an MSR
due to setting reserved bits, the MSR is not supported/emulated by kvm,
or violating other restrictions, it stops further processing and returns
the number of MSRs have been set successfully.

Signed-off-by: Xiaoyao Li 
---
v2:
  elaborate the changelog and description of ioctl KVM_SET_MSRS based on
  Sean's comments.

---
 Documentation/virt/kvm/api.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.txt b/Documentation/virt/kvm/api.txt
index 2d067767b617..4638e893dec0 100644
--- a/Documentation/virt/kvm/api.txt
+++ b/Documentation/virt/kvm/api.txt
@@ -586,7 +586,7 @@ Capability: basic
 Architectures: x86
 Type: vcpu ioctl
 Parameters: struct kvm_msrs (in)
-Returns: 0 on success, -1 on error
+Returns: number of msrs successfully set (see below), -1 on error
 
 Writes model-specific registers to the vcpu.  See KVM_GET_MSRS for the
 data structures.
@@ -595,6 +595,11 @@ Application code should set the 'nmsrs' member (which 
indicates the
 size of the entries array), and the 'index' and 'data' members of each
 array entry.
 
+It tries to set the MSRs in array entries[] one by one. Once failing to
+set an MSR (due to setting reserved bits, the MSR is not supported/emulated
+by kvm, or violating other restrctions), it stops setting following MSRs
+and returns the number of MSRs have been set successfully.
+
 
 4.20 KVM_SET_CPUID
 
-- 
2.19.1

Re: [PATCH] net/skbuff: silence warnings under memory pressure

[Michal Hocko]

> On Tue, 2019-09-03 at 20:53 +0200, Michal Hocko wrote:
> > On Tue 03-09-19 11:42:22, Qian Cai wrote:
> > > On Tue, 2019-09-03 at 15:22 +0200, Michal Hocko wrote:
> > > > On Fri 30-08-19 18:15:22, Eric Dumazet wrote:
> > > > > If there is a risk of flooding the syslog, we should fix this
> > > > > generically
> > > > > in mm layer, not adding hundred of __GFP_NOWARN all over the places.
> > > > 
> > > > We do already ratelimit in warn_alloc. If it isn't sufficient then we
> > > > can think of a different parameters. Or maybe it is the ratelimiting
> > > > which doesn't work here. Hard to tell and something to explore.
> > > 
> > > The time-based ratelimit won't work for skb_build() as when a system under
> > > memory pressure, and the CPU is fast and IO is so slow, it could take a 
> > > long
> > > time to swap and trigger OOM.
> > 
> > I really do not understand what does OOM and swapping have to do with
> > the ratelimiting here. The sole purpose of the ratelimit is to reduce
> > the amount of warnings to be printed. Slow IO might have an effect on
> > when the OOM killer is invoked but atomic allocations are not directly
> > dependent on IO.
> 
> When there is a heavy memory pressure, the system is trying hard to reclaim
> memory to fill up the watermark. However, the IO is slow to page out, but the
> memory pressure keep draining atomic reservoir, and some of those skb_build()
> will fail eventually.

Yes this is true but this has nothing to do with the ratelimitted
warn_alloc AFAICS. It is natural that atomic allocations are going
to fail more likely under extreme memory pressure but we are talking
about an excessive amount of debugging output that is generated and
that should be throttled. And that's why we have ratelimit there. If it
doesn't work well then we should look into why.

> Only if there is a fast IO, it will finish swapping sooner and then invoke the
> OOM to end the memory pressure.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] net/skbuff: silence warnings under memory pressure

[Michal Hocko]

Cc printk maintainers

On Tue 03-09-19 17:42:28, Qian Cai wrote:
> > > I suppose what happens is those skb_build() allocations are from softirq,
> > > and
> > > once one of them failed, it calls printk() which generates more 
> > > interrupts.
> > > Hence, the infinite loop.
> > 
> > Please elaborate more.
> > 
> 
> If you look at the original report, the failed allocation dump_stack() is,
> 
>  
>  warn_alloc.cold.43+0x8a/0x148
>  __alloc_pages_nodemask+0x1a5c/0x1bb0
>  alloc_pages_current+0x9c/0x110
>  allocate_slab+0x34a/0x11f0
>  new_slab+0x46/0x70
>  ___slab_alloc+0x604/0x950
>  __slab_alloc+0x12/0x20
>  kmem_cache_alloc+0x32a/0x400
>  __build_skb+0x23/0x60
>  build_skb+0x1a/0xb0
>  igb_clean_rx_irq+0xafc/0x1010 [igb]
>  igb_poll+0x4bb/0xe30 [igb]
>  net_rx_action+0x244/0x7a0
>  __do_softirq+0x1a0/0x60a
>  irq_exit+0xb5/0xd0
>  do_IRQ+0x81/0x170
>  common_interrupt+0xf/0xf
>  
> 
> Since it has no __GFP_NOWARN to begin with, it will call,
> 
> printk
>   vprintk_default
> vprintk_emit
>   wake_up_klogd
> irq_work_queue
>   __irq_work_queue_local
> arch_irq_work_raise
>   apic->send_IPI_self(IRQ_WORK_VECTOR)
> smp_irq_work_interrupt
>   exiting_irq
> irq_exit
> 
> and end up processing pending net_rx_action softirqs again which are plenty 
> due
> to connected via ssh etc.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/1] mm/pgtable/debug: Add test validating architecture page table helpers

[Anshuman Khandual]

On 09/03/2019 04:43 PM, kbuild test robot wrote:
> Hi Anshuman,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc7 next-20190902]
> [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/Anshuman-Khandual/mm-debug-Add-tests-for-architecture-exported-page-table-helpers/20190903-162959
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=m68k 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from arch/m68k/include/asm/bug.h:32:0,
> from include/linux/bug.h:5,
> from include/linux/thread_info.h:12,
> from include/asm-generic/preempt.h:5,
> from ./arch/m68k/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:78,
> from arch/m68k/include/asm/irqflags.h:6,
> from include/linux/irqflags.h:16,
> from arch/m68k/include/asm/atomic.h:6,
> from include/linux/atomic.h:7,
> from include/linux/mm_types_task.h:13,
> from include/linux/mm_types.h:5,
> from include/linux/hugetlb.h:5,
> from mm/arch_pgtable_test.c:14:
>mm/arch_pgtable_test.c: In function 'pmd_clear_tests':
>>> arch/m68k/include/asm/page.h:31:22: error: lvalue required as unary '&' 
>>> operand
> #define pmd_val(x) ((&x)->pmd[0])
>  ^
>include/asm-generic/bug.h:124:25: note: in definition of macro 'WARN_ON'
>  int __ret_warn_on = !!(condition);\
> ^
>>> arch/m68k/include/asm/motorola_pgtable.h:138:26: note: in expansion of 
>>> macro 'pmd_val'
> #define pmd_none(pmd)  (!pmd_val(pmd))
>  ^~~
>>> mm/arch_pgtable_test.c:233:11: note: in expansion of macro 'pmd_none'
>  WARN_ON(!pmd_none(READ_ONCE(*pmdp)));
>   ^~~~
>mm/arch_pgtable_test.c: In function 'pmd_populate_tests':
>>> arch/m68k/include/asm/page.h:31:22: error: lvalue required as unary '&' 
>>> operand
> #define pmd_val(x) ((&x)->pmd[0])

Storing READ_ONCE(*pmdp) in a local pmd_t variable first solves the problem.

[PATCH 1/4] gpio/aspeed: Fix incorrect number of banks

[Rashmica Gupta]

Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')

Signed-off-by: Rashmica Gupta 
---
 drivers/gpio/gpio-aspeed.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 9defe25d4721..77752b2624e8 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct 
platform_device *pdev)
gpio->chip.base = -1;
 
/* Allocate a cache of the output registers */
-   banks = gpio->config->nr_gpios >> 5;
+   banks = (gpio->config->nr_gpios >> 5) + 1;
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
-- 
2.20.1

[PATCH 4/4] gpio: Update documentation with ast2600 controllers

[Rashmica Gupta]

Signed-off-by: Rashmica Gupta 
---
 Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt 
b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
index 7e9b586770b0..cd388797e07c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
@@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
 ---
 
 Required properties:
-- compatible   : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
+- compatible   : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
+ "aspeed,ast2600-gpio", or 
"aspeed,ast2600-1-8v-gpio"
 
 - #gpio-cells  : Should be two
  - First cell is the GPIO line number
-- 
2.20.1

[PATCH 3/4] gpio: Add in ast2600 details to Aspeed driver

[Rashmica Gupta]

The ast2600 has two gpio controllers, one for 3.6V GPIOS and one for 1.8V GPIOS.

Signed-off-by: Rashmica Gupta 
---
 drivers/gpio/gpio-aspeed.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 60ab042c9129..98881c99d0b9 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct irq_chip *ic = irq_desc_get_chip(desc);
struct aspeed_gpio *data = gpiochip_get_data(gc);
-   unsigned int i, p, girq;
+   unsigned int i, p, girq, banks;
unsigned long reg;
+   struct aspeed_gpio *gpio = gpiochip_get_data(gc);
 
chained_irq_enter(ic, desc);
 
-   for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
+   banks = (gpio->config->nr_gpios >> 5) + 1;
+   for (i = 0; i < banks; i++) {
const struct aspeed_gpio_bank *bank = &aspeed_gpio_banks[i];
 
reg = ioread32(bank_reg(data, bank, reg_irq_status));
@@ -1108,9 +1110,32 @@ static const struct aspeed_gpio_config ast2500_config =
/* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
{ .nr_gpios = 232, .props = ast2500_bank_props, };
 
+static const struct aspeed_bank_props ast2600_bank_props[] = {
+   /* input  output   */
+   {5, 0x,  0x}, /* U/V/W/X */
+   {6, 0x,  0x0fff}, /* Y/Z */
+   { },
+};
+
+static const struct aspeed_gpio_config ast2600_config =
+   /* 208 3.6V GPIOs */
+   { .nr_gpios = 208, .props = ast2600_bank_props, };
+
+static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
+   /* input  output   */
+   {1, 0x000f,  0x000f}, /* E */
+   { },
+};
+
+static const struct aspeed_gpio_config ast2600_1_8v_config =
+   /* 36 1.8V GPIOs */
+   { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
+
 static const struct of_device_id aspeed_gpio_of_table[] = {
{ .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config, },
{ .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config, },
+   { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config, },
+   { .compatible = "aspeed,ast2600-1-8v-gpio", .data = 
&ast2600_1_8v_config,},
{}
 };
 MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
-- 
2.20.1

[PATCH 2/4] gpio/aspeed: Setup irqchip dynamically

[Rashmica Gupta]

This is in preparation for ast2600 as we will have two gpio drivers
which need their own irqchip.

Signed-off-by: Rashmica Gupta 
---
 drivers/gpio/gpio-aspeed.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 77752b2624e8..60ab042c9129 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -52,6 +52,7 @@ struct aspeed_gpio_config {
  */
 struct aspeed_gpio {
struct gpio_chip chip;
+   struct irq_chip irqc;
spinlock_t lock;
void __iomem *base;
int irq;
@@ -681,14 +682,6 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(ic, desc);
 }
 
-static struct irq_chip aspeed_gpio_irqchip = {
-   .name   = "aspeed-gpio",
-   .irq_ack= aspeed_gpio_irq_ack,
-   .irq_mask   = aspeed_gpio_irq_mask,
-   .irq_unmask = aspeed_gpio_irq_unmask,
-   .irq_set_type   = aspeed_gpio_set_type,
-};
-
 static void set_irq_valid_mask(struct aspeed_gpio *gpio)
 {
const struct aspeed_bank_props *props = gpio->config->props;
@@ -1192,7 +1185,12 @@ static int __init aspeed_gpio_probe(struct 
platform_device *pdev)
 
gpio->irq = rc;
girq = &gpio->chip.irq;
-   girq->chip = &aspeed_gpio_irqchip;
+   girq->chip = &gpio->irqc;
+   girq->chip->name = dev_name(&pdev->dev);
+   girq->chip->irq_ack = aspeed_gpio_irq_ack;
+   girq->chip->irq_mask = aspeed_gpio_irq_mask;
+   girq->chip->irq_unmask = aspeed_gpio_irq_unmask;
+   girq->chip->irq_set_type = aspeed_gpio_set_type;
girq->parent_handler = aspeed_gpio_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(&pdev->dev, 1,
-- 
2.20.1

RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode

[Kobayashi, Kento (Sony)]

Hi,

My company's member, Mr.Jacky, sent patch in June 26th.
But we didn't receive comment about our patch.
Could you confirm and tell us this patch is needed or not?

Regards,
Kento Kobayashi



From: Cao, Jacky  
Sent: Monday, July 15, 2019 10:05 AM
To: ba...@kernel.org; gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Kobayashi, Kento 
(Sony) ; Cao, Jacky 
Subject: RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode

Hi, 

Since around half month past, let me confirm the status of this issue.
If any comment about the fix patch, would you kind to share with us? 
Thank you.

Best Regards
Jacky

From: Cao, Jacky 
Sent: Wednesday, June 26, 2019 1:48 PM
To: mailto:ba...@kernel.org; mailto:gre...@linuxfoundation.org; 
mailto:linux-...@vger.kernel.org; mailto:linux-kernel@vger.kernel.org
Cc: Kobayashi, Kento (Sony) ; Cao, Jacky 

Subject: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode

The power budget for SuperSpeed mode should be 900 mA
according to USB3.0 specification, so set the power
budget to 900 mA for dummy_start_ss which is only used
for SuperSpeed mode.

If the max power consumption of SuperSpeed device is
larger than 500 mA, insufficient available bus power
error happens in usb_choose_configuration function
when the device connects to dummy hcd.

Signed-off-by: Jacky Cao 
---
drivers/usb/gadget/udc/dummy_hcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index 8414fac..52f2cf5 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -48,6 +48,7 @@
#define DRIVER_VERSION "02 May 2005"

 #define POWER_BUDGET  500  /* in mA; use 8 for low-power port testing */
+#define POWER_BUDGET_3_0  900  /* in mA */

 static const char  driver_name[] = "dummy_hcd";
static const char  driver_desc[] = "USB Host+Gadget Emulator";
@@ -2432,7 +2433,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd)
 dum_hcd->rh_state = DUMMY_RH_RUNNING;
 dum_hcd->stream_en_ep = 0;
 INIT_LIST_HEAD(&dum_hcd->urbp_list);
- dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET;
+ dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0;
 dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING;
 dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1;
#ifdef CONFIG_USB_OTG
-- 
2.7.4

Re: [PATCH -next] carl9170: remove set but not used variable 'udev'

[Kalle Valo]

YueHaibing  wrote:

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/wireless/ath/carl9170/usb.c: In function carl9170_usb_disconnect:
> drivers/net/wireless/ath/carl9170/usb.c:1110:21:
>  warning: variable udev set but not used [-Wunused-but-set-variable]
> 
> It is not use since commit feb09b293327 ("carl9170:
> fix misuse of device driver API")
> 
> Reported-by: Hulk Robot 
> Signed-off-by: YueHaibing 
> Acked-by: Christian Lamparter 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

68092f9cf932 carl9170: remove set but not used variable 'udev'

-- 
https://patchwork.kernel.org/patch/11027909/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v1 14/18] MIPS: Loongson64: Add generic dts

[Jiaxun Yang]

在 2019/9/4 11:44, 陈华才 写道:

Hi, Jiaxun,

1, There are too many dts files (all cputype/boardtype/n-ways combinations), in 
my opinon we don't need to distinguish 1way/2way/4way. In this way we can 
largely reduce dts files.

2, Please don't use "ls" to stand-for loongson, at least in file names.


Thanks, I'm going to drop cpu node in v2.

Renaming files seems meaningless, but I'm going to do that too.

--

Jiaxun Yang

Re: [PATCH] wil6210: Delete an unnecessary kfree() call in wil_tid_ampdu_rx_alloc()

[Kalle Valo]

Markus Elfring  wrote:

> A null pointer would be passed to a call of the function “kfree”
> directly after a call of the function “kcalloc” failed at one place.
> Remove this superfluous function call.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> Reviewed-by: Maya Erez 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

d20b1e6c8307 wil6210: Delete an unnecessary kfree() call in 
wil_tid_ampdu_rx_alloc()

-- 
https://patchwork.kernel.org/patch/7119/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] nvme-core: Fix subsystem instance mismatches

[Christoph Hellwig]

On Tue, Sep 03, 2019 at 10:46:20AM -0600, Keith Busch wrote:
> Could we possibly make /dev/nvmeX be a subsystem handle without causing
> trouble for anyone? This would essentially be the same thing as today
> for non-CMIC controllers with a device-per-controller and only affects
> the CMIC ones.

A per-subsyste character device doesn't make sense, as a lot of admin
command require a specific controller.

If this really is an isue for people we'll just need to refcount the
handle allocation.  That is:

 - nvme_init_ctrl allocates a new nvme_instance or so object, which
   does the ida_simple_get.
 - we allocate a new subsystem that reuses the handle and grabs
   a reference in nvme_init_subsystem, then if we find an existing
   subsystem we drop that reference again.
 - last free of a ctrl or subsystem also drops a reference, with
   the final free releasing the ida

Re: [PATCH][next] wil6210: fix wil_cid_valid with negative cid values

[Kalle Valo]

Colin King  wrote:

> There are several occasions where a negative cid value is passed
> into wil_cid_valid and this is converted into a u8 causing the
> range check of cid >= 0 to always succeed.  Fix this by making
> the cid argument an int to handle any -ve error value of cid.
> 
> An example of this behaviour is in wil_cfg80211_dump_station,
> where cid is assigned -ENOENT if the call to wil_find_cid_by_idx
> fails, and this -ve value is passed to wil_cid_valid.  I believe
> that the conversion of -ENOENT to the u8 value 254 which is
> greater than wil->max_assoc_sta causes wil_find_cid_by_idx to
> currently work fine, but I think is by luck and not the
> intended behaviour.
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Maya Erez 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

23bb9f692b66 wil6210: fix wil_cid_valid with negative cid values

-- 
https://patchwork.kernel.org/patch/11027989/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [RT PATCH v2] net/xfrm/xfrm_ipcomp: Protect scratch buffer with local_lock

[Joerg Vehlow]

I just happen to be analyzing an error in the kernel if ipcomp is used with rt 
patches. The reason was the meissing lock around the scratch buffer for the 
compress call. Now that I have applied Juris fix, I get another error:

[  139.717259] BUG: unable to handle kernel NULL pointer dereference at 
0518
[  139.717260] PGD 0 P4D 0 
[  139.717262] Oops:  [#1] PREEMPT SMP PTI
[  139.717273] CPU: 2 PID: 11987 Comm: netstress Not tainted 
4.19.59-rt24-preemt-rt #1
[  139.717274] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[  139.717306] RIP: 0010:xfrm_trans_reinject+0x97/0xd0
[  139.717307] Code: 42 eb 45 83 6d b0 01 31 f6 48 8b 42 08 48 c7 42 08 00 00 
00 00 48 8b 0a 48 c7 02 00 00 00 00 48 89 41 08 48 89 08 48 8b 42 10 <48> 8b b8 
18 05 00 00 48 8b 42 40 e8 d9 e1 4b 00 48 8b 55 a0 48 39
[  139.717307] RSP: 0018:c97b37e8 EFLAGS: 00010246
[  139.717308] RAX:  RBX: c97b37e8 RCX: 88807db206a8
[  139.717309] RDX: 88807db206a8 RSI:  RDI: 
[  139.717309] RBP: c97b3848 R08: 0001 R09: c97b35c8
[  139.717309] R10: ea0001dcfc00 R11: 000890c4 R12: 88807db20680
[  139.717310] R13: 000f4240 R14:  R15: 
[  139.717310] FS:  7f4643034700() GS:88807db0() 
knlGS:
[  139.717311] CS:  0010 DS:  ES:  CR0: 80050033
[  139.717337] CR2: 0518 CR3: 769c6000 CR4: 06e0
[  139.717350] DR0:  DR1:  DR2: 
[  139.717350] DR3:  DR6: fffe0ff0 DR7: 0400
[  139.717350] Call Trace:
[  139.717387]  tasklet_action_common.isra.18+0x6d/0xd0
[  139.717388]  tasklet_action+0x1d/0x20
[  139.717389]  do_current_softirqs+0x196/0x360
[  139.717390]  __local_bh_enable+0x51/0x60
[  139.717397]  ip_finish_output2+0x18b/0x3f0
[  139.717408]  ? task_rq_lock+0x53/0xe0
[  139.717415]  ip_finish_output+0xbe/0x1b0
[  139.717416]  ip_output+0x72/0x100
[  139.717422]  ? ipcomp_output+0x5e/0x280
[  139.717424]  xfrm_output_resume+0x4b5/0x540
[  139.717436]  ? refcount_dec_and_test_checked+0x11/0x20
[  139.717443]  ? kfree_skbmem+0x33/0x80
[  139.717444]  xfrm_output+0xd7/0x110
[  139.717451]  xfrm4_output_finish+0x2b/0x30
[  139.717452]  __xfrm4_output+0x3a/0x50
[  139.717453]  xfrm4_output+0x40/0xe0
[  139.717454]  ? xfrm_dst_check+0x174/0x250
[  139.717455]  ? xfrm4_output+0x40/0xe0
[  139.717456]  ? xfrm_dst_check+0x174/0x250
[  139.717457]  ip_local_out+0x3b/0x50
[  139.717458]  __ip_queue_xmit+0x16b/0x420
[  139.717464]  ip_queue_xmit+0x10/0x20
[  139.717466]  __tcp_transmit_skb+0x566/0xad0
[  139.717467]  tcp_write_xmit+0x3a4/0x1050
[  139.717468]  __tcp_push_pending_frames+0x35/0xe0
[  139.717469]  tcp_push+0xdb/0x100
[  139.717469]  tcp_sendmsg_locked+0x491/0xd70
[  139.717470]  tcp_sendmsg+0x2c/0x50
[  139.717476]  inet_sendmsg+0x3e/0xf0
[  139.717483]  sock_sendmsg+0x3e/0x50
[  139.717484]  __sys_sendto+0x114/0x1a0
[  139.717491]  ? __rt_mutex_unlock+0xe/0x10
[  139.717492]  ? _mutex_unlock+0xe/0x10
[  139.717500]  ? ksys_write+0xc5/0xe0
[  139.717501]  __x64_sys_sendto+0x28/0x30
[  139.717503]  do_syscall_64+0x4d/0x110
[  139.717504]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Did I find some other bug here? Can you maybe point me in a direction,
because I am quite lost now where to look.


Apart from that:
Also is the bh_disable/bh_enable in ipcomp_compress even required, if
a lock is used?

Joerg

Re: [PATCH 1/2] dt-bindings: milbeaut-m10v-xdmac: Add Socionext Milbeaut XDMAC bindings

[Vinod Koul]

On 18-08-19, 00:22, jassisinghb...@gmail.com wrote:
> From: Jassi Brar 
> 
> Document the devicetree bindings for Socionext Milbeaut XDMAC
> controller. Controller only supports Mem->Mem transfers. Number
> of physical channels are determined by the number of irqs registered.
> 
> Signed-off-by: Jassi Brar 
> ---
>  .../bindings/dma/milbeaut-m10v-xdmac.txt  | 24 +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/dma/milbeaut-m10v-xdmac.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-xdmac.txt 
> b/Documentation/devicetree/bindings/dma/milbeaut-m10v-xdmac.txt
> new file mode 100644
> index ..1f15512e3f19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-xdmac.txt
> @@ -0,0 +1,24 @@
> +* Milbeaut AXI DMA Controller
> +
> +Milbeaut AXI DMA controller has only memory to memory transfer capability.
> +
> +* DMA controller
> +
> +Required property:
> +- compatible:Should be  "socionext,milbeaut-m10v-xdmac"
> +- reg:   Should contain DMA registers location and length.
> +- interrupts:Should contain all of the per-channel DMA interrupts.
> +Number of channels is configurable - 2, 4 or 8, so
> +the number of interrupts specfied should be {2,4,8}.

s/specfied/specified

-- 
~Vinod

linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi all,

After merging the net-next tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

scripts/link-vmlinux.sh: 74: Bad substitution

Caused by commit

  341dfcf8d78e ("btf: expose BTF info through sysfs")

interacting with commit

  1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension")

from the kbuild tree.

The change in the net-next tree turned link-vmlinux.sh into a bash script
(I think).

I have applied the following patch for today:

From: Stephen Rothwell 
Date: Wed, 4 Sep 2019 15:43:41 +1000
Subject: [PATCH] link-vmlinux.sh is now a bash script

Signed-off-by: Stephen Rothwell 
---
 Makefile| 4 ++--
 scripts/link-vmlinux.sh | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index ac97fb282d99..523d12c5cebe 100644
--- a/Makefile
+++ b/Makefile
@@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard 
$(srctree)/arch/$(SRCARCH)/Makefile.postlink)
 
 # Final link of vmlinux with optional arch pass after final link
 cmd_link-vmlinux = \
-   $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
+   $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
 
 vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
@@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES)
 PHONY += archclean vmlinuxclean
 
 vmlinuxclean:
-   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean
+   $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean
$(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean)
 
 clean: archclean vmlinuxclean
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index f7edb75f9806..ea1f8673869d 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 # SPDX-License-Identifier: GPL-2.0
 #
 # link vmlinux
-- 
2.23.0.rc1

-- 
Cheers,
Stephen Rothwell


pgpZGTOrUpsca.pgp
Description: OpenPGP digital signature

Re: [PATCH] dmaengine: sprd: Fix the DMA link-list configuration

[Vinod Koul]

On 30-08-19, 15:37, Baolin Wang wrote:
> For the Spreadtrum DMA link-list mode, when the DMA engine got a slave
> hardware request, which will trigger the DMA engine to load the DMA
> configuration from the link-list memory automatically. But before the
> slave hardware request, the slave will get an incorrect residue due
> to the first node used to trigger the link-list was configured as the
> last source address and destination address.
> 
> Thus we should make sure the first node was configured the start source
> address and destination address, which can fix this issue.

Applied, thanks

-- 
~Vinod

[PATCH] mfd: intel-lpss: Add default I2C device properties for Gemini Lake

[Jarkko Nikula]

It turned out Intel Gemini Lake doesn't use the same I2C timing
parameters as Broxton.

I got confirmation from the Windows team that Gemini Lake systems should
use updated timing parameters that differ from those used in Broxton
based systems.

Fixes: f80e78aa11ad ("mfd: intel-lpss: Add Intel Gemini Lake PCI IDs")
Tested-by: Chris Chiu 
Signed-off-by: Jarkko Nikula 
---
This is not immediate stable material since there is no regression
related to this. Those machines that need updated parameters have
obviously never worked and I don't want this to cause regression either
so better to let this get some test coverage first.
---
 drivers/mfd/intel-lpss-pci.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index ade6e1ce5a98..269cb851a596 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -120,6 +120,18 @@ static const struct intel_lpss_platform_info apl_i2c_info 
= {
.properties = apl_i2c_properties,
 };
 
+static struct property_entry glk_i2c_properties[] = {
+   PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 313),
+   PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
+   PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 290),
+   { },
+};
+
+static const struct intel_lpss_platform_info glk_i2c_info = {
+   .clk_rate = 13300,
+   .properties = glk_i2c_properties,
+};
+
 static const struct intel_lpss_platform_info cnl_i2c_info = {
.clk_rate = 21600,
.properties = spt_i2c_properties,
@@ -172,14 +184,14 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x1ac6), (kernel_ulong_t)&bxt_info },
{ PCI_VDEVICE(INTEL, 0x1aee), (kernel_ulong_t)&bxt_uart_info },
/* GLK */
-   { PCI_VDEVICE(INTEL, 0x31ac), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31ae), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31b0), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31b2), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31b4), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31b6), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31b8), (kernel_ulong_t)&bxt_i2c_info },
-   { PCI_VDEVICE(INTEL, 0x31ba), (kernel_ulong_t)&bxt_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31ac), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31ae), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31b0), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31b2), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31b4), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31b6), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31b8), (kernel_ulong_t)&glk_i2c_info },
+   { PCI_VDEVICE(INTEL, 0x31ba), (kernel_ulong_t)&glk_i2c_info },
{ PCI_VDEVICE(INTEL, 0x31bc), (kernel_ulong_t)&bxt_uart_info },
{ PCI_VDEVICE(INTEL, 0x31be), (kernel_ulong_t)&bxt_uart_info },
{ PCI_VDEVICE(INTEL, 0x31c0), (kernel_ulong_t)&bxt_uart_info },
-- 
2.23.0.rc1

[PATCH v5 1/2] dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add a YAML schema to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
changes in v5:
  - earlier Review-by tag given by Rob
  - rework done with syscon parent node.

changes in v4:
  - As per Rob's review: validate 5.2 and 5.3
  - drop unrelated items.

changes in v3:
  - resolve 'make dt_binding_check' warnings

changes in v2:
  As per Rob Herring review comments, the following updates
 - change GPL-2.0 -> (GPL-2.0-only OR BSD-2-Clause)
 - filename is the compatible string plus .yaml
 - LGM: Lightning Mountain
 - update maintainer
 - add intel,syscon under property list
 - keep one example instead of two
---
 .../bindings/phy/intel,lgm-emmc-phy.yaml   | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
new file mode 100644
index ..8f6ac8b3da42
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+description: Bindings for eMMC PHY on Intel's Lightning Mountain SoC, syscon
+  node is used to reference the base address of eMMC phy registers.
+
+select:
+  properties:
+compatible:
+  contains:
+const: intel,lgm-syscon
+
+reg:
+  maxItems: 1
+
+  required:
+- compatible
+- reg
+
+properties:
+  "#phy-cells":
+const: 0
+
+  compatible:
+contains:
+  const: intel,lgm-emmc-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+maxItems: 1
+
+required:
+  - "#phy-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+examples:
+  - |
+sysconf: chiptop@e020 {
+  compatible = "intel,lgm-syscon";
+  reg = <0xe020 0x100>;
+
+  emmc-phy: emmc-phy {
+compatible = "intel,lgm-emmc-phy";
+reg = <0x00a8 0x4>,
+  <0x00ac 0x4>,
+  <0x00b0 0x4>,
+  <0x00b4 0x4>;
+clocks = <&emmc>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+  };
+};
+...
-- 
2.11.0

[PATCH v5 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add support for eMMC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Andy Shevchenko 
---
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/intel/Kconfig  |   9 ++
 drivers/phy/intel/Makefile |   2 +
 drivers/phy/intel/phy-intel-emmc.c | 283 +
 5 files changed, 296 insertions(+)
 create mode 100644 drivers/phy/intel/Kconfig
 create mode 100644 drivers/phy/intel/Makefile
 create mode 100644 drivers/phy/intel/phy-intel-emmc.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0263db2ac874..b3ed94b98d9b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -69,5 +69,6 @@ source "drivers/phy/socionext/Kconfig"
 source "drivers/phy/st/Kconfig"
 source "drivers/phy/tegra/Kconfig"
 source "drivers/phy/ti/Kconfig"
+source "drivers/phy/intel/Kconfig"
 
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c96a1afc95bd..310c149a9df5 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,6 +18,7 @@ obj-y += broadcom/\
   cadence/ \
   freescale/   \
   hisilicon/   \
+  intel/   \
   lantiq/  \
   marvell/ \
   motorola/\
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
new file mode 100644
index ..4ea6a8897cd7
--- /dev/null
+++ b/drivers/phy/intel/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Phy drivers for Intel Lightning Mountain(LGM) platform
+#
+config PHY_INTEL_EMMC
+   tristate "Intel EMMC PHY driver"
+   select GENERIC_PHY
+   help
+ Enable this to support the Intel EMMC PHY
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
new file mode 100644
index ..6b876a75599d
--- /dev/null
+++ b/drivers/phy/intel/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
diff --git a/drivers/phy/intel/phy-intel-emmc.c 
b/drivers/phy/intel/phy-intel-emmc.c
new file mode 100644
index ..1a358e7fd236
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-emmc.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel eMMC PHY driver
+ * Copyright (C) 2019 Intel, Corp.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* eMMC phy register definitions */
+#define EMMC_PHYCTRL0_REG  0xa8
+#define DR_TY_MASK GENMASK(30, 28)
+#define DR_TY_SHIFT(x) (((x) << 28) & DR_TY_MASK)
+#define OTAPDLYENA BIT(14)
+#define OTAPDLYSEL_MASKGENMASK(13, 10)
+#define OTAPDLYSEL_SHIFT(x)(((x) << 10) & OTAPDLYSEL_MASK)
+
+#define EMMC_PHYCTRL1_REG  0xac
+#define PDB_MASK   BIT(0)
+#define PDB_SHIFT(x)   (((x) << 0) & PDB_MASK)
+#define ENDLL_MASK BIT(7)
+#define ENDLL_SHIFT(x) (((x) << 7) & ENDLL_MASK)
+
+#define EMMC_PHYCTRL2_REG  0xb0
+#define FRQSEL_25M 0
+#define FRQSEL_50M 1
+#define FRQSEL_100M2
+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)(((x) << 22) & FRQSEL_MASK)
+
+#define EMMC_PHYSTAT_REG   0xbc
+#define CALDONE_MASK   BIT(9)
+#define DLLRDY_MASKBIT(8)
+#define IS_CALDONE(x)  ((x) & CALDONE_MASK)
+#define IS_DLLRDY(x)   ((x) & DLLRDY_MASK)
+
+struct intel_emmc_phy {
+   struct regmap *syscfg;
+   struct clk *emmcclk;
+};
+
+static int intel_emmc_phy_power(struct phy *phy, bool on_off)
+{
+   struct intel_emmc_phy *priv = phy_get_drvdata(phy);
+   unsigned int caldone;
+   unsigned int dllrdy;
+   unsigned int freqsel;
+   unsigned long rate;
+   int ret, quot;
+
+   /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+   ret = regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG, PDB_MASK,
+PDB_SHIFT(0));
+   if (ret) {
+   dev_err(&phy->dev, "CALIO power down bar failed: %d\n", ret);
+   return ret;
+   }
+
+   /* Already finish power_off above */
+   if (!on_off)
+   return 0;
+
+   rate = clk_get_rate(priv->emmcclk);
+   quot = DIV_ROUND_CLOSEST(rate, 5000);
+   if (quot > FRQSEL_150M)
+   dev_warn(&phy->dev, "Unsupported rate: %lu\n", rate);
+   freqsel = clamp_t(int, quot, FRQSEL_25M, FRQSEL_150M);
+
+   /*
+* According to the user manual, calpad calib

Re: Tweak I2C SDA hold time on GemniLake to make touchpad work

[Jarkko Nikula]

On 9/4/19 7:38 AM, Chris Chiu wrote:

On Tue, Sep 3, 2019 at 8:03 PM Jarkko Nikula
 wrote:


Hi Chris

On 9/3/19 11:18 AM, Mika Westerberg wrote:

+Jarkko

On Tue, Sep 03, 2019 at 04:10:27PM +0800, Chris Chiu wrote:

Hi,

We're working on the acer Gemnilake laptop TravelMate B118-M for
touchpad not working issue. The touchpad fails to bring up and the
i2c-hid ouput the message as follows
  [8.317293] i2c_hid i2c-ELAN0502:00: hid_descr_cmd failed
We tried on latest linux kernel 5.3.0-rc6 and it reports the same.

We then look into I2C signal level measurement to find out why.
The following is the signal output from LA for the SCL/SDA.
https://imgur.com/sKcpvdo
The SCL frequency is ~400kHz from the SCL period, but the SDA
transition is quite weird. Per the I2C spec, the data on the SDA line
must be stable during the high period of the clock. The HIGH or LOW
state of the data line can only change when the clock signal on the
SCL line is LOW. The SDA period span across 2 SCL high, I think
that's the reason why the I2C read the wrong data and fail to initialize.

Thus, we treak the SDA hold time by the following modification.

--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -97,7 +97,8 @@ static const struct intel_lpss_platform_info bxt_uart_info = {
   };

   static struct property_entry bxt_i2c_properties[] = {
-   PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
+   PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
  PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
  PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
  { },

The reason why I choose sda hold time is by the Table 10 of
https://www.nxp.com/docs/en/user-guide/UM10204.pdf, the device
must provide a hold time at lease 300ns and and 42 here is relatively
too small. The signal measurement result for the same pin on Windows
is as follows.
https://imgur.com/BtKUIZB
Comparing to the same result running Linux
https://imgur.com/N4fPTYN

After applying the sda hold time tweak patch above, the touchpad can
be correctly initialized and work. The LA signal is shown as down below.
https://imgur.com/B3PmnIp


Could you try does attached patch work for you?

It's from last year for another related issue but there platform was
actually Apollo Lake instead of Gemini Lake but anyway it was found out
that Windows uses different timing parameters than Linux on Gemini Lake.

I didn't take patch forward back then due known Gemini Lake machines
were working with the Broxton I2C timing parameters but now it's time if
attached patch fixes the issue on your machine.

Patch is from top of v5.3-rc7 but should probably apply also to older
kernels.

--
Jarkko


Thanks, Jarkko, the patche works on my acer laptops.

Thanks. I'll send the patch out with Cc'ing you. I took the freedom to 
add your Tested-by tag if you don't mind :-)


--
Jarkko

Re: [PATCH v2 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext Milbeaut HDMAC bindings

[Vinod Koul]

On 18-08-19, 00:17, jassisinghb...@gmail.com wrote:
> From: Jassi Brar 
> 
> Document the devicetree bindings for Socionext Milbeaut HDMAC
> controller. Controller has upto 8 floating channels, that need
> a predefined slave-id to work from a set of slaves.
> 
> Signed-off-by: Jassi Brar 
> ---
>  .../bindings/dma/milbeaut-m10v-hdmac.txt  | 32 +++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt 
> b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> new file mode 100644
> index ..f0960724f1c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> @@ -0,0 +1,32 @@
> +* Milbeaut AHB DMA Controller
> +
> +Milbeaut AHB DMA controller has transfer capability bellow.

s/bellow/below:

> + - device to memory transfer
> + - memory to device transfer
> +
> +Required property:
> +- compatible:   Should be  "socionext,milbeaut-m10v-hdmac"
> +- reg:  Should contain DMA registers location and length.
> +- interrupts:   Should contain all of the per-channel DMA interrupts.
> + Number of channels is configurable - 2, 4 or 8, so
> + the number of interrupts specfied should be {2,4,8}.

s/specfied/specified

-- 
~Vinod

Re: [PATCH] dma: iop-adma.c: fix printk format warning

[Vinod Koul]

On 03-09-19, 22:06, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix printk format warning in iop-adma.c (seen on x86_64) by using
> %pad:
> 
> ../drivers/dma/iop-adma.c:118:12: warning: format ‘%x’ expects argument of 
> type ‘unsigned int’, but argument 6 has type ‘dma_addr_t {aka long long 
> unsigned int}’ [-Wformat=]

Applied, thanks

-- 
~Vinod

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Daniel Colascione]

On Tue, Sep 3, 2019 at 10:15 PM Joel Fernandes  wrote:
>
> On Tue, Sep 03, 2019 at 09:51:20PM -0700, Daniel Colascione wrote:
> > On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan  wrote:
> > >
> > > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
> > >  wrote:
> > > >
> > > > Useful to track how RSS is changing per TGID to detect spikes in RSS and
> > > > memory hogs. Several Android teams have been using this patch in various
> > > > kernel trees for half a year now. Many reported to me it is really
> > > > useful so I'm posting it upstream.
> >
> > It's also worth being able to turn off the per-task memory counter
> > caching, otherwise you'll have two levels of batching before the
> > counter gets updated, IIUC.
>
> I prefer to keep split RSS accounting turned on if it is available.

Why? AFAIK, nobody's produced numbers showing that split accounting
has a real benefit.

> I think
> discussing split RSS accounting is a bit out of scope of this patch as well.

It's in-scope, because with split RSS accounting, allocated memory can
stay accumulated in task structs for an indefinite time without being
flushed to the mm. As a result, if you take the stream of virtual
memory management system calls that  program makes on one hand, and VM
counter values on the other, the two don't add up. For various kinds
of robustness (trace self-checking, say) it's important that various
sources of data add up.

If we're adding a configuration knob that controls how often VM
counters get reflected in system trace points, we should also have a
knob to control delayed VM counter operations. The whole point is for
users to be able to specify how precisely they want VM counter changes
reported to analysis tools.

> Any improvements on that front can be a follow-up.
>
> Curious, has split RSS accounting shown you any issue with this patch?

Split accounting has been a source of confusion for a while now: it
causes that numbers-don't-add-up problem even when sampling from
procfs instead of reading memory tracepoint data.

Re: [PATCH RFC 2/2] interconnect: qcom: add msm8974 driver

[Bjorn Andersson]

On Mon 02 Sep 14:19 PDT 2019, Brian Masney wrote:

> Add driver for the Qualcomm MSM8974 interconnect providers that support
> setting system bandwidth requirements between various network-on-chip
> fabrics.
> 
> I marked this as a PATCH RFC since I'm not able to write to all of the
> master IDs with qcom_icc_rpm_smd_send(). I included tables below that
> shows which of the 20 master IDs that I'm able to activate with
> qcom_icc_rpm_smd_send() [1] and the remaining 37 where
> qcom_icc_rpm_smd_send() fails with -ENXIO [2].
> 
> The device tree snippets that I'm using is in patch 1 of this series,
> however the relevant interconnect properties for the mdp5 are:
> 
> interconnects = <&mmssnoc MNOC_MAS_GRAPHICS_3D &bimc BIMC_SLV_EBI_CH0>,
> <&ocmemnoc OCMEM_VNOC_MAS_GFX3D &ocmemnoc 
> OCMEM_SLV_OCMEM>;
> interconnect-names = "mdp0-mem", "mdp1-mem";
> 
> The two interconnects have the following paths:
> 
> - mdp0-mem
>   - mas_graphics_3d
>   - mnoc_to_bimc
>   - bimc_to_mnoc
>   - slv_ebi_ch0
> 
> - mdp1-mem
>   - mas_v_ocmem_gfx3d
>   - ocmem_vnoc_to_onoc
>   - ocmem_noc_to_ocmem_vnoc
>   - slv_ocmem
> 
> ocmem_noc_to_ocmem_vnoc is the only one that is successfully activated
> and the remaining fail in these two paths.
> 
> With this interconnect driver, I am able to remove a clock hack that I
> had in place that set the speed of MDSS_AXI_CLK high and I'm able to use
> kmscube. However, I do see a clock warning on system startup [3].
> 
> The display doesn't work for me with the downstream MSM sources so I may
> have to get that working to debug this some more unless anyone has any
> suggestions. I verified that the downstream msm8974 sources are using
> rpm smd to setup the interconnects for the msm bus:
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/msm_bus/msm_bus_rpm_smd.c#L153
> The only difference I noticed is that that upstream uses a 32 bit field
> for the 'value' field in drivers/interconnect/qcom/smd-rpm.c for
> qcom_icc_rpm_smd_send(), and downstream uses a 64 bit value instead.
> Changing that upstream doesn't make a difference.
> 
> Downstream msm8974 msm bus code:
> https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/arch/arm/mach-msm/msm_bus/msm_bus_board_8974.c
> 
> [1] Master IDs that I'm able to activate with qcom_icc_rpm_smd_send():
> 
> HW IDName
> ---
>  3   mas_mss_proc
> 18   slv_tcsr
> 21   slv_crypto_1_cfg
> 22   slv_imem_cfg
> 25   slv_boot_rom
> 29   slv_mpm
> 33   cnoc_to_snoc
> 34   slv_cnoc_onoc_cfg
> 35   slv_cnoc_mnoc_mmss_cfg
> 36   slv_cnoc_mnoc_cfg
> 37   slv_pnoc_cfg
> 38   slv_snoc_mpu_cfg
> 39   slv_snoc_cfg
> 40   slv_ebi1_dll_cfg
> 41   slv_phy_apu_cfg
> 42   slv_ebi1_phy_cfg
> 43   slv_rpm
> 44   slv_service_cnoc
> 52   mnoc_to_bimc
> 54   slv_display_cfg
> 
> [2] Master IDs where qcom_icc_rpm_smd_send() fails with -ENXIO. The
> -ENXIO error comes from qcom_smd_rpm_callback() in
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/soc/qcom/smd-rpm.c#L179
> 
> HW IDName
> ---
>  1   mas_ampss_m0
>  2   mas_ampss_m1
>  4   bimc_to_mnoc
>  5   bimc_to_snoc
>  6   slv_ebi_ch0
>  7   slv_ampss_l2
>  8   mas_rpm_inst
>  9   mas_rpm_data
> 10   mas_rpm_sys
> 11   mas_dehr
> 12   mas_qdss_dap
> 13   mas_spdm
> 14   mas_tic
> 15   slv_clk_ctl
> 16   slv_cnoc_mss
> 17   slv_security
> 19   slv_tlmm
> 20   slv_crypto_0_cfg
> 23   slv_message_ram
> 24   slv_bimc_cfg
> 26   slv_pmic_arb
> 27   slv_spdm_wrapper
> 28   slv_dehr_cfg
> 30   slv_qdss_cfg
> 31   slv_rbcpr_cfg
> 32   slv_rbcpr_qdss_apu_cfg
> 45   mas_graphics_3d
> 46   mas_jpeg
> 47   mas_mdp_port0
> 48   mas_video_p0
> 49   mas_video_p1
> 50   mas_vfe
> 51   mnoc_to_cnoc
> 53   slv_camera_cfg
> 55   slv_ocmem_cfg
> 56   slv_cpr_cfg
> 57   slv_cpr_xpu_cfg
> 
> [3] Clock warning on system startup:
> 
> WARNING: CPU: 3 PID: 26 at drivers/clk/qcom/clk-rcg2.c:121 
> update_config+0xe8/0xf0
> gfx3d_clk_src: rcg didn't update its configuration.
> Modules linked in: msm qcom_spmi_vadc qcom_vadc_common pm8941_pwrkey 
> qcom_spmi_iadc msm_vibrator brcmfmac qnoc_msm8974 icc_core inv_mpu6050_i2c(+) 
> inv_mpu6050 brcmutil cfg80211 bq24190_charger tsl2772 rmi_i2c rmi_core 
> icc_smd_rpm usb_f_rndis dm_mod
> CPU: 3 PID: 26 Comm: kworker/3:0 Not tainted 
> 5.3.0-rc4-next-20190816-00021-gd27e1e778708-dirty #148
> Hardware name: Generic DT based system
> Workqueue: events deferred_probe_work_func
> [] (unwind_

Re: [RFC PATCH] mm, oom: disable dump_tasks by default

[Michal Hocko]

On Wed 04-09-19 05:52:43, Tetsuo Handa wrote:
> On 2019/09/03 23:45, Michal Hocko wrote:
> > It's primary purpose is
> > to help analyse oom victim selection decision.
> 
> I disagree, for I use the process list for understanding what / how many
> processes are consuming what kind of memory (without crashing the system)
> for anomaly detection purpose. Although we can't dump memory consumed by
> e.g. file descriptors, disabling dump_tasks() loose that clue, and is
> problematic for me.

Does anything really prevent you from enabling this by sysctl though? Or
do you claim that this is a general usage pattern and therefore the
default change is not acceptable or do you want a changelog to be
updated?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Suren Baghdasaryan]

On Tue, Sep 3, 2019 at 10:02 PM Joel Fernandes  wrote:
>
> On Tue, Sep 03, 2019 at 09:44:51PM -0700, Suren Baghdasaryan wrote:
> > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
> >  wrote:
> > >
> > > Useful to track how RSS is changing per TGID to detect spikes in RSS and
> > > memory hogs. Several Android teams have been using this patch in various
> > > kernel trees for half a year now. Many reported to me it is really
> > > useful so I'm posting it upstream.
> > >
> > > Initial patch developed by Tim Murray. Changes I made from original patch:
> > > o Prevent any additional space consumed by mm_struct.
> > > o Keep overhead low by checking if tracing is enabled.
> > > o Add some noise reduction and lower overhead by emitting only on
> > >   threshold changes.
> > >
> > > Co-developed-by: Tim Murray 
> > > Signed-off-by: Tim Murray 
> > > Signed-off-by: Joel Fernandes (Google) 
> > >
> > > ---
> > >
> > > v1->v2: Added more commit message.
> > >
> > > Cc: carmenjack...@google.com
> > > Cc: mayankgu...@google.com
> > > Cc: dan...@google.com
> > > Cc: rost...@goodmis.org
> > > Cc: minc...@kernel.org
> > > Cc: a...@linux-foundation.org
> > > Cc: kernel-t...@android.com
> > >
> > >  include/linux/mm.h  | 14 +++---
> > >  include/trace/events/kmem.h | 21 +
> > >  mm/memory.c | 20 
> > >  3 files changed, 52 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index 0334ca97c584..823aaf759bdb 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -1671,19 +1671,27 @@ static inline unsigned long get_mm_counter(struct 
> > > mm_struct *mm, int member)
> > > return (unsigned long)val;
> > >  }
> > >
> > > +void mm_trace_rss_stat(int member, long count, long value);
> > > +
> > >  static inline void add_mm_counter(struct mm_struct *mm, int member, long 
> > > value)
> > >  {
> > > -   atomic_long_add(value, &mm->rss_stat.count[member]);
> > > +   long count = atomic_long_add_return(value, 
> > > &mm->rss_stat.count[member]);
> > > +
> > > +   mm_trace_rss_stat(member, count, value);
> > >  }
> > >
> > >  static inline void inc_mm_counter(struct mm_struct *mm, int member)
> > >  {
> > > -   atomic_long_inc(&mm->rss_stat.count[member]);
> > > +   long count = atomic_long_inc_return(&mm->rss_stat.count[member]);
> > > +
> > > +   mm_trace_rss_stat(member, count, 1);
> > >  }
> > >
> > >  static inline void dec_mm_counter(struct mm_struct *mm, int member)
> > >  {
> > > -   atomic_long_dec(&mm->rss_stat.count[member]);
> > > +   long count = atomic_long_dec_return(&mm->rss_stat.count[member]);
> > > +
> > > +   mm_trace_rss_stat(member, count, -1);
> > >  }
> > >
> > >  /* Optimized variant when page is already known not to be PageAnon */
> > > diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> > > index eb57e3037deb..8b88e04fafbf 100644
> > > --- a/include/trace/events/kmem.h
> > > +++ b/include/trace/events/kmem.h
> > > @@ -315,6 +315,27 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> > > __entry->change_ownership)
> > >  );
> > >
> > > +TRACE_EVENT(rss_stat,
> > > +
> > > +   TP_PROTO(int member,
> > > +   long count),
> > > +
> > > +   TP_ARGS(member, count),
> > > +
> > > +   TP_STRUCT__entry(
> > > +   __field(int, member)
> > > +   __field(long, size)
> > > +   ),
> > > +
> > > +   TP_fast_assign(
> > > +   __entry->member = member;
> > > +   __entry->size = (count << PAGE_SHIFT);
> > > +   ),
> > > +
> > > +   TP_printk("member=%d size=%ldB",
> > > +   __entry->member,
> > > +   __entry->size)
> > > +   );
> > >  #endif /* _TRACE_KMEM_H */
> > >
> > >  /* This part must be outside protection */
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index e2bb51b6242e..9d81322c24a3 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -72,6 +72,8 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> > > +
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -140,6 +142,24 @@ static int __init init_zero_pfn(void)
> > >  }
> > >  core_initcall(init_zero_pfn);
> > >
> > > +/*
> > > + * This threshold is the boundary in the value space, that the counter 
> > > has to
> > > + * advance before we trace it. Should be a power of 2. It is to reduce 
> > > unwanted
> > > + * trace overhead. The counter is in units of number of pages.
> > > + */
> > > +#define TRACE_MM_COUNTER_THRESHOLD 128
> >
> > IIUC the counter has to change by 128 pages (512kB assuming 4kB pages)
> > before the change gets traced. Would it make sense to make this step
> > size configurable? For a system with limited memory size change of
> > 512kB might be considerable while on systems with plenty of memory
> > that might be negligible. Not even mentioning possible difference in
> > page sizes

Re: [PATCH 2/2] PCI: Unify pci_dev_is_disconnected() and pci_dev_is_inaccessible()

[Lukas Wunner]

On Tue, Sep 03, 2019 at 10:36:35PM -0600, Kelsey Skunberg wrote:
> Change pci_dev_is_disconnected() call inside pci_dev_is_inaccessible() to:
> 
>   pdev->error_state == pci_channel_io_perm_failure
> 
> Change remaining pci_dev_is_disconnected() calls to
> pci_dev_is_inaccessible() calls.

I don't think that's a good idea because it introduces a config space read
(for the vendor ID) in places where we don't want that.  E.g., after the
check of pdev->error_state, a regular config space read may take place and
if that returns all ones, we may already be able to determine that the
device is inaccessible, obviating the need for a vendor ID check.
Config space reads aren't for free.

Thanks,

Lukas

Re: About compiler memory barrier for atomic_set/atomic_read on x86

[Yin, Fengwei]

Hi Peter,

On 9/4/2019 7:38 AM, Yin, Fengwei wrote:

Hi Peter,

On 9/3/2019 10:06 PM, Peter Zijlstra wrote:

On Tue, Sep 03, 2019 at 09:23:41PM +0800, Yin, Fengwei wrote:

Hi Peter,
There is one question regarding following commit:

commit 69d927bba39517d0980462efc051875b7f4db185
Author: Peter Zijlstra 
Date:   Wed Apr 24 13:38:23 2019 +0200

 x86/atomic: Fix smp_mb__{before,after}_atomic()

 Recent probing at the Linux Kernel Memory Model uncovered a
 'surprise'. Strongly ordered architectures where the atomic RmW
 primitive implies full memory ordering and
 smp_mb__{before,after}_atomic() are a simple barrier() (such as 
x86)


This change made atomic RmW operations include compiler barrier. And 
made

__smp_mb__before_atomic/__smp_mb__after_atomic not include compiler
barrier any more for x86.

We face the issue to handle atomic_set/atomic_read which is mapped to
WRITE_ONCE/READ_ONCE on x86. These two functions don't include compiler
barrier actually (if operator size is less than 8 bytes).

Before the commit 69d927bba39517d0980462efc051875b7f4db185, we could use
__smp_mb__before_atomic/__smp_mb__after_atomic together with these two
functions to make sure the memory order. It can't work after the commit
69d927bba39517d0980462efc051875b7f4db185. I am wandering whether
we should make atomic_set/atomic_read also include compiler memory
barrier on x86? Thanks.


No; using smp_mb__{before,after}_atomic() with atomic_{set,read}() is
_wrong_! And it is documented as such; see Documentation/atomic_t.txt.


Thanks a lot for direct me to this doc. And yes, from this doc:
    - smp_mb__{before,after}_atomic() only apply to the RMW atomic ops
    - non-RMW operations are unordered;

I checked the /Documentation/memory-barriers.txt too. In section
"COMPILER BARRIER", "However, READ_ONCE() and WRITE_ONCE() can be
thought of as weak forms of barrier() that affect only the specific
accesses flagged by the READ_ONCE() or WRITE_ONCE()".

For x86 READ_ONCE/WRITE_ONCE doesn't have compiler barrier if the
operator size is less than 8 bytes. Should we update x86 code?

So, if I use atomic_set/read, to prevent the compiler from moving memory
access around, I should use compiler barrier explicitly. Right?

It looks like atomic_set_release/read_acquire could be used in my case.

Regards
Yin, Fengwei



Regards
Yin, Fengwei

Re: [PATCH] mm: fix double page fault on arm64 if PTE_AF is cleared

[Anshuman Khandual]

On 09/04/2019 10:27 AM, Justin He (Arm Technology China) wrote:
> Hi Anshuman, thanks for the comments, see below please
> 
>> -Original Message-
>> From: Anshuman Khandual 
>> Sent: 2019年9月4日 12:38
>> To: Justin He (Arm Technology China) ; Andrew
>> Morton ; Matthew Wilcox
>> ; Jérôme Glisse ; Ralph
>> Campbell ; Jason Gunthorpe ;
>> Peter Zijlstra ; Dave Airlie ;
>> Aneesh Kumar K.V ; Thomas Hellstrom
>> ; Souptick Joarder ;
>> linux...@kvack.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] mm: fix double page fault on arm64 if PTE_AF is
>> cleared
>>
>>
>>
>> On 09/04/2019 08:49 AM, Anshuman Khandual wrote:
>>> /*
>>>  * This really shouldn't fail, because the page is there
>>>  * in the page tables. But it might just be unreadable,
>>>  * in which case we just give up and fill the result with
>>> -* zeroes.
>>> +* zeroes. If PTE_AF is cleared on arm64, it might
>>> +* cause double page fault here. so makes pte young here
>>>  */
>>> +   if (!pte_young(vmf->orig_pte)) {
>>> +   entry = pte_mkyoung(vmf->orig_pte);
>>> +   if (ptep_set_access_flags(vmf->vma, vmf->address,
>>> +   vmf->pte, entry, vmf->flags &
>> FAULT_FLAG_WRITE))
>>> +   update_mmu_cache(vmf->vma, vmf-
>>> address,
>>> +   vmf->pte);
>>> +   }
>>
>> This looks correct where it updates the pte entry with PTE_AF which
>> will prevent a subsequent page fault. But I think what we really need
>> here is to make sure 'uaddr' is mapped correctly at vma->pte. Probably
>> a generic function arch_map_pte() when defined for arm64 should check
>> CPU version and ensure continuance of PTE_AF if required. The comment
>> above also need to be updated saying not only the page should be there
>> in the page table, it needs to mapped appropriately as well.
> 
> I agree that a generic interface here is needed but not the arch_map_pte().
> In this case, I thought all the pgd/pud/pmd/pte had been set correctly except
> for the PTE_AF bit.
> How about arch_hw_access_flag()?

Sure, go ahead. I just meant 'map' to include not only the PFN but also
appropriate HW attributes not cause a page fault.

> If non-arm64, arch_hw_access_flag() == true

The function does not need to return anything. Dummy default definition
in generic MM will do nothing when arch does not override.

> If arm64 with hardware-managed access flag supported, == true
> else == false?

On arm64 with hardware-managed access flag supported, it will do nothing.
But in case its not supported the above mentioned pte update as in the
current proposal needs to be executed. The details should hide in arch
specific override.

Re: [PATCH v2 3/3] nvme: fire discovery log page change events to userspace

[Greg Kroah-Hartman]

On Tue, Sep 03, 2019 at 06:35:30PM -0700, Sagi Grimberg wrote:
> 
> > > Still don't understand how this is ok...
> > > 
> > > I have /dev/nvme0 represents a network endpoint that I would discover
> > > from, it is raising me an event to do a discovery operation (namely to
> > > issue an ioctl to it) so my udev code calls a systemd script.
> > > 
> > > By the time I actually get to do that, /dev/nvme0 represents now a new
> > > network endpoint (where the event is no longer relevant to). I would
> > > rather the discovery to explicitly fail than to give me something
> > > different, so we pass some arguments that we verify in the operation.
> > > 
> > > Its a stretch case, but it was raised by people as a potential issue.
> > 
> > Ok, and how do you handle this same thing for something like /dev/sda ?
> > (hint, it isn't new, and is something we solved over a decade ago)
> > 
> > If you worry about stuff like this, use a persistant device naming
> > scheme and have your device node be pointed to by a symlink.  Create
> > that symlink by using the information in the initial 'ADD' uevent.
> > 
> > That way, when userspace opens the device node, it "knows" exactly which
> > one it opens.  It sounds like you have a bunch of metadata to describe
> > these uniquely, so pass that in the ADD event, not in some other crazy
> > non-standard manner.
> 
> We could send these variables when adding the device and then validating
> them using a rich-text-explanatory symlink. Seems slightly backwards to
> me, but that would work too.

That's the way the driver model is expected to work, instead of having
to do crazy device-specific stuff.

> We create the char device using device_add (in nvme_init_subsystem),
> I didn't find any way to append env variables to that ADD uevent.

You do that in your uevent or dev_uevent callback like all other
subsystems.  Nothing "new" to do here, again, it's been working fine for
everyone else for well over a decade now :)

thanks,

greg k-h

Re: [PATCH] powerpc: Perform a bounds check in arch_add_memory

[Alastair D'Silva]

On Mon, 2019-09-02 at 09:28 +0200, David Hildenbrand wrote:
> On 02.09.19 01:54, Alastair D'Silva wrote:
> > On Tue, 2019-08-27 at 09:13 +0200, David Hildenbrand wrote:
> > > On 27.08.19 08:39, Alastair D'Silva wrote:
> > > > On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote:
> > > > > On Tue 27-08-19 15:20:46, Alastair D'Silva wrote:
> > > > > > From: Alastair D'Silva 
> > > > > > 
> > > > > > It is possible for firmware to allocate memory ranges
> > > > > > outside
> > > > > > the range of physical memory that we support
> > > > > > (MAX_PHYSMEM_BITS).
> > > > > 
> > > > > Doesn't that count as a FW bug? Do you have any evidence of
> > > > > that
> > > > > in
> > > > > the
> > > > > field? Just wondering...
> > > > > 
> > > > 
> > > > Not outside our lab, but OpenCAPI attached LPC memory is
> > > > assigned
> > > > addresses based on the slot/NPU it is connected to. These
> > > > addresses
> > > > prior to:
> > > > 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory
> > > > to
> > > > 2PB")
> > > > were inaccessible and resulted in bogus sections - see our
> > > > discussion
> > > > on 'mm: Trigger bug on if a section is not found in
> > > > __section_nr'.
> > > > Doing this check here was your suggestion :)
> > > > 
> > > > It's entirely possible that a similar problem will occur in the
> > > > future,
> > > > and it's cheap to guard against, which is why I've added this.
> > > > 
> > > 
> > > If you keep it here, I guess this should be wrapped by a
> > > WARN_ON_ONCE().
> > > 
> > > If we move it to common code (e.g., __add_pages() or
> > > add_memory()),
> > > then
> > > probably not. I can see that s390x allows to configure
> > > MAX_PHYSMEM_BITS,
> > > so the check could actually make sense.
> > > 
> > 
> > I couldn't see a nice platform indepedent way to determine the
> > allowable address range, but if there is, then I'll move this to
> > the
> > generic code instead.
> > 
> 
> At least on the !ZONE_DEVICE path we have
> 
> __add_memory() -> register_memory_resource() ...
> 
> return ERR_PTR(-E2BIG);
> 
> 
> I was thinking about something like
> 
> int add_pages()
> {
>   if ((start + size - 1) >> MAX_PHYSMEM_BITS)
>   return -E2BIG;  
> 
>   return arch_add_memory(...)
> }
> 
> And switching users of arch_add_memory() to add_pages(). However, x86
> already has an add_pages() function, so that would need some more
> thought.
> 
> Maybe simply renaming the existing add_pages() to arch_add_pages().
> 
> add_pages(): Create virtual mapping
> __add_pages(): Don't create virtual mapping
> 
> arch_add_memory(): Arch backend for add_pages()
> arch_add_pages(): Arch backend for __add_pages()
> 
> It would be even more consistent if we would have arch_add_pages()
> vs.
> __arch_add_pages().

Looking a bit further, I think a good course of action would be to add
the check to memory_hotplug.c:check_hotplug_memory_range().

This would be the least invasive, and could check both
MAX_POSSIBLE_PHYSMEM_BITS and MAX_PHYSMEM_BITS.

With that in mind, we can drop this patch.

-- 
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Joel Fernandes]

On Tue, Sep 03, 2019 at 09:51:20PM -0700, Daniel Colascione wrote:
> On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan  wrote:
> >
> > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
> >  wrote:
> > >
> > > Useful to track how RSS is changing per TGID to detect spikes in RSS and
> > > memory hogs. Several Android teams have been using this patch in various
> > > kernel trees for half a year now. Many reported to me it is really
> > > useful so I'm posting it upstream.
> 
> It's also worth being able to turn off the per-task memory counter
> caching, otherwise you'll have two levels of batching before the
> counter gets updated, IIUC.

I prefer to keep split RSS accounting turned on if it is available. I think
discussing split RSS accounting is a bit out of scope of this patch as well.
Any improvements on that front can be a follow-up.

Curious, has split RSS accounting shown you any issue with this patch?

thanks,

 - Joel

Re: [PATCH 2/2] ipc/sem: Convert to use built-in RCU list checking

[kbuild test robot]

Hi "Joel,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc7 next-20190903]
[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/Joel-Fernandes-Google/pci-Convert-to-use-built-in-RCU-list-checking/20190901-211013
config: x86_64-rhel-7.6 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All error/warnings (new ones prefixed by >>):

   ipc/sem.c: In function '__lookup_undo':
>> ipc/sem.c:1856:31: error: macro "list_for_each_entry_rcu" passed 4 
>> arguments, but takes just 3
spin_is_locked(&ulp->lock)) {
  ^
>> ipc/sem.c:1855:2: error: 'list_for_each_entry_rcu' undeclared (first use in 
>> this function); did you mean 'class_for_each_device'?
 list_for_each_entry_rcu(un, &ulp->list_proc, list_proc,
 ^~~
 class_for_each_device
   ipc/sem.c:1855:2: note: each undeclared identifier is reported only once for 
each function it appears in
>> ipc/sem.c:1856:33: error: expected ';' before '{' token
spin_is_locked(&ulp->lock)) {
^
   ipc/sem.c:1853:19: warning: unused variable 'un' [-Wunused-variable]
 struct sem_undo *un;
  ^~
>> ipc/sem.c:1861:1: warning: no return statement in function returning 
>> non-void [-Wreturn-type]
}
^

vim +/list_for_each_entry_rcu +1856 ipc/sem.c

  1850  
  1851  static struct sem_undo *__lookup_undo(struct sem_undo_list *ulp, int 
semid)
  1852  {
  1853  struct sem_undo *un;
  1854  
> 1855  list_for_each_entry_rcu(un, &ulp->list_proc, list_proc,
> 1856  spin_is_locked(&ulp->lock)) {
  1857  if (un->semid == semid)
  1858  return un;
  1859  }
  1860  return NULL;
> 1861  }
  1862  

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


.config.gz
Description: application/gzip

[PATCH] dma: iop-adma.c: fix printk format warning

[Randy Dunlap]

From: Randy Dunlap 

Fix printk format warning in iop-adma.c (seen on x86_64) by using
%pad:

../drivers/dma/iop-adma.c:118:12: warning: format ‘%x’ expects argument of type 
‘unsigned int’, but argument 6 has type ‘dma_addr_t {aka long long unsigned 
int}’ [-Wformat=]

Fixes: c211092313b9 ("dmaengine: driver for the iop32x, iop33x, and iop13xx 
raid engines")
Signed-off-by: Randy Dunlap 
Cc: Dan Williams 
Acked-by: Dan Williams 
---
v2: add Ack from Dan and update to current linux-next;

 drivers/dma/iop-adma.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20190903.orig/drivers/dma/iop-adma.c
+++ linux-next-20190903/drivers/dma/iop-adma.c
@@ -116,9 +116,9 @@ static void __iop_adma_slot_cleanup(stru
list_for_each_entry_safe(iter, _iter, &iop_chan->chain,
chain_node) {
pr_debug("\tcookie: %d slot: %d busy: %d "
-   "this_desc: %#x next_desc: %#llx ack: %d\n",
+   "this_desc: %pad next_desc: %#llx ack: %d\n",
iter->async_tx.cookie, iter->idx, busy,
-   iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
+   &iter->async_tx.phys, (u64)iop_desc_get_next_desc(iter),
async_tx_test_ack(&iter->async_tx));
prefetch(_iter);
prefetch(&_iter->async_tx);

Re: [PATCH 1/2] pci: Convert to use built-in RCU list checking

[Joel Fernandes]

On Wed, Sep 04, 2019 at 12:06:43PM +0800, kbuild test robot wrote:
> Hi "Joel,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc7 next-20190903]
> [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/Joel-Fernandes-Google/pci-Convert-to-use-built-in-RCU-list-checking/20190901-211013
> config: x86_64-rhel-7.6 (attached as .config)
> compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 

This error seems bogus. I pulled -next and applied this patch and it builds
fine. I am not sure what is wrong with the 0day tree, and the above 0day link
is also dead.

What's going on with 0day ?!

thanks,

 - Joel

> 
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/pci/controller/vmd.c: In function 'vmd_irq':
> >> drivers/pci/controller/vmd.c:722:37: error: macro 
> >> "list_for_each_entry_rcu" passed 4 arguments, but takes just 3
> srcu_read_lock_held(&irqs->srcu))
> ^
> >> drivers/pci/controller/vmd.c:721:2: error: unknown type name 
> >> 'list_for_each_entry_rcu'
>  list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node,
>  ^~~
> >> drivers/pci/controller/vmd.c:723:28: error: expected ')' before '->' token
>   generic_handle_irq(vmdirq->virq);
>^~
> >> drivers/pci/controller/vmd.c:721:2: warning: ISO C90 forbids mixed 
> >> declarations and code [-Wdeclaration-after-statement]
>  list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node,
>  ^~~
>drivers/pci/controller/vmd.c:717:18: warning: unused variable 'vmdirq' 
> [-Wunused-variable]
>  struct vmd_irq *vmdirq;
>  ^~
> 
> vim +/list_for_each_entry_rcu +722 drivers/pci/controller/vmd.c
> 
>713
>714static irqreturn_t vmd_irq(int irq, void *data)
>715{
>716struct vmd_irq_list *irqs = data;
>717struct vmd_irq *vmdirq;
>718int idx;
>719
>720idx = srcu_read_lock(&irqs->srcu);
>  > 721list_for_each_entry_rcu(vmdirq, &irqs->irq_list, node,
>  > 722
> srcu_read_lock_held(&irqs->srcu))
>  > 723generic_handle_irq(vmdirq->virq);
>724srcu_read_unlock(&irqs->srcu, idx);
>725
>726return IRQ_HANDLED;
>727}
>728
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v5 4/4] ftrace: Add an option for tracing console latencies

[kbuild test robot]

Hi Viktor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc7 next-20190903]
[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/Viktor-Rosendahl/Some-new-features-for-the-preempt-irqsoff-tracers/20190904-083632
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from kernel/events/hw_breakpoint.c:20:0:
>> include/linux/irqflags.h:71:9: error: unknown type name 'bool'
 extern bool console_tracing_disabled(void);
^~~~

vim +/bool +71 include/linux/irqflags.h

66  
67  #if defined(CONFIG_IRQSOFF_TRACER) || \
68  defined(CONFIG_PREEMPT_TRACER)
69   extern void stop_critical_timings(void);
70   extern void start_critical_timings(void);
  > 71   extern bool console_tracing_disabled(void);
72  

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


.config.gz
Description: application/gzip

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Joel Fernandes]

On Tue, Sep 03, 2019 at 09:44:51PM -0700, Suren Baghdasaryan wrote:
> On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
>  wrote:
> >
> > Useful to track how RSS is changing per TGID to detect spikes in RSS and
> > memory hogs. Several Android teams have been using this patch in various
> > kernel trees for half a year now. Many reported to me it is really
> > useful so I'm posting it upstream.
> >
> > Initial patch developed by Tim Murray. Changes I made from original patch:
> > o Prevent any additional space consumed by mm_struct.
> > o Keep overhead low by checking if tracing is enabled.
> > o Add some noise reduction and lower overhead by emitting only on
> >   threshold changes.
> >
> > Co-developed-by: Tim Murray 
> > Signed-off-by: Tim Murray 
> > Signed-off-by: Joel Fernandes (Google) 
> >
> > ---
> >
> > v1->v2: Added more commit message.
> >
> > Cc: carmenjack...@google.com
> > Cc: mayankgu...@google.com
> > Cc: dan...@google.com
> > Cc: rost...@goodmis.org
> > Cc: minc...@kernel.org
> > Cc: a...@linux-foundation.org
> > Cc: kernel-t...@android.com
> >
> >  include/linux/mm.h  | 14 +++---
> >  include/trace/events/kmem.h | 21 +
> >  mm/memory.c | 20 
> >  3 files changed, 52 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 0334ca97c584..823aaf759bdb 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -1671,19 +1671,27 @@ static inline unsigned long get_mm_counter(struct 
> > mm_struct *mm, int member)
> > return (unsigned long)val;
> >  }
> >
> > +void mm_trace_rss_stat(int member, long count, long value);
> > +
> >  static inline void add_mm_counter(struct mm_struct *mm, int member, long 
> > value)
> >  {
> > -   atomic_long_add(value, &mm->rss_stat.count[member]);
> > +   long count = atomic_long_add_return(value, 
> > &mm->rss_stat.count[member]);
> > +
> > +   mm_trace_rss_stat(member, count, value);
> >  }
> >
> >  static inline void inc_mm_counter(struct mm_struct *mm, int member)
> >  {
> > -   atomic_long_inc(&mm->rss_stat.count[member]);
> > +   long count = atomic_long_inc_return(&mm->rss_stat.count[member]);
> > +
> > +   mm_trace_rss_stat(member, count, 1);
> >  }
> >
> >  static inline void dec_mm_counter(struct mm_struct *mm, int member)
> >  {
> > -   atomic_long_dec(&mm->rss_stat.count[member]);
> > +   long count = atomic_long_dec_return(&mm->rss_stat.count[member]);
> > +
> > +   mm_trace_rss_stat(member, count, -1);
> >  }
> >
> >  /* Optimized variant when page is already known not to be PageAnon */
> > diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> > index eb57e3037deb..8b88e04fafbf 100644
> > --- a/include/trace/events/kmem.h
> > +++ b/include/trace/events/kmem.h
> > @@ -315,6 +315,27 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> > __entry->change_ownership)
> >  );
> >
> > +TRACE_EVENT(rss_stat,
> > +
> > +   TP_PROTO(int member,
> > +   long count),
> > +
> > +   TP_ARGS(member, count),
> > +
> > +   TP_STRUCT__entry(
> > +   __field(int, member)
> > +   __field(long, size)
> > +   ),
> > +
> > +   TP_fast_assign(
> > +   __entry->member = member;
> > +   __entry->size = (count << PAGE_SHIFT);
> > +   ),
> > +
> > +   TP_printk("member=%d size=%ldB",
> > +   __entry->member,
> > +   __entry->size)
> > +   );
> >  #endif /* _TRACE_KMEM_H */
> >
> >  /* This part must be outside protection */
> > diff --git a/mm/memory.c b/mm/memory.c
> > index e2bb51b6242e..9d81322c24a3 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -72,6 +72,8 @@
> >  #include 
> >  #include 
> >
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -140,6 +142,24 @@ static int __init init_zero_pfn(void)
> >  }
> >  core_initcall(init_zero_pfn);
> >
> > +/*
> > + * This threshold is the boundary in the value space, that the counter has 
> > to
> > + * advance before we trace it. Should be a power of 2. It is to reduce 
> > unwanted
> > + * trace overhead. The counter is in units of number of pages.
> > + */
> > +#define TRACE_MM_COUNTER_THRESHOLD 128
> 
> IIUC the counter has to change by 128 pages (512kB assuming 4kB pages)
> before the change gets traced. Would it make sense to make this step
> size configurable? For a system with limited memory size change of
> 512kB might be considerable while on systems with plenty of memory
> that might be negligible. Not even mentioning possible difference in
> page sizes. Maybe something like
> /sys/kernel/debug/tracing/rss_step_order with
> TRACE_MM_COUNTER_THRESHOLD=(1< > +void mm_trace_rss_stat(int member, long count, long value)
> > +{
> > +   long thresh_mask = ~(TRACE_MM_COUNTER_THRESHOLD - 1);
> > +
> > +   if (!trace_rss_stat_enabled())
> > +   return;
> > +
> > + 

Re: [PATCH RFC 1/2] dt-bindings: interconnect: qcom: add msm8974 bindings

[Bjorn Andersson]

On Mon 02 Sep 14:19 PDT 2019, Brian Masney wrote:

> Add device tree bindings for the Qualcomm MSM8974 interconnect providers
> that support setting system bandwidth requirements between various
> network-on-chip fabrics.
> 
> Signed-off-by: Brian Masney 
> ---
>  .../bindings/interconnect/qcom,msm8974.yaml   | 163 ++
>  .../dt-bindings/interconnect/qcom,msm8974.h   | 146 
>  2 files changed, 309 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
>  create mode 100644 include/dt-bindings/interconnect/qcom,msm8974.h
> 
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml 
> b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
> new file mode 100644
> index ..fbf440f5ffe0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml
> @@ -0,0 +1,163 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interconnect/qcom,msm8974.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm MSM8974 Network-On-Chip Interconnect
> +
> +maintainers:
> +  - Brian Masney 
> +
> +description: |
> +   The Qualcomm MSM8974 interconnect providers support setting system
> +   bandwidth requirements between various network-on-chip fabrics.
> +
> +properties:
> +  reg:
> +maxItems: 1
> +
> +  compatible:
> +enum:
> +  - qcom,msm8974-bimc
> +  - qcom,msm8974-cnoc
> +  - qcom,msm8974-mmssnoc
> +  - qcom,msm8974-ocmemnoc
> +  - qcom,msm8974-pnoc
> +  - qcom,msm8974-snoc
> +
> +  '#interconnect-cells':
> +const: 1
> +
> +  clock-names:
> +items:
> +  - const: bus
> +  - const: bus_a
> +
> +  clocks:
> +items:
> +  - description: Bus Clock
> +  - description: Bus A Clock
> +
> +required:
> +  - compatible
> +  - reg
> +  - '#interconnect-cells'
> +  - clock-names
> +  - clocks
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +  #include 
> +  #include 
> +  #include 
> +  #include 
> +
> +  bimc: interconnect@fc38 {
> +  reg = <0xfc38 0x6a000>;
> +  compatible = "qcom,msm8974-bimc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
> +   <&rpmcc RPM_SMD_BIMC_A_CLK>;
> +  };
> +
> +  cnoc: interconnect@fc48 {
> +  reg = <0xfc48 0x4000>;
> +  compatible = "qcom,msm8974-cnoc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_CNOC_CLK>,
> +   <&rpmcc RPM_SMD_CNOC_A_CLK>;
> +  };
> +
> +  mmssnoc: interconnect@fc478000 {
> +  reg = <0xfc478000 0x4000>;
> +  compatible = "qcom,msm8974-mmssnoc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_MMSSNOC_AHB_CLK>,
> +   <&rpmcc RPM_SMD_MMSSNOC_AHB_A_CLK>;

Isn't MMSS_S0_AXI_CLK the bus clock of the mmssnoc (which somehow seems
to depend on mmssnoc_ahb_clk)?

> +  };
> +
> +  ocmemnoc: interconnect@fc47 {
> +  reg = <0xfc47 0x4000>;
> +  compatible = "qcom,msm8974-ocmemnoc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>,
> +   <&rpmcc RPM_SMD_OCMEMGX_A_CLK>;
> +  };
> +
> +  pnoc: interconnect@fc468000 {
> +  reg = <0xfc468000 0x4000>;
> +  compatible = "qcom,msm8974-pnoc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_PNOC_CLK>,
> +   <&rpmcc RPM_SMD_PNOC_A_CLK>;
> +  };
> +
> +  snoc: interconnect@fc46 {
> +  reg = <0xfc46 0x4000>;
> +  compatible = "qcom,msm8974-snoc";
> +  #interconnect-cells = <1>;
> +  clock-names = "bus", "bus_a";
> +  clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
> +   <&rpmcc RPM_SMD_SNOC_A_CLK>;
> +  };
> +
> +  mdss: mdss@fd90 {

I think you can omit the client, as this adheres to the standard binding
for interconnect clients. And you don't need to have an example that
covers all compatibles either...


> +  compatible = "qcom,mdss";
> +  reg = <0xfd90 0x100>, <0xfd924000 0x1000>;
> +  reg-names = "mdss_phys", "vbif_phys";
> +
> +  power-domains = <&mmcc MDSS_GDSC>;
> +
> +  clocks = <&mmcc MDSS_AHB_CLK>,
> +   <&mmcc MDSS_AXI_CLK>,
> +   <&mmcc MDSS_VSYNC_CLK>;
> +  clock-names = "iface", "bus", "v

Re: [PATCH] IOAT: iop-adma.c: fix printk format warning

[Vinod Koul]

On 30-08-19, 14:44, Dan Williams wrote:
> [ add Vinod and dmaengine ]
> 
> On Fri, Aug 30, 2019 at 2:32 PM Randy Dunlap  wrote:
> >
> > From: Randy Dunlap 
> >
> > Fix printk format warning in iop-adma.c (seen on x86_64) by using
> > %pad:
> >
> > ../drivers/dma/iop-adma.c:118:12: warning: format ‘%x’ expects argument of 
> > type ‘unsigned int’, but argument 6 has type ‘dma_addr_t {aka long long 
> > unsigned int}’ [-Wformat=]

This doesnt apply for me. Please rebase on next and resend with Dan's
ack

-- 
~Vinod

Re: [PATCH -rcu dev 1/2] Revert b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks counter")

[Joel Fernandes]

On Tue, Sep 03, 2019 at 01:02:49PM -0700, Paul E. McKenney wrote:
[snip] 
> > ---
> >  include/linux/rcutiny.h |  3 --
> >  kernel/rcu/tree.c   | 82 ++---
> >  2 files changed, 19 insertions(+), 66 deletions(-)
> > 
> > diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> > index b7607e2667ae..b3f689711289 100644
> > --- a/include/linux/rcutiny.h
> > +++ b/include/linux/rcutiny.h
> > @@ -14,9 +14,6 @@
> >  
> >  #include  /* for HZ */
> >  
> > -/* Never flag non-existent other CPUs! */
> > -static inline bool rcu_eqs_special_set(int cpu) { return false; }
> > -
> >  static inline unsigned long get_state_synchronize_rcu(void)
> >  {
> > return 0;
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 68ebf0eb64c8..417dd00b9e87 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -69,20 +69,10 @@
> >  
> >  /* Data structures. */
> >  
> > -/*
> > - * Steal a bit from the bottom of ->dynticks for idle entry/exit
> > - * control.  Initially this is for TLB flushing.
> > - */
> > -#define RCU_DYNTICK_CTRL_MASK 0x1
> > -#define RCU_DYNTICK_CTRL_CTR  (RCU_DYNTICK_CTRL_MASK + 1)
> > -#ifndef rcu_eqs_special_exit
> > -#define rcu_eqs_special_exit() do { } while (0)
> > -#endif
> > -
> >  static DEFINE_PER_CPU_SHARED_ALIGNED(struct rcu_data, rcu_data) = {
> > .dynticks_nesting = 1,
> > .dynticks_nmi_nesting = DYNTICK_IRQ_NONIDLE,
> > -   .dynticks = ATOMIC_INIT(RCU_DYNTICK_CTRL_CTR),
> > +   .dynticks = ATOMIC_INIT(1),
> >  };
> >  struct rcu_state rcu_state = {
> > .level = { &rcu_state.node[0] },
> > @@ -229,20 +219,15 @@ void rcu_softirq_qs(void)
> >  static void rcu_dynticks_eqs_enter(void)
> >  {
> > struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> > -   int seq;
> > +   int special;
> 
> Given that we really are now loading a pure sequence number, why
> change the name to "special"?  This revert is after all removing
> the ability of ->dynticks to be special.

I have no preference for this variable name, I can call it seq. I was going
by staying close to 'git revert' to minimize any issues from reverting. I'll
change it to seq then. But we are also going to rewrite this code anyway as
we were discussing.
 
> > /*
> > -* CPUs seeing atomic_add_return() must see prior idle sojourns,
> > +* CPUs seeing atomic_inc_return() must see prior idle sojourns,
> >  * and we also must force ordering with the next RCU read-side
> >  * critical section.
> >  */
> > -   seq = atomic_add_return(RCU_DYNTICK_CTRL_CTR, &rdp->dynticks);
> > -   WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > -!(seq & RCU_DYNTICK_CTRL_CTR));
> > -   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > -   atomic_andnot(RCU_DYNTICK_CTRL_MASK, &rdp->dynticks);
> > -   smp_mb__after_atomic(); /* _exit after clearing mask. */
> > -   /* Prefer duplicate flushes to losing a flush. */
> > -   rcu_eqs_special_exit();
> > -   }
> > +   special = atomic_inc_return(&rdp->dynticks);
> > +   WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && !(special & 0x1));
> >  }
> >  
> >  /*
> > @@ -284,9 +262,9 @@ static void rcu_dynticks_eqs_online(void)
> >  {
> > struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> >  
> > -   if (atomic_read(&rdp->dynticks) & RCU_DYNTICK_CTRL_CTR)
> > +   if (atomic_read(&rdp->dynticks) & 0x1)
> > return;
> > -   atomic_add(RCU_DYNTICK_CTRL_CTR, &rdp->dynticks);
> > +   atomic_add(0x1, &rdp->dynticks);
> 
> This could be atomic_inc(), right?

True, again I will blame 'git revert' ;-) Will change.

> > -/*
> > - * Set the special (bottom) bit of the specified CPU so that it
> > - * will take special action (such as flushing its TLB) on the
> > - * next exit from an extended quiescent state.  Returns true if
> > - * the bit was successfully set, or false if the CPU was not in
> > - * an extended quiescent state.
> > - */
> > -bool rcu_eqs_special_set(int cpu)
> > -{
> > -   int old;
> > -   int new;
> > -   struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
> > -
> > -   do {
> > -   old = atomic_read(&rdp->dynticks);
> > -   if (old & RCU_DYNTICK_CTRL_CTR)
> > -   return false;
> > -   new = old | RCU_DYNTICK_CTRL_MASK;
> > -   } while (atomic_cmpxchg(&rdp->dynticks, old, new) != old);
> > -   return true;
> > -}
> > -
> >  /*
> >   * Let the RCU core know that this CPU has gone through the scheduler,
> >   * which is a quiescent state.  This is called when the need for a
> > @@ -366,13 +322,13 @@ bool rcu_eqs_special_set(int cpu)
> >   */
> >  void rcu_momentary_dyntick_idle(void)
> >  {
> > -   int special;
> > +   struct rcu_data *rdp = this_cpu_ptr(&rcu_data);
> > +   int special = atomic_add_return(2, &rdp->dynticks);
> >  
> > -   raw_cpu_write(rcu_data.rcu_need_heavy_qs, false);
> > -   special = atomic_add_return(2 * RCU_DYNTICK_CTRL_CTR,
> > -   &this_cpu_ptr(&rcu_data)->dynticks);
> >   

[PATCH] remove the acheive sp error

[Marcus Eagan]

From: marcussorealheis 

---
 drivers/clk/rockchip/clk-cpu.c  | 2 +-
 drivers/clk/samsung/clk-cpu.c   | 2 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
 fs/xfs/xfs_inode.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-cpu.c b/drivers/clk/rockchip/clk-cpu.c
index 0dc478a19451..e5b69f281b0f 100644
--- a/drivers/clk/rockchip/clk-cpu.c
+++ b/drivers/clk/rockchip/clk-cpu.c
@@ -19,7 +19,7 @@
  * clock and the corresponding rate changes of the auxillary clocks of the CPU
  * domain. The platform clock driver provides a clock register configuration
  * for each configurable rate which is then used to program the clock hardware
- * registers to acheive a fast co-oridinated rate change for all the CPU domain
+ * registers to achieve a fast co-oridinated rate change for all the CPU domain
  * clocks.
  *
  * On a rate change request for the CPU clock, the rate change is propagated
diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
index efc4fa61fbaf..d2c0193a3930 100644
--- a/drivers/clk/samsung/clk-cpu.c
+++ b/drivers/clk/samsung/clk-cpu.c
@@ -19,7 +19,7 @@
  * clock and the corresponding rate changes of the auxillary clocks of the CPU
  * domain. The platform clock driver provides a clock register configuration
  * for each configurable rate which is then used to program the clock hardware
- * registers to acheive a fast co-oridinated rate change for all the CPU domain
+ * registers to achieve a fast co-oridinated rate change for all the CPU domain
  * clocks.
  *
  * On a rate change request for the CPU clock, the rate change is propagated
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 310afa708831..e9c7d5e0fd93 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -185,7 +185,7 @@ void hns3_set_vector_coalesce_rl(struct 
hns3_enet_tqp_vector *tqp_vector,
 
/* this defines the configuration for RL (Interrupt Rate Limiter).
 * Rl defines rate of interrupts i.e. number of interrupts-per-second
-* GL and RL(Rate Limiter) are 2 ways to acheive interrupt coalescing
+* GL and RL(Rate Limiter) are 2 ways to achieve interrupt coalescing
 */
 
if (rl_reg > 0 && !tqp_vector->tx_group.coal.gl_adapt_enable &&
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 6467d5e1df2d..ab7d60174651 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -2574,7 +2574,7 @@ xfs_ifree_cluster(
 * only using to mark the buffer as stale in the log, and to
 * attach stale cached inodes on it. That means it will never be
 * dispatched for IO. If it is, we want to know about it, and we
-* want it to fail. We can acheive this by adding a write
+* want it to fail. We can achieve this by adding a write
 * verifier to the buffer.
 */
bp->b_ops = &xfs_inode_buf_ops;
-- 
2.22.0

Re: [PATCH] dmaengine: stm32-dma: Use struct_size() helper

[Vinod Koul]

On 30-08-19, 11:14, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
> 
> struct stm32_dma_desc {
>   ...
> struct stm32_dma_sg_req sg_req[];
> };
> 
> 
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> So, replace the following function:
> 
> static struct stm32_dma_desc *stm32_dma_alloc_desc(u32 num_sgs)
> {
>return kzalloc(sizeof(struct stm32_dma_desc) +
>   sizeof(struct stm32_dma_sg_req) * num_sgs, GFP_NOWAIT);
> }
> 
> with:
> 
> kzalloc(struct_size(desc, sg_req, num_sgs), GFP_NOWAIT)
> 
> This code was detected with the help of Coccinelle.

Applied, thanks

-- 
~Vinod

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Daniel Colascione]

On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan  wrote:
>
> On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
>  wrote:
> >
> > Useful to track how RSS is changing per TGID to detect spikes in RSS and
> > memory hogs. Several Android teams have been using this patch in various
> > kernel trees for half a year now. Many reported to me it is really
> > useful so I'm posting it upstream.

It's also worth being able to turn off the per-task memory counter
caching, otherwise you'll have two levels of batching before the
counter gets updated, IIUC.

Re: "beyond 2038" warnings from loopback mount is noisy

[Deepa Dinamani]

If we don't care to warn about the timestamps that are clamped in
memory, maybe we could just warn when they are being written out.
Would something like this be more acceptable? I would also remove the
warning in ext4.h. I think we don't have to check if the inode is 128
bytes here (Please correct me if I am wrong). If this looks ok, I can
post this.

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9e3ae3be3de9..24b14bd3feab 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -833,10 +833,8 @@ do {
 \
(raw_inode)->xtime ## _extra =
 \

ext4_encode_extra_time(&(inode)->xtime);\
}
 \
-   else{\
+   else\
(raw_inode)->xtime = cpu_to_le32(clamp_t(int32_t,
(inode)->xtime.tv_sec, S32_MIN, S32_MAX));\
-   ext4_warning_inode(inode, "inode does not support
timestamps beyond 2038"); \
-   } \
 } while (0)

 #define EXT4_EINODE_SET_XTIME(xtime, einode, raw_inode)
\
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 491f9ee4040e..cef5b87cc5a6 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -2791,7 +2791,7 @@ int ext4_expand_extra_isize_ea(struct inode
*inode, int new_extra_isize,

 cleanup:
if (error && (mnt_count != le16_to_cpu(sbi->s_es->s_mnt_count))) {
-   ext4_warning(inode->i_sb, "Unable to expand inode %lu.
Delete some EAs or run e2fsck.",
+   ext4_warning(inode->i_sb, "Unable to expand inode %lu.
Delete some EAs or run e2fsck. Timestamps on the inode expire beyond
2038",
 inode->i_ino);
mnt_count = le16_to_cpu(sbi->s_es->s_mnt_count);
}

Re: [PATCH] ioat/dca: Use struct_size() helper

[Vinod Koul]

On 28-08-19, 13:40, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
> 
> struct ioat_dca_priv {
>   ...
> struct ioat_dca_slot req_slots[0];
> };
> 
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
> 
> So, replace the following form:
> 
> sizeof(*ioatdca) + (sizeof(struct ioat_dca_slot) * slots)
> 
> with:
> 
> struct_size(ioatdca, req_slots, slots)
> 
> This code was detected with the help of Coccinelle.

Please do not invent subsystem tags, git log should tell you the
convention to be used!

Applied after fixing tags, thanks

-- 
~Vinod

Re: [PATCH v2 1/5] i3c: master: detach and free device if pre_assign_dyn_addr() fails

[Przemyslaw Gaj]

The 09/03/2019 11:57, Vitor Soares wrote:
> EXTERNAL MAIL
> 
> 
> From: Przemyslaw Gaj 
> Date: Tue, Sep 03, 2019 at 12:13:57
> 
> > Hi Vitor,
> > 
> > I'm sorry for the delay.
> > 
> > The 09/03/2019 12:35, Vitor Soares wrote:
> > > EXTERNAL MAIL
> > > 
> > > 
> > > On pre_assing_dyn_addr() the devices that fail:
> > >   i3c_master_setdasa_locked()
> > >   i3c_master_reattach_i3c_dev()
> > >   i3c_master_retrieve_dev_info()
> > > 
> > > are kept in memory and master->bus.devs list. This makes the i3c devices
> > > without a dynamic address are sent on DEFSLVS CCC command. Fix this by
> > > detaching and freeing the devices that fail on pre_assign_dyn_addr().
> > 
> > What is the problem with sending devices without dynamic address in DEFSLVS?
> 
> How do you address them?
> For the DA field in DEFSLVS frame, the spec says: "shall contain the 
> current value of the Slave's assigned 7-bit Dynamic address". If the 
> device doesn't have the dynamic address assigned yet why send it?
>

What stops us from operating with this device in I2C mode using his SA?

> > Shouldn't we still inform rest of the devices about that? About fact that
> > device with SA without DA exists on the bus?
> 
> I would like to understand what is the use case for this? 

Look above. I2C mode still should be possible IMO. Just consider the case when
you really need some information from that device, main master can assign
dynamic address later but you can make some transfers. I know our framework
does not support that case but secondary master can be different system which
should know that this device exists and don't have DA yet, so I2C mode is
available.

> 
> On I3C spec table "I3C Devices Roles vs Responsibilities", Secondary 
> Master is not responsible to do Dynamic Address Assignment but it is 
> optional to do Hot-Join Dynamic Address Assignment.
> 

Yes, we discussed that few times during the review of Mastership patch series.

> > 
> > I think that this is limitation for us. Espacially we have SA and DA fields 
> > in
> > DEFSLVS frame so we are able to distinguish devices with and without Dynamic
> > Address.
> 
> I would say the reason behind is regarding how to distinguish i2c from 
> i3c devices.
> 
> > 
> > > 
> > > Signed-off-by: Vitor Soares 
> > > ---
> > > Changes in v2:
> > >   - Move out detach/free the i3c_dev_desc from pre_assign_dyn_addr()
> > >   - Convert i3c_master_pre_assign_dyn_addr() to return an int
> > > 
> > >  drivers/i3c/master.c | 22 +++---
> > >  1 file changed, 15 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > > index 5f4bd52..586e34f 100644
> > > --- a/drivers/i3c/master.c
> > > +++ b/drivers/i3c/master.c
> > > @@ -1426,19 +1426,19 @@ static void i3c_master_detach_i2c_dev(struct 
> > > i2c_dev_desc *dev)
> > >   master->ops->detach_i2c_dev(dev);
> > >  }
> > >  
> > > -static void i3c_master_pre_assign_dyn_addr(struct i3c_dev_desc *dev)
> > > +static int i3c_master_pre_assign_dyn_addr(struct i3c_dev_desc *dev)
> > >  {
> > >   struct i3c_master_controller *master = i3c_dev_get_master(dev);
> > >   int ret;
> > >  
> > >   if (!dev->boardinfo || !dev->boardinfo->init_dyn_addr ||
> > >   !dev->boardinfo->static_addr)
> > > - return;
> > > + return 0;
> > >  
> > >   ret = i3c_master_setdasa_locked(master, dev->info.static_addr,
> > >   dev->boardinfo->init_dyn_addr);
> > >   if (ret)
> > > - return;
> > > + return ret;
> > >  
> > >   dev->info.dyn_addr = dev->boardinfo->init_dyn_addr;
> > >   ret = i3c_master_reattach_i3c_dev(dev, 0);
> > > @@ -1449,10 +1449,12 @@ static void i3c_master_pre_assign_dyn_addr(struct 
> > > i3c_dev_desc *dev)
> > >   if (ret)
> > >   goto err_rstdaa;
> > >  
> > > - return;
> > > + return 0;
> > >  
> > >  err_rstdaa:
> > >   i3c_master_rstdaa_locked(master, dev->boardinfo->init_dyn_addr);
> > > +
> > > + return ret;
> > >  }
> > >  
> > >  static void
> > > @@ -1647,7 +1649,7 @@ static int i3c_master_bus_init(struct 
> > > i3c_master_controller *master)
> > >   enum i3c_addr_slot_status status;
> > >   struct i2c_dev_boardinfo *i2cboardinfo;
> > >   struct i3c_dev_boardinfo *i3cboardinfo;
> > > - struct i3c_dev_desc *i3cdev;
> > > + struct i3c_dev_desc *i3cdev, *i3ctmp;
> > >   struct i2c_dev_desc *i2cdev;
> > >   int ret;
> > >  
> > > @@ -1746,8 +1748,14 @@ static int i3c_master_bus_init(struct 
> > > i3c_master_controller *master)
> > >* Pre-assign dynamic address and retrieve device information if
> > >* needed.
> > >*/
> > > - i3c_bus_for_each_i3cdev(&master->bus, i3cdev)
> > > - i3c_master_pre_assign_dyn_addr(i3cdev);
> > > + list_for_each_entry_safe(i3cdev, i3ctmp, &master->bus.devs.i3c,
> > > +  common.node) {
> > > + ret = i3c_master_pre_assign_dyn_addr(i3cdev);
> > > + if (ret) {
> > > + i3c_master_detach_i3c_dev(i3cdev);
> > > 

Re: [PATCH -next] dmaengine: iop-adma: remove set but not used variable 'slots_per_op'

[Vinod Koul]

On 21-08-19, 20:19, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/dma/iop-adma.c: In function iop_adma_tx_submit:
> drivers/dma/iop-adma.c:367:6: warning:
>  variable slots_per_op set but not used [-Wunused-but-set-variable]
> 
> It is never used, so can be removed.

Applied, thanks

-- 
~Vinod

[PATCH 2/2] PCI: Unify pci_dev_is_disconnected() and pci_dev_is_inaccessible()

[Kelsey Skunberg]

Combine pci_dev_is_disconnected() with pci_dev_is_inaccessible() so only
one function is used to learn if we should avoid accessing a device that's
inaccessible due to surprise removal or an error condition.

The use cases for pci_dev_is_disconnected() do not need to distinguish
between a device being inaccessible due to a surprise removal or an error
condition. This provides the opportunity to unify
pci_dev_is_disconnected() and pci_dev_is_inaccessible() to reduce multiple
functions used for the same task.

Change pci_dev_is_disconnected() call inside pci_dev_is_inaccessible() to:

pdev->error_state == pci_channel_io_perm_failure

Change remaining pci_dev_is_disconnected() calls to
pci_dev_is_inaccessible() calls.

Remove pci_dev_is_disconnected() from /pci/pci.h which would now no longer
be used.

Demonstration of changes to pci_dev_is_disconnected() and
pci_dev_is_inaccessible():

Before combining:

static inline bool pci_dev_is_disconnected(const struct pci_dev *dev)
{
return dev->error_state == pci_channel_io_perm_failure;
}

bool pci_dev_is_inaccessible(struct pci_dev *pdev)
{
u32 v;

if (pci_dev_is_disconnected(pdev))
return true;
return !pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 
0);
}

After combining:

bool pci_dev_is_inaccessible(struct pci_dev *pdev)
{
u32 v;

if (pdev->error_state == pci_channel_io_perm_failure)
return true;
return !pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 
0);
}

Signed-off-by: Kelsey Skunberg 
---
 drivers/pci/access.c| 12 ++--
 drivers/pci/msi.c   |  4 ++--
 drivers/pci/pci.c   |  2 +-
 drivers/pci/pci.h   |  5 -
 drivers/pci/pcie/portdrv_core.c |  2 +-
 5 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 544922f097c0..c096340afb8c 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -535,7 +535,7 @@ EXPORT_SYMBOL(pcie_capability_clear_and_set_dword);
 
 int pci_read_config_byte(const struct pci_dev *dev, int where, u8 *val)
 {
-   if (pci_dev_is_disconnected(dev)) {
+   if (pci_dev_is_inaccessible(dev)) {
*val = ~0;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -545,7 +545,7 @@ EXPORT_SYMBOL(pci_read_config_byte);
 
 int pci_read_config_word(const struct pci_dev *dev, int where, u16 *val)
 {
-   if (pci_dev_is_disconnected(dev)) {
+   if (pci_dev_is_inaccessible(dev)) {
*val = ~0;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -556,7 +556,7 @@ EXPORT_SYMBOL(pci_read_config_word);
 int pci_read_config_dword(const struct pci_dev *dev, int where,
u32 *val)
 {
-   if (pci_dev_is_disconnected(dev)) {
+   if (pci_dev_is_inaccessible(dev)) {
*val = ~0;
return PCIBIOS_DEVICE_NOT_FOUND;
}
@@ -566,7 +566,7 @@ EXPORT_SYMBOL(pci_read_config_dword);
 
 int pci_write_config_byte(const struct pci_dev *dev, int where, u8 val)
 {
-   if (pci_dev_is_disconnected(dev))
+   if (pci_dev_is_inaccessible(dev))
return PCIBIOS_DEVICE_NOT_FOUND;
return pci_bus_write_config_byte(dev->bus, dev->devfn, where, val);
 }
@@ -574,7 +574,7 @@ EXPORT_SYMBOL(pci_write_config_byte);
 
 int pci_write_config_word(const struct pci_dev *dev, int where, u16 val)
 {
-   if (pci_dev_is_disconnected(dev))
+   if (pci_dev_is_inaccessible(dev))
return PCIBIOS_DEVICE_NOT_FOUND;
return pci_bus_write_config_word(dev->bus, dev->devfn, where, val);
 }
@@ -583,7 +583,7 @@ EXPORT_SYMBOL(pci_write_config_word);
 int pci_write_config_dword(const struct pci_dev *dev, int where,
 u32 val)
 {
-   if (pci_dev_is_disconnected(dev))
+   if (pci_dev_is_inaccessible(dev))
return PCIBIOS_DEVICE_NOT_FOUND;
return pci_bus_write_config_dword(dev->bus, dev->devfn, where, val);
 }
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0884bedcfc7a..4680043aa315 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -311,7 +311,7 @@ void __pci_write_msi_msg(struct msi_desc *entry, struct 
msi_msg *msg)
 {
struct pci_dev *dev = msi_desc_to_pci_dev(entry);
 
-   if (dev->current_state != PCI_D0 || pci_dev_is_disconnected(dev)) {
+   if (dev->current_state != PCI_D0 || pci_dev_is_inaccessible(dev)) {
/* Don't touch the hardware now */
} else if (entry->msi_attrib.is_msix) {
void __iomem *base = pci_msix_desc_addr(entry);
@@ -1008,7 +1008,7 @@ static void pci_msix_shutdown(struct pci_dev *dev)
if (!pci_msi_enable || !dev || !dev->msix_enabled)
return;
 
-   if (pci_dev

[PATCH 1/2] PCI: Change pci_device_is_present() to pci_dev_is_inaccessible()

[Kelsey Skunberg]

The pci_device_is_present() name may encourage poor practice of calling
pci_device_is_present() and if true, assuming the device is still present
after the call. This type of practice can be racy when assuming a device
is still connected after checking.

Change pci_device_is_present() to pci_dev_is_inaccessible() to promote
only using to learn whether we should avoid accessing a device that's
inaccessible.

Change pci_device_is_inaccessible() to now return true if PCI device is
inaccessible.

Change the boolean values returned from calling pci_dev_is_inaccessible()
to their opposite value to reflect the change of checking if the device is
present to checking if the device is inaccessible. Example:
Before:
if (!pci_device_is_present(tp->pdev))
return -ENODEV;
After:
if (pci_dev_is_inaccessible(tp->pdev))
return -ENODEV;

Signed-off-by: Kelsey Skunberg 
---
 drivers/net/ethernet/broadcom/tg3.c   |  4 ++--
 drivers/net/ethernet/intel/igb/igb_main.c |  2 +-
 drivers/nvme/host/pci.c   |  2 +-
 drivers/pci/hotplug/acpiphp_glue.c|  2 +-
 drivers/pci/pci.c | 10 +-
 drivers/thunderbolt/nhi.c |  2 +-
 include/linux/pci.h   |  2 +-
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 4c404d2213f9..7646a8303d01 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9067,7 +9067,7 @@ static int tg3_chip_reset(struct tg3 *tp)
void (*write_op)(struct tg3 *, u32, u32);
int i, err;
 
-   if (!pci_device_is_present(tp->pdev))
+   if (pci_dev_is_inaccessible(tp->pdev))
return -ENODEV;
 
tg3_nvram_lock(tp);
@@ -11782,7 +11782,7 @@ static int tg3_close(struct net_device *dev)
 
tg3_stop(tp);
 
-   if (pci_device_is_present(tp->pdev)) {
+   if (!pci_dev_is_inaccessible(tp->pdev)) {
tg3_power_down_prepare(tp);
 
tg3_carrier_off(tp);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c 
b/drivers/net/ethernet/intel/igb/igb_main.c
index b4df3e319467..87bc067c2abc 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -8835,7 +8835,7 @@ static int __maybe_unused igb_resume(struct device *dev)
pci_restore_state(pdev);
pci_save_state(pdev);
 
-   if (!pci_device_is_present(pdev))
+   if (pci_dev_is_inaccessible(pdev))
return -ENODEV;
err = pci_enable_device_mem(pdev);
if (err) {
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index bb970ca82517..2a4500325471 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2812,7 +2812,7 @@ static void nvme_remove(struct pci_dev *pdev)
nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
pci_set_drvdata(pdev, NULL);
 
-   if (!pci_device_is_present(pdev)) {
+   if (pci_dev_is_inaccessible(pdev)) {
nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DEAD);
nvme_dev_disable(dev, true);
nvme_dev_remove_admin(dev);
diff --git a/drivers/pci/hotplug/acpiphp_glue.c 
b/drivers/pci/hotplug/acpiphp_glue.c
index e4c46637f32f..9cc2d65877bd 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -647,7 +647,7 @@ static void trim_stale_devices(struct pci_dev *dev)
alive = alive || (ACPI_SUCCESS(status) && 
device_status_valid(sta));
}
if (!alive)
-   alive = pci_device_is_present(dev);
+   alive = !pci_dev_is_inaccessible(dev);
 
if (!alive) {
pci_dev_set_disconnected(dev, NULL);
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 29ed5ec1ac27..7b4e248db5f9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -931,7 +931,7 @@ static int pci_raw_set_power_state(struct pci_dev *dev, 
pci_power_t state)
 void pci_update_current_state(struct pci_dev *dev, pci_power_t state)
 {
if (platform_pci_get_power_state(dev) == PCI_D3cold ||
-   !pci_device_is_present(dev)) {
+   pci_dev_is_inaccessible(dev)) {
dev->current_state = PCI_D3cold;
} else if (dev->pm_cap) {
u16 pmcsr;
@@ -5906,15 +5906,15 @@ bool pci_devs_are_dma_aliases(struct pci_dev *dev1, 
struct pci_dev *dev2)
test_bit(dev1->devfn, dev2->dma_alias_mask));
 }
 
-bool pci_device_is_present(struct pci_dev *pdev)
+bool pci_dev_is_inaccessible(struct pci_dev *pdev)
 {
u32 v;
 
if (pci_dev_is_disconnected(pdev))
-   return false;
-   return pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 0);
+   return true;
+   return !pci_bus_read_dev_vendor_id(pdev->bus, pdev->devfn, &v, 0);
 }
-EXPORT

[PATCH 0/2] PCI: Change to using pci_dev_is_inaccessible()

[Kelsey Skunberg]

Patch 1: Change pci_device_is_present() name to pci_dev_is_inaccessible()
 to encourage only using to learn if we should not access a
 device that's inaccessible. Return value will need to be reversed
 to reflect the name change.

Patch 2: Relies on patch 1. Unify pci_dev_is_disconnected() with
 pci_dev_is_inaccessible() so there is only one function
 needed to learn if a device is inaccessible due to surprise
 removal or an error condition.

Kelsey Skunberg (2):
  PCI: Change pci_device_is_present() to pci_dev_is_inaccessible()
  PCI: Unify pci_dev_is_disconnected() and pci_dev_is_inaccessible()

 drivers/net/ethernet/broadcom/tg3.c   |  4 ++--
 drivers/net/ethernet/intel/igb/igb_main.c |  2 +-
 drivers/nvme/host/pci.c   |  2 +-
 drivers/pci/access.c  | 12 ++--
 drivers/pci/hotplug/acpiphp_glue.c|  2 +-
 drivers/pci/msi.c |  4 ++--
 drivers/pci/pci.c | 12 ++--
 drivers/pci/pci.h |  5 -
 drivers/pci/pcie/portdrv_core.c   |  2 +-
 drivers/thunderbolt/nhi.c |  2 +-
 include/linux/pci.h   |  2 +-
 11 files changed, 22 insertions(+), 27 deletions(-)

-- 
2.20.1

Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold

[Suren Baghdasaryan]

On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google)
 wrote:
>
> Useful to track how RSS is changing per TGID to detect spikes in RSS and
> memory hogs. Several Android teams have been using this patch in various
> kernel trees for half a year now. Many reported to me it is really
> useful so I'm posting it upstream.
>
> Initial patch developed by Tim Murray. Changes I made from original patch:
> o Prevent any additional space consumed by mm_struct.
> o Keep overhead low by checking if tracing is enabled.
> o Add some noise reduction and lower overhead by emitting only on
>   threshold changes.
>
> Co-developed-by: Tim Murray 
> Signed-off-by: Tim Murray 
> Signed-off-by: Joel Fernandes (Google) 
>
> ---
>
> v1->v2: Added more commit message.
>
> Cc: carmenjack...@google.com
> Cc: mayankgu...@google.com
> Cc: dan...@google.com
> Cc: rost...@goodmis.org
> Cc: minc...@kernel.org
> Cc: a...@linux-foundation.org
> Cc: kernel-t...@android.com
>
>  include/linux/mm.h  | 14 +++---
>  include/trace/events/kmem.h | 21 +
>  mm/memory.c | 20 
>  3 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0334ca97c584..823aaf759bdb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1671,19 +1671,27 @@ static inline unsigned long get_mm_counter(struct 
> mm_struct *mm, int member)
> return (unsigned long)val;
>  }
>
> +void mm_trace_rss_stat(int member, long count, long value);
> +
>  static inline void add_mm_counter(struct mm_struct *mm, int member, long 
> value)
>  {
> -   atomic_long_add(value, &mm->rss_stat.count[member]);
> +   long count = atomic_long_add_return(value, 
> &mm->rss_stat.count[member]);
> +
> +   mm_trace_rss_stat(member, count, value);
>  }
>
>  static inline void inc_mm_counter(struct mm_struct *mm, int member)
>  {
> -   atomic_long_inc(&mm->rss_stat.count[member]);
> +   long count = atomic_long_inc_return(&mm->rss_stat.count[member]);
> +
> +   mm_trace_rss_stat(member, count, 1);
>  }
>
>  static inline void dec_mm_counter(struct mm_struct *mm, int member)
>  {
> -   atomic_long_dec(&mm->rss_stat.count[member]);
> +   long count = atomic_long_dec_return(&mm->rss_stat.count[member]);
> +
> +   mm_trace_rss_stat(member, count, -1);
>  }
>
>  /* Optimized variant when page is already known not to be PageAnon */
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index eb57e3037deb..8b88e04fafbf 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -315,6 +315,27 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> __entry->change_ownership)
>  );
>
> +TRACE_EVENT(rss_stat,
> +
> +   TP_PROTO(int member,
> +   long count),
> +
> +   TP_ARGS(member, count),
> +
> +   TP_STRUCT__entry(
> +   __field(int, member)
> +   __field(long, size)
> +   ),
> +
> +   TP_fast_assign(
> +   __entry->member = member;
> +   __entry->size = (count << PAGE_SHIFT);
> +   ),
> +
> +   TP_printk("member=%d size=%ldB",
> +   __entry->member,
> +   __entry->size)
> +   );
>  #endif /* _TRACE_KMEM_H */
>
>  /* This part must be outside protection */
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..9d81322c24a3 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -72,6 +72,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -140,6 +142,24 @@ static int __init init_zero_pfn(void)
>  }
>  core_initcall(init_zero_pfn);
>
> +/*
> + * This threshold is the boundary in the value space, that the counter has to
> + * advance before we trace it. Should be a power of 2. It is to reduce 
> unwanted
> + * trace overhead. The counter is in units of number of pages.
> + */
> +#define TRACE_MM_COUNTER_THRESHOLD 128

IIUC the counter has to change by 128 pages (512kB assuming 4kB pages)
before the change gets traced. Would it make sense to make this step
size configurable? For a system with limited memory size change of
512kB might be considerable while on systems with plenty of memory
that might be negligible. Not even mentioning possible difference in
page sizes. Maybe something like
/sys/kernel/debug/tracing/rss_step_order with
TRACE_MM_COUNTER_THRESHOLD=(1< +
> +void mm_trace_rss_stat(int member, long count, long value)
> +{
> +   long thresh_mask = ~(TRACE_MM_COUNTER_THRESHOLD - 1);
> +
> +   if (!trace_rss_stat_enabled())
> +   return;
> +
> +   /* Threshold roll-over, trace it */
> +   if ((count & thresh_mask) != ((count - value) & thresh_mask))
> +   trace_rss_stat(member, count);
> +}
>
>  #if defined(SPLIT_RSS_COUNTING)
>
> --
> 2.23.0.187.g17f5b7556c-goog
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-team+unsubscr...@andr

[PATCH V2 12/12] serial: tegra: Add PIO mode support

[Krishna Yarlagadda]

Add PIO mode support in receive and transmit path with RX interrupt
trigger of 16 bytes for Tegra194 and older chips.

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/tty/serial/serial-tegra.c | 117 --
 1 file changed, 86 insertions(+), 31 deletions(-)

diff --git a/drivers/tty/serial/serial-tegra.c 
b/drivers/tty/serial/serial-tegra.c
index d0fd417..2f59951 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -139,6 +139,8 @@ struct tegra_uart_port {
int n_adjustable_baud_rates;
int required_rate;
int configured_rate;
+   booluse_rx_pio;
+   booluse_tx_pio;
 };
 
 static void tegra_uart_start_next_tx(struct tegra_uart_port *tup);
@@ -567,7 +569,7 @@ static void tegra_uart_start_next_tx(struct tegra_uart_port 
*tup)
if (!count)
return;
 
-   if (count < TEGRA_UART_MIN_DMA)
+   if (tup->use_tx_pio || count < TEGRA_UART_MIN_DMA)
tegra_uart_start_pio_tx(tup, count);
else if (BYTES_TO_ALIGN(tail) > 0)
tegra_uart_start_pio_tx(tup, BYTES_TO_ALIGN(tail));
@@ -800,6 +802,18 @@ static void tegra_uart_handle_modem_signal_change(struct 
uart_port *u)
uart_handle_cts_change(&tup->uport, msr & UART_MSR_CTS);
 }
 
+static void do_handle_rx_pio(struct tegra_uart_port *tup)
+{
+   struct tty_struct *tty = tty_port_tty_get(&tup->uport.state->port);
+   struct tty_port *port = &tup->uport.state->port;
+
+   tegra_uart_handle_rx_pio(tup, port);
+   if (tty) {
+   tty_flip_buffer_push(port);
+   tty_kref_put(tty);
+   }
+}
+
 static irqreturn_t tegra_uart_isr(int irq, void *data)
 {
struct tegra_uart_port *tup = data;
@@ -813,7 +827,7 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
while (1) {
iir = tegra_uart_read(tup, UART_IIR);
if (iir & UART_IIR_NO_INT) {
-   if (is_rx_int) {
+   if (!tup->use_rx_pio && is_rx_int) {
tegra_uart_handle_rx_dma(tup);
if (tup->rx_in_progress) {
ier = tup->ier_shadow;
@@ -841,7 +855,7 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
case 4: /* End of data */
case 6: /* Rx timeout */
case 2: /* Receive */
-   if (!is_rx_int) {
+   if (!tup->use_rx_pio && !is_rx_int) {
is_rx_int = true;
/* Disable Rx interrupts */
ier = tup->ier_shadow;
@@ -851,6 +865,8 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
UART_IER_RTOIE | TEGRA_UART_IER_EORD);
tup->ier_shadow = ier;
tegra_uart_write(tup, ier, UART_IER);
+   } else {
+   do_handle_rx_pio(tup);
}
break;
 
@@ -869,6 +885,7 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
 static void tegra_uart_stop_rx(struct uart_port *u)
 {
struct tegra_uart_port *tup = to_tegra_uport(u);
+   struct tty_port *port = &tup->uport.state->port;
struct dma_tx_state state;
unsigned long ier;
 
@@ -886,9 +903,13 @@ static void tegra_uart_stop_rx(struct uart_port *u)
tup->ier_shadow = ier;
tegra_uart_write(tup, ier, UART_IER);
tup->rx_in_progress = 0;
-   dmaengine_terminate_all(tup->rx_dma_chan);
-   dmaengine_tx_status(tup->rx_dma_chan, tup->rx_cookie, &state);
-   tegra_uart_rx_buffer_push(tup, state.residue);
+   if (tup->rx_dma_chan && !tup->use_rx_pio) {
+   dmaengine_terminate_all(tup->rx_dma_chan);
+   dmaengine_tx_status(tup->rx_dma_chan, tup->rx_cookie, &state);
+   tegra_uart_rx_buffer_push(tup, state.residue);
+   } else {
+   tegra_uart_handle_rx_pio(tup, port);
+   }
 }
 
 static void tegra_uart_hw_deinit(struct tegra_uart_port *tup)
@@ -939,8 +960,10 @@ static void tegra_uart_hw_deinit(struct tegra_uart_port 
*tup)
tup->rx_in_progress = 0;
tup->tx_in_progress = 0;
 
-   tegra_uart_dma_channel_free(tup, true);
-   tegra_uart_dma_channel_free(tup, false);
+   if (!tup->use_rx_pio)
+   tegra_uart_dma_channel_free(tup, true);
+   if (!tup->use_tx_pio)
+   tegra_uart_dma_channel_free(tup, false);
 
clk_disable_unprepare(tup->uart_clk);
 }
@@ -985,10 +1008,14 @@ static int tegra_uart_hw_init(struct tegra_uart_port 
*tup)
 */
 

[PATCH V2 06/12] serial: tegra: check for FIFO mode enabled status

[Krishna Yarlagadda]

Chips prior to Tegra186 needed delay of 3 UART clock cycles to avoid
data loss. This issue is fixed in Tegra186 and a new flag is added to
check if FIFO mode is enabled. chip data updated to check if this flag
is available for a chip. Tegra186 has new compatible to enable this
flag.

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/tty/serial/serial-tegra.c | 52 ++-
 1 file changed, 46 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/serial-tegra.c 
b/drivers/tty/serial/serial-tegra.c
index c3f9913..69af621 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -72,6 +72,8 @@
 #define TEGRA_TX_PIO   1
 #define TEGRA_TX_DMA   2
 
+#define TEGRA_UART_FCR_IIR_FIFO_EN 0x40
+
 /**
  * tegra_uart_chip_data: SOC specific data.
  *
@@ -84,6 +86,7 @@ struct tegra_uart_chip_data {
booltx_fifo_full_status;
boolallow_txfifo_reset_fifo_mode;
boolsupport_clk_src_div;
+   boolfifo_mode_enable_status;
 };
 
 struct tegra_uart_port {
@@ -263,6 +266,21 @@ static void tegra_uart_wait_sym_time(struct 
tegra_uart_port *tup,
tup->current_baud));
 }
 
+static int tegra_uart_wait_fifo_mode_enabled(struct tegra_uart_port *tup)
+{
+   unsigned long iir;
+   unsigned int tmout = 100;
+
+   do {
+   iir = tegra_uart_read(tup, UART_IIR);
+   if (iir & TEGRA_UART_FCR_IIR_FIFO_EN)
+   return 0;
+   udelay(1);
+   } while (--tmout);
+
+   return -ETIMEDOUT;
+}
+
 static void tegra_uart_fifo_reset(struct tegra_uart_port *tup, u8 fcr_bits)
 {
unsigned long fcr = tup->fcr_shadow;
@@ -282,6 +300,8 @@ static void tegra_uart_fifo_reset(struct tegra_uart_port 
*tup, u8 fcr_bits)
tegra_uart_write(tup, fcr, UART_FCR);
fcr |= UART_FCR_ENABLE_FIFO;
tegra_uart_write(tup, fcr, UART_FCR);
+   if (tup->cdata->fifo_mode_enable_status)
+   tegra_uart_wait_fifo_mode_enabled(tup);
}
 
/* Dummy read to ensure the write is posted */
@@ -917,12 +937,20 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup)
/* Dummy read to ensure the write is posted */
tegra_uart_read(tup, UART_SCR);
 
-   /*
-* For all tegra devices (up to t210), there is a hardware issue that
-* requires software to wait for 3 UART clock periods after enabling
-* the TX fifo, otherwise data could be lost.
-*/
-   tegra_uart_wait_cycle_time(tup, 3);
+   if (tup->cdata->fifo_mode_enable_status) {
+   ret = tegra_uart_wait_fifo_mode_enabled(tup);
+   dev_err(tup->uport.dev, "FIFO mode not enabled\n");
+   if (ret < 0)
+   return ret;
+   } else {
+   /*
+* For all tegra devices (up to t210), there is a hardware
+* issue that requires software to wait for 3 UART clock
+* periods after enabling the TX fifo, otherwise data could
+* be lost.
+*/
+   tegra_uart_wait_cycle_time(tup, 3);
+   }
 
/*
 * Initialize the UART with default configuration
@@ -1293,12 +1321,21 @@ static struct tegra_uart_chip_data 
tegra20_uart_chip_data = {
.tx_fifo_full_status= false,
.allow_txfifo_reset_fifo_mode   = true,
.support_clk_src_div= false,
+   .fifo_mode_enable_status= false,
 };
 
 static struct tegra_uart_chip_data tegra30_uart_chip_data = {
.tx_fifo_full_status= true,
.allow_txfifo_reset_fifo_mode   = false,
.support_clk_src_div= true,
+   .fifo_mode_enable_status= false,
+};
+
+static struct tegra_uart_chip_data tegra186_uart_chip_data = {
+   .tx_fifo_full_status= true,
+   .allow_txfifo_reset_fifo_mode   = false,
+   .support_clk_src_div= true,
+   .fifo_mode_enable_status= true,
 };
 
 static const struct of_device_id tegra_uart_of_match[] = {
@@ -1309,6 +1346,9 @@ static const struct of_device_id tegra_uart_of_match[] = {
.compatible = "nvidia,tegra20-hsuart",
.data   = &tegra20_uart_chip_data,
}, {
+   .compatible = "nvidia,tegra186-hsuart",
+   .data   = &tegra186_uart_chip_data,
+   }, {
},
 };
 MODULE_DEVICE_TABLE(of, tegra_uart_of_match);
-- 
2.7.4

[PATCH V2 05/12] dt-binding: serial: tegra: add new chips

[Krishna Yarlagadda]

Add new compatible string for Tegra186. It differs from earlier chips
as it has FIFO mode enable check and 8 byte DMA buffer.
Add new compatible string for Tegra194. Tegra194 has different error
tolerance levels for baud rate compared to older chips.

Signed-off-by: Krishna Yarlagadda 
---
 Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt 
b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
index d7edf73..dab31d4 100644
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -1,7 +1,12 @@
 NVIDIA Tegra20/Tegra30 high speed (DMA based) UART controller driver.
 
 Required properties:
-- compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+- compatible : should be,
+  "nvidia,tegra20-hsuart" for Tegra20,
+  "nvidia,tegra30-hsuart" for Tegra30,
+  "nvidia,tegra186-hsuart" for Tegra186,
+  "nvidia,tegra194-hsuart" for Tegra194.
+
 - reg: Should contain UART controller registers location and length.
 - interrupts: Should contain UART controller interrupts.
 - clocks: Must contain one entry, for the module clock.
-- 
2.7.4

[PATCH V2 08/12] serial: tegra: add support to use 8 bytes trigger

[Krishna Yarlagadda]

Add support to use 8 bytes trigger for Tegra186 SOC.

Signed-off-by: Shardar Shariff Md 
Signed-off-by: Krishna Yarlagadda 
---
 drivers/tty/serial/serial-tegra.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/serial-tegra.c 
b/drivers/tty/serial/serial-tegra.c
index 8422516..02f8535 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -88,6 +88,7 @@ struct tegra_uart_chip_data {
boolsupport_clk_src_div;
boolfifo_mode_enable_status;
int uart_max_port;
+   int max_dma_burst_bytes;
 };
 
 struct tegra_uart_port {
@@ -931,7 +932,12 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup)
 * programmed in the DMA registers.
 */
tup->fcr_shadow = UART_FCR_ENABLE_FIFO;
-   tup->fcr_shadow |= UART_FCR_R_TRIG_01;
+
+   if (tup->cdata->max_dma_burst_bytes == 8)
+   tup->fcr_shadow |= UART_FCR_R_TRIG_10;
+   else
+   tup->fcr_shadow |= UART_FCR_R_TRIG_01;
+
tup->fcr_shadow |= TEGRA_UART_TX_TRIG_16B;
tegra_uart_write(tup, tup->fcr_shadow, UART_FCR);
 
@@ -1045,7 +1051,7 @@ static int tegra_uart_dma_channel_allocate(struct 
tegra_uart_port *tup,
}
dma_sconfig.src_addr = tup->uport.mapbase;
dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-   dma_sconfig.src_maxburst = 4;
+   dma_sconfig.src_maxburst = tup->cdata->max_dma_burst_bytes;
tup->rx_dma_chan = dma_chan;
tup->rx_dma_buf_virt = dma_buf;
tup->rx_dma_buf_phys = dma_phys;
@@ -1324,6 +1330,7 @@ static struct tegra_uart_chip_data tegra20_uart_chip_data 
= {
.support_clk_src_div= false,
.fifo_mode_enable_status= false,
.uart_max_port  = 5,
+   .max_dma_burst_bytes= 4,
 };
 
 static struct tegra_uart_chip_data tegra30_uart_chip_data = {
@@ -1332,6 +1339,7 @@ static struct tegra_uart_chip_data tegra30_uart_chip_data 
= {
.support_clk_src_div= true,
.fifo_mode_enable_status= false,
.uart_max_port  = 5,
+   .max_dma_burst_bytes= 4,
 };
 
 static struct tegra_uart_chip_data tegra186_uart_chip_data = {
@@ -1340,6 +1348,7 @@ static struct tegra_uart_chip_data 
tegra186_uart_chip_data = {
.support_clk_src_div= true,
.fifo_mode_enable_status= true,
.uart_max_port  = 8,
+   .max_dma_burst_bytes= 8,
 };
 
 static const struct of_device_id tegra_uart_of_match[] = {
-- 
2.7.4