Re: [PATCH 4.14 105/136] usb/ehci-platform: Set PM runtime as active on resume

[Eugeniu Rosca]

Hello everyone,

Cc: linux-renesas-soc
Cc: linux-pm

On Tue, Jun 23, 2020 at 09:59:21PM +0200, Greg Kroah-Hartman wrote:
> From: Qais Yousef 
> 
> [ Upstream commit 16bdc04cc98ab0c74392ceef2475ecc5e73fcf49 ]
> 
> Follow suit of ohci-platform.c and perform pm_runtime_set_active() on
> resume.
> 
> ohci-platform.c had a warning reported due to the missing
> pm_runtime_set_active() [1].
> 
> [1] 
> https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3...@e107158-lin.cambridge.arm.com/
> 
> Acked-by: Alan Stern 
> Signed-off-by: Qais Yousef 
> CC: Tony Prisk 
> CC: Greg Kroah-Hartman 
> CC: Mathias Nyman 
> CC: Oliver Neukum 
> CC: linux-arm-ker...@lists.infradead.org
> CC: linux-...@vger.kernel.org
> CC: linux-kernel@vger.kernel.org
> Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.you...@arm.com
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/usb/host/ehci-platform.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-platform.c 
> b/drivers/usb/host/ehci-platform.c
> index f1908ea9fbd86..6fcd332880143 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -390,6 +390,11 @@ static int ehci_platform_resume(struct device *dev)
>   }
>  
>   ehci_resume(hcd, priv->reset_on_resume);
> +
> + pm_runtime_disable(dev);
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> +
>   return 0;

After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
Set PM runtime as active on resume") into downstream v4.14.x, we started
to consistently experience below panic [1] on every second s2ram of
R-Car H3 Salvator-X Renesas reference board.

After some investigations, we concluded the following:
 - the issue does not exist in vanilla v5.8-rc4+
 - [bisecting shows that] the panic on v4.14.186 is caused by the lack
   of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
   link support"). Getting evidence for that is easy. Reverting
   987351e1ea7772 in vanilla leads to a similar backtrace [2].

Questions:
 - Backporting 987351e1ea7772 ("phy: core: Add consumer device
   link support") to v4.14.187 looks challenging enough, so probably not
   worth it. Anybody to contradict this?
 - Assuming no plans to backport the missing mainline commit to v4.14.x,
   should the following three v4.14.186 commits be reverted on v4.14.x?
   * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
   * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
   * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")

[1] https://elinux.org/R-Car/Boards/Salvator-X#Suspend-to-RAM
root@rcar-gen3:~# cat s2ram.sh 
modprobe i2c-dev
echo 9 > /proc/sys/kernel/printk
i2cset -f -y 7 0x30 0x20 0x0F
echo 0 > /sys/module/suspend/parameters/pm_test_delay
echo core  > /sys/power/pm_test
echo deep > /sys/power/mem_sleep
echo 1 > /sys/power/pm_debug_messages
echo 0 > /sys/power/pm_print_times
echo mem > /sys/power/state;
root@rcar-gen3:~#
root@rcar-gen3:~# sh s2ram.sh 
[   65.853020] PM: suspend entry (deep)
[   65.858395] PM: Syncing filesystems ... done.
[   65.895890] PM: Preparing system for sleep (deep)
[   65.906272] Freezing user space processes ... (elapsed 0.004 seconds) done.
[   65.918350] OOM killer disabled.
[   65.921827] Freezing remaining freezable tasks ... (elapsed 0.005 seconds) 
done.
[   65.935063] PM: Suspending system (deep)
[   66.094910] PM: suspend of devices complete after 143.807 msecs
[   66.101282] PM: suspend devices took 0.162 seconds
[   66.133020] PM: late suspend of devices complete after 26.225 msecs
[   66.166806] PM: noirq suspend of devices complete after 24.050 msecs
[   66.173518] Disabling non-boot CPUs ...
[   66.199539] CPU1: shutdown
[   66.202563] psci: CPU1 killed (polled 0 ms)
[   66.230911] CPU2: shutdown
[   66.233923] psci: CPU2 killed (polled 0 ms)
[   66.261940] CPU3: shutdown
[   66.265351] psci: CPU3 killed (polled 0 ms)
[   66.300596] CPU4: shutdown
[   66.303837] psci: CPU4 killed (polled 0 ms)
[   66.340455] NOHZ: local_softirq_pending 202
[   66.346818] CPU5: shutdown
[   66.349811] psci: CPU5 killed (polled 0 ms)
[   66.388761] CPU6: shutdown
[   66.391732] psci: CPU6 killed (polled 0 ms)
[   66.442557] CPU7: shutdown
[   66.445659] psci: CPU7 killed (polled 0 ms)
[   66.452730] PM: suspend debug: Waiting for 0 second(s).
[   66.452730] PM: Timekeeping suspended for 0.005 seconds
[   66.452898] Enabling non-boot CPUs ...
[   66.470705] CPU1 is up
[   66.480825] CPU2 is up
[   66.491482] CPU3 is up
[   66.517818] CPU4 is up
[   66.537699] CPU5 is up
[   66.558622] CPU6 is up
[   66.580985] CPU7 is up
[   66.597724] PM: noirq resume of devices complete after 13.979 msecs
[   66.689793] PM: early resume of devices complete after 83.851 msecs
[   66.700577] Bad mode in Error handler detected on CPU3, code 0xbf02 -- 
SError
[   66.700610] Bad mode in Error handler detected on CPU2, c

Re: [PATCH 0/9] timer: Reduce timers softirq v2

[Juri Lelli]

Hi,

On 07/07/20 03:32, Frederic Weisbecker wrote:
> Hi,
> 
> No huge change here, just addressed reviews and fixed warnings:
> 
> * Reposted patch 1 separately with appropriate "Fixes:" tag and stable Cc'ed:
>   https://lore.kernel.org/lkml/20200703010657.2302-1-frede...@kernel.org/
> 
> * Fix missing initialization of next_expiry in 4/9 (thanks Juri)
> 
> * Dropped "timer: Simplify LVL_START() and calc_index()" and added comments
>   to explain current layout instead in 2/9 (thanks Thomas)
> 
> * Rewrote changelog of 9/9 (Thanks Thomas)
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
>   timers/softirq-v2
> 
> HEAD: 5545d80b7b9bd69ede1c17fda194ac6620e7063f
> 
> Thanks,
>   Frederic
> ---

Testing of this set looks good (even with RT). Feel free to add

Tested-by: Juri Lelli 

to all the patches and to the patch you posted separately (old 01).

Thanks!

Juri

RE: [PATCH v2 0/2] Add support to get/set PHY attributes using PHY framework

[Swapnil Kashinath Jakhade]

Ping requesting review comments.
https://lkml.org/lkml/2020/5/26/507

Thanks & regards,
Swapnil

> -Original Message-
> From: Yuti Amonkar 
> Sent: Tuesday, May 26, 2020 8:05 PM
> To: linux-kernel@vger.kernel.org; kis...@ti.com; robh...@kernel.org;
> mark.rutl...@arm.com; max...@cerno.tech
> Cc: nsek...@ti.com; jsa...@ti.com; tomi.valkei...@ti.com;
> prane...@ti.com; Milind Parab ; Swapnil Kashinath
> Jakhade ; Yuti Suresh Amonkar
> 
> Subject: [PATCH v2 0/2] Add support to get/set PHY attributes using PHY
> framework
> 
> This patch series adds support to use kernel PHY subsystem APIs to get/set
> PHY attributes like number of lanes and maximum link rate.
> 
> It includes following patches:
> 
> 1. v2-0001-phy-Add-max_link_rate-as-a-PHY-attribute-and-APIs.patch
> This patch adds max_link_rate as a PHY attribute along with a pair of APIs
> that allow the generic PHY subsystem to get/set PHY attributes supported by
> the PHY.
> The PHY provider driver may use phy_set_attrs() API to set the values that
> PHY supports.
> The controller driver may then use phy_get_attrs() API to fetch the PHY
> attributes in order to properly configure the controller.
> 
> 2. v2-0002-phy-phy-cadence-torrent-Use-kernel-PHY-API-to-set.patch
> This patch uses kernel PHY API phy_set_attrs to set corresponding PHY
> properties in Cadence Torrent PHY driver. This will enable drivers using this
> PHY to read these properties using PHY framework.
> 
> The phy_get_attrs() API will be used in the DRM bridge driver [1] which is in
> process of upstreaming.
> 
> [1]
> 
> https://lkml.org/lkml/2020/2/26/263
> 
> Version History:
> 
> v2:
> - Implemented single pair of functions to get/set all PHY attributes
> 
> Swapnil Jakhade (1):
>   phy: phy-cadence-torrent: Use kernel PHY API to set PHY attributes
> 
> Yuti Amonkar (1):
>   phy: Add max_link_rate as a PHY attribute and APIs to get/set
> phy_attrs
> 
>  drivers/phy/cadence/phy-cadence-torrent.c |  7 +++
>  include/linux/phy/phy.h   | 25 +++
>  2 files changed, 32 insertions(+)
> 
> --
> 2.17.1

Re: [PATCH v4 04/11] mm/hugetlb: make hugetlb migration callback CMA aware

[Joonsoo Kim]

2020년 7월 9일 (목) 오후 3:43, Michal Hocko 님이 작성:
>
> On Wed 08-07-20 09:41:06, Michal Hocko wrote:
> > On Wed 08-07-20 16:16:02, Joonsoo Kim wrote:
> > > On Tue, Jul 07, 2020 at 01:22:31PM +0200, Vlastimil Babka wrote:
> > > > On 7/7/20 9:44 AM, js1...@gmail.com wrote:
> > > > > From: Joonsoo Kim 
> > > > >
> > > > > new_non_cma_page() in gup.c which try to allocate migration target 
> > > > > page
> > > > > requires to allocate the new page that is not on the CMA area.
> > > > > new_non_cma_page() implements it by removing __GFP_MOVABLE flag.  
> > > > > This way
> > > > > works well for THP page or normal page but not for hugetlb page.
> > > > >
> > > > > hugetlb page allocation process consists of two steps.  First is 
> > > > > dequeing
> > > > > from the pool.  Second is, if there is no available page on the queue,
> > > > > allocating from the page allocator.
> > > > >
> > > > > new_non_cma_page() can control allocation from the page allocator by
> > > > > specifying correct gfp flag.  However, dequeing cannot be controlled 
> > > > > until
> > > > > now, so, new_non_cma_page() skips dequeing completely.  It is a 
> > > > > suboptimal
> > > > > since new_non_cma_page() cannot utilize hugetlb pages on the queue so 
> > > > > this
> > > > > patch tries to fix this situation.
> > > > >
> > > > > This patch makes the deque function on hugetlb CMA aware and skip CMA
> > > > > pages if newly added skip_cma argument is passed as true.
> > > >
> > > > Hmm, can't you instead change dequeue_huge_page_node_exact() to test 
> > > > the PF_
> > > > flag and avoid adding bool skip_cma everywhere?
> > >
> > > Okay! Please check following patch.
> > > >
> > > > I think that's what Michal suggested [1] except he said "the code 
> > > > already does
> > > > by memalloc_nocma_{save,restore} API". It needs extending a bit though, 
> > > > AFAICS.
> > > > __gup_longterm_locked() indeed does the save/restore, but restore comes 
> > > > before
> > > > check_and_migrate_cma_pages() and thus new_non_cma_page() is called, so 
> > > > an
> > > > adjustment is needed there, but that's all?
> > > >
> > > > Hm the adjustment should be also done because save/restore is done 
> > > > around
> > > > __get_user_pages_locked(), but check_and_migrate_cma_pages() also calls
> > > > __get_user_pages_locked(), and that call not being between nocma save 
> > > > and
> > > > restore is thus also a correctness issue?
> > >
> > > Simply, I call memalloc_nocma_{save,restore} in new_non_cma_page(). It
> > > would not cause any problem.
> >
> > I believe a proper fix is the following. The scope is really defined for
> > FOLL_LONGTERM pins and pushing it inside check_and_migrate_cma_pages
> > will solve the problem as well but it imho makes more sense to do it in
> > the caller the same way we do for any others.
> >
> > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages 
> > allocated from CMA region")
> >
> > I am not sure this is worth backporting to stable yet.
>
> Should I post it as a separate patch do you plan to include this into your 
> next version?

It's better to include it on my next version since this patch would
cause a conflict with
the next tree that includes my v3 of this patchset.

Thanks.

Re: [PATCH v4 0/4] printk: replace ringbuffer

[John Ogness]

On 2020-07-08, Petr Mladek  wrote:
> OK, I think that we are ready to try this in linux-next.
> I am going to push it there via printk/linux.git.
>
> [...]
> 
> Of course, there are still many potential problems. The following comes
> to my mind:
>
> [...]
>
>+ Debugging tools accessing the buffer directly would need to
>  understand the new structure. Fortunately John provided
>  patches for the most prominent ones.

The next series in the printk-rework (move LOG_CONT handling from
writers to readers) makes some further changes that, while not
incompatible, could affect the output of existing tools. It may be a
good idea to let the new ringbuffer sit in linux-next until the next
series has been discussed/reviewed/merged. After the next series,
everything will be in place (with regard to userspace tools) to finish
the rework.

As reminder, here are all the steps planned for the full rework:

1. replace ringbuffer
2. implement NMI-safe LOG_CONT (i.e. move handling to readers)
3. remove logbuf_lock
4. remove safe buffers
5. implement per-console printing kthreads
6. implement emergency mode and write_atomic() support
7. implement write_atomic() for 8250 UART

Some of the steps may be combined into a single series if the changes
are not too dramatic.

John Ogness

Re: [V2 PATCH] usb: mtu3: fix NULL pointer dereference

[Chunfeng Yun]

On Thu, 2020-07-09 at 09:40 +0300, Felipe Balbi wrote:
> Chunfeng Yun  writes:
> 
> > Some pointers are dereferenced before successful checks.
> >
> > Reported-by: Markus Elfring 
> > Signed-off-by: Chunfeng Yun 
> 
> do you need a Fixes tag here? Perhaps a Cc stable too?
It will not cause somes issues, I think no need add it.

According to Greg's comment, I guess he means no need check these
pointers at all, so I'll send a new version to remove checks.

Thank you

> 

Re: [PATCH v2 3/3] misc: cxl: flash: Remove unused variable 'drc_index'

[Andrew Donnellan]

On 9/7/20 4:56 pm, Lee Jones wrote:

Keeping the pointer increment though.

Fixes the following W=1 kernel build warning:

  drivers/misc/cxl/flash.c: In function ‘update_devicetree’:
  drivers/misc/cxl/flash.c:178:16: warning: variable ‘drc_index’ set but not 
used [-Wunused-but-set-variable]
  178 | __be32 *data, drc_index, phandle;
  | ^

Cc: Frederic Barrat 
Cc: Andrew Donnellan 
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Lee Jones 


Acked-by: Andrew Donnellan 

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited

[PATCH] EDAC-GHES: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 drivers/edac/ghes_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index cb3dab56a875..e019319d7c2d 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -4,7 +4,7 @@
  *
  * Copyright (c) 2013 by Mauro Carvalho Chehab
  *
- * Red Hat Inc. http://www.redhat.com
+ * Red Hat Inc. https://www.redhat.com
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.27.0

Re: linux-next: build warning after merge of the scmi tree

[Sudeep Holla]

On Thu, Jul 09, 2020 at 09:54:12AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the scmi tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/firmware/arm_scmi/clock.c: In function 'rate_cmp_func':
> drivers/firmware/arm_scmi/clock.c:128:12: warning: initialization discards 
> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   128 |  u64 *r1 = _r1, *r2 = _r2;
>   |^~~
> drivers/firmware/arm_scmi/clock.c:128:23: warning: initialization discards 
> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   128 |  u64 *r1 = _r1, *r2 = _r2;
>   |   ^~~
> 
> Introduced by commit
> 
>   f0a2500a2a05 ("firmware: arm_scmi: Keep the discrete clock rates sorted")
> 

Sorry for both the issues, I will update the tree with proper patch.

-- 
Regards,
Sudeep

Re: [PATCH] drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register

[Thomas Zimmermann]

Am 09.07.20 um 08:51 schrieb Joel Stanley:
> On Wed, 1 Jul 2020 at 09:10, Sam Ravnborg  wrote:
>>
>> Hi Guenter.
>>
>> On Tue, Jun 30, 2020 at 05:10:02PM -0700, Guenter Roeck wrote:
>>> The following backtrace is seen when running aspeed G5 kernels.
>>>
>>> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_fb_helper.c:2233 
>>> drm_fbdev_generic_setup+0x138/0x198
>>> aspeed_gfx 1e6e6000.display: Device has not been registered.
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3 #1
>>> Hardware name: Generic DT based system
>>> Backtrace:
>>> [<8010d6d0>] (dump_backtrace) from [<8010d9b8>] (show_stack+0x20/0x24)
>>> r7:0009 r6:6153 r5: r4:8119fa94
>>> [<8010d998>] (show_stack) from [<80b8cb98>] (dump_stack+0xcc/0xec)
>>> [<80b8cacc>] (dump_stack) from [<80123ef0>] (__warn+0xd8/0xfc)
>>> r7:0009 r6:80e62ed0 r5: r4:974c3ccc
>>> [<80123e18>] (__warn) from [<80123f98>] (warn_slowpath_fmt+0x84/0xc4)
>>> r9:0009 r8:806a0140 r7:08b9 r6:80e62ed0 r5:80e631f8 r4:974c2000
>>> [<80123f18>] (warn_slowpath_fmt) from [<806a0140>] 
>>> (drm_fbdev_generic_setup+0x138/0x198)
>>> r9:0001 r8:9758fc10 r7:9758fc00 r6: r5:0020 r4:9768a000
>>> [<806a0008>] (drm_fbdev_generic_setup) from [<806d4558>] 
>>> (aspeed_gfx_probe+0x204/0x32c)
>>> r7:9758fc00 r6: r5: r4:9768a000
>>> [<806d4354>] (aspeed_gfx_probe) from [<806dfca0>] 
>>> (platform_drv_probe+0x58/0xa8)
>>>
>>> Since commit 1aed9509b29a6 ("drm/fb-helper: Remove return value from
>>> drm_fbdev_generic_setup()"), drm_fbdev_generic_setup() must be called
>>> after drm_dev_register() to avoid the warning. Do that.
>>>
>>> Fixes: 1aed9509b29a6 ("drm/fb-helper: Remove return value from 
>>> drm_fbdev_generic_setup()")
>>> Signed-off-by: Guenter Roeck 
>>
>> I thought we had this fixed already - but could not find the patch.
>> Must have been another driver then.
>>
>> Acked-by: Sam Ravnborg 
>>
>> I assume Joel Stanley will pick up this patch.
> 
> I do not have the drm maintainer tools set up at the moment. Could one
> of the other maintainers put this in the drm-misc tree?

Added to drm-misc-fixes

Best regards
Thomas

> 
> Acked-by: Joel Stanley 
> 
> Cheers,
> 
> Joel
> 
>>
>> Sam
>>
>>> ---
>>>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
>>> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> index 6b27242b9ee3..bca3fcff16ec 100644
>>> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> @@ -173,8 +173,6 @@ static int aspeed_gfx_load(struct drm_device *drm)
>>>
>>>   drm_mode_config_reset(drm);
>>>
>>> - drm_fbdev_generic_setup(drm, 32);
>>> -
>>>   return 0;
>>>  }
>>>
>>> @@ -225,6 +223,7 @@ static int aspeed_gfx_probe(struct platform_device 
>>> *pdev)
>>>   if (ret)
>>>   goto err_unload;
>>>
>>> + drm_fbdev_generic_setup(&priv->drm, 32);
>>>   return 0;
>>>
>>>  err_unload:
>>> --
>>> 2.17.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature

[v3 PATCH] usb: mtu3: remove unnecessary NULL pointer checks

[Chunfeng Yun]

The class driver will ensure the parameters are not NULL
pointers before call the hook function of usb_ep_ops,
so no need check them again.

Reported-by: Markus Elfring 
Signed-off-by: Chunfeng Yun 
---
v3: remove unnecessary NULL pointer checks but not add more checks.

v2: nothing changed, but abandon another patch.
---
 drivers/usb/mtu3/mtu3_gadget.c | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f93732e..6b26cb8 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -263,23 +263,15 @@ void mtu3_free_request(struct usb_ep *ep, struct 
usb_request *req)
 static int mtu3_gadget_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
 {
-   struct mtu3_ep *mep;
-   struct mtu3_request *mreq;
-   struct mtu3 *mtu;
+   struct mtu3_ep *mep = to_mtu3_ep(ep);
+   struct mtu3_request *mreq = to_mtu3_request(req);
+   struct mtu3 *mtu = mep->mtu;
unsigned long flags;
int ret = 0;
 
-   if (!ep || !req)
-   return -EINVAL;
-
if (!req->buf)
return -ENODATA;
 
-   mep = to_mtu3_ep(ep);
-   mtu = mep->mtu;
-   mreq = to_mtu3_request(req);
-   mreq->mtu = mtu;
-
if (mreq->mep != mep)
return -EINVAL;
 
@@ -303,6 +295,7 @@ static int mtu3_gadget_queue(struct usb_ep *ep,
return -ESHUTDOWN;
}
 
+   mreq->mtu = mtu;
mreq->request.actual = 0;
mreq->request.status = -EINPROGRESS;
 
@@ -335,11 +328,11 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, struct 
usb_request *req)
struct mtu3_ep *mep = to_mtu3_ep(ep);
struct mtu3_request *mreq = to_mtu3_request(req);
struct mtu3_request *r;
+   struct mtu3 *mtu = mep->mtu;
unsigned long flags;
int ret = 0;
-   struct mtu3 *mtu = mep->mtu;
 
-   if (!ep || !req || mreq->mep != mep)
+   if (mreq->mep != mep)
return -EINVAL;
 
dev_dbg(mtu->dev, "%s : req=%p\n", __func__, req);
@@ -379,9 +372,6 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int 
value)
unsigned long flags;
int ret = 0;
 
-   if (!ep)
-   return -EINVAL;
-
dev_dbg(mtu->dev, "%s : %s...", __func__, ep->name);
 
spin_lock_irqsave(&mtu->lock, flags);
@@ -424,9 +414,6 @@ static int mtu3_gadget_ep_set_wedge(struct usb_ep *ep)
 {
struct mtu3_ep *mep = to_mtu3_ep(ep);
 
-   if (!ep)
-   return -EINVAL;
-
mep->wedged = 1;
 
return usb_ep_set_halt(ep);
-- 
1.9.1

[PATCH v3 1/4] iommu/vt-d: Refactor device_to_iommu() helper

[Lu Baolu]

It is refactored in two ways:

- Make it global so that it could be used in other files.

- Make bus/devfn optional so that callers could ignore these two returned
values when they only want to get the coresponding iommu pointer.

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel/iommu.c | 55 +++--
 drivers/iommu/intel/svm.c   |  8 +++---
 include/linux/intel-iommu.h |  3 +-
 3 files changed, 21 insertions(+), 45 deletions(-)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 2ce490c2eab8..4a6b6960fc32 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -778,16 +778,16 @@ is_downstream_to_pci_bridge(struct device *dev, struct 
device *bridge)
return false;
 }
 
-static struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 
*devfn)
+struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devfn)
 {
struct dmar_drhd_unit *drhd = NULL;
+   struct pci_dev *pdev = NULL;
struct intel_iommu *iommu;
struct device *tmp;
-   struct pci_dev *pdev = NULL;
u16 segment = 0;
int i;
 
-   if (iommu_dummy(dev))
+   if (!dev || iommu_dummy(dev))
return NULL;
 
if (dev_is_pci(dev)) {
@@ -818,8 +818,10 @@ static struct intel_iommu *device_to_iommu(struct device 
*dev, u8 *bus, u8 *devf
if (pdev && pdev->is_virtfn)
goto got_pdev;
 
-   *bus = drhd->devices[i].bus;
-   *devfn = drhd->devices[i].devfn;
+   if (bus && devfn) {
+   *bus = drhd->devices[i].bus;
+   *devfn = drhd->devices[i].devfn;
+   }
goto out;
}
 
@@ -829,8 +831,10 @@ static struct intel_iommu *device_to_iommu(struct device 
*dev, u8 *bus, u8 *devf
 
if (pdev && drhd->include_all) {
got_pdev:
-   *bus = pdev->bus->number;
-   *devfn = pdev->devfn;
+   if (bus && devfn) {
+   *bus = pdev->bus->number;
+   *devfn = pdev->devfn;
+   }
goto out;
}
}
@@ -5146,11 +5150,10 @@ static int aux_domain_add_dev(struct dmar_domain 
*domain,
  struct device *dev)
 {
int ret;
-   u8 bus, devfn;
unsigned long flags;
struct intel_iommu *iommu;
 
-   iommu = device_to_iommu(dev, &bus, &devfn);
+   iommu = device_to_iommu(dev, NULL, NULL);
if (!iommu)
return -ENODEV;
 
@@ -5236,9 +5239,8 @@ static int prepare_domain_attach_device(struct 
iommu_domain *domain,
struct dmar_domain *dmar_domain = to_dmar_domain(domain);
struct intel_iommu *iommu;
int addr_width;
-   u8 bus, devfn;
 
-   iommu = device_to_iommu(dev, &bus, &devfn);
+   iommu = device_to_iommu(dev, NULL, NULL);
if (!iommu)
return -ENODEV;
 
@@ -5658,9 +5660,8 @@ static bool intel_iommu_capable(enum iommu_cap cap)
 static struct iommu_device *intel_iommu_probe_device(struct device *dev)
 {
struct intel_iommu *iommu;
-   u8 bus, devfn;
 
-   iommu = device_to_iommu(dev, &bus, &devfn);
+   iommu = device_to_iommu(dev, NULL, NULL);
if (!iommu)
return ERR_PTR(-ENODEV);
 
@@ -5673,9 +5674,8 @@ static struct iommu_device 
*intel_iommu_probe_device(struct device *dev)
 static void intel_iommu_release_device(struct device *dev)
 {
struct intel_iommu *iommu;
-   u8 bus, devfn;
 
-   iommu = device_to_iommu(dev, &bus, &devfn);
+   iommu = device_to_iommu(dev, NULL, NULL);
if (!iommu)
return;
 
@@ -5825,37 +5825,14 @@ static struct iommu_group 
*intel_iommu_device_group(struct device *dev)
return generic_device_group(dev);
 }
 
-#ifdef CONFIG_INTEL_IOMMU_SVM
-struct intel_iommu *intel_svm_device_to_iommu(struct device *dev)
-{
-   struct intel_iommu *iommu;
-   u8 bus, devfn;
-
-   if (iommu_dummy(dev)) {
-   dev_warn(dev,
-"No IOMMU translation for device; cannot enable 
SVM\n");
-   return NULL;
-   }
-
-   iommu = device_to_iommu(dev, &bus, &devfn);
-   if ((!iommu)) {
-   dev_err(dev, "No IOMMU for device; cannot enable SVM\n");
-   return NULL;
-   }
-
-   return iommu;
-}
-#endif /* CONFIG_INTEL_IOMMU_SVM */
-
 static int intel_iommu_enable_auxd(struct device *dev)
 {
struct device_domain_info *info;
struct intel_iommu *iommu;
unsigned long flags;
-   u8 bus, devfn;
int ret;
 
-   iommu = device_to_iommu(dev, 

[PATCH v3 0/4] iommu/vt-d: Add prq report and response support

[Lu Baolu]

Hi,

This series adds page request event reporting and response support to
the Intel IOMMU driver. This is necessary when the page requests must
be processed by any component other than the vendor IOMMU driver. For
example, when a guest page table was bound to a PASID through the
iommu_ops->sva_bind_gpasid() api, the page requests should be routed to
the guest, and after the page is served, the device should be responded
with the result.

Your review comments are very appreciated.

Best regards,
baolu

Change log:
v2->v3:
  - Adress Kevin's review comments

https://lore.kernel.org/linux-iommu/20200706002535.9381-1-baolu...@linux.intel.com/T/#t
  - Set IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID flag

https://lore.kernel.org/linux-iommu/20200706002535.9381-1-baolu...@linux.intel.com/T/#m0190af2f6cf967217e9def6fa0fed4e0fe5a477e

v1->v2:
  - v1 posted at https://lkml.org/lkml/2020/6/27/387
  - Remove unnecessary pci_get_domain_bus_and_slot()
  - Return error when sdev == NULL in intel_svm_page_response()

Lu Baolu (4):
  iommu/vt-d: Refactor device_to_iommu() helper
  iommu/vt-d: Add a helper to get svm and sdev for pasid
  iommu/vt-d: Report page request faults for guest SVA
  iommu/vt-d: Add page response ops support

 drivers/iommu/intel/iommu.c |  56 ++
 drivers/iommu/intel/svm.c   | 332 
 include/linux/intel-iommu.h |   6 +-
 3 files changed, 278 insertions(+), 116 deletions(-)

-- 
2.17.1

[PATCH v3 2/4] iommu/vt-d: Add a helper to get svm and sdev for pasid

[Lu Baolu]

There are several places in the code that need to get the pointers of
svm and sdev according to a pasid and device. Add a helper to achieve
this for code consolidation and readability.

Signed-off-by: Lu Baolu 
Reviewed-by: Kevin Tian 
---
 drivers/iommu/intel/svm.c | 121 +-
 1 file changed, 68 insertions(+), 53 deletions(-)

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 25dd74f27252..c23167877b2b 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -228,6 +228,50 @@ static LIST_HEAD(global_svm_list);
list_for_each_entry((sdev), &(svm)->devs, list) \
if ((d) != (sdev)->dev) {} else
 
+static int pasid_to_svm_sdev(struct device *dev, unsigned int pasid,
+struct intel_svm **rsvm,
+struct intel_svm_dev **rsdev)
+{
+   struct intel_svm_dev *d, *sdev = NULL;
+   struct intel_svm *svm;
+
+   /* The caller should hold the pasid_mutex lock */
+   if (WARN_ON(!mutex_is_locked(&pasid_mutex)))
+   return -EINVAL;
+
+   if (pasid == INVALID_IOASID || pasid >= PASID_MAX)
+   return -EINVAL;
+
+   svm = ioasid_find(NULL, pasid, NULL);
+   if (IS_ERR(svm))
+   return PTR_ERR(svm);
+
+   if (!svm)
+   goto out;
+
+   /*
+* If we found svm for the PASID, there must be at least one device
+* bond.
+*/
+   if (WARN_ON(list_empty(&svm->devs)))
+   return -EINVAL;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(d, &svm->devs, list) {
+   if (d->dev == dev) {
+   sdev = d;
+   break;
+   }
+   }
+   rcu_read_unlock();
+
+out:
+   *rsvm = svm;
+   *rsdev = sdev;
+
+   return 0;
+}
+
 int intel_svm_bind_gpasid(struct iommu_domain *domain, struct device *dev,
  struct iommu_gpasid_bind_data *data)
 {
@@ -261,39 +305,27 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain, 
struct device *dev,
dmar_domain = to_dmar_domain(domain);
 
mutex_lock(&pasid_mutex);
-   svm = ioasid_find(NULL, data->hpasid, NULL);
-   if (IS_ERR(svm)) {
-   ret = PTR_ERR(svm);
+   ret = pasid_to_svm_sdev(dev, data->hpasid, &svm, &sdev);
+   if (ret)
goto out;
-   }
 
-   if (svm) {
+   if (sdev) {
/*
-* If we found svm for the PASID, there must be at
-* least one device bond, otherwise svm should be freed.
+* For devices with aux domains, we should allow
+* multiple bind calls with the same PASID and pdev.
 */
-   if (WARN_ON(list_empty(&svm->devs))) {
-   ret = -EINVAL;
-   goto out;
+   if (iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX)) {
+   sdev->users++;
+   } else {
+   dev_warn_ratelimited(dev,
+"Already bound with PASID %u\n",
+svm->pasid);
+   ret = -EBUSY;
}
+   goto out;
+   }
 
-   for_each_svm_dev(sdev, svm, dev) {
-   /*
-* For devices with aux domains, we should allow
-* multiple bind calls with the same PASID and pdev.
-*/
-   if (iommu_dev_feature_enabled(dev,
- IOMMU_DEV_FEAT_AUX)) {
-   sdev->users++;
-   } else {
-   dev_warn_ratelimited(dev,
-"Already bound with PASID 
%u\n",
-svm->pasid);
-   ret = -EBUSY;
-   }
-   goto out;
-   }
-   } else {
+   if (!svm) {
/* We come here when PASID has never been bond to a device. */
svm = kzalloc(sizeof(*svm), GFP_KERNEL);
if (!svm) {
@@ -376,25 +408,17 @@ int intel_svm_unbind_gpasid(struct device *dev, int pasid)
struct intel_iommu *iommu = device_to_iommu(dev, NULL, NULL);
struct intel_svm_dev *sdev;
struct intel_svm *svm;
-   int ret = -EINVAL;
+   int ret;
 
if (WARN_ON(!iommu))
return -EINVAL;
 
mutex_lock(&pasid_mutex);
-   svm = ioasid_find(NULL, pasid, NULL);
-   if (!svm) {
-   ret = -EINVAL;
-   goto out;
-   }
-
-   if (IS_ERR(svm)) {
-   ret = PTR_ERR(svm);
+   ret = pasid_to_svm_sdev(dev, pasid, &svm, &sdev);
+   if (ret)
goto out;
-  

[PATCH v3 4/4] iommu/vt-d: Add page response ops support

[Lu Baolu]

After page requests are handled, software must respond to the device
which raised the page request with the result. This is done through
the iommu ops.page_response if the request was reported to outside of
vendor iommu driver through iommu_report_device_fault(). This adds the
VT-d implementation of page_response ops.

Co-developed-by: Jacob Pan 
Signed-off-by: Jacob Pan 
Co-developed-by: Liu Yi L 
Signed-off-by: Liu Yi L 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/iommu.c |   1 +
 drivers/iommu/intel/svm.c   | 100 
 include/linux/intel-iommu.h |   3 ++
 3 files changed, 104 insertions(+)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 4a6b6960fc32..98390a6d8113 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -6057,6 +6057,7 @@ const struct iommu_ops intel_iommu_ops = {
.sva_bind   = intel_svm_bind,
.sva_unbind = intel_svm_unbind,
.sva_get_pasid  = intel_svm_get_pasid,
+   .page_response  = intel_svm_page_response,
 #endif
 };
 
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index d24e71bac8db..839d2af377b6 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1082,3 +1082,103 @@ int intel_svm_get_pasid(struct iommu_sva *sva)
 
return pasid;
 }
+
+int intel_svm_page_response(struct device *dev,
+   struct iommu_fault_event *evt,
+   struct iommu_page_response *msg)
+{
+   struct iommu_fault_page_request *prm;
+   struct intel_svm_dev *sdev = NULL;
+   struct intel_svm *svm = NULL;
+   struct intel_iommu *iommu;
+   bool private_present;
+   bool pasid_present;
+   bool last_page;
+   u8 bus, devfn;
+   int ret = 0;
+   u16 sid;
+
+   if (!dev || !dev_is_pci(dev))
+   return -ENODEV;
+
+   iommu = device_to_iommu(dev, &bus, &devfn);
+   if (!iommu)
+   return -ENODEV;
+
+   if (!msg || !evt)
+   return -EINVAL;
+
+   mutex_lock(&pasid_mutex);
+
+   prm = &evt->fault.prm;
+   sid = PCI_DEVID(bus, devfn);
+   pasid_present = prm->flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
+   private_present = prm->flags & IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA;
+   last_page = prm->flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
+
+   if (pasid_present) {
+   if (prm->pasid == 0 || prm->pasid >= PASID_MAX) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   ret = pasid_to_svm_sdev(dev, prm->pasid, &svm, &sdev);
+   if (ret || !sdev) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   /*
+* For responses from userspace, need to make sure that the
+* pasid has been bound to its mm.
+   */
+   if (svm->flags & SVM_FLAG_GUEST_MODE) {
+   struct mm_struct *mm;
+
+   mm = get_task_mm(current);
+   if (!mm) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (mm != svm->mm) {
+   ret = -ENODEV;
+   mmput(mm);
+   goto out;
+   }
+
+   mmput(mm);
+   }
+   } else {
+   pr_err_ratelimited("Invalid page response: no pasid\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /*
+* Per VT-d spec. v3.0 ch7.7, system software must respond
+* with page group response if private data is present (PDP)
+* or last page in group (LPIG) bit is set. This is an
+* additional VT-d requirement beyond PCI ATS spec.
+*/
+   if (last_page || private_present) {
+   struct qi_desc desc;
+
+   desc.qw0 = QI_PGRP_PASID(prm->pasid) | QI_PGRP_DID(sid) |
+   QI_PGRP_PASID_P(pasid_present) |
+   QI_PGRP_PDP(private_present) |
+   QI_PGRP_RESP_CODE(msg->code) |
+   QI_PGRP_RESP_TYPE;
+   desc.qw1 = QI_PGRP_IDX(prm->grpid) | QI_PGRP_LPIG(last_page);
+   desc.qw2 = 0;
+   desc.qw3 = 0;
+   if (private_present)
+   memcpy(&desc.qw2, prm->private_data,
+  sizeof(prm->private_data));
+
+   qi_submit_sync(iommu, &desc, 1, 0);
+   }
+out:
+   mutex_unlock(&pasid_mutex);
+   return ret;
+}
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index fc2cfc3db6e1..bf6009a344f5 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -741,6 +

[PATCH v3 3/4] iommu/vt-d: Report page request faults for guest SVA

[Lu Baolu]

A pasid might be bound to a page table from a VM guest via the iommu
ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
on the physical IOMMU, we need to inject the page fault request into
the guest. After the guest completes handling the page fault, a page
response need to be sent back via the iommu ops.page_response().

This adds support to report a page request fault. Any external module
which is interested in handling this fault should regiester a notifier
with iommu_register_device_fault_handler().

Co-developed-by: Jacob Pan 
Signed-off-by: Jacob Pan 
Co-developed-by: Liu Yi L 
Signed-off-by: Liu Yi L 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/svm.c | 103 +++---
 1 file changed, 85 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index c23167877b2b..d24e71bac8db 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -815,8 +815,63 @@ static void intel_svm_drain_prq(struct device *dev, int 
pasid)
}
 }
 
+static int prq_to_iommu_prot(struct page_req_dsc *req)
+{
+   int prot = 0;
+
+   if (req->rd_req)
+   prot |= IOMMU_FAULT_PERM_READ;
+   if (req->wr_req)
+   prot |= IOMMU_FAULT_PERM_WRITE;
+   if (req->exe_req)
+   prot |= IOMMU_FAULT_PERM_EXEC;
+   if (req->pm_req)
+   prot |= IOMMU_FAULT_PERM_PRIV;
+
+   return prot;
+}
+
+static int
+intel_svm_prq_report(struct device *dev, struct page_req_dsc *desc)
+{
+   struct iommu_fault_event event;
+
+   /* Fill in event data for device specific processing */
+   memset(&event, 0, sizeof(struct iommu_fault_event));
+   event.fault.type = IOMMU_FAULT_PAGE_REQ;
+   event.fault.prm.addr = desc->addr;
+   event.fault.prm.pasid = desc->pasid;
+   event.fault.prm.grpid = desc->prg_index;
+   event.fault.prm.perm = prq_to_iommu_prot(desc);
+
+   if (!dev || !dev_is_pci(dev))
+   return -ENODEV;
+
+   if (desc->lpig)
+   event.fault.prm.flags |= IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
+   if (desc->pasid_present) {
+   event.fault.prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
+   event.fault.prm.flags |= IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID;
+   }
+   if (desc->priv_data_present) {
+   /*
+* Set last page in group bit if private data is present,
+* page response is required as it does for LPIG.
+* iommu_report_device_fault() doesn't understand this vendor
+* specific requirement thus we set last_page as a workaround.
+*/
+   event.fault.prm.flags |= IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
+   event.fault.prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA;
+   memcpy(event.fault.prm.private_data, desc->priv_data,
+  sizeof(desc->priv_data));
+   }
+
+   return iommu_report_device_fault(dev, &event);
+}
+
 static irqreturn_t prq_event_thread(int irq, void *d)
 {
+   struct intel_svm_dev *sdev = NULL;
struct intel_iommu *iommu = d;
struct intel_svm *svm = NULL;
int head, tail, handled = 0;
@@ -828,7 +883,6 @@ static irqreturn_t prq_event_thread(int irq, void *d)
tail = dmar_readq(iommu->reg + DMAR_PQT_REG) & PRQ_RING_MASK;
head = dmar_readq(iommu->reg + DMAR_PQH_REG) & PRQ_RING_MASK;
while (head != tail) {
-   struct intel_svm_dev *sdev;
struct vm_area_struct *vma;
struct page_req_dsc *req;
struct qi_desc resp;
@@ -864,6 +918,20 @@ static irqreturn_t prq_event_thread(int irq, void *d)
}
}
 
+   if (!sdev || sdev->sid != req->rid) {
+   struct intel_svm_dev *t;
+
+   sdev = NULL;
+   rcu_read_lock();
+   list_for_each_entry_rcu(t, &svm->devs, list) {
+   if (t->sid == req->rid) {
+   sdev = t;
+   break;
+   }
+   }
+   rcu_read_unlock();
+   }
+
result = QI_RESP_INVALID;
/* Since we're using init_mm.pgd directly, we should never take
 * any faults on kernel addresses. */
@@ -874,6 +942,17 @@ static irqreturn_t prq_event_thread(int irq, void *d)
if (!is_canonical_address(address))
goto bad_req;
 
+   /*
+* If prq is to be handled outside iommu driver via receiver of
+* the fault notifiers, we skip the page response here.
+*/
+   if (svm->flags & SVM_FLAG_GUEST_MODE) {
+   if (sdev && !intel_svm_prq_report(sdev->dev, req))
+  

Re: [f2fs-dev] [PATCH] f2fs: don't skip writeback of quota data

[Chao Yu]

On 2020/7/9 13:30, Jaegeuk Kim wrote:
> It doesn't need to bypass flushing quota data in background.

The condition is used to flush quota data in batch to avoid random
small-sized udpate, did you hit any problem here?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/data.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 44645f4f914b6..72e8b50e588c1 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -3148,7 +3148,7 @@ static int __f2fs_write_data_pages(struct address_space 
> *mapping,
>   if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
>   goto skip_write;
>  
> - if ((S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) &&
> + if (S_ISDIR(inode->i_mode) &&
>   wbc->sync_mode == WB_SYNC_NONE &&
>   get_dirty_pages(inode) < nr_pages_to_skip(sbi, DATA) &&
>   f2fs_available_free_memory(sbi, DIRTY_DENTS))
> 

Re: [PATCH 5/6] phy: exynos5-usbdrd: use correct format for structure description

[Marek Szyprowski]

On 08.07.2020 15:28, Vinod Koul wrote:
> We get warning with W=1 build:
> drivers/phy/samsung/phy-exynos5-usbdrd.c:211: warning: Function
> parameter or member 'phys' not described in 'exynos5_usbdrd_phy'
> drivers/phy/samsung/phy-exynos5-usbdrd.c:211: warning: Function
> parameter or member 'vbus' not described in 'exynos5_usbdrd_phy'
> drivers/phy/samsung/phy-exynos5-usbdrd.c:211: warning: Function
> parameter or member 'vbus_boost' not described in 'exynos5_usbdrd_phy'
>
> These members are provided with description but format is not quite
> right resulting in above warnings
>
> Cc: Marek Szyprowski 
> Signed-off-by: Vinod Koul 
Acked-by: Marek Szyprowski 
> ---
>   drivers/phy/samsung/phy-exynos5-usbdrd.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
> b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> index eb06ce9f748f..bfb0e8914103 100644
> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> @@ -180,14 +180,14 @@ struct exynos5_usbdrd_phy_drvdata {
>* @utmiclk: clock for utmi+ phy
>* @itpclk: clock for ITP generation
>* @drv_data: pointer to SoC level driver data structure
> - * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
> + * @phys: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
>*  instances each with its 'phy' and 'phy_cfg'.
>* @extrefclk: frequency select settings when using 'separate
>* reference clocks' for SS and HS operations
>* @ref_clk: reference clock to PHY block from which PHY's
>*   operational clocks are derived
> - * vbus: VBUS regulator for phy
> - * vbus_boost: Boost regulator for VBUS present on few Exynos boards
> + * @vbus: VBUS regulator for phy
> + * @vbus_boost: Boost regulator for VBUS present on few Exynos boards
>*/
>   struct exynos5_usbdrd_phy {
>   struct device *dev;

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [Proposal] DRM: AMD: Convert logging to drm_* functions.

[Christian König]

Am 08.07.20 um 18:11 schrieb Suraj Upadhyay:

Hii AMD Maintainers,
I plan to convert logging of information, error and warnings
inside the AMD driver(s) to drm_* functions and macros for loggin,
as described by the TODO list in the DRM documentation[1].

I need your approval for the change before sending any patches, to make
sure that this is a good idea and that the patches will be merged.

The patches will essentially convert all the dev_info(), dev_warn(),
dev_err() and dev_err_once() to drm_info(), drm_warn(), drm_err() and
drm_err_once() respectively.


Well to be honest I would rather like see the conversion done in the 
other direction.


I think the drm_* functions are just an unnecessary extra layer on top 
of the core kernel functions and should probably be removed sooner or 
later because of midlayering.


Regards,
Christian.



Thank You,

Suraj Upadhyay.

[1] 
https://dri.freedesktop.org/docs/drm/gpu/todo.html#convert-logging-to-drm-functions-with-drm-device-paramater

Re: [PATCH v4 06/11] mm/migrate: make a standard migration target allocation function

[Joonsoo Kim]

2020년 7월 8일 (수) 오전 4:00, Michal Hocko 님이 작성:
>
> On Tue 07-07-20 16:49:51, Vlastimil Babka wrote:
> > On 7/7/20 9:44 AM, js1...@gmail.com wrote:
> > > From: Joonsoo Kim 
> > >
> > > There are some similar functions for migration target allocation.  Since
> > > there is no fundamental difference, it's better to keep just one rather
> > > than keeping all variants.  This patch implements base migration target
> > > allocation function.  In the following patches, variants will be converted
> > > to use this function.
> > >
> > > Changes should be mechanical but there are some differences. First, Some
> > > callers' nodemask is assgined to NULL since NULL nodemask will be
> > > considered as all available nodes, that is, &node_states[N_MEMORY].
> > > Second, for hugetlb page allocation, gfp_mask is ORed since a user could
> > > provide a gfp_mask from now on.
> >
> > I think that's wrong. See how htlb_alloc_mask() determines between
> > GFP_HIGHUSER_MOVABLE and GFP_HIGHUSER, but then you OR it with 
> > __GFP_MOVABLE so
> > it's always GFP_HIGHUSER_MOVABLE.

Indeed.

> Right you are! Not that it would make any real difference because only
> migrateable hugetlb pages will get __GFP_MOVABLE and so we shouldn't
> really end up here for !movable pages in the first place (not sure about
> soft offlining at this moment). But yeah it would be simply better to
> override gfp mask for hugetlb which we have been doing anyway.

Override gfp mask doesn't work since some users will call this function with
__GFP_THISNODE.  I will use hugepage_movable_supported() here and
clear __GFP_MOVABLE if needed.

Thanks.

Thanks.

RE: [PATCH v3 06/14] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)

[Liu, Yi L]

Hi Alex,

After more thinking, looks like adding a r-b tree is still not enough to
solve the potential problem for free a range of PASID in one ioctl. If
caller gives [0, MAX_UNIT] in the free request, kernel anyhow should
loop all the PASIDs and search in the r-b tree. Even VFIO can track the
smallest/largest allocated PASID, and limit the free range to an accurate
range, it is still no efficient. For example, user has allocated two PASIDs
( 1 and 999), and user gives the [0, MAX_UNIT] range in free request. VFIO
will limit the free range to be [1, 999], but still needs to loop PASID 1 -
999, and search in r-b tree.

So I'm wondering can we fall back to prior proposal which only free one
PASID for a free request. how about your opinion?

https://lore.kernel.org/linux-iommu/20200416084031.7266a...@w520.home/

Regards,
Yi Liu

> From: Liu, Yi L 
> Sent: Thursday, July 9, 2020 10:26 AM
> 
> Hi Kevin,
> 
> > From: Tian, Kevin 
> > Sent: Thursday, July 9, 2020 10:18 AM
> >
> > > From: Liu, Yi L 
> > > Sent: Thursday, July 9, 2020 10:08 AM
> > >
> > > Hi Kevin,
> > >
> > > > From: Tian, Kevin 
> > > > Sent: Thursday, July 9, 2020 9:57 AM
> > > >
> > > > > From: Liu, Yi L 
> > > > > Sent: Thursday, July 9, 2020 8:32 AM
> > > > >
> > > > > Hi Alex,
> > > > >
> > > > > > Alex Williamson 
> > > > > > Sent: Thursday, July 9, 2020 3:55 AM
> > > > > >
> > > > > > On Wed, 8 Jul 2020 08:16:16 + "Liu, Yi L"
> > > > > >  wrote:
> > > > > >
> > > > > > > Hi Alex,
> > > > > > >
> > > > > > > > From: Liu, Yi L < yi.l@intel.com>
> > > > > > > > Sent: Friday, July 3, 2020 2:28 PM
> > > > > > > >
> > > > > > > > Hi Alex,
> > > > > > > >
> > > > > > > > > From: Alex Williamson 
> > > > > > > > > Sent: Friday, July 3, 2020 5:19 AM
> > > > > > > > >
> > > > > > > > > On Wed, 24 Jun 2020 01:55:19 -0700 Liu Yi L
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > > This patch allows user space to request PASID
> > > > > > > > > > allocation/free,
> > > e.g.
> > > > > > > > > > when serving the request from the guest.
> > > > > > > > > >
> > > > > > > > > > PASIDs that are not freed by userspace are
> > > > > > > > > > automatically freed
> > > > > when
> > > > > > > > > > the IOASID set is destroyed when process exits.
> > > > > > > [...]
> > > > > > > > > > +static int vfio_iommu_type1_pasid_request(struct
> > > > > > > > > > +vfio_iommu
> > > > > *iommu,
> > > > > > > > > > + unsigned long arg) {
> > > > > > > > > > +   struct vfio_iommu_type1_pasid_request req;
> > > > > > > > > > +   unsigned long minsz;
> > > > > > > > > > +
> > > > > > > > > > +   minsz = offsetofend(struct
> > vfio_iommu_type1_pasid_request,
> > > > > > range);
> > > > > > > > > > +
> > > > > > > > > > +   if (copy_from_user(&req, (void __user *)arg, minsz))
> > > > > > > > > > +   return -EFAULT;
> > > > > > > > > > +
> > > > > > > > > > +   if (req.argsz < minsz || (req.flags &
> > > > > > ~VFIO_PASID_REQUEST_MASK))
> > > > > > > > > > +   return -EINVAL;
> > > > > > > > > > +
> > > > > > > > > > +   if (req.range.min > req.range.max)
> > > > > > > > >
> > > > > > > > > Is it exploitable that a user can spin the kernel for a
> > > > > > > > > long time in the case of a free by calling this with [0,
> > > > > > > > > MAX_UINT] regardless of their
> > > > > > actual
> > > > > > > > allocations?
> > > > > > > >
> > > > > > > > IOASID can ensure that user can only free the PASIDs
> > > > > > > > allocated to the
> > > > > user.
> > > > > > but
> > > > > > > > it's true, kernel needs to loop all the PASIDs within the
> > > > > > > > range provided by user.
> > > > > > it
> > > > > > > > may take a long time. is there anything we can do? one
> > > > > > > > thing may limit
> > > > > the
> > > > > > range
> > > > > > > > provided by user?
> > > > > > >
> > > > > > > thought about it more, we have per-VM pasid quota (say
> > > > > > > 1000), so even if user passed down [0, MAX_UNIT], kernel
> > > > > > > will only loop the
> > > > > > > 1000 pasids at most. do you think we still need to do something 
> > > > > > > on it?
> > > > > >
> > > > > > How do you figure that?  vfio_iommu_type1_pasid_request()
> > > > > > accepts the user's min/max so long as (max > min) and passes
> > > > > > that to vfio_iommu_type1_pasid_free(), then to
> > > > > > vfio_pasid_free_range() which loops as:
> > > > > >
> > > > > > ioasid_t pasid = min;
> > > > > > for (; pasid <= max; pasid++)
> > > > > > ioasid_free(pasid);
> > > > > >
> > > > > > A user might only be able to allocate 1000 pasids, but
> > > > > > apparently they can ask to free all they want.
> > > > > >
> > > > > > It's also not obvious to me that calling ioasid_free() is only
> > > > > > allowing the user to free their own passid.  Does it?  It
> > > > > > would be a pretty
> > > >
> > > > Agree. I thought ioasid_free should at least carry a token since
> > > > the user
> > > space is
> > > > only allowed to manage PASIDs in its own

Re: [PATCH v4 05/11] mm/migrate: clear __GFP_RECLAIM for THP allocation for migration

[Joonsoo Kim]

2020년 7월 7일 (화) 오후 9:17, Vlastimil Babka 님이 작성:
>
> On 7/7/20 9:44 AM, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> >
> > In mm/migrate.c, THP allocation for migration is called with the provided
> > gfp_mask | GFP_TRANSHUGE. This gfp_mask contains __GFP_RECLAIM and it
> > would be conflict with the intention of the GFP_TRANSHUGE.
> >
> > GFP_TRANSHUGE/GFP_TRANSHUGE_LIGHT is introduced to control the reclaim
> > behaviour by well defined manner since overhead of THP allocation is
> > quite large and the whole system could suffer from it. So, they deals
> > with __GFP_RECLAIM mask deliberately. If gfp_mask contains __GFP_RECLAIM
> > and uses gfp_mask | GFP_TRANSHUGE(_LIGHT) for THP allocation, it means
> > that it breaks the purpose of the GFP_TRANSHUGE(_LIGHT).
> >
> > This patch fixes this situation by clearing __GFP_RECLAIM in provided
> > gfp_mask. Note that there are some other THP allocations for migration
> > and they just uses GFP_TRANSHUGE(_LIGHT) directly. This patch would make
> > all THP allocation for migration consistent.
> >
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  mm/migrate.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 02b31fe..ecd7615 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -1547,6 +1547,11 @@ struct page *new_page_nodemask(struct page *page,
> >   }
> >
> >   if (PageTransHuge(page)) {
> > + /*
> > +  * clear __GFP_RECALIM since GFP_TRANSHUGE is the gfp_mask
> > +  * that chooses the reclaim masks deliberately.
> > +  */
> > + gfp_mask &= ~__GFP_RECLAIM;
> >   gfp_mask |= GFP_TRANSHUGE;
>
> In addition to what Michal said...
>
> The mask is not passed to this function, so I would just redefine it, as is 
> done
> in the hugetlb case. We probably don't even need the __GFP_RETRY_MAYFAIL for 
> the
> THP case asi it's just there to prevent OOM kill (per commit 0f55685627d6d ) 
> and
> the costly order of THP is enough for that.

As I said in another reply, provided __GFP_THISNODE should be handled
so just redefining it would not work.

Thanks.

Re: [PATCH v4] mm/zswap: move to use crypto_acomp API for hardware acceleration

[Sebastian Andrzej Siewior]

On 2020-07-08 21:45:47 [+], Song Bao Hua (Barry Song) wrote:
> > On 2020-07-08 00:52:10 [+1200], Barry Song wrote:
> > > @@ -127,9 +129,17 @@
> > > +struct crypto_acomp_ctx {
> > > + struct crypto_acomp *acomp;
> > > + struct acomp_req *req;
> > > + struct crypto_wait wait;
> > > + u8 *dstmem;
> > > + struct mutex mutex;
> > > +};
> > …
> > > @@ -1074,12 +1138,32 @@ static int zswap_frontswap_store(unsigned
> > type, pgoff_t offset,
> > >   }
> > >
> > >   /* compress */
> > > - dst = get_cpu_var(zswap_dstmem);
> > > - tfm = *get_cpu_ptr(entry->pool->tfm);
> > > - src = kmap_atomic(page);
> > > - ret = crypto_comp_compress(tfm, src, PAGE_SIZE, dst, &dlen);
> > > - kunmap_atomic(src);
> > > - put_cpu_ptr(entry->pool->tfm);
> > > + acomp_ctx = *this_cpu_ptr(entry->pool->acomp_ctx);
> > > +
> > > + mutex_lock(&acomp_ctx->mutex);
> > > +
> > > + src = kmap(page);
> > > + dst = acomp_ctx->dstmem;
> > 
> > that mutex is per-CPU, per-context. The dstmem pointer is per-CPU. So if
> > I read this right, you can get preempted after crypto_wait_req() and
> > another context in this CPU writes its data to the same dstmem and then…
> > 
> 
> This isn't true. Another thread in this cpu will be blocked by the mutex.
> It is impossible for two threads to write the same dstmem.
> If thread1 ran on cpu1, it held cpu1's mutex; if another thread wants to run 
> on cpu1, it is blocked.
> If thread1 ran on cpu1 first, it held cpu1's mutex, then it migrated to cpu2 
> (with very rare chance)
>   a. if another thread wants to run on cpu1, it is blocked;

How it is blocked? That "struct crypto_acomp_ctx" is
"this_cpu_ptr(entry->pool->acomp_ctx)" - which is per-CPU of a pool
which you can have multiple of. But `dstmem' you have only one per-CPU
no matter have many pools you have.
So pool1 on CPU1 uses the same `dstmem' as pool2 on CPU1. But pool1 and
pool2 on CPU1 use a different mutex for protection of this `dstmem'.

> Thanks
> Barry

Sebastian

Re:[PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0

[Richard]

On Thu, 9 Jul 2020 at 09:50, 彭浩(Richard)  wrote:
>> >Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
>> >relocation that operates on a b or bl instruction that is more than
>> >128 megabytes away from its target.
>> >
>> My understanding is that a module that calls functions that are not part of 
>> the module will use PLT.
>> Plt_max_entries =0 May occur if a module does not depend on other module 
>> functions.
>>
>
>A PLT slot is allocated for each b or bl instruction that refers to a
>symbol that lives in a different section, either of the same module
> (e.g., bl in .init calling into .text), of another module, or of the
>core kernel.
>
>I don't see how you end up with plt_max_entries in this case, though.
if a module does not depend on other module functions, PLT entries in the 
module is equal to 0.
If this is the case I don't think I need to do anything, just return 0.What do 
you think should be 
done about this situation? Any Suggestions?
Thanks.
>Are you sure you have CONFIG_RANDOMIZE_BASE enabled?
>
CONFIG_RANDOMIZE_BASE = y or n has this warning (two servers, kernel version is 
different).

>> >In module_frob_arch_sections(), we count all such relocations that
>> >point to other sections, and allocate a PLT slot for each (and update
>> >plt_max_entries) accordingly. So this means that the relocation in
>> >question was disregarded, and this could happen for only two reasons:
>> >- the branch instruction and its target are both in the same section,
>> >in which case this section is *really* large,
>> >- CONFIG_RANDOMIZE_BASE is disabled, but you are still ending up in a
>> >situation where the modules are really far away from the core kernel
>> >or from other modules.
>> >
>> >Do you have a lot of [large] modules loaded when this happens?
>> I don’t think I have [large] modules.  I'll trace which module caused this 
>> warning.
>
>Yes please.
I can't print debug until someone else is not using the server.

Re: [PATCH] bfq: fix blkio cgroup leakage

[Paolo Valente]

> Il giorno 8 lug 2020, alle ore 19:48, Dmitry Monakhov  
> ha scritto:
> 
> Paolo Valente  writes:
> 
>> Hi,
>> sorry for the delay.  The commit you propose to drop fix the issues
>> reported in [1].
>> 
>> Such a commit does introduce the leak that you report (thank you for
>> spotting it).  Yet, according to the threads mentioned in [1],
>> dropping that commit would take us back to those issues.
>> 
>> Maybe the solution is to fix the unbalance that you spotted?
> I'm not quite shure that do I understand which bug was addressed for commit 
> db37a34c563b.
> AFAIU both bugs mentioned in original patchset was fixed by:
> 478de3380 ("block, bfq: deschedule empty bfq_queues not referred by any 
> proces")
> f718b0932 ( block, bfq: do not plug I/O for bfq_queues with no proc refs)"
> 
> So I review commit db37a34c563b as independent one.
> It introduces extra reference for bfq_groups via bfqg_and_blkg_get(),
> but do we actually need it here?
> 
> #IF CONFIG_BFQ_GROUP_IOSCHED is enabled:
> bfqd->root_group is holded by bfqd from bfq_init_queue()
> other bfq_queue objects are owned by corresponding blkcg from bfq_pd_alloc()
> So bfq_queue can not disappear under us.
> 

You are right, but incomplete.  No extra ref is needed for an entity
that represents a bfq_queue.  And this consideration mistook me before
I realized that that commit was needed.  The problem is that an entity
may also represent a group of entities.  In that case no reference is
taken through any bfq_queue.  The commit you want to remove takes this
missing reference.

Paolo

> #IF CONFIG_BFQ_GROUP_IOSCHED is disabled:
> we have only one  bfqd->root_group object which allocated from 
> bfq_create_group_hierarch()
> and bfqg_and_blkg_get() bfqg_and_blkg_put() are noop
> 
> Resume: in both cases extra reference is not required, so I continue to
> insist that we should revert  commit db37a34c563b because it tries to
> solve a non existing issue, but introduce the real one.
> 
> Please correct me if I'm wrong.
>> 
>> I'll check it ASAP, unless you do it before me.
>> 
>> Thanks,
>> Paolo
>> 
>> [1] https://lkml.org/lkml/2020/1/31/94
>> 
>>> Il giorno 2 lug 2020, alle ore 12:57, Dmitry Monakhov  
>>> ha scritto:
>>> 
>>> commit db37a34c563b ("block, bfq: get a ref to a group when adding it to a 
>>> service tree")
>>> introduce leak forbfq_group and blkcg_gq objects because of get/put
>>> imbalance. See trace balow:
>>> -> blkg_alloc
>>>  -> bfq_pq_alloc
>>>-> bfqg_get (+1)
>>> ->bfq_activate_bfqq
>>> ->bfq_activate_requeue_entity
>>>   -> __bfq_activate_entity
>>>  ->bfq_get_entity
> ->> ->bfqg_and_blkg_get (+1)  < : Note1
>>> ->bfq_del_bfqq_busy
>>> ->bfq_deactivate_entity+0x53/0xc0 [bfq]
>>>   ->__bfq_deactivate_entity+0x1b8/0x210 [bfq]
>>> -> bfq_forget_entity(is_in_service = true)
>>>  entity->on_st_or_in_serv = false   <=== :Note2
>>>  if (is_in_service)
>>>  return;  ==> do not touch reference
>>> -> blkcg_css_offline
>>> -> blkcg_destroy_blkgs
>>> -> blkg_destroy
>>>  -> bfq_pd_offline
>>>   -> __bfq_deactivate_entity
>>>if (!entity->on_st_or_in_serv) /* true, because (Note2)
>>> return false;
>>> -> bfq_pd_free
>>>   -> bfqg_put() (-1, byt bfqg->ref == 2) because of (Note2)
>>> So bfq_group and blkcg_gq  will leak forever, see test-case below.
>>> If fact bfq_group objects reference counting are quite different
>>> from bfq_queue. bfq_groups object are referenced by blkcg_gq via
>>> blkg_policy_data pointer, so  neither nor blkg_get() neither bfqg_get
>>> required here.
>>> 
>>> 
>>> This patch drop commit db37a34c563b ("block, bfq: get a ref to a group when 
>>> adding it to a service tree")
>>> and add corresponding comment.
>>> 
>>> ##TESTCASE_BEGIN:
>>> #!/bin/bash
>>> 
>>> max_iters=${1:-100}
>>> #prep cgroup mounts
>>> mount -t tmpfs cgroup_root /sys/fs/cgroup
>>> mkdir /sys/fs/cgroup/blkio
>>> mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
>>> 
>>> # Prepare blkdev
>>> grep blkio /proc/cgroups
>>> truncate -s 1M img
>>> losetup /dev/loop0 img
>>> echo bfq > /sys/block/loop0/queue/scheduler
>>> 
>>> grep blkio /proc/cgroups
>>> for ((i=0;i>> do
>>>   mkdir -p /sys/fs/cgroup/blkio/a
>>>   echo 0 > /sys/fs/cgroup/blkio/a/cgroup.procs
>>>   dd if=/dev/loop0 bs=4k count=1 of=/dev/null iflag=direct 2> /dev/null
>>>   echo 0 > /sys/fs/cgroup/blkio/cgroup.procs
>>>   rmdir /sys/fs/cgroup/blkio/a
>>>   grep blkio /proc/cgroups
>>> done
>>> ##TESTCASE_END:
>>> 
>>> Signed-off-by: Dmitry Monakhov 
>>> ---
>>> block/bfq-cgroup.c  |  2 +-
>>> block/bfq-iosched.h |  1 -
>>> block/bfq-wf2q.c| 15 +--
>>> 3 files changed, 6 insertions(+), 12 deletions(-)
>>> 
>>> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
>>> index 68882b9..b791e20 100644
>>> --- a/block/bfq-cgroup.c
>>> +++ b/block/bfq-cgroup.c
>>> @@ -332,7 +332,7 @@ static void bfqg_put(struct bfq_group *bfqg)
>>> kfree(bfqg);
>>> }
>>> 
>>> -void bfqg_and_blkg_get(struct bfq_group *bfqg)
>>>

Re: [PATCH] Replace HTTP links with HTTPS ones: PWM SUBSYSTEM

[Uwe Kleine-König]

On Wed, Jul 08, 2020 at 07:59:24PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

LGTM:

Acked-by: Uwe Kleine-König 

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH] scsi: fcoe: add missed kfree() in an error path

[Markus Elfring]

>>> fcoe_fdmi_info() misses to call kfree() in an error path.
>>> Add the missed function call to fix it.
>>
>> I suggest to use an additional jump target for the completion
>> of the desired exception handling.
>>
>>
>> …
>>> +++ b/drivers/scsi/fcoe/fcoe.c
>>> @@ -830,6 +830,7 @@ static void fcoe_fdmi_info(struct fc_lport *lport, 
>>> struct net_device *netdev)
>>>   if (rc) {
>>>   printk(KERN_INFO "fcoe: Failed to retrieve FDMI "
>>>   "information from netdev.\n");
>>> +    kfree(fdmi);
>>>   return;
>>>   }
>>
>> -    return;
>> +    goto free_fdmi;
>>
>>
>> How do you think about to apply any further coding style adjustments?
>
> The local variable "fdmi" is invisible to the function.

I have got understanding difficulties for this information.
The function call “kfree(fdmi)” is already used at the end of this if branch.
Thus I propose to add a label there.

Do you notice any additional improvement possibilities for this software module?

Regards,
Markus

Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

[Daniel Vetter]

On Wed, Jul 8, 2020 at 8:30 PM Dan Williams  wrote:
>
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link: 
> http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.st...@dwillia2-desk3.amr.corp.intel.com
> Acked-by: Randy Dunlap 
> Acked-by: Dave Airlie 
> Acked-by: SeongJae Park 
> Acked-by: Christian Brauner 
> Acked-by: James Bottomley 
> Reviewed-by: Mark Brown 
> Signed-off-by: Theodore Ts'o 
> Signed-off-by: Shuah Khan 
> Signed-off-by: Dan Carpenter 
> Signed-off-by: Kees Cook 
> Signed-off-by: Olof Johansson 
> Signed-off-by: Jonathan Corbet 
> Signed-off-by: Chris Mason 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Dan Williams 

Replied to the old version, once more here so it's not lost.

Acked-by: Daniel Vetter 

> ---
> Changes since v2 [1]:
> - Pick up missed sign-offs and acks from Jon, Shuah, and Christian
>   (sorry about missing those earlier).
>
> - Reformat the replacement list to make it easier to read.
>
> - Add 'controller' as a suggested replacement (Kees and Mark)
>
> - Fix up the paired term for 'performer' to be 'director' (Kees)
>
> - Collect some new acks, reviewed-by's, and sign-offs for v2.
>
> - Fix up Chris's email
>
> [1]: 
> http://lore.kernel.org/r/159419296487.2464622.863943877093636532.st...@dwillia2-desk3.amr.corp.intel.com
>
>
>  Documentation/process/coding-style.rst |   20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/process/coding-style.rst 
> b/Documentation/process/coding-style.rst
> index 2657a55c6f12..1bee6f8affdb 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -319,6 +319,26 @@ If you are afraid to mix up your local variable names, 
> you have another
>  problem, which is called the function-growth-hormone-imbalance syndrome.
>  See chapter 6 (Functions).
>
> +For symbol names and documentation, avoid introducing new usage of
> +'master / slave' (or 'slave' independent of 'master') and 'blacklist /
> +whitelist'.
> +
> +Recommended replacements for 'master / slave' are:
> +'{primary,main} / {secondary,replica,subordinate}'
> +'{initiator,requester} / {target,responder}'
> +'{controller,host} / {device,worker,proxy}'
> +'leader / follower'
> +'director / performer'
> +
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI/API,
> +or when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications
> +translate specification usage of the terminology to the kernel coding
> +standard where possible.
>
>  5) Typedefs
>  ---
>
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1] platform/chrome: cros_ec_debugfs: conditionally create uptime node

[Enric Balletbo i Serra]

Hi Eizan,

Thank you for your patch

On 8/7/20 6:53, Eizan Miyamoto wrote:
> Before creating an 'uptime' node in debugfs, this change adds a check to
> see if a EC_CMD_GET_UPTIME_INFO command can be successfully run.
> 
> If the uptime node is created, userspace programs may periodically poll
> it (e.g., timberslide), causing commands to be sent to the EC each time.
> If the EC doesn't support EC_CMD_GET_UPTIME_INFO, an error will be
> emitted in the EC console, producing noise.
> 

A similar patch with the same purpose sent by Gwendal was already accepted and
queued for 5.9. See [1].


Thanks,
 Enric

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git/commit/?h=for-next&id=d378cdd0113878e3860f954d16dd3e91defb1492



> Signed-off-by: Eizan Miyamoto 
> ---
> 
>  drivers/platform/chrome/cros_ec_debugfs.c | 35 +--
>  1 file changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c 
> b/drivers/platform/chrome/cros_ec_debugfs.c
> index ecfada00e6c51..8708fe12f8ca8 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -242,17 +242,14 @@ static ssize_t cros_ec_pdinfo_read(struct file *file,
>  read_buf, p - read_buf);
>  }
>  
> -static ssize_t cros_ec_uptime_read(struct file *file, char __user *user_buf,
> -size_t count, loff_t *ppos)
> +static int cros_ec_get_uptime(struct cros_ec_device *ec_dev,
> +   uint32_t *uptime)
>  {
> - struct cros_ec_debugfs *debug_info = file->private_data;
> - struct cros_ec_device *ec_dev = debug_info->ec->ec_dev;
>   struct {
>   struct cros_ec_command cmd;
>   struct ec_response_uptime_info resp;
>   } __packed msg = {};
>   struct ec_response_uptime_info *resp;
> - char read_buf[32];
>   int ret;
>  
>   resp = (struct ec_response_uptime_info *)&msg.resp;
> @@ -264,8 +261,24 @@ static ssize_t cros_ec_uptime_read(struct file *file, 
> char __user *user_buf,
>   if (ret < 0)
>   return ret;
>  
> - ret = scnprintf(read_buf, sizeof(read_buf), "%u\n",
> - resp->time_since_ec_boot_ms);
> + *uptime = resp->time_since_ec_boot_ms;
> + return 0;
> +}
> +
> +static ssize_t cros_ec_uptime_read(struct file *file, char __user *user_buf,
> +size_t count, loff_t *ppos)
> +{
> + struct cros_ec_debugfs *debug_info = file->private_data;
> + struct cros_ec_device *ec_dev = debug_info->ec->ec_dev;
> + char read_buf[32];
> + int ret;
> + uint32_t uptime;
> +
> + ret = cros_ec_get_uptime(ec_dev, &uptime);
> + if (ret < 0)
> + return ret;
> +
> + ret = scnprintf(read_buf, sizeof(read_buf), "%u\n", uptime);
>  
>   return simple_read_from_buffer(user_buf, count, ppos, read_buf, ret);
>  }
> @@ -425,6 +438,7 @@ static int cros_ec_debugfs_probe(struct platform_device 
> *pd)
>   const char *name = ec_platform->ec_name;
>   struct cros_ec_debugfs *debug_info;
>   int ret;
> + uint32_t uptime;
>  
>   debug_info = devm_kzalloc(ec->dev, sizeof(*debug_info), GFP_KERNEL);
>   if (!debug_info)
> @@ -444,8 +458,11 @@ static int cros_ec_debugfs_probe(struct platform_device 
> *pd)
>   debugfs_create_file("pdinfo", 0444, debug_info->dir, debug_info,
>   &cros_ec_pdinfo_fops);
>  
> - debugfs_create_file("uptime", 0444, debug_info->dir, debug_info,
> - &cros_ec_uptime_fops);
> + if (cros_ec_get_uptime(debug_info->ec->ec_dev, &uptime) >= 0)
> + debugfs_create_file("uptime", 0444, debug_info->dir, debug_info,
> + &cros_ec_uptime_fops);
> + else
> + dev_dbg(ec->dev, "EC does not provide uptime");
>  
>   debugfs_create_x32("last_resume_result", 0444, debug_info->dir,
>  &ec->ec_dev->last_resume_result);
> 

[PATCH] PCI: Replace kmalloc with kzalloc in the comment/message

[Yi Wang]

From: Liao Pingfang 

Use kzalloc instead of kmalloc in the comment/message according to
the previous kzalloc() call.

Signed-off-by: Liao Pingfang 
Signed-off-by: Yi Wang 
---
 drivers/pci/hotplug/ibmphp_pci.c | 2 +-
 drivers/pci/setup-bus.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/hotplug/ibmphp_pci.c b/drivers/pci/hotplug/ibmphp_pci.c
index e22d023..2d36992 100644
--- a/drivers/pci/hotplug/ibmphp_pci.c
+++ b/drivers/pci/hotplug/ibmphp_pci.c
@@ -205,7 +205,7 @@ int ibmphp_configure_card(struct pci_func *func, u8 slotno)
cur_func->next 
= newfunc;
 
rc = 
ibmphp_configure_card(newfunc, slotno);
-   /* This could only 
happen if kmalloc failed */
+   /* This could only 
happen if kzalloc failed */
if (rc) {
/* We need to 
do this in case bridge itself got configured properly, but devices behind it 
failed */
func->bus = 1; 
/* To indicate to the unconfigure function that this is a PPB */
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index bbcef1a..13c5a44 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -151,7 +151,7 @@ static void pdev_sort_resources(struct pci_dev *dev, struct 
list_head *head)
 
tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
if (!tmp)
-   panic("pdev_sort_resources(): kmalloc() failed!\n");
+   panic("%s: kzalloc() failed!\n", __func__);
tmp->res = r;
tmp->dev = dev;
 
-- 
2.9.5

[PATCH v3 1/4] iomap: Constify ioreadX() iomem argument (as in generic implementation)

[Krzysztof Kozlowski]

The ioreadX() and ioreadX_rep() helpers have inconsistent interface.  On
some architectures void *__iomem address argument is a pointer to const,
on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Suggested-by: Geert Uytterhoeven 
Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Arnd Bergmann 
---
 arch/alpha/include/asm/core_apecs.h   |  6 +--
 arch/alpha/include/asm/core_cia.h |  6 +--
 arch/alpha/include/asm/core_lca.h |  6 +--
 arch/alpha/include/asm/core_marvel.h  |  4 +-
 arch/alpha/include/asm/core_mcpcia.h  |  6 +--
 arch/alpha/include/asm/core_t2.h  |  2 +-
 arch/alpha/include/asm/io.h   | 12 ++---
 arch/alpha/include/asm/io_trivial.h   | 16 +++---
 arch/alpha/include/asm/jensen.h   |  2 +-
 arch/alpha/include/asm/machvec.h  |  6 +--
 arch/alpha/kernel/core_marvel.c   |  2 +-
 arch/alpha/kernel/io.c| 12 ++---
 arch/parisc/include/asm/io.h  |  4 +-
 arch/parisc/lib/iomap.c   | 72 +--
 arch/powerpc/kernel/iomap.c   | 28 +--
 arch/sh/kernel/iomap.c| 22 
 drivers/sh/clk/cpg.c  |  2 +-
 include/asm-generic/iomap.h   | 28 +--
 include/linux/io-64-nonatomic-hi-lo.h |  4 +-
 include/linux/io-64-nonatomic-lo-hi.h |  4 +-
 lib/iomap.c   | 30 +--
 21 files changed, 137 insertions(+), 137 deletions(-)

diff --git a/arch/alpha/include/asm/core_apecs.h 
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
}   \
} while (0)
 
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h 
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
 #define vuip   volatile unsigned int __force *
 #define vulp   volatile unsigned long __force *
 
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h 
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
 
 
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int lca_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread16(const void __iomem *xaddr)

[PATCH] TI DAVINCI SERIES MEDIA DRIVER: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 drivers/media/platform/davinci/vpbe_display.c | 2 +-
 drivers/media/platform/davinci/vpif.c | 2 +-
 drivers/media/platform/davinci/vpif.h | 2 +-
 drivers/media/platform/davinci/vpif_display.c | 2 +-
 drivers/media/platform/davinci/vpif_display.h | 2 +-
 include/media/davinci/vpbe_display.h  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_display.c 
b/drivers/media/platform/davinci/vpbe_display.c
index 7ab13eb7527d..d19bad997f30 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2010 Texas Instruments Incorporated - https://www.ti.com/
  */
 #include 
 #include 
diff --git a/drivers/media/platform/davinci/vpif.c 
b/drivers/media/platform/davinci/vpif.c
index df66461f5d4f..e9794c9fc7fe 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -5,7 +5,7 @@
  * The hardware supports SDTV, HDTV formats, raw data capture.
  * Currently, the driver supports NTSC and PAL standards.
  *
- * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Texas Instruments Incorporated - https://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
diff --git a/drivers/media/platform/davinci/vpif.h 
b/drivers/media/platform/davinci/vpif.h
index 2466c7c77deb..c6d1d890478a 100644
--- a/drivers/media/platform/davinci/vpif.h
+++ b/drivers/media/platform/davinci/vpif.h
@@ -1,7 +1,7 @@
 /*
  * VPIF header file
  *
- * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Texas Instruments Incorporated - https://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index 7d55fd45240e..46afc029138f 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -2,7 +2,7 @@
  * vpif-display - VPIF display driver
  * Display driver for TI DaVinci VPIF
  *
- * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Texas Instruments Incorporated - https://www.ti.com/
  * Copyright (C) 2014 Lad, Prabhakar 
  *
  * This program is free software; you can redistribute it and/or
diff --git a/drivers/media/platform/davinci/vpif_display.h 
b/drivers/media/platform/davinci/vpif_display.h
index af2765fdcea8..f731a65eefd6 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -1,7 +1,7 @@
 /*
  * VPIF display header file
  *
- * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2009 Texas Instruments Incorporated - https://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
diff --git a/include/media/davinci/vpbe_display.h 
b/include/media/davinci/vpbe_display.h
index 56d05a855140..6d2a93740130 100644
--- a/include/media/davinci/vpbe_display.h
+++ b/include/media/davinci/vpbe_display.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0-only */
 /*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright (C) 2010 Texas Instruments Incorporated - https://www.ti.com/
  */
 #ifndef VPBE_DISPLAY_H
 #define VPBE_DISPLAY_H
-- 
2.27.0

[PATCH v3 0/4] iomap: Constify ioreadX() iomem argument

[Krzysztof Kozlowski]

Hi,

Multiple architectures are affected in the first patch and all further
patches depend on the first.

Maybe this could go in through Andrew Morton's tree?


Changes since v2

1. Drop all non-essential patches (cleanups),
2. Update also drivers/sh/clk/cpg.c .


Changes since v1

https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add acks and reviews,
4. Re-order patches so all optional driver changes are at the end.


Description
===
The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.

It seems there is nothing really stopping all of them to take
pointer to const.

Patchset was only compile tested on affected architectures.  No real
testing.


volatile

There is still interface inconsistency between architectures around
"volatile" qualifier:
 - include/asm-generic/io.h:static inline u32 ioread32(const volatile void 
__iomem *addr)
 - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem 
*);

This is still discussed and out of scope of this patchset.


Best regards,
Krzysztof


Krzysztof Kozlowski (4):
  iomap: Constify ioreadX() iomem argument (as in generic
implementation)
  rtl818x: Constify ioreadX() iomem argument (as in generic
implementation)
  ntb: intel: Constify ioreadX() iomem argument (as in generic
implementation)
  virtio: pci: Constify ioreadX() iomem argument (as in generic
implementation)

 arch/alpha/include/asm/core_apecs.h   |  6 +-
 arch/alpha/include/asm/core_cia.h |  6 +-
 arch/alpha/include/asm/core_lca.h |  6 +-
 arch/alpha/include/asm/core_marvel.h  |  4 +-
 arch/alpha/include/asm/core_mcpcia.h  |  6 +-
 arch/alpha/include/asm/core_t2.h  |  2 +-
 arch/alpha/include/asm/io.h   | 12 ++--
 arch/alpha/include/asm/io_trivial.h   | 16 ++---
 arch/alpha/include/asm/jensen.h   |  2 +-
 arch/alpha/include/asm/machvec.h  |  6 +-
 arch/alpha/kernel/core_marvel.c   |  2 +-
 arch/alpha/kernel/io.c| 12 ++--
 arch/parisc/include/asm/io.h  |  4 +-
 arch/parisc/lib/iomap.c   | 72 +--
 arch/powerpc/kernel/iomap.c   | 28 
 arch/sh/kernel/iomap.c| 22 +++---
 .../realtek/rtl818x/rtl8180/rtl8180.h |  6 +-
 drivers/ntb/hw/intel/ntb_hw_gen1.c|  2 +-
 drivers/ntb/hw/intel/ntb_hw_gen3.h|  2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.h   |  2 +-
 drivers/sh/clk/cpg.c  |  2 +-
 drivers/virtio/virtio_pci_modern.c|  6 +-
 include/asm-generic/iomap.h   | 28 
 include/linux/io-64-nonatomic-hi-lo.h |  4 +-
 include/linux/io-64-nonatomic-lo-hi.h |  4 +-
 lib/iomap.c   | 30 
 26 files changed, 146 insertions(+), 146 deletions(-)

-- 
2.17.1

[PATCH v3 2/4] rtl818x: Constify ioreadX() iomem argument (as in generic implementation)

[Krzysztof Kozlowski]

The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Kalle Valo 
---
 drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h 
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
index 7948a2da195a..2ff00800d45b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
@@ -150,17 +150,17 @@ void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr, 
u32 data);
 void rtl8180_set_anaparam(struct rtl8180_priv *priv, u32 anaparam);
 void rtl8180_set_anaparam2(struct rtl8180_priv *priv, u32 anaparam2);
 
-static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, u8 __iomem *addr)
+static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, const u8 __iomem 
*addr)
 {
return ioread8(addr);
 }
 
-static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, __le16 __iomem 
*addr)
+static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, const __le16 
__iomem *addr)
 {
return ioread16(addr);
 }
 
-static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, __le32 __iomem 
*addr)
+static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, const __le32 
__iomem *addr)
 {
return ioread32(addr);
 }
-- 
2.17.1

[PATCH v3 3/4] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)

[Krzysztof Kozlowski]

The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Geert Uytterhoeven 
Acked-by: Dave Jiang 
---
 drivers/ntb/hw/intel/ntb_hw_gen1.c  | 2 +-
 drivers/ntb/hw/intel/ntb_hw_gen3.h  | 2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c 
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index 423f9b8fbbcf..3185efeab487 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1205,7 +1205,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int 
pidx, int sidx,
   ndev->peer_reg->spad);
 }
 
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
 {
return (u64)ioread16(mmio);
 }
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h 
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 2bc5d8356045..dea93989942d 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
 #define GEN3_DB_TOTAL_SHIFT33
 #define GEN3_SPAD_COUNT16
 
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
 {
return ioread64(mmio);
 }
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h 
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index d61fcd91714b..05e2335c9596 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -103,7 +103,7 @@ struct intel_ntb_dev;
 struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
-   u64 (*db_ioread)(void __iomem *mmio);
+   u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long   ntb_ctl;
resource_size_t db_size;
-- 
2.17.1

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Stone]

Hi,
Jumping in after a couple of weeks where I've paged most everything
out of my brain ...

On Fri, 19 Jun 2020 at 10:43, Daniel Vetter  wrote:
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > The proposed patches might very well encode the wrong contract, that's
> > > all up for discussion. But fundamentally questioning that we need one
> > > is missing what upstream is all about.
> >
> > Then I have not clearly communicated, as my opinion is not that
> > validation is worthless, but that the implementation is enshrining a
> > global property on a low level primitive that prevents it from being
> > used elsewhere. And I want to replace completion [chains] with fences, and
> > bio with fences, and closures with fences, and what other equivalencies
> > there are in the kernel. The fence is as central a locking construct as
> > struct completion and deserves to be a foundational primitive provided
> > by kernel/ used throughout all drivers for discrete problem domains.
> >
> > This is narrowing dma_fence whereby adding
> >   struct lockdep_map *dma_fence::wait_map
> > and annotating linkage, allows you to continue to specify that all
> > dma_fence used for a particular purpose must follow common rules,
> > without restricting the primitive for uses outside of this scope.
>
> Somewhere else in this thread I had discussions with Jason Gunthorpe about
> this topic. It might maybe change somewhat depending upon exact rules, but
> his take is very much "I don't want dma_fence in rdma". Or pretty close to
> that at least.
>
> Similar discussions with habanalabs, they're using dma_fence internally
> without any of the uapi. Discussion there has also now concluded that it's
> best if they remove them, and simply switch over to a wait_queue or
> completion like every other driver does.
>
> The next round of the patches already have a paragraph to at least
> somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> consensus might be pointing even more strongly at dma_fence being solely
> something for gpus and closely related subsystem (maybe media) for syncing
> dma-buf access.
>
> So dma_fence as general replacement for completion chains I think just
> wont happen.
>
> What might make sense is if e.g. the lockdep annotations could be reused,
> at least in design, for wait_queue or completion or anything else
> really. I do think that has a fair chance compared to the automagic
> cross-release annotations approach, which relied way too heavily on
> guessing where barriers are. My experience from just a bit of playing
> around with these patches here and discussing them with other driver
> maintainers is that accurately deciding where critical sections start and
> end is a job for humans only. And if you get it wrong, you will have a
> false positive.
>
> And you're indeed correct that if we'd do annotations for completions and
> wait queues, then that would need to have a class per semantically
> equivalent user, like we have lockdep classes for mutexes, not just one
> overall.
>
> But dma_fence otoh is something very specific, which comes with very
> specific rules attached - it's not a generic wait_queue at all. Originally
> it did start out as one even, but it is a very specialized wait_queue.
>
> So there's imo two cases:
>
> - Your completion is entirely orthogonal of dma_fences, and can never ever
>   block a dma_fence. Don't use dma_fence for this, and no problem. It's
>   just another wait_queue somewhere.
>
> - Your completion can eventually, maybe through lots of convolutions and
>   depdencies, block a dma_fence. In that case full dma_fence rules apply,
>   and the only thing you can do with a custom annotation is make the rules
>   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
>   take certain scheduler locks. But the userspace visible/published fence
>   do take them, maybe as part of command submission or retirement.
>   Entirely hypotethical, no idea any driver actually needs this.

I don't claim to understand the implementation of i915's scheduler and
GEM handling, and it seems like there's some public context missing
here. But to me, the above is a good statement of what I (and a lot of
other userspace) have been relying on - that dma-fence is a very
tightly scoped thing which is very predictable but in extremis.

It would be great to have something like this enshrined in dma-fence
documentation, visible to both kernel and external users. The
properties we've so far been assuming for the graphics pipeline -
covering production & execution of vertex/fragment workloads on the
GPU, framebuffer display, and to the extent this is necessary
involving compute - are something like this:

A single dma-fence with no dependencies represents (the tail of) a
unit of work, which has been all but committed to the hardware. Once
committed to the hardware, this work will complete (successfully or in
error) in bounded time. The unit of work referred to 

[PATCH v2 1/2] riscv: Add STACKPROTECTOR supported

[guoren]

From: Guo Ren 

The -fstack-protector & -fstack-protector-strong features are from
gcc. The patch only add basic kernel support to stack-protector
feature and some arch could have its own solution such as
ARM64_PTR_AUTH.

After enabling STACKPROTECTOR and STACKPROTECTOR_STRONG, the .text
size is expanded from  0x7de066 to 0x81fb32 (only 5%) to add canary
checking code.

Signed-off-by: Guo Ren 
Reviewed-by: Kees Cook 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Masami Hiramatsu 
Cc: Björn Töpel 
Cc: Greentime Hu 
Cc: Atish Patra 
---
 arch/riscv/Kconfig  |  1 +
 arch/riscv/include/asm/stackprotector.h | 33 +
 arch/riscv/kernel/process.c |  6 ++
 3 files changed, 40 insertions(+)
 create mode 100644 arch/riscv/include/asm/stackprotector.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index f927a91..4b0e308 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -63,6 +63,7 @@ config RISCV
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+   select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA if MODULES
diff --git a/arch/riscv/include/asm/stackprotector.h 
b/arch/riscv/include/asm/stackprotector.h
new file mode 100644
index ..8e1ef2c
--- /dev/null
+++ b/arch/riscv/include/asm/stackprotector.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_STACKPROTECTOR_H
+#define _ASM_RISCV_STACKPROTECTOR_H
+
+#include 
+#include 
+#include 
+
+extern unsigned long __stack_chk_guard;
+
+/*
+ * Initialize the stackprotector canary value.
+ *
+ * NOTE: this must only be called from functions that never return,
+ * and it must always be inlined.
+ */
+static __always_inline void boot_init_stack_canary(void)
+{
+   unsigned long canary;
+   unsigned long tsc;
+
+   /* Try to get a semi random initial value. */
+   get_random_bytes(&canary, sizeof(canary));
+   tsc = get_cycles();
+   canary += tsc + (tsc << 32UL);
+   canary ^= LINUX_VERSION_CODE;
+   canary &= CANARY_MASK;
+
+   current->stack_canary = canary;
+   __stack_chk_guard = current->stack_canary;
+}
+#endif /* _ASM_RISCV_STACKPROTECTOR_H */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 824d117..6548929 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -24,6 +24,12 @@
 
 register unsigned long gp_in_global __asm__("gp");
 
+#ifdef CONFIG_STACKPROTECTOR
+#include 
+unsigned long __stack_chk_guard __read_mostly;
+EXPORT_SYMBOL(__stack_chk_guard);
+#endif
+
 extern asmlinkage void ret_from_fork(void);
 extern asmlinkage void ret_from_kernel_thread(void);
 
-- 
2.7.4

[PATCH v3 4/4] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)

[Krzysztof Kozlowski]

The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/virtio/virtio_pci_modern.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/virtio/virtio_pci_modern.c 
b/drivers/virtio/virtio_pci_modern.c
index db93cedd262f..90eff165a719 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -27,16 +27,16 @@
  * method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
  * for 16-bit fields and 8-bit accesses for 8-bit fields.
  */
-static inline u8 vp_ioread8(u8 __iomem *addr)
+static inline u8 vp_ioread8(const u8 __iomem *addr)
 {
return ioread8(addr);
 }
-static inline u16 vp_ioread16 (__le16 __iomem *addr)
+static inline u16 vp_ioread16 (const __le16 __iomem *addr)
 {
return ioread16(addr);
 }
 
-static inline u32 vp_ioread32(__le32 __iomem *addr)
+static inline u32 vp_ioread32(const __le32 __iomem *addr)
 {
return ioread32(addr);
 }
-- 
2.17.1

[PATCH v2 2/2] riscv: Enable per-task stack canaries

[guoren]

From: Guo Ren 

This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.

After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.

x86: Use a fix offset from gs, not flexible.

struct fixed_percpu_data {
/*
 * GCC hardcodes the stack canary as %gs:40.  Since the
 * irq_stack is the object at %gs:0, we reserve the bottom
 * 48 bytes of the irq stack for the canary.
 */
chargs_base[40]; // :(
unsigned long   stack_canary;
};

arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx

riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx

Here is riscv gcc's work [1].

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549583.html

In the end, these codes are inserted by gcc before return:

*  0xffe00020b396 <+120>:   ld  a5,1008(tp) # 0x3f0
*  0xffe00020b39a <+124>:   xor a5,a5,a4
*  0xffe00020b39c <+126>:   mv  a0,s5
*  0xffe00020b39e <+128>:   bneza5,0xffe00020b61c <_do_fork+766>
   0xffe00020b3a2 <+132>:   ld  ra,136(sp)
   0xffe00020b3a4 <+134>:   ld  s0,128(sp)
   0xffe00020b3a6 <+136>:   ld  s1,120(sp)
   0xffe00020b3a8 <+138>:   ld  s2,112(sp)
   0xffe00020b3aa <+140>:   ld  s3,104(sp)
   0xffe00020b3ac <+142>:   ld  s4,96(sp)
   0xffe00020b3ae <+144>:   ld  s5,88(sp)
   0xffe00020b3b0 <+146>:   ld  s6,80(sp)
   0xffe00020b3b2 <+148>:   ld  s7,72(sp)
   0xffe00020b3b4 <+150>:   addisp,sp,144
   0xffe00020b3b6 <+152>:   ret
   ...
*  0xffe00020b61c <+766>:   auipc   ra,0x7f8
*  0xffe00020b620 <+770>:   jalr-1764(ra) # 0xffe000a02f38 
<__stack_chk_fail>

Signed-off-by: Guo Ren 
Signed-off-by: cooper 
Cc: cooper 
Cc: Kees Cook 
---
Change v2:
 - Change to -mstack-protector-guard=tls for gcc final define
 - Solve compile error by changing position of KBUILD_CFLAGS in
   Makefile

Signed-off-by: Guo Ren 
---
 arch/riscv/Kconfig  |  7 +++
 arch/riscv/Makefile | 10 ++
 arch/riscv/include/asm/stackprotector.h |  3 ++-
 arch/riscv/kernel/asm-offsets.c |  3 +++
 arch/riscv/kernel/process.c |  2 +-
 5 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4b0e308..d98ce29 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -394,6 +394,13 @@ config CMDLINE_FORCE
 
 endchoice
 
+config CC_HAVE_STACKPROTECTOR_TLS
+   def_bool $(cc-option,-mstack-protector-guard=tls 
-mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
+
+config STACKPROTECTOR_PER_TASK
+   def_bool y
+   depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
+
 endmenu
 
 config BUILTIN_DTB
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index fb6e37d..f5f8ee9 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -68,6 +68,16 @@ KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax)
 # architectures.  It's faster to have GCC emit only aligned accesses.
 KBUILD_CFLAGS += $(call cc-option,-mstrict-align)
 
+ifeq ($(CONFIG_STACKPROTECTOR_PER_TASK),y)
+prepare: stack_protector_prepare
+stack_protector_prepare: prepare0
+   $(eval KBUILD_CFLAGS += -mstack-protector-guard=tls   \
+   -mstack-protector-guard-reg=tp\
+   -mstack-protector-guard-offset=$(shell\
+   awk '{if ($$2 == "TSK_STACK_CANARY") print $$3;}' \
+   include/generated/asm-offsets.h))
+endif
+
 # arch specific predefines for sparse
 CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS)
 
diff --git a/arch/riscv/include/asm/stackprotector.h 
b/arch/riscv/include/asm/stackprotector.h
index 8e1ef2c..bda4d83 100644
--- a/arch/riscv/include/asm/stackprotector.h
+++ b/arch/riscv/include/asm/stackprotector.h
@@ -28,6 +28,7 @@ static __always_inline void boot_init_stack_canary(void)
canary &= CANARY_MASK;
 
current->stack_canary = canary;
-   __stack_chk_guard = current->stack_canary;
+   if (!IS_ENABLED(CONFIG_STACKPROTECTOR_PER_TASK))
+   __stack_chk_guard = current->stack_canary;
 }
 #endif /* _ASM_RISCV_STACKPROTECTOR_H */
diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c
index 07cb9c1..999b465 100644
--- a/arch/riscv/kernel/asm-offsets.c
+++ b/arch/riscv/kernel/asm-offsets.c
@@ -29,6 +29,9 @@ void asm_of

Re: [PATCH] spi: spi-geni-qcom: Set the clock properly at runtime resume

[Akash Asthana]

Hi Doug,

  
@@ -670,7 +674,13 @@ static int __maybe_unused spi_geni_runtime_resume(struct device *dev)

if (ret)
return ret;
  
-	return geni_se_resources_on(&mas->se);

+   ret = geni_se_resources_on(&mas->se);
+   if (ret)
+   return ret;
+
+   dev_pm_opp_set_rate(mas->dev, mas->cur_sclk_hz);
+
+   return 0;
  }


Should we fail to resume if error is returned from 'opp_set_rate'?

'spi_geni_prepare_message' use to fail for any error from 
'opp_set_rate'  before patch series "Avoid clock setting if not needed".


But now it's possible that 'prepare_message' can return success even 
when opp are not at desired state(from previous resume call).


Regards,

Akash

  
  static int __maybe_unused spi_geni_suspend(struct device *dev)


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

Re: [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0

[Will Deacon]

On Thu, Jul 09, 2020 at 07:18:01AM +, 彭浩(Richard) wrote:
> On Thu, 9 Jul 2020 at 09:50, 彭浩(Richard)  wrote:
> >> >Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
> >> >relocation that operates on a b or bl instruction that is more than
> >> >128 megabytes away from its target.
> >> >
> >> My understanding is that a module that calls functions that are not part 
> >> of the module will use PLT.
> >> Plt_max_entries =0 May occur if a module does not depend on other module 
> >> functions.
> >>
> >
> >A PLT slot is allocated for each b or bl instruction that refers to a
> >symbol that lives in a different section, either of the same module
> > (e.g., bl in .init calling into .text), of another module, or of the
> >core kernel.
> >
> >I don't see how you end up with plt_max_entries in this case, though.
> if a module does not depend on other module functions, PLT entries in the 
> module is equal to 0.

This brings me back to my earlier question: if there are no PLT entries in
the module, then count_plts() will not find any R_AARCH64_JUMP26 or
R_AARCH64_CALL26 relocations that require PLTs and will therefore return 0.
The absence of these relocations means that module_emit_plt_entry() will not
be called by apply_relocate_add(), and so your patch should have no effect.

You seem to be saying that module_emit_plt_entry() _is_ being called,
despite count_plts() returning 0. One way that can happen is if PLTs are
needed for branches within a single, very large text section, but you also
say that's not the case.

So I think we need more information from you so that we can either reproduce
this ourselves, or better understand where things are going wrong.

Finally, you said that your kernel is "5.6.0-rc3+". Are you able to
reproduce with mainline (5.8-rc4)?

Will

P.S. whenever you reply, the mail threading breaks :(

Re: [PATCH 4/5] iommu/arm-smmu-qcom: Consstently initialize stream mappings

[Vinod Koul]

On 08-07-20, 22:01, Bjorn Andersson wrote:
> Firmware that traps writes to S2CR to translate BYPASS into FAULT also
> ignores writes of type FAULT. As such booting with "disable_bypass" set
> will result in all S2CR registers left as configured by the bootloader.
> 
> This has been seen to result in indeterministic results, as these
> mappings might linger and reference context banks that Linux is
> reconfiguring.
> 
> Use the fact that BYPASS writes result in FAULT type to force all stream
> mappings to FAULT.

s/Consstently/Consistently in patch subject

-- 
~Vinod

Re: [PATCH v3 1/4] iomap: Constify ioreadX() iomem argument (as in generic implementation)

[Krzysztof Kozlowski]

On Thu, Jul 09, 2020 at 09:28:34AM +0200, Krzysztof Kozlowski wrote:
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface.  On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
> 
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
> 
> Suggested-by: Geert Uytterhoeven 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Geert Uytterhoeven 
> Reviewed-by: Arnd Bergmann 

I forgot to put here one more Ack, for PowerPC:
Acked-by: Michael Ellerman  (powerpc)

https://lore.kernel.org/lkml/87ftedj0zz@mpe.ellerman.id.au/

Best regards,
Krzysztof

Re: [PATCH 0/5] iommu/arm-smmu: Support maintaining bootloader mappings

[Vinod Koul]

On 08-07-20, 22:01, Bjorn Andersson wrote:
> Based on previous attempts and discussions this is the latest attempt at
> inheriting stream mappings set up by the bootloader, for e.g. boot splash or
> efifb.
> 
> The first patch is an implementation of Robin's suggestion that we should just
> mark the relevant stream mappings as BYPASS. Relying on something else to set
> up the stream mappings wanted - e.g. by reading it back in platform specific
> implementation code.
> 
> The series then tackles the problem seen in most versions of Qualcomm 
> firmware,
> that the hypervisor intercepts BYPASS writes and turn them into FAULTs. It 
> does
> this by allocating context banks for identity domains as well, with 
> translation
> disabled.
> 
> Lastly it amends the stream mapping initialization code to allocate a specific
> identity domain that is used for any mappings inherited from the bootloader, 
> if
> above Qualcomm quirk is required.
> 
> 
> The series has been tested and shown to allow booting SDM845, SDM850, SM8150,
> SM8250 with boot splash screen setup by the bootloader. Specifically it also
> allows the Lenovo Yoga C630 to boot with SMMU and efifb enabled.

This resolves issue on RB3 for me so:

Tested-by: Vinod Koul 

-- 
~Vinod

Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached

[Maxime Ripard]

Hi Eric,

On Tue, Jul 07, 2020 at 09:48:45AM -0700, Eric Anholt wrote:
> On Tue, Jul 7, 2020 at 3:26 AM Maxime Ripard  wrote:
> >
> > If the DSI driver is the last to probe, component_add will try to run all
> > the bind callbacks straight away and return the error code.
> >
> > However, since we depend on a power domain, we're pretty much guaranteed to
> > be in that case on the BCM2711, and are just lucky on the previous SoCs
> > since the v3d also depends on that power domain and is further in the probe
> > order.
> >
> > In that case, the DSI host will not stick around in the system: the DSI
> > bind callback will be executed, will not find any DSI device attached and
> > will return EPROBE_DEFER, and we will then remove the DSI host and ask to
> > be probed later on.
> >
> > But since that host doesn't stick around, DSI devices like the RaspberryPi
> > touchscreen whose probe is not linked to the DSI host (unlike the usual DSI
> > devices that will be probed through the call to mipi_dsi_host_register)
> > cannot attach to the DSI host, and we thus end up in a situation where the
> > DSI host cannot probe because the panel hasn't probed yet, and the panel
> > cannot probe because the DSI host hasn't yet.
> >
> > In order to break this cycle, let's wait until there's a DSI device that
> > attaches to the DSI host to register the component and allow to progress
> > further.
> >
> > Suggested-by: Andrzej Hajda 
> > Signed-off-by: Maxime Ripard 
> 
> I feel like I've written this patch before, but I've thankfully
> forgotten most of my battle with DSI probing.  As long as this still
> lets vc4 probe in the absence of a DSI panel in the DT as well, then
> this is enthusiastically acked.

I'm not really sure what you mean by that, did you mean vc4 has to probe
when the DSI controller is enabled but there's no panel described, or it
has to probe when the DSI controller is disabled?

Maxime

Re: [PATCH v2 2/3] media: rockchip: Introduce driver for Rockhip's camera interface

[Maxime Chevallier]

Hi Ezequiel,

Sorry for the late reply, some answers to your very useful comments
below :)

On Sun, 31 May 2020 10:40:14 -0300
Ezequiel Garcia  wrote:

>Hi Maxime,
>
>Thanks for posting this patch. I think you can still improve it,
>but it's a neat first try! :-)
>
>On Fri, 29 May 2020 at 10:05, Maxime Chevallier
> wrote:
>>
>> Introduce a driver for the camera interface on some Rockchip platforms.
>>
>> This controller supports CSI2, Parallel and BT656 interfaces, but for
>> now only the parallel interface could be tested, hence it's the only one
>> that's supported in the first version of this driver.
>>  
>
>I'm confused, you mention parallel as the only tested interface,
>but the cover letters mentions PAL. Doesn't PAL mean BT.656
>or am I completely lost?

No you are correct, this is a misunderstanding on my part about the
various formats and naming schemes.

The main point I wanted to outline is that the hardware supports a CSI2
interface, which this version of the driver doesn't implement.

>(I am not super familiar with parallel sensors).
>
>> This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288,
>> but for now it's only be tested on PX30.
>>  
>
>My RK3288 and RK3326 (i.e. PX30) refer to this IP block as "Video
>Input interface".
>I am wondering if it won't be clearer for developers / users if we
>rename the driver
>to rockchip-vip (and of course s/cif/vip and s/CIF/VIP).

After looking into the datasheets for these SoCs, it's clear that the
denomination should indeed be "VIP" and not "CIF", thanks !

>> Most of this driver was written follwing the BSP driver from rockchip,
>> removing the parts that either didn't fit correctly the guidelines, or
>> that couldn't be tested.
>>
>> This basic version doesn't support cropping nor scaling, and is only
>> designed with one sensor being attached to it a any time.
>>
>> Signed-off-by: Maxime Chevallier 
>> ---
>>
>> Changes since V1 :
>>
>>  - Convert to the bulk APIs for clocks and resets  
>
>Note that the bulk API clock conversion was not
>properly done.
>
>>  - remove useless references to priv data
>>  - Move around some init functions at probe time
>>  - Upate some helpers to more suitable ones
>>
>> Here is the output from v4l2-compliance. There are no fails in the final
>> summary, but there is one in the output that I didn't catch previously.
>>
>> Still, here's the V2 in the meantime, if you have any further reviews
>> ompliance SHA: not available, 64 bits
>>
>> Compliance test for rkcif device /dev/video0:
>>
>> Driver Info:
>> Driver name  : rkcif
>> Card type: rkcif
>> Bus info : platform:ff49.cif
>> Driver version   : 5.7.0
>> Capabilities : 0x84201000
>> Video Capture Multiplanar
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps  : 0x04201000
>> Video Capture Multiplanar
>> Streaming
>> Extended Pix Format
>> Media Driver Info:
>> Driver name  : rkcif
>> Model: rkcif
>> Serial   :
>> Bus info :
>> Media version: 5.7.0
>> Hardware revision: 0x (0)
>> Driver version   : 5.7.0
>> Interface Info:
>> ID   : 0x0302
>> Type : V4L Video
>> Entity Info:
>> ID   : 0x0001 (1)
>> Name : video_rkcif
>> Function : V4L2 I/O
>> Pad 0x0104   : 0: Sink
>>   Link 0x0207: from remote pad 0x106 of entity 'tw9900 
>> 2-0044': Data, Enabled
>>
>> Required ioctls:
>> test MC information (see 'Media Driver Info' above): OK
>> test VIDIOC_QUERYCAP: OK
>>
>> Allow for multiple opens:
>> test second /dev/video0 open: OK
>> test VIDIOC_QUERYCAP: OK
>> test VIDIOC_G/S_PRIORITY: OK
>> test for unlimited opens: OK
>>
>> Debug ioctls:
>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>
>> Input ioctls:
>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>> test VIDIOC_G/S/ENUMINPUT: OK
>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>> Inputs: 1 Audio Inputs: 0 Tuners: 0
>>
>> Output ioctls:
>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>
>> Input/Output configuration ioctls:
>> test VIDIOC_ENUM/G/S/QUERY_STD: O

Re: [PATCH v4 11/18] nitro_enclaves: Add logic for enclave memory region set

[Paraschiv, Andra-Irina]

On 06/07/2020 13:46, Alexander Graf wrote:



On 22.06.20 22:03, Andra Paraschiv wrote:

Another resource that is being set for an enclave is memory. User space
memory regions, that need to be backed by contiguous memory regions,
are associated with the enclave.

One solution for allocating / reserving contiguous memory regions, that
is used for integration, is hugetlbfs. The user space process that is
associated with the enclave passes to the driver these memory regions.

The enclave memory regions need to be from the same NUMA node as the
enclave CPUs.

Add ioctl command logic for setting user space memory region for an
enclave.

Signed-off-by: Alexandru Vasile 
Signed-off-by: Andra Paraschiv 
---
Changelog

v3 -> v4

* Check enclave memory regions are from the same NUMA node as the
   enclave CPUs.
* Use dev_err instead of custom NE log pattern.
* Update the NE ioctl call to match the decoupling from the KVM API.

v2 -> v3

* Remove the WARN_ON calls.
* Update static calls sanity checks.
* Update kzfree() calls to kfree().

v1 -> v2

* Add log pattern for NE.
* Update goto labels to match their purpose.
* Remove the BUG_ON calls.
* Check if enclave max memory regions is reached when setting an enclave
   memory region.
* Check if enclave state is init when setting an enclave memory region.
---
  drivers/virt/nitro_enclaves/ne_misc_dev.c | 257 ++
  1 file changed, 257 insertions(+)

diff --git a/drivers/virt/nitro_enclaves/ne_misc_dev.c 
b/drivers/virt/nitro_enclaves/ne_misc_dev.c

index cfdefa52ed2a..17ccb6cdbd75 100644
--- a/drivers/virt/nitro_enclaves/ne_misc_dev.c
+++ b/drivers/virt/nitro_enclaves/ne_misc_dev.c
@@ -476,6 +476,233 @@ static int ne_create_vcpu_ioctl(struct 
ne_enclave *ne_enclave, u32 vcpu_id)

  return rc;
  }
  +/**
+ * ne_sanity_check_user_mem_region - Sanity check the userspace memory
+ * region received during the set user memory region ioctl call.
+ *
+ * This function gets called with the ne_enclave mutex held.
+ *
+ * @ne_enclave: private data associated with the current enclave.
+ * @mem_region: user space memory region to be sanity checked.
+ *
+ * @returns: 0 on success, negative return value on failure.
+ */
+static int ne_sanity_check_user_mem_region(struct ne_enclave 
*ne_enclave,

+    struct ne_user_memory_region *mem_region)
+{
+    if (ne_enclave->mm != current->mm)
+    return -EIO;
+
+    if ((mem_region->memory_size % NE_MIN_MEM_REGION_SIZE) != 0) {
+    dev_err_ratelimited(ne_misc_dev.this_device,
+    "Mem size not multiple of 2 MiB\n");
+
+    return -EINVAL;


Can we make this an error that gets propagated to user space 
explicitly? I'd rather have a clear error return value of this 
function than a random message in dmesg.


We can make this, will add memory checks specific NE error codes, as for 
the other call paths in the series e.g. enclave CPU(s) setup.





+    }
+
+    if ((mem_region->userspace_addr & (NE_MIN_MEM_REGION_SIZE - 1)) ||


This logic already relies on the fact that NE_MIN_MEM_REGION_SIZE is a 
power of two. Can you do the same above on the memory_size check?


Done.



+    !access_ok((void __user *)(unsigned 
long)mem_region->userspace_addr,

+   mem_region->memory_size)) {
+    dev_err_ratelimited(ne_misc_dev.this_device,
+    "Invalid user space addr range\n");
+
+    return -EINVAL;


Same comment again. Return different errors for different conditions, 
so that user space has a chance to print proper errors to its users.


Also, don't we have to check alignment of userspace_addr as well?



Would need an alignment check for 2 MiB at least, yes.


+    }
+
+    return 0;
+}
+
+/**
+ * ne_set_user_memory_region_ioctl - Add user space memory region to 
the slot

+ * associated with the current enclave.
+ *
+ * This function gets called with the ne_enclave mutex held.
+ *
+ * @ne_enclave: private data associated with the current enclave.
+ * @mem_region: user space memory region to be associated with the 
given slot.

+ *
+ * @returns: 0 on success, negative return value on failure.
+ */
+static int ne_set_user_memory_region_ioctl(struct ne_enclave 
*ne_enclave,

+    struct ne_user_memory_region *mem_region)
+{
+    struct ne_pci_dev_cmd_reply cmd_reply = {};
+    long gup_rc = 0;
+    unsigned long i = 0;
+    struct ne_mem_region *ne_mem_region = NULL;
+    unsigned long nr_phys_contig_mem_regions = 0;
+    unsigned long nr_pinned_pages = 0;
+    struct page **phys_contig_mem_regions = NULL;
+    int rc = -EINVAL;
+    struct slot_add_mem_req slot_add_mem_req = {};
+
+    rc = ne_sanity_check_user_mem_region(ne_enclave, mem_region);
+    if (rc < 0)
+    return rc;
+
+    ne_mem_region = kzalloc(sizeof(*ne_mem_region), GFP_KERNEL);
+    if (!ne_mem_region)
+    return -ENOMEM;
+
+    /*
+ * TODO: Update nr_pages value to handle contiguous virtual address
+ * ranges mapped to non-contiguous physical regions. Hugetlbfs 
can gi

Re: [PATCH v4] mm/zswap: move to use crypto_acomp API for hardware acceleration

[Sebastian Andrzej Siewior]

On 2020-07-09 01:32:38 [+], Song Bao Hua (Barry Song) wrote:
> > This looks using the same synchronous mechanism around an asynchronous
> > interface. It works as a PoC.
> > 
> > As far as I remember the crypto async interface, the incoming skbs were fed 
> > to
> > the async interface and returned to the caller so the NIC could continue
> > allocate new RX skbs and move on. Only if the queue of requests was getting
> > to long the code started to throttle. Eventually the async crypto code
> > completed the decryption operation in a different context and fed the
> > decrypted packet(s) into the stack.
> > 
> > From a quick view, you would have to return -EINPROGRESS here and have at
> > the caller side something like that:
> > 
> > iff --git a/mm/page_io.c b/mm/page_io.c
> > index e8726f3e3820b..9d1baa46ec3ed 100644
> > --- a/mm/page_io.c
> > +++ b/mm/page_io.c
> > @@ -252,12 +252,15 @@ int swap_writepage(struct page *page, struct
> > writeback_control *wbc)
> > unlock_page(page);
> > goto out;
> > }
> > -   if (frontswap_store(page) == 0) {
> > +   ret = frontswap_store(page);
> > +   if (ret == 0) {
> > set_page_writeback(page);
> > unlock_page(page);
> > end_page_writeback(page);
> > goto out;
> > }
> > +   if (ret = -EINPROGRESS)
> > +   goto out;
> > ret = __swap_writepage(page, wbc, end_swap_bio_write);
> >  out:
> > return ret;
> > 
> Unfortunately, this is not true and things are not that simple.
> 
> We can't simply depend on -EINPROGRESS and go out.
> We have to wait for the result of compression to decide if we should
> do __swap_writepage(). As one page might be compressed into two
> pages, in this case, we will still need to do _swap_writepage().
> As I replied in the latest email, all of the async improvement to frontswap
> needs very careful thinking and benchmark. It can only happen after
> we build the base in this patch, fixing the broken connection between
> zswap and those new zip drivers.

At the time the compression finishes you see what happens and based on
the design you can either complete it immediately (the 0/error case from
above) or forward the result to the caller and let him decide.

> Thanks
> Barry

Sebastian

Re: [PATCH v2 0/2] Add support to get/set PHY attributes using PHY framework

[Vinod Koul]

On 09-07-20, 07:02, Swapnil Kashinath Jakhade wrote:
> Ping requesting review comments.
> https://lkml.org/lkml/2020/5/26/507

I dont have this, can you repost?

Thanks
> 
> Thanks & regards,
> Swapnil
> 
> > -Original Message-
> > From: Yuti Amonkar 
> > Sent: Tuesday, May 26, 2020 8:05 PM
> > To: linux-kernel@vger.kernel.org; kis...@ti.com; robh...@kernel.org;
> > mark.rutl...@arm.com; max...@cerno.tech
> > Cc: nsek...@ti.com; jsa...@ti.com; tomi.valkei...@ti.com;
> > prane...@ti.com; Milind Parab ; Swapnil Kashinath
> > Jakhade ; Yuti Suresh Amonkar
> > 
> > Subject: [PATCH v2 0/2] Add support to get/set PHY attributes using PHY
> > framework
> > 
> > This patch series adds support to use kernel PHY subsystem APIs to get/set
> > PHY attributes like number of lanes and maximum link rate.
> > 
> > It includes following patches:
> > 
> > 1. v2-0001-phy-Add-max_link_rate-as-a-PHY-attribute-and-APIs.patch
> > This patch adds max_link_rate as a PHY attribute along with a pair of APIs
> > that allow the generic PHY subsystem to get/set PHY attributes supported by
> > the PHY.
> > The PHY provider driver may use phy_set_attrs() API to set the values that
> > PHY supports.
> > The controller driver may then use phy_get_attrs() API to fetch the PHY
> > attributes in order to properly configure the controller.
> > 
> > 2. v2-0002-phy-phy-cadence-torrent-Use-kernel-PHY-API-to-set.patch
> > This patch uses kernel PHY API phy_set_attrs to set corresponding PHY
> > properties in Cadence Torrent PHY driver. This will enable drivers using 
> > this
> > PHY to read these properties using PHY framework.
> > 
> > The phy_get_attrs() API will be used in the DRM bridge driver [1] which is 
> > in
> > process of upstreaming.
> > 
> > [1]
> > 
> > https://lkml.org/lkml/2020/2/26/263
> > 
> > Version History:
> > 
> > v2:
> > - Implemented single pair of functions to get/set all PHY attributes
> > 
> > Swapnil Jakhade (1):
> >   phy: phy-cadence-torrent: Use kernel PHY API to set PHY attributes
> > 
> > Yuti Amonkar (1):
> >   phy: Add max_link_rate as a PHY attribute and APIs to get/set
> > phy_attrs
> > 
> >  drivers/phy/cadence/phy-cadence-torrent.c |  7 +++
> >  include/linux/phy/phy.h   | 25 +++
> >  2 files changed, 32 insertions(+)
> > 
> > --
> > 2.17.1

-- 
~Vinod

Re: [PATCH 2/2] doc, mm: clarify /proc//oom_score value range

[Yafang Shao]

On Thu, Jul 9, 2020 at 2:26 PM Michal Hocko  wrote:
>
> From: Michal Hocko 
>
> The exported value includes oom_score_adj so the range is no [0, 1000]
> as described in the previous section but rather [0, 2000]. Mention that
> fact explicitly.
>
> Signed-off-by: Michal Hocko 
> ---
>  Documentation/filesystems/proc.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/filesystems/proc.rst 
> b/Documentation/filesystems/proc.rst
> index 8e3b5dffcfa8..78a0dec323a3 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -1673,6 +1673,9 @@ requires CAP_SYS_RESOURCE.
>  3.2 /proc//oom_score - Display current oom-killer score
>  -
>
> +Please note that the exported value includes oom_score_adj so it is 
> effectively
> +in range [0,2000].
> +

[0, 2000] may be not a proper range, see my reply in another thread.[1]
As this value hasn't been documented before and nobody notices that, I
think there might be no user really care about it before.
So we should discuss the proper range if we really think the user will
care about this value.

[1]. 
https://lore.kernel.org/linux-mm/CALOAHbAvj-gWZMLef=PuKTfDScwfM8gPPX0evzjoref1bG=z...@mail.gmail.com/T/#m2332c3e6b7f869383cb74ab3a0f7b6c670b3b23b

>  This file can be used to check the current score used by the oom-killer is 
> for
>  any given . Use it together with /proc//oom_score_adj to tune which
>  process should be killed in an out-of-memory situation.
> --
> 2.27.0
>


-- 
Thanks
Yafang

RE: [PATCH v5 0/5] scsi: ufs: Add Host Performance Booster Support

[Daejun Park]

> Hello,
> > 
> > Just a gentle reminder that I'd like some feedback.
> > Any suggestions here?
> If no-one objects, I think you can submit your patches for review as non-RFC.
> 
[PATCH v5 0/5] scsi: ufs: Add Host Performance Booster Support
~~
It is non-RFC version.

Thanks,
Daejun.

Re: Re: linux-next: build warning after merge of the spi tree

[Peng Fan]

Hi, Browm, Stephen
Firstly, feel sorry for the problem introduced by me. I think I must modify 
my bad,but should I send another patch to delete the label "out_free" or 
re-send patch of v2(which maybe need to go back)?
Could you give me some advices? Sorry again.

Thanks

"Peng Fan" wrote:
> Very sorry for that, I will re-send v2 later.
> 
> "Stephen Rothwell" wrote:
> > Hi all,
> > 
> > After merging the spi tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> > 
> > drivers/spi/spi-atmel.c: In function 'atmel_spi_probe':
> > drivers/spi/spi-atmel.c:1680:1: warning: label 'out_free' defined but not 
> > used [-Wunused-label]
> >  1680 | out_free:
> >   | ^~~~
> > 
> > Introduced by commit
> > 
> >   2d9a744685bc ("spi: atmel: No need to call spi_master_put() if 
> > spi_alloc_master() failed")
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell

RE: [PATCH v4 1/2] dt-bindings: dma: Add bindings for intel LGM SOC

[Langer, Thomas]

> -Original Message-
> From: devicetree-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Amireddy Mallikarjuna reddy
> Sent: Donnerstag, 9. Juli 2020 08:01
> To: dmaeng...@vger.kernel.org; vk...@kernel.org;
> devicet...@vger.kernel.org; robh...@kernel.org
> Cc: linux-kernel@vger.kernel.org; Shevchenko, Andriy
> ; chuanhua@linux.intel.com; Kim, Cheol
> Yong ; Wu, Qiming ;
> malliamireddy...@gmail.com; Amireddy Mallikarjuna reddy
> 
> Subject: [PATCH v4 1/2] dt-bindings: dma: Add bindings for intel LGM SOC
> 
> Add DT bindings YAML schema for DMA controller driver
> of Lightning Mountain(LGM) SoC.
> 
> Signed-off-by: Amireddy Mallikarjuna reddy
> 
> ---
> v1:
> - Initial version.
> 
> v2:
> - Fix bot errors.
> 
> v3:
> - No change.
> 
> v4:
> - Address Thomas langer comments

Please read my comments again and then respond about the topics you ignored.
I added some hints below again.

Thanks.

> ---
>  .../devicetree/bindings/dma/intel,ldma.yaml| 416
> +
>  1 file changed, 416 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/dma/intel,ldma.yaml
> 
> diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml
> b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
> new file mode 100644
> index ..7f666b9812e4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
> @@ -0,0 +1,416 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/intel,ldma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Lightning Mountain centralized low speed DMA and high speed DMA
> controllers.
> +
> +maintainers:
> +  - chuanhua@intel.com
> +  - mallikarjunax.re...@intel.com
> +
> +properties:
> + $nodename:
> +   pattern: "^dma(@.*)?$"

Please explain the difference to the common dma binding.

> +
> + "#dma-cells":
> +   const: 1
> +
> + compatible:
> +  anyOf:
> +   - const: intel,lgm-cdma
> +   - const: intel,lgm-dma2tx
> +   - const: intel,lgm-dma1rx
> +   - const: intel,lgm-dma1tx
> +   - const: intel,lgm-dma0tx
> +   - const: intel,lgm-dma3
> +   - const: intel,lgm-toe-dma30
> +   - const: intel,lgm-toe-dma31

Please explain why you need so many different compatible strings.

> +
> + reg:
> +  maxItems: 1
> +
> + clocks:
> +  maxItems: 1
> +
> + resets:
> +  maxItems: 1
> +
> + interrupts:
> +  maxItems: 1
> +
> + intel,dma-poll-cnt:
> +   $ref: /schemas/types.yaml#definitions/uint32
> +   description:
> + DMA descriptor polling counter. It may need fine tune according
> + to the system application scenario.
> +
> + intel,dma-byte-en:
> +   type: boolean
> +   description:
> + DMA byte enable is only valid for DMA write(RX).
> + Byte enable(1) means DMA write will be based on the number of
> dwords
> + instead of the whole burst.
> +
> + intel,dma-drb:
> +type: boolean
> +description:
> +  DMA descriptor read back to make sure data and desc
> synchronization.
> +
> + intel,dma-burst:
> +$ref: /schemas/types.yaml#definitions/uint32
> +description:
> +   Specifiy the DMA burst size(in dwords), the valid value will be
> 8, 16, 32.
> +   Default is 16 for data path dma, 32 is for memcopy DMA.
> +
> + intel,dma-polling-cnt:
> +$ref: /schemas/types.yaml#definitions/uint32
> +description:
> +   DMA descriptor polling counter. It may need fine tune according
> to
> +   the system application scenario.
> +
> + intel,dma-desc-in-sram:
> +type: boolean
> +description:
> +   DMA descritpors in SRAM or not. Some old controllers descriptors
> +   can be in DRAM or SRAM. The new ones are all in SRAM.
> +
> + intel,dma-orrc:
> +$ref: /schemas/types.yaml#definitions/uint32
> +description:
> +   DMA outstanding read counter. The maximum value is 16, and it
> may
> +   need fine tune according to the system application scenarios.
> +
> + intel,dma-dburst-wr:
> +type: boolean
> +description:
> +   Enable RX dynamic burst write. It only applies to RX DMA and
> memcopy DMA.
> +
> +
> + dma-ports:
> +type: object
> +description:
> +   This sub-node must contain a sub-node for each DMA port.
> +properties:
> +  '#address-cells':
> +const: 1
> +  '#size-cells':
> +const: 0
> +
> +patternProperties:
> +  "^dma-ports@[0-9]+$":
> +  type: object
> +
> +  properties:
> +reg:
> +  items:
> +- enum: [0, 1, 2, 3, 4, 5]
> +  description:
> + Which port this node refers to.
> +
> +intel,name:
> +  $ref: /schemas/types.yaml#definitions/string-array
> +  description:
> + Port name of each DMA port.
> +
> +intel,chans:
> +  $ref: /schemas/types.yaml#/definitions/uint32-array
> +  description:
> + The channel

RE: [PATCH v4] mm/zswap: move to use crypto_acomp API for hardware acceleration

[Song Bao Hua (Barry Song)]

> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Sebastian Andrzej
> Siewior
> Sent: Thursday, July 9, 2020 7:39 PM
> To: Song Bao Hua (Barry Song) 
> Cc: a...@linux-foundation.org; herb...@gondor.apana.org.au;
> da...@davemloft.net; linux-cry...@vger.kernel.org; linux...@kvack.org;
> linux-kernel@vger.kernel.org; Linuxarm ; Luis Claudio
> R . Goncalves ; Mahipal Challa
> ; Seth Jennings ;
> Dan Streetman ; Vitaly Wool
> ; Wangzhou (B) ;
> Colin Ian King 
> Subject: Re: [PATCH v4] mm/zswap: move to use crypto_acomp API for
> hardware acceleration
> 
> On 2020-07-09 01:32:38 [+], Song Bao Hua (Barry Song) wrote:
> > > This looks using the same synchronous mechanism around an
> asynchronous
> > > interface. It works as a PoC.
> > >
> > > As far as I remember the crypto async interface, the incoming skbs were 
> > > fed
> to
> > > the async interface and returned to the caller so the NIC could continue
> > > allocate new RX skbs and move on. Only if the queue of requests was
> getting
> > > to long the code started to throttle. Eventually the async crypto code
> > > completed the decryption operation in a different context and fed the
> > > decrypted packet(s) into the stack.
> > >
> > > From a quick view, you would have to return -EINPROGRESS here and have
> at
> > > the caller side something like that:
> > >
> > > iff --git a/mm/page_io.c b/mm/page_io.c
> > > index e8726f3e3820b..9d1baa46ec3ed 100644
> > > --- a/mm/page_io.c
> > > +++ b/mm/page_io.c
> > > @@ -252,12 +252,15 @@ int swap_writepage(struct page *page, struct
> > > writeback_control *wbc)
> > > unlock_page(page);
> > > goto out;
> > > }
> > > -   if (frontswap_store(page) == 0) {
> > > +   ret = frontswap_store(page);
> > > +   if (ret == 0) {
> > > set_page_writeback(page);
> > > unlock_page(page);
> > > end_page_writeback(page);
> > > goto out;
> > > }
> > > +   if (ret = -EINPROGRESS)
> > > +   goto out;
> > > ret = __swap_writepage(page, wbc, end_swap_bio_write);
> > >  out:
> > > return ret;
> > >
> > Unfortunately, this is not true and things are not that simple.
> >
> > We can't simply depend on -EINPROGRESS and go out.
> > We have to wait for the result of compression to decide if we should
> > do __swap_writepage(). As one page might be compressed into two
> > pages, in this case, we will still need to do _swap_writepage().
> > As I replied in the latest email, all of the async improvement to frontswap
> > needs very careful thinking and benchmark. It can only happen after
> > we build the base in this patch, fixing the broken connection between
> > zswap and those new zip drivers.
> 
> At the time the compression finishes you see what happens and based on
> the design you can either complete it immediately (the 0/error case from
> above) or forward the result to the caller and let him decide.

Hello Sebastian, thanks for your reply and careful review.

Right now, frontswap is pretty much one thing which happens before 
__swap_writepage().
The whole design is full of the assumption that frontswap is sync. So if 
frontswap
consumes a page without any error, this page won't go to __swap_writepage()
which is async. On the other hand, if frontswap's store has any error, that 
means
this page needs to swap to disk.

int swap_writepage(struct page *page, struct writeback_control *wbc)
{
int ret = 0;

if (try_to_free_swap(page)) {
unlock_page(page);
goto out;
}
if (frontswap_store(page) == 0) {
set_page_writeback(page);
unlock_page(page);
end_page_writeback(page);
goto out;
}
ret = __swap_writepage(page, wbc, end_swap_bio_write);
out:
return ret;
}

I don't think we can simply "forward the result to the caller and let him 
decide".
Would you like to present some pseudo code?

Thanks
Barry

Re: [PATCH v2] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs

[Philippe CORNU]

On 7/8/20 7:08 PM, Angelo Ribeiro wrote:
> Hi,
> 
> Is this patch good to go?
> @dan...@ffwll.ch, @Philippe CORNU
> 
> Was already tested by @Yannick FERTRE
> and @Adrian Pop
> on https://lkml.org/lkml/2020/4/6/691 .
> 
> Thanks,
> Angelo
> 
> From: Yannick
> FERTRE 
> Date: Wed, Jun 24, 2020 at 16:35:04
> 
>> Hello Angelo,
>> thanks for the patch.
>> Tested-by: Yannick Fertre 
>> Tested OK on STM32MP1-DISCO, DSI v1.31
>>
>> Best regards
>>
>>
>> On 4/6/20 3:49 PM, Angelo Ribeiro wrote:
>>> Add support for the video pattern generator (VPG) BER pattern mode and
>>> configuration in runtime.
>>>
>>> This enables using the debugfs interface to manipulate the VPG after
>>> the pipeline is set.
>>> Also, enables the usage of the VPG BER pattern.
>>>
>>> Changes in v2:
>>> - Added VID_MODE_VPG_MODE
>>> - Solved incompatible return type on __get and __set
>>>
>>> Reported-by: kbuild test robot 
>>> Reported-by: Adrian Pop 
>>> Cc: Gustavo Pimentel 
>>> Cc: Joao Pinto 
>>> Cc: Jose Abreu 
>>> Signed-off-by: Angelo Ribeiro 
>>> ---
>>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 98 
>>> ---
>>>1 file changed, 90 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index b18351b..9de3645 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -91,6 +91,7 @@
>>>#define VID_MODE_TYPE_BURST  0x2
>>>#define VID_MODE_TYPE_MASK   0x3
>>>#define VID_MODE_VPG_ENABLE  BIT(16)
>>> +#define VID_MODE_VPG_MODE  BIT(20)
>>>#define VID_MODE_VPG_HORIZONTAL  BIT(24)
>>>
>>>#define DSI_VID_PKT_SIZE 0x3c
>>> @@ -221,6 +222,21 @@
>>>#define PHY_STATUS_TIMEOUT_US1
>>>#define CMD_PKT_STATUS_TIMEOUT_US2
>>>
>>> +#ifdef CONFIG_DEBUG_FS
>>> +#define VPG_DEFS(name, dsi) \
>>> +   ((void __force *)&((*dsi).vpg_defs.name))
>>> +
>>> +#define REGISTER(name, mask, dsi) \
>>> +   { #name, VPG_DEFS(name, dsi), mask, dsi }
>>> +
>>> +struct debugfs_entries {
>>> +   const char  *name;
>>> +   bool*reg;
>>> +   u32 mask;
>>> +   struct dw_mipi_dsi  *dsi;
>>> +};
>>> +#endif /* CONFIG_DEBUG_FS */
>>> +
>>>struct dw_mipi_dsi {
>>> struct drm_bridge bridge;
>>> struct mipi_dsi_host dsi_host;
>>> @@ -238,9 +254,12 @@ struct dw_mipi_dsi {
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>> struct dentry *debugfs;
>>> -
>>> -   bool vpg;
>>> -   bool vpg_horizontal;
>>> +   struct debugfs_entries *debugfs_vpg;
>>> +   struct {
>>> +   bool vpg;
>>> +   bool vpg_horizontal;
>>> +   bool vpg_ber_pattern;
>>> +   } vpg_defs;
>>>#endif /* CONFIG_DEBUG_FS */
>>>
>>> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
>>> @@ -530,9 +549,11 @@ static void dw_mipi_dsi_video_mode_config(struct 
>>> dw_mipi_dsi *dsi)
>>> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>> -   if (dsi->vpg) {
>>> +   if (dsi->vpg_defs.vpg) {
>>> val |= VID_MODE_VPG_ENABLE;
>>> -   val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
>>> +   val |= dsi->vpg_defs.vpg_horizontal ?
>>> +  VID_MODE_VPG_HORIZONTAL : 0;
>>> +   val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
>>> }
>>>#endif /* CONFIG_DEBUG_FS */
>>>
>>> @@ -961,6 +982,68 @@ static const struct drm_bridge_funcs 
>>> dw_mipi_dsi_bridge_funcs = {
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>>
>>> +int dw_mipi_dsi_debugfs_write(void *data, u64 val)
>>> +{
>>> +   struct debugfs_entries *vpg = data;
>>> +   struct dw_mipi_dsi *dsi;
>>> +   u32 mode_cfg;
>>> +
>>> +   if (!vpg)
>>> +   return -ENODEV;
>>> +
>>> +   dsi = vpg->dsi;
>>> +
>>> +   *vpg->reg = (bool)val;
>>> +
>>> +   mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
>>> +
>>> +   if (*vpg->reg)
>>> +   mode_cfg |= vpg->mask;
>>> +   else
>>> +   mode_cfg &= ~vpg->mask;
>>> +
>>> +   dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
>>> +{
>>> +   struct debugfs_entries *vpg = data;
>>> +
>>> +   if (!vpg)
>>> +   return -ENODEV;
>>> +
>>> +   *val = *vpg->reg;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
>>> +dw_mipi_dsi_debugfs_write, "%llu\n");
>>> +
>>> +static void debugfs_create_files(void *data)
>>> +{
>>> +   struct dw_mipi_dsi *dsi = data;
>>> +   struct debugfs_entries debugfs[] = {
>>> +   REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi),
>>> +   REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi),
>>> +   REGISTER(

Re: [PATCH 0/6] crypto: hisilicon/hpre bugfix - misc fixes

[Herbert Xu]

On Thu, Jul 02, 2020 at 10:31:13AM +0800, Meng Yu wrote:
> Bugfix: crypto: hisilicon/hpre - modify the macros, add a switch in
>   sriov_configure, unified debugfs interface, and disable
>   hardware FLR.
> 
> Hui Tang (2):
>   crypto: hisilicon/hpre - HPRE_OVERTIME_THRHLD can be written by
> debugfs
>   crypto: hisilicon/hpre - disable FLR triggered by hardware
> 
> Meng Yu (4):
>   crypto: hisilicon/hpre - Init the value of current_q of debugfs
>   crypto: hisilicon/hpre - Modify the Macro definition and format
>   crypto: hisilicon/hpre - Add a switch in sriov_configure
>   crypto: hisilicon/hpre - update debugfs interface parameters
> 
>  drivers/crypto/hisilicon/hpre/hpre_main.c | 114 
> --
>  1 file changed, 62 insertions(+), 52 deletions(-)

This doesn't apply against cryptodev.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

linux-next: manual merge of the akpm-current tree with the userns tree

[Stephen Rothwell]

Hi all,

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

  fs/exec.c

between commit:

  25cf336de51b ("exec: Remove do_execve_file")

from the userns tree and commit:

  538d50d50815 ("umh: fix refcount underflow in fork_usermode_blob().")

from the akpm-current tree.

I fixed it up (I effectively dropped the akpm-current tree patch since
the former commit means that "file" is no longer passed the affected
function) 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


pgp4UyWZYnhAA.pgp
Description: OpenPGP digital signature

Re: [PATCH] riscv: Enable ELF-ASLR for riscv

[Guo Ren]

On Thu, Jul 9, 2020 at 1:32 PM Alex Ghiti  wrote:
>
> Hi Guo,
>
> Le 7/9/20 à 12:38 AM, guo...@kernel.org a écrit :
> > From: Guo Ren 
> >
> > Let riscv enable randomizes the stack, heap and binary images of
> > ELF binaries. Seems it's ok at all after qemu & chip test and
> > there is no founded side effect.
> >
> > So just simply select ARCH_HAS_ELF_RANDOMIZE :)
> >
> > Signed-off-by: Guo Ren 
> > Cc: Palmer Dabbelt 
> > Cc: Paul Walmsley 
> > Cc: Zong Li 
> > Cc: Greentime Hu 
> > ---
> >   arch/riscv/Kconfig | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 91bfc6c..eed6647 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -20,6 +20,7 @@ config RISCV
> >   select ARCH_HAS_GIGANTIC_PAGE
> >   select ARCH_HAS_MMIOWB
> >   select ARCH_HAS_PTE_SPECIAL
> > + select ARCH_HAS_ELF_RANDOMIZE
> >   select ARCH_HAS_SET_DIRECT_MAP
> >   select ARCH_HAS_SET_MEMORY
> >   select ARCH_HAS_STRICT_KERNEL_RWX if MMU
> >
>
> Actually it is already the case: ARCH_HAS_ELF_RANDOMIZE is already
> selected by ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
Oops :P, Thx for correcting, abandon the patch.

-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Thu, Jul 09, 2020 at 08:29:21AM +0100, Daniel Stone wrote:
> Hi,
> Jumping in after a couple of weeks where I've paged most everything
> out of my brain ...
> 
> On Fri, 19 Jun 2020 at 10:43, Daniel Vetter  wrote:
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > > The proposed patches might very well encode the wrong contract, that's
> > > > all up for discussion. But fundamentally questioning that we need one
> > > > is missing what upstream is all about.
> > >
> > > Then I have not clearly communicated, as my opinion is not that
> > > validation is worthless, but that the implementation is enshrining a
> > > global property on a low level primitive that prevents it from being
> > > used elsewhere. And I want to replace completion [chains] with fences, and
> > > bio with fences, and closures with fences, and what other equivalencies
> > > there are in the kernel. The fence is as central a locking construct as
> > > struct completion and deserves to be a foundational primitive provided
> > > by kernel/ used throughout all drivers for discrete problem domains.
> > >
> > > This is narrowing dma_fence whereby adding
> > >   struct lockdep_map *dma_fence::wait_map
> > > and annotating linkage, allows you to continue to specify that all
> > > dma_fence used for a particular purpose must follow common rules,
> > > without restricting the primitive for uses outside of this scope.
> >
> > Somewhere else in this thread I had discussions with Jason Gunthorpe about
> > this topic. It might maybe change somewhat depending upon exact rules, but
> > his take is very much "I don't want dma_fence in rdma". Or pretty close to
> > that at least.
> >
> > Similar discussions with habanalabs, they're using dma_fence internally
> > without any of the uapi. Discussion there has also now concluded that it's
> > best if they remove them, and simply switch over to a wait_queue or
> > completion like every other driver does.
> >
> > The next round of the patches already have a paragraph to at least
> > somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> > consensus might be pointing even more strongly at dma_fence being solely
> > something for gpus and closely related subsystem (maybe media) for syncing
> > dma-buf access.
> >
> > So dma_fence as general replacement for completion chains I think just
> > wont happen.
> >
> > What might make sense is if e.g. the lockdep annotations could be reused,
> > at least in design, for wait_queue or completion or anything else
> > really. I do think that has a fair chance compared to the automagic
> > cross-release annotations approach, which relied way too heavily on
> > guessing where barriers are. My experience from just a bit of playing
> > around with these patches here and discussing them with other driver
> > maintainers is that accurately deciding where critical sections start and
> > end is a job for humans only. And if you get it wrong, you will have a
> > false positive.
> >
> > And you're indeed correct that if we'd do annotations for completions and
> > wait queues, then that would need to have a class per semantically
> > equivalent user, like we have lockdep classes for mutexes, not just one
> > overall.
> >
> > But dma_fence otoh is something very specific, which comes with very
> > specific rules attached - it's not a generic wait_queue at all. Originally
> > it did start out as one even, but it is a very specialized wait_queue.
> >
> > So there's imo two cases:
> >
> > - Your completion is entirely orthogonal of dma_fences, and can never ever
> >   block a dma_fence. Don't use dma_fence for this, and no problem. It's
> >   just another wait_queue somewhere.
> >
> > - Your completion can eventually, maybe through lots of convolutions and
> >   depdencies, block a dma_fence. In that case full dma_fence rules apply,
> >   and the only thing you can do with a custom annotation is make the rules
> >   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
> >   take certain scheduler locks. But the userspace visible/published fence
> >   do take them, maybe as part of command submission or retirement.
> >   Entirely hypotethical, no idea any driver actually needs this.
> 
> I don't claim to understand the implementation of i915's scheduler and
> GEM handling, and it seems like there's some public context missing
> here. But to me, the above is a good statement of what I (and a lot of
> other userspace) have been relying on - that dma-fence is a very
> tightly scoped thing which is very predictable but in extremis.
> 
> It would be great to have something like this enshrined in dma-fence
> documentation, visible to both kernel and external users. The
> properties we've so far been assuming for the graphics pipeline -
> covering production & execution of vertex/fragment workloads on the
> GPU, framebuffer display, and to the extent this is necessary
> involving compute - are something like this:
> 
> A single dma-fen

[PATCH 4/4] MAINTAINERS: Add Silvaco I3C master

[Miquel Raynal]

Add Conor and myself as maintainers.

Signed-off-by: Miquel Raynal 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 496fd4eafb68..7e44a06fd5da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15587,6 +15587,14 @@ S: Maintained
 F: Documentation/fb/sm712fb.rst
 F: drivers/video/fbdev/sm712*
 
+SILVACO I3C DUAL-ROLE MASTER
+M: Miquel Raynal 
+M: Conor Culhane 
+L: linux-...@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/i3c/svc,i3c-master.yaml
+F: drivers/i3c/master/svc-i3c-master.c
+
 SIMPLE FIRMWARE INTERFACE (SFI)
 S: Obsolete
 W: http://simplefirmware.org/
-- 
2.20.1

[PATCH v4] HID: i2c-hid: Enable wakeup capability from Suspend-to-Idle

[Kai-Heng Feng]

Many laptops can be woken up from Suspend-to-Idle by touchpad. This is
also the default behavior on other OSes.

However, if touchpad and touchscreen contact to each other when lid is
closed, wakeup events can be triggered inadventertly.

So let's disable the wakeup by default, but enable the wakeup capability
so users can enable it at their own discretion.

Signed-off-by: Kai-Heng Feng 
---
v4:
 - Enable the capability, but disable the wakeup default.

v3:
 - Use device_init_wakeup().
 - Wording change.

v2:
 - Fix compile error when ACPI is not enabled.

 drivers/hid/i2c-hid/i2c-hid-core.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 294c84e136d7..c18ca6a6cb3d 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -931,6 +931,14 @@ static void i2c_hid_acpi_fix_up_power(struct device *dev)
acpi_device_fix_up_power(adev);
 }
 
+static void i2c_hid_acpi_enable_wakeup(struct device *dev)
+{
+   if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
+   device_set_wakeup_capable(dev, true);
+   device_set_wakeup_enable(dev, false);
+   }
+}
+
 static const struct acpi_device_id i2c_hid_acpi_match[] = {
{"ACPI0C50", 0 },
{"PNP0C50", 0 },
@@ -945,6 +953,8 @@ static inline int i2c_hid_acpi_pdata(struct i2c_client 
*client,
 }
 
 static inline void i2c_hid_acpi_fix_up_power(struct device *dev) {}
+
+static inline void i2c_hid_acpi_enable_wakeup(struct device *dev) {}
 #endif
 
 #ifdef CONFIG_OF
@@ -1072,6 +1082,8 @@ static int i2c_hid_probe(struct i2c_client *client,
 
i2c_hid_acpi_fix_up_power(&client->dev);
 
+   i2c_hid_acpi_enable_wakeup(&client->dev);
+
device_enable_async_suspend(&client->dev);
 
/* Make sure there is something at this address */
-- 
2.17.1

[PATCH 2/4] dt-bindings: i3c: Describe Silvaco master binding

[Miquel Raynal]

Silvaco provide a dual-role I3C master.

Description is rather simple: it needs a register mapping, three
clocks and an interrupt.

Signed-off-by: Miquel Raynal 
---
 .../bindings/i3c/svc,i3c-master.yaml  | 59 +++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i3c/svc,i3c-master.yaml

diff --git a/Documentation/devicetree/bindings/i3c/svc,i3c-master.yaml 
b/Documentation/devicetree/bindings/i3c/svc,i3c-master.yaml
new file mode 100644
index ..11e670c6b76f
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/svc,i3c-master.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i3c/svc,i3c-master.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silvaco I3C master
+
+maintainers:
+  - Conor Culhane 
+
+properties:
+  compatible:
+const: svc,i3c-master
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clock-names:
+description: |
+  There are three clocks:
+pclk: System clock
+fast_clk: Fast clock (for the bus)
+slow_clk: Slow clock (for other events)
+
+items:
+  - const: pclk
+  - const: fast_clk
+  - const: slow_clk
+
+  clocks:
+minItems: 3
+maxItems: 3
+
+  resets:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clock-names
+  - clocks
+
+examples:
+  - |
+i3c-master@a000 {
+compatible = "svc,i3c-master";
+clocks = <&zynqmp_clk 71>, <&fclk>, <&sclk>;
+clock-names = "pclk", "fast_clk", "slow_clk";
+interrupt-parent = <&gic>;
+interrupts = <0 89 4>;
+reg = <0x0 0xa000 0x0 0x1000>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
-- 
2.20.1

[PATCH 1/4] dt-bindings: Add vendor prefix for Silvaco

[Miquel Raynal]

Silvaco, Inc. is an EDA provider of software tools used for process
and device development and for analog/mixed-signal, power IC and
memory design [1].

[1] https://www.silvaco.com/company/profile/profile.html

Signed-off-by: Miquel Raynal 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9aeab66be85f..5933966db783 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1004,6 +1004,8 @@ patternProperties:
 description: Shenzhen Sunchip Technology Co., Ltd
   "^SUNW,.*":
 description: Sun Microsystems, Inc
+  "^svc,.*":
+description: Silvaco, Inc.
   "^swir,.*":
 description: Sierra Wireless
   "^syna,.*":
-- 
2.20.1

[PATCH 3/4] i3c: master: svc: Add Silvaco I3C master driver

[Miquel Raynal]

Add support for Silvaco I3C dual-role IP. The master role is supported
in SDR mode only. I2C transfers have not been tested but are shared
because they are so close to the I3C transfers in terms of registers
configuration.

Signed-off-by: Miquel Raynal 
---
 drivers/i3c/master/Kconfig  |8 +
 drivers/i3c/master/Makefile |1 +
 drivers/i3c/master/svc-i3c-master.c | 1355 +++
 3 files changed, 1364 insertions(+)
 create mode 100644 drivers/i3c/master/svc-i3c-master.c

diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index 4e80a1fcbf91..032b4de14277 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -21,3 +21,11 @@ config DW_I3C_MASTER
 
  This driver can also be built as a module.  If so, the module
  will be called dw-i3c-master.
+
+config SVC_I3C_MASTER
+   tristate "Silvaco I3C Dual-Role Master driver"
+   depends on I3C
+   depends on HAS_IOMEM
+   depends on !(ALPHA || PARISC)
+   help
+ Support for Silvaco I3C Dual-Role Master Controller.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index 7eea9e086144..69e5f5479df9 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_CDNS_I3C_MASTER)  += i3c-master-cdns.o
 obj-$(CONFIG_DW_I3C_MASTER)+= dw-i3c-master.o
+obj-$(CONFIG_SVC_I3C_MASTER)   += svc-i3c-master.o
diff --git a/drivers/i3c/master/svc-i3c-master.c 
b/drivers/i3c/master/svc-i3c-master.c
new file mode 100644
index ..d75bf3c49165
--- /dev/null
+++ b/drivers/i3c/master/svc-i3c-master.c
@@ -0,0 +1,1355 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Silvaco dual-role I3C master driver
+ *
+ * Copyright (C) 2020 Silvaco
+ * Author: Miquel RAYNAL 
+ * Based on a work from: Conor Culhane 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Master Mode Registers */
+#define SVC_I3C_MCONFIG  0x000
+#define   SVC_I3C_MCONFIG_MASTER_EN BIT(0)
+#define   SVC_I3C_MCONFIG_DISTO(x) FIELD_PREP(BIT(3), (x))
+#define   SVC_I3C_MCONFIG_HKEEP(x) FIELD_PREP(GENMASK(5, 4), (x))
+#define   SVC_I3C_MCONFIG_ODSTOP(x) FIELD_PREP(BIT(6), (x))
+#define   SVC_I3C_MCONFIG_PPBAUD(x) FIELD_PREP(GENMASK(11, 8), (x))
+#define   SVC_I3C_MCONFIG_PPLOW(x) FIELD_PREP(GENMASK(15, 12), (x))
+#define   SVC_I3C_MCONFIG_ODBAUD(x) FIELD_PREP(GENMASK(23, 16), (x))
+#define   SVC_I3C_MCONFIG_ODHPP(x) FIELD_PREP(BIT(24), (x))
+#define   SVC_I3C_MCONFIG_SKEW(x) FIELD_PREP(GENMASK(27, 25), (x))
+#define   SVC_I3C_MCONFIG_I2CBAUD(x) FIELD_PREP(GENMASK(31, 28), (x))
+
+#define SVC_I3C_MCTRL0x084
+#define   SVC_I3C_MCTRL_REQUEST_START_ADDR1
+#define   SVC_I3C_MCTRL_REQUEST_STOP  2
+#define   SVC_I3C_MCTRL_REQUEST_IBI_ACKNACK   3
+#define   SVC_I3C_MCTRL_REQUEST_PROC_DAA  4
+#define   SVC_I3C_MCTRL_REQUEST_AUTO_IBI  7
+#define   SVC_I3C_MCTRL_TYPE_I3C 0
+#define   SVC_I3C_MCTRL_TYPE_I2C BIT(4)
+#define   SVC_I3C_MCTRL_IBIRESP_ACK_WITHOUT_BYTE 0
+#define   SVC_I3C_MCTRL_IBIRESP_ACK_WITH_BYTE BIT(7)
+#define   SVC_I3C_MCTRL_IBIRESP_NACK BIT(6)
+#define   SVC_I3C_MCTRL_IBIRESP_MANUAL GENMASK(7, 6)
+#define   SVC_I3C_MCTRL_DIR(x) FIELD_PREP(BIT(8), (x))
+#define   SVC_I3C_MCTRL_DIR_WRITE 0
+#define   SVC_I3C_MCTRL_DIR_READ 1
+#define   SVC_I3C_MCTRL_ADDR(x) FIELD_PREP(GENMASK(15, 9), (x))
+#define   SVC_I3C_MCTRL_RDTERM(x) FIELD_PREP(GENMASK(23, 16), (x))
+
+#define SVC_I3C_MSTATUS  0x088
+#define   SVC_I3C_MSTATUS_STATE(x) FIELD_GET(GENMASK(2, 0), (x))
+#define   SVC_I3C_MSTATUS_STATE_DAA(x) (SVC_I3C_MSTATUS_STATE(x) == 5)
+#define   SVC_I3C_MSTATUS_STATE_IDLE(x) (SVC_I3C_MSTATUS_STATE(x) == 0)
+#define   SVC_I3C_MSTATUS_BETWEEN(x) FIELD_GET(BIT(4), (x))
+#define   SVC_I3C_MSTATUS_NACKED(x) FIELD_GET(BIT(5), (x))
+#define   SVC_I3C_MSTATUS_IBITYPE(x) FIELD_GET(GENMASK(7, 6), (x))
+#define   SVC_I3C_MSTATUS_IBITYPE_IBI 1
+#define   SVC_I3C_MSTATUS_IBITYPE_MASTER_REQUEST 2
+#define   SVC_I3C_MSTATUS_IBITYPE_HOT_JOIN 3
+#define   SVC_I3C_MSTATUS_MCTRLDONE(x) FIELD_GET(BIT(9), (x))
+#define   SVC_I3C_MSTATUS_COMPLETE(x) FIELD_GET(BIT(10), (x))
+#define   SVC_I3C_MSTATUS_ERRWARN(x) FIELD_GET(BIT(15), (x))
+#define   SVC_I3C_MSTATUS_IBIADDR(x) FIELD_GET(GENMASK(30, 24), (x))
+
+#define SVC_I3C_IBIRULES 0x08C
+#define SVC_I3C_MINTSET  0x090
+#define SVC_I3C_MINTCLR  0x094
+#define SVC_I3C_MINTMASKED   0x098
+#define   SVC_I3C_MINT_SLVSTART BIT(8)
+#define   SVC_I3C_MINT_MCTRLDONE BIT(9)
+#define   SVC_I3C_MINT_RXPEND BIT(11)
+#define   SVC_I3C_MINT_TXNOTFULL BIT(12)
+#define   SVC_I3C_MINT_IBIWON BIT(13)
+
+#define SVC_I3C_MERRWARN 0x09C
+#define SVC_I3C_MDMACTRL 0x0A0
+#define SVC_I3C_MDATACTRL0x0AC
+#define   SVC_I3C_MDATACTRL_FLUSHTB BIT(0)
+#define   SVC_I3C_MDATACTRL_FLUSHRB BIT(1)
+#define   SVC_I3C_MDATACTRL_UNLOCK_TRIG BIT(3)
+

[PATCH 1/4] perf-probe: Avoid setting probes on same address on same event

[Masami Hiramatsu]

There is a case that the several same-name symbols points
same address. In that case, perf probe returns an error.

E.g.

  perf probe -x /lib64/libc-2.30.so -v -a "memcpy arg1=%di"
  probe-definition(0): memcpy arg1=%di
  symbol:memcpy file:(null) line:0 offset:0 return:0 lazy:(null)
  parsing arg: arg1=%di into name:arg1 %di
  1 arguments
  symbol:setjmp file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:longjmp file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:longjmp_target file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:lll_lock_wait_private file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_mallopt_arena_max file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_mallopt_arena_test file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_tunable_tcache_max_bytes file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_tunable_tcache_count file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_tunable_tcache_unsorted_limit file:(null) line:0 offset:0 
return:0 lazy:(null)
  symbol:memory_mallopt_trim_threshold file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_mallopt_top_pad file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_mallopt_mmap_threshold file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_mallopt_mmap_max file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_mallopt_perturb file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_mallopt_mxfast file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_heap_new file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_arena_reuse_free_list file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_arena_reuse file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_arena_reuse_wait file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_arena_new file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_arena_retry file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_sbrk_less file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_heap_free file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_heap_less file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_tcache_double_free file:(null) line:0 offset:0 return:0 
lazy:(null)
  symbol:memory_heap_more file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_sbrk_more file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_malloc_retry file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_memalign_retry file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_mallopt_free_dyn_thresholds file:(null) line:0 offset:0 
return:0 lazy:(null)
  symbol:memory_realloc_retry file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_calloc_retry file:(null) line:0 offset:0 return:0 lazy:(null)
  symbol:memory_mallopt file:(null) line:0 offset:0 return:0 lazy:(null)
  Open Debuginfo file: /usr/lib/debug/usr/lib64/libc-2.30.so.debug
  Try to find probe point from debuginfo.
  Opening /sys/kernel/debug/tracing//README write=0
  Failed to find the location of the '%di' variable at this address.
   Perhaps it has been optimized out.
   Use -V with the --range option to show '%di' location range.
  An error occurred in debuginfo analysis (-2).
  Trying to use symbols.
  Opening /sys/kernel/debug/tracing//uprobe_events write=1
  Writing event: p:probe_libc/memcpy /usr/lib64/libc-2.30.so:0x914c0 arg1=%di
  Writing event: p:probe_libc/memcpy /usr/lib64/libc-2.30.so:0x914c0 arg1=%di
  Failed to write event: File exists
Error: Failed to add events. Reason: File exists (Code: -17)

You can see the perf tried to write completely same probe definition
twice, which caused an error.

To fix this issue, check the symbol list and drop duplicated
symbols (which has same symbol name and address) from it.

With this patch;

  # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di"
  Failed to find the location of the '%di' variable at this address.
   Perhaps it has been optimized out.
   Use -V with the --range option to show '%di' location range.
  Added new events:
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)

  You can now use it in all perf tools, such as:

perf record -e probe_libc:memcpy -aR sleep 1


Reported-by: Andi Kleen 
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index df713a5d1e26..1e95a336862c 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2968,6 +2968,15 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
for (j = 0; j < num_matched_functions; j++) {
sym = syms[j];
 
+   /* Th

[PATCH 0/4] perf-probe: Fix GNU IFUNC probe issue etc.

[Masami Hiramatsu]

Hi,

Here are patches to fix some issues of probing on GNU IFUNC, duplicated
symbols, and memory leak, which were reported by Andi.

Andi reported that some issues on probing memcpy function in glibc,
which was related to GNU IFUNC (indirect function). As I described
in the patch [4/4], it is hard to support probing on the functions
which are selected by GNU indirect function because those are chosen
at runtime. I think we need a user-mode helper in uprobes to find which
one is chosen at runtime. (Oleg, Srikar, would you have any idea?)

While cleaning up the patches, I also found a memory leak problem
so fixed it ([3/4]).

Thank you,

---

Masami Hiramatsu (4):
  perf-probe: Avoid setting probes on same address on same event
  perf-probe: Fix wrong variable warning when the probe point is not found
  perf-probe: Fix memory leakage when the probe point is not found
  perf-probe: Warn if the target function is GNU Indirect function


 tools/perf/util/probe-event.c  |   14 ++
 tools/perf/util/probe-finder.c |5 -
 2 files changed, 18 insertions(+), 1 deletion(-)

--
Masami Hiramatsu (Linaro) 

[PATCH 2/4] perf-probe: Fix wrong variable warning when the probe point is not found

[Masami Hiramatsu]

Fix a wrong "variable not found" warning when the probe point is
not found in the debuginfo.
Since the debuginfo__find_probes() can return 0 even if it does not
find given probe point in the debuginfo, fill_empty_trace_arg() can
be called with tf.ntevs == 0 and it can warn a wrong warning.
To fix this, reject ntevs == 0 in fill_empty_trace_arg().

E.g. without this patch;

  # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di"
  Failed to find the location of the '%di' variable at this address.
   Perhaps it has been optimized out.
   Use -V with the --range option to show '%di' location range.
  Added new events:
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)

  You can now use it in all perf tools, such as:

perf record -e probe_libc:memcpy -aR sleep 1

With this;

  # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di"
  Added new events:
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)
probe_libc:memcpy(on memcpy in /usr/lib64/libc-2.30.so with arg1=%di)

  You can now use it in all perf tools, such as:

perf record -e probe_libc:memcpy -aR sleep 1


Reported-by: Andi Kleen 
Fixes: cb4027308570 ("perf probe: Trace a magic number if variable is not 
found")
Cc: sta...@vger.kernel.org
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-finder.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 55924255c535..9963e4e8ea20 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1408,6 +1408,9 @@ static int fill_empty_trace_arg(struct perf_probe_event 
*pev,
char *type;
int i, j, ret;
 
+   if (!ntevs)
+   return -ENOENT;
+
for (i = 0; i < pev->nargs; i++) {
type = NULL;
for (j = 0; j < ntevs; j++) {

[PATCH 4/4] perf-probe: Warn if the target function is GNU Indirect function

[Masami Hiramatsu]

Warn if the probe target function is GNU indirect function (GNU_IFUNC)
because it may not what the user want to probe.

The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC )
is the dynamic solved symbol at runtime. IFUNC function is a selector
which is invoked from the elf loader, but the symbol address of the
function which will be modified by the IFUNC is same as the IFUNC in
the symbol table. This can confuse users who is trying to probe on
such functions.

For example, the memcpy is one of IFUNC.

# perf probe -x /lib64/libc-2.30.so -a memcpy
# perf probe -l
  probe_libc:memcpy(on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in 
/usr/lib64/libc-2.30.so)

the probe is put on a IFUNC.

# perf record -e probe_libc:memcpy --call-graph dwarf -aR ./perf
# perf script
perf  1742 [000] 26201.715632: probe_libc:memcpy: (7fdaa53824c0)
7fdaa53824c0 __new_memcpy_ifunc+0x0 (inlined)
7fdaa5d4a980 elf_machine_rela+0x6c0 (inlined)
7fdaa5d4a980 elf_dynamic_do_Rela+0x6c0 (inlined)
7fdaa5d4a980 _dl_relocate_object+0x6c0 (/usr/lib64/ld-2.30.so)
7fdaa5d42155 dl_main+0x1cc5 (/usr/lib64/ld-2.30.so)
7fdaa5d5831a _dl_sysdep_start+0x54a (/usr/lib64/ld-2.30.so)
7fdaa5d3ffeb _dl_start_final+0x25b (inlined)
7fdaa5d3ffeb _dl_start+0x25b (/usr/lib64/ld-2.30.so)
7fdaa5d3f117 .annobin_rtld.c+0x7 (inlined)
...

And the event is invoked from the elf loader instead of the target
program's main code.


Moreover, at this moment, we can not probe on the function which will
be selected by the IFUNC, because it is determined at runtime. But
uprobe will be prepared before running the target binary.

Thus, I decided to warn user when the perf probe detects the probe point
is on the GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to
debug the IFUNC function, they can ignore this warning.


Reported-by: Andi Kleen 
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 1e95a336862c..671176d39569 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -379,6 +379,11 @@ static int find_alternative_probe_point(struct debuginfo 
*dinfo,
address = sym->start;
else
address = map->unmap_ip(map, sym->start) - map->reloc;
+   if (sym->type == STT_GNU_IFUNC) {
+   pr_warning("Warning: The probe address (0x%lx) is in a 
GNU indirect function.\n"
+   "This may not work as you expected unless you 
intend to probe the indirect function.\n",
+   (unsigned long)address);
+   }
break;
}
if (!address) {

[PATCH 3/4] perf-probe: Fix memory leakage when the probe point is not found

[Masami Hiramatsu]

Fix the memory leakage in debuginfo__find_trace_events() when the probe
point is not found in the debuginfo. If there is no probe point found in
the debuginfo, debuginfo__find_probes() will NOT return -ENOENT, but 0.
Thus the caller of debuginfo__find_probes() must check the tf.ntevs and
release the allocated memory for the array of struct probe_trace_event.

The current code releases the memory only if the debuginfo__find_probes()
hits an error but not checks tf.ntevs. In the result, the memory allocated
on *tevs are not released if tf.ntevs == 0.

This fixes the memory leakage by checking tf.ntevs == 0 in addition to
ret < 0.

Fixes: ff741783506c ("perf probe: Introduce debuginfo to encapsulate dwarf 
information")
Cc: sta...@vger.kernel.org
Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-finder.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 9963e4e8ea20..659024342e9a 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1467,7 +1467,7 @@ int debuginfo__find_trace_events(struct debuginfo *dbg,
if (ret >= 0 && tf.pf.skip_empty_arg)
ret = fill_empty_trace_arg(pev, tf.tevs, tf.ntevs);
 
-   if (ret < 0) {
+   if (ret < 0 || tf.ntevs == 0) {
for (i = 0; i < tf.ntevs; i++)
clear_probe_trace_event(&tf.tevs[i]);
zfree(tevs);

[PATCH] service_layers: osunixmap: Remove unnecessary brackets in acpi_os_map_memory()

[Xu Wang]

Remove extra brackets.

Signed-off-by: Xu Wang 
---
 tools/power/acpi/os_specific/service_layers/osunixmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/power/acpi/os_specific/service_layers/osunixmap.c 
b/tools/power/acpi/os_specific/service_layers/osunixmap.c
index c565546e85bc..52f3e70b5c81 100644
--- a/tools/power/acpi/os_specific/service_layers/osunixmap.c
+++ b/tools/power/acpi/os_specific/service_layers/osunixmap.c
@@ -70,7 +70,7 @@ void *acpi_os_map_memory(acpi_physical_address where, 
acpi_size length)
fd = open(SYSTEM_MEMORY, O_RDONLY | O_BINARY);
if (fd < 0) {
fprintf(stderr, "Cannot open %s\n", SYSTEM_MEMORY);
-   return (NULL);
+   return NULL;
}
 
/* Align the offset to use mmap */
@@ -85,7 +85,7 @@ void *acpi_os_map_memory(acpi_physical_address where, 
acpi_size length)
if (mapped_memory == MAP_FAILED) {
fprintf(stderr, "Cannot map %s\n", SYSTEM_MEMORY);
close(fd);
-   return (NULL);
+   return NULL;
}
 
close(fd);
-- 
2.17.1

[RFC PATCH] usb: dwc3: fix maximum_speed check for usb2.0-only core

[Chunfeng Yun]

The maximum_speed will be USB_SPEED_SUPER_PLUS, but the
maximum_speed check for usb2.0-only core doesn't consider it,
so fix it, and move the ckeck into dwc3_check_params().

Signed-off-by: Chunfeng Yun 
---
Note:

When I look at the code, find that this may be a problem, but no
platform to test it.
---
 drivers/usb/dwc3/core.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25c686a7..ffd5ab3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -930,13 +930,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
 */
dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
 
-   /* Handle USB2.0-only core configuration */
-   if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
-   DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
-   if (dwc->maximum_speed == USB_SPEED_SUPER)
-   dwc->maximum_speed = USB_SPEED_HIGH;
-   }
-
ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
@@ -1426,6 +1419,13 @@ static void dwc3_check_params(struct dwc3 *dwc)
 
break;
}
+
+   /* Handle USB2.0-only core configuration */
+   if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
+   DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
+   if (dwc->maximum_speed > USB_SPEED_HIGH)
+   dwc->maximum_speed = USB_SPEED_HIGH;
+   }
 }
 
 static int dwc3_probe(struct platform_device *pdev)
-- 
1.9.1

Re: [PATCH] tty/sysrq: Add alternative SysRq key

[Andrzej Pietrasiewicz]

Hi Dmitry,

W dniu 09.07.2020 o 07:05, Dmitry Torokhov pisze:

Hi Andrzej,

On Fri, Jun 19, 2020 at 06:28:19PM +0200, Andrzej Pietrasiewicz wrote:

There exist machines which don't have SysRq key at all, e.g. chromebooks.

This patch allows configuring an alternative key to act as SysRq. Devices
which declare KEY_SYSRQ in their 'keybit' bitmap continue using KEY_SYSRQ,
but other devices use the alternative SysRq key instead, by default F10.
Which key is actually used can be modified with sysrq's module parameter.


I guess you will be removing KEY_SYSRQ form all Chrome OS internal AT
keyboards and external USB keyboard with Chrome OS layouts as well? Via
udev keymap? I suppose this could work... Or have a per device setting
as we allocate a separate handle for each input device attached to the
SysRq handler.



To me it makes most sense to have the decision taken per each input
device - if it is capable of providing KEY_SYSRQ, then it is used,
otherwise the alternative is taken.

The question is how to provide this information at ->connect() time.

Ideally chromebook's keyboard should be modelled in such a way that
it reflects reality. And the reality is that chromebooks probably
declare they use full AT PS/2 keyboard even though they have less keys.

It is unclear to me whether it makes sense to struggle to better
reflect actual keys repertoire at the kernel level. If udev's keymap
can be used, that should do. Now, are we able to guarantee that the
modification of the keyboard layout happens before the sysrq handler
is matched against the keyboard?

Andrzej



Signed-off-by: Andrzej Pietrasiewicz 
---
  drivers/tty/sysrq.c | 28 +---
  1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 0dc3878794fd..e1d271c84746 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -604,6 +604,7 @@ EXPORT_SYMBOL(handle_sysrq);
  
  #ifdef CONFIG_INPUT

  static int sysrq_reset_downtime_ms;
+static unsigned short alternative_sysrq_key = KEY_F10;
  
  /* Simple translation table for the SysRq keys */

  static const unsigned char sysrq_xlate[KEY_CNT] =
@@ -621,6 +622,7 @@ struct sysrq_state {
unsigned long key_down[BITS_TO_LONGS(KEY_CNT)];
unsigned int alt;
unsigned int alt_use;
+   unsigned short sysrq_key;
bool active;
bool need_reinject;
bool reinjecting;
@@ -770,10 +772,10 @@ static void sysrq_reinject_alt_sysrq(struct work_struct 
*work)
  
  		/* Simulate press and release of Alt + SysRq */

input_inject_event(handle, EV_KEY, alt_code, 1);
-   input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
+   input_inject_event(handle, EV_KEY, sysrq->sysrq_key, 1);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
  
-		input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);

+   input_inject_event(handle, EV_KEY, sysrq->sysrq_key, 0);
input_inject_event(handle, EV_KEY, alt_code, 0);
input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
  
@@ -805,6 +807,7 @@ static bool sysrq_handle_keypress(struct sysrq_state *sysrq,

}
break;
  
+key_sysrq:

case KEY_SYSRQ:
if (value == 1 && sysrq->alt != KEY_RESERVED) {
sysrq->active = true;
@@ -825,11 +828,15 @@ static bool sysrq_handle_keypress(struct sysrq_state 
*sysrq,
 * triggering print screen function.
 */
if (sysrq->active)
-   clear_bit(KEY_SYSRQ, sysrq->handle.dev->key);
+   clear_bit(sysrq->sysrq_key, sysrq->handle.dev->key);
  
  		break;
  
  	default:

+   /* handle non-default sysrq key */
+   if (code == sysrq->sysrq_key)
+   goto key_sysrq;
+
if (sysrq->active && value && value != 2) {
sysrq->need_reinject = false;
__handle_sysrq(sysrq_xlate[code], true);
@@ -924,6 +931,14 @@ static int sysrq_connect(struct input_handler *handler,
sysrq->handle.private = sysrq;
timer_setup(&sysrq->keyreset_timer, sysrq_do_reset, 0);
  
+	if (test_bit(KEY_SYSRQ, dev->keybit)) {

+   sysrq->sysrq_key = KEY_SYSRQ;
+   pr_info("%s: using default sysrq key [%x]\n", dev->name, 
KEY_SYSRQ);
+   } else {
+   sysrq->sysrq_key = alternative_sysrq_key;
+   pr_info("%s: Using alternative sysrq key: [%x]\n", dev->name, 
sysrq->sysrq_key);
+   }


This is way too noisy IMO.


+
error = input_register_handle(&sysrq->handle);
if (error) {
pr_err("Failed to register input sysrq handler, error %d\n",
@@ -1032,6 +1047,13 @@ module_param_array_named(reset_seq, sysrq_reset_seq, 
sysrq_reset_seq,
  
  module_param_named(sysrq_downtime_ms, sysrq_reset_downtime_ms, int, 0644);
  
+module_param(alternative_sysrq_

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

[Zong Li]

On Thu, Jul 9, 2020 at 1:05 PM Palmer Dabbelt  wrote:
>
> On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:
> > This is a preparatory patch for relocatable kernel.
> >
> > The kernel used to be linked at PAGE_OFFSET address and used to be loaded
> > physically at the beginning of the main memory. Therefore, we could use
> > the linear mapping for the kernel mapping.
> >
> > But the relocated kernel base address will be different from PAGE_OFFSET
> > and since in the linear mapping, two different virtual addresses cannot
> > point to the same physical address, the kernel mapping needs to lie outside
> > the linear mapping.
>
> I know it's been a while, but I keep opening this up to review it and just
> can't get over how ugly it is to put the kernel's linear map in the vmalloc
> region.
>
> I guess I don't understand why this is necessary at all.  Specifically: why
> can't we just relocate the kernel within the linear map?  That would let the
> bootloader put the kernel wherever it wants, modulo the physical memory size 
> we
> support.  We'd need to handle the regions that are coupled to the kernel's
> execution address, but we could just put them in an explicit memory region
> which is what we should probably be doing anyway.

The original implementation of relocation doesn't move the kernel's linear map
to the vmalloc region, and I also give the KASLR RFC patch [1] based on that.
In original, we relocate the kernel in the linear map region, we would
calculate a
random value first as the offset, then we move the kernel image to the
new target
address which is obtained by adding this offset to it's VA and PA.
It's enough for
randomizing the kernel, but it seems to me if we want to decouple the kernel's
linear mapping, the physical mapping of RAM and virtual mapping of RAM,
it might be good to move the kernel's mapping out from the linear region.
Even so, it is still an intrusive change. As far as I know, only arm64
does something
like that.

[1]  https://patchwork.kernel.org/project/linux-riscv/list/?series=260615



>
> > In addition, because modules and BPF must be close to the kernel (inside
> > +-2GB window), the kernel is placed at the end of the vmalloc zone minus
> > 2GB, which leaves room for modules and BPF. The kernel could not be
> > placed at the beginning of the vmalloc zone since other vmalloc
> > allocations from the kernel could get all the +-2GB window around the
> > kernel which would prevent new modules and BPF programs to be loaded.
>
> Well, that's not enough to make sure this doesn't happen -- it's just enough 
> to
> make sure it doesn't happen very quickily.  That's the same boat we're already
> in, though, so it's not like it's worse.
>
> > Signed-off-by: Alexandre Ghiti 
> > Reviewed-by: Zong Li 
> > ---
> >  arch/riscv/boot/loader.lds.S |  3 +-
> >  arch/riscv/include/asm/page.h| 10 +-
> >  arch/riscv/include/asm/pgtable.h | 38 ++---
> >  arch/riscv/kernel/head.S |  3 +-
> >  arch/riscv/kernel/module.c   |  4 +--
> >  arch/riscv/kernel/vmlinux.lds.S  |  3 +-
> >  arch/riscv/mm/init.c | 58 +---
> >  arch/riscv/mm/physaddr.c |  2 +-
> >  8 files changed, 88 insertions(+), 33 deletions(-)
> >
> > diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
> > index 47a5003c2e28..62d94696a19c 100644
> > --- a/arch/riscv/boot/loader.lds.S
> > +++ b/arch/riscv/boot/loader.lds.S
> > @@ -1,13 +1,14 @@
> >  /* SPDX-License-Identifier: GPL-2.0 */
> >
> >  #include 
> > +#include 
> >
> >  OUTPUT_ARCH(riscv)
> >  ENTRY(_start)
> >
> >  SECTIONS
> >  {
> > - . = PAGE_OFFSET;
> > + . = KERNEL_LINK_ADDR;
> >
> >   .payload : {
> >   *(.payload)
> > diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> > index 2d50f76efe48..48bb09b6a9b7 100644
> > --- a/arch/riscv/include/asm/page.h
> > +++ b/arch/riscv/include/asm/page.h
> > @@ -90,18 +90,26 @@ typedef struct page *pgtable_t;
> >
> >  #ifdef CONFIG_MMU
> >  extern unsigned long va_pa_offset;
> > +extern unsigned long va_kernel_pa_offset;
> >  extern unsigned long pfn_base;
> >  #define ARCH_PFN_OFFSET  (pfn_base)
> >  #else
> >  #define va_pa_offset 0
> > +#define va_kernel_pa_offset  0
> >  #define ARCH_PFN_OFFSET  (PAGE_OFFSET >> PAGE_SHIFT)
> >  #endif /* CONFIG_MMU */
> >
> >  extern unsigned long max_low_pfn;
> >  extern unsigned long min_low_pfn;
> > +extern unsigned long kernel_virt_addr;
> >
> >  #define __pa_to_va_nodebug(x)((void *)((unsigned long) (x) + 
> > va_pa_offset))
> > -#define __va_to_pa_nodebug(x)((unsigned long)(x) - va_pa_offset)
> > +#define linear_mapping_va_to_pa(x)   ((unsigned long)(x) - va_pa_offset)
> > +#define kernel_mapping_va_to_pa(x)   \
> > + ((unsigned long)(x) - va_kernel_pa_offset)
> > +#define __va_to_pa_nodebug(x)\
> > + (((x) >= PAGE_OFFSET) ? \
> > + li

[RESEND PATCH 2/2] fpga: dfl: fix bug in port reset handshake

[Xu Yilun]

From: Matthew Gerlach 

When putting the port in reset, driver must wait for the soft reset
acknowledgment bit instead of the soft reset bit.

Fixes: 47c1b19c160f (fpga: dfl: afu: add port ops support)
Signed-off-by: Matthew Gerlach 
Signed-off-by: Xu Yilun 
Acked-by: Wu Hao 
---
 drivers/fpga/dfl-afu-main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/dfl-afu-main.c b/drivers/fpga/dfl-afu-main.c
index 7c84fee..753cda4 100644
--- a/drivers/fpga/dfl-afu-main.c
+++ b/drivers/fpga/dfl-afu-main.c
@@ -83,7 +83,8 @@ int __afu_port_disable(struct platform_device *pdev)
 * on this port and minimum soft reset pulse width has elapsed.
 * Driver polls port_soft_reset_ack to determine if reset done by HW.
 */
-   if (readq_poll_timeout(base + PORT_HDR_CTRL, v, v & PORT_CTRL_SFTRST,
+   if (readq_poll_timeout(base + PORT_HDR_CTRL, v,
+  v & PORT_CTRL_SFTRST_ACK,
   RST_POLL_INVL, RST_POLL_TIMEOUT)) {
dev_err(&pdev->dev, "timeout, fail to reset device\n");
return -ETIMEDOUT;
-- 
2.7.4

[RESEND PATCH 1/2] fpga: dfl: pci: reduce the scope of variable 'ret'

[Xu Yilun]

This is to fix lkp cppcheck warnings:

 drivers/fpga/dfl-pci.c:230:6: warning: The scope of the variable 'ret' can be 
reduced. [variableScope]
int ret = 0;
^

 drivers/fpga/dfl-pci.c:230:10: warning: Variable 'ret' is assigned a value 
that is never used. [unreadVariable]
int ret = 0;
^

Fixes: 3c2760b78f90 ("fpga: dfl: pci: fix return value of 
cci_pci_sriov_configure")
Reported-by: kbuild test robot 
Signed-off-by: Xu Yilun 
Acked-by: Wu Hao 
---
 drivers/fpga/dfl-pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index 4a14a24..73b5153 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -285,7 +285,6 @@ static int cci_pci_sriov_configure(struct pci_dev *pcidev, 
int num_vfs)
 {
struct cci_drvdata *drvdata = pci_get_drvdata(pcidev);
struct dfl_fpga_cdev *cdev = drvdata->cdev;
-   int ret = 0;
 
if (!num_vfs) {
/*
@@ -297,6 +296,8 @@ static int cci_pci_sriov_configure(struct pci_dev *pcidev, 
int num_vfs)
dfl_fpga_cdev_config_ports_pf(cdev);
 
} else {
+   int ret;
+
/*
 * before enable SRIOV, put released ports into VF access mode
 * first of all.
-- 
2.7.4

[RESEND PATCH 0/2] Bug fixes for FPGA DFL

[Xu Yilun]

Resend these 2 fix patches since the to-be-fixed patches have been
merged to mainline.

Matthew Gerlach (1):
  fpga: dfl: fix bug in port reset handshake

Xu Yilun (1):
  fpga: dfl: pci: reduce the scope of variable 'ret'

 drivers/fpga/dfl-afu-main.c | 3 ++-
 drivers/fpga/dfl-pci.c  | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] firmware: arm_scmi: Keep the discrete clock rates sorted

[Sudeep Holla]

Instead of relying on the firmware to keep the clock rates sorted, let
us sort the list. This is not essential for clock layer but it helps
to find the min and max rates easily from the list.

Link: https://lore.kernel.org/r/20200708110725.18017-1-sudeep.ho...@arm.com
Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock 
protocol")
Reported-by: Dien Pham 
Signed-off-by: Sudeep Holla 
---
 drivers/firmware/arm_scmi/clock.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)


Hi Dien-san,

If you could review/test these patches, I can queue them ASAP.
I am planning to send the PR for ARM SoC later this week, so I need
your tested-by.

v1[1]->v2:
- Fixed the warning, sent the wrong version earlier

Regards,
Sudeep

[1] https://lore.kernel.org/r/20200708110725.18017-1-sudeep.ho...@arm.com

diff --git a/drivers/firmware/arm_scmi/clock.c 
b/drivers/firmware/arm_scmi/clock.c
index 4c2227662b26..c90f23a812f5 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -5,6 +5,8 @@
  * Copyright (C) 2018 ARM Ltd.
  */

+#include 
+
 #include "common.h"

 enum scmi_clock_protocol_cmd {
@@ -121,6 +123,13 @@ static int scmi_clock_attributes_get(const struct 
scmi_handle *handle,
return ret;
 }

+static int rate_cmp_func(const void *_r1, const void *_r2)
+{
+   const u64 *r1 = _r1, *r2 = _r2;
+
+   return r1 - r2;
+}
+
 static int
 scmi_clock_describe_rates_get(const struct scmi_handle *handle, u32 clk_id,
  struct scmi_clock_info *clk)
@@ -184,8 +193,10 @@ scmi_clock_describe_rates_get(const struct scmi_handle 
*handle, u32 clk_id,
 */
} while (num_returned && num_remaining);

-   if (rate_discrete)
+   if (rate_discrete) {
clk->list.num_rates = tot_rate_cnt;
+   sort(rate, tot_rate_cnt, sizeof(*rate), rate_cmp_func, NULL);
+   }

clk->rate_discrete = rate_discrete;

--
2.17.1

[PATCH v2 2/2] clk: scmi: Fix min and max rate when registering clocks with discrete rates

[Sudeep Holla]

Currently we are not initializing the scmi clock with discrete rates
correctly. We fetch the min_rate and max_rate value only for clocks with
ranges and ignore the ones with discrete rates. This will lead to wrong
initialization of rate range when clock supports discrete rate.

Fix this by using the first and the last rate in the sorted list of the
discrete clock rates while registering the clock.

Link: https://lore.kernel.org/r/20200708110725.18017-2-sudeep.ho...@arm.com
Fixes: 6d6a1d82eaef7 ("clk: add support for clocks provided by SCMI")
Reported-by: Dien Pham 
Signed-off-by: Sudeep Holla 
---
 drivers/clk/clk-scmi.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

Hi Stephen,

If you are fine, I can take this via ARM SoC along with the change in
firmware driver. However it is also fine if you want to merge this
independently as there is no strict dependency. Let me know either way.

v1[1]->v2:
- Fixed the missing ; which was sent by mistake.

Regards,
Sudeep

[1] https://lore.kernel.org/r/20200708110725.18017-2-sudeep.ho...@arm.com

diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index c491f5de0f3f..c754dfbb73fd 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -103,6 +103,8 @@ static const struct clk_ops scmi_clk_ops = {
 static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk)
 {
int ret;
+   unsigned long min_rate, max_rate;
+
struct clk_init_data init = {
.flags = CLK_GET_RATE_NOCACHE,
.num_parents = 0,
@@ -112,9 +114,23 @@ static int scmi_clk_ops_init(struct device *dev, struct 
scmi_clk *sclk)
 
sclk->hw.init = &init;
ret = devm_clk_hw_register(dev, &sclk->hw);
-   if (!ret)
-   clk_hw_set_rate_range(&sclk->hw, sclk->info->range.min_rate,
- sclk->info->range.max_rate);
+   if (ret)
+   return ret;
+
+   if (sclk->info->rate_discrete) {
+   int num_rates = sclk->info->list.num_rates;
+
+   if (num_rates <= 0)
+   return -EINVAL;
+
+   min_rate = sclk->info->list.rates[0];
+   max_rate = sclk->info->list.rates[num_rates - 1];
+   } else {
+   min_rate = sclk->info->range.min_rate;
+   max_rate = sclk->info->range.max_rate;
+   }
+
+   clk_hw_set_rate_range(&sclk->hw, min_rate, max_rate);
return ret;
 }
 
-- 
2.17.1

Re: [PATCH 1/1] MAINTAINERS: add Hridya and myself into Android driver maintainers list

[Greg KH]

On Wed, Jul 08, 2020 at 04:12:53PM -0700, Suren Baghdasaryan wrote:
> Add new maintainers for ashmem driver to handle related issues.
> 
> Signed-off-by: Suren Baghdasaryan 

Can I get an ack/reviewed-by/something by the existing maintainers to
verify this?  :)

And I thought we were deleting ashmem soon?

thanks,

greg k-h

Re: [PATCH 2/2] doc, mm: clarify /proc//oom_score value range

[Michal Hocko]

On Thu 09-07-20 15:41:11, Yafang Shao wrote:
> On Thu, Jul 9, 2020 at 2:26 PM Michal Hocko  wrote:
> >
> > From: Michal Hocko 
> >
> > The exported value includes oom_score_adj so the range is no [0, 1000]
> > as described in the previous section but rather [0, 2000]. Mention that
> > fact explicitly.
> >
> > Signed-off-by: Michal Hocko 
> > ---
> >  Documentation/filesystems/proc.rst | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/filesystems/proc.rst 
> > b/Documentation/filesystems/proc.rst
> > index 8e3b5dffcfa8..78a0dec323a3 100644
> > --- a/Documentation/filesystems/proc.rst
> > +++ b/Documentation/filesystems/proc.rst
> > @@ -1673,6 +1673,9 @@ requires CAP_SYS_RESOURCE.
> >  3.2 /proc//oom_score - Display current oom-killer score
> >  -
> >
> > +Please note that the exported value includes oom_score_adj so it is 
> > effectively
> > +in range [0,2000].
> > +
> 
> [0, 2000] may be not a proper range, see my reply in another thread.[1]
> As this value hasn't been documented before and nobody notices that, I
> think there might be no user really care about it before.
> So we should discuss the proper range if we really think the user will
> care about this value.

Even if we decide the range should change, I do not really assume this
will happen, it is good to have the existing behavior clarified.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] bfq: fix blkio cgroup leakage

[Dmitry Monakhov]

Paolo Valente  writes:

>> Il giorno 8 lug 2020, alle ore 19:48, Dmitry Monakhov  
>> ha scritto:
>> 
>> Paolo Valente  writes:
>> 
>>> Hi,
>>> sorry for the delay.  The commit you propose to drop fix the issues
>>> reported in [1].
>>> 
>>> Such a commit does introduce the leak that you report (thank you for
>>> spotting it).  Yet, according to the threads mentioned in [1],
>>> dropping that commit would take us back to those issues.
>>> 
>>> Maybe the solution is to fix the unbalance that you spotted?
>> I'm not quite shure that do I understand which bug was addressed for commit 
>> db37a34c563b.
>> AFAIU both bugs mentioned in original patchset was fixed by:
>> 478de3380 ("block, bfq: deschedule empty bfq_queues not referred by any 
>> proces")
>> f718b0932 ( block, bfq: do not plug I/O for bfq_queues with no proc refs)"
>> 
>> So I review commit db37a34c563b as independent one.
>> It introduces extra reference for bfq_groups via bfqg_and_blkg_get(),
>> but do we actually need it here?
>> 
>> #IF CONFIG_BFQ_GROUP_IOSCHED is enabled:
>> bfqd->root_group is holded by bfqd from bfq_init_queue()
>> other bfq_queue objects are owned by corresponding blkcg from bfq_pd_alloc()
>> So bfq_queue can not disappear under us.
>> 
>
> You are right, but incomplete.  No extra ref is needed for an entity
> that represents a bfq_queue.  And this consideration mistook me before
> I realized that that commit was needed.  The problem is that an entity
> may also represent a group of entities.  In that case no reference is
> taken through any bfq_queue.  The commit you want to remove takes this
> missing reference.
Sorry, It looks like I've mistyped sentance above, I ment to say bfq_group.
So here is my statement corrected:
 #IF CONFIG_BFQ_GROUP_IOSCHED is enabled:
 bfqd->root_group is holded by bfqd from bfq_init_queue()
 other *bfq_group* objects are owned by corresponding blkcg, reference get from 
bfq_pd_alloc()
 So *bfq_group* can not disappear under us.

So no extra reference is required for entity represents bfq_group. Commit is 
not required.
>
> Paolo
>
>> #IF CONFIG_BFQ_GROUP_IOSCHED is disabled:
>> we have only one  bfqd->root_group object which allocated from 
>> bfq_create_group_hierarch()
>> and bfqg_and_blkg_get() bfqg_and_blkg_put() are noop
>> 
>> Resume: in both cases extra reference is not required, so I continue to
>> insist that we should revert  commit db37a34c563b because it tries to
>> solve a non existing issue, but introduce the real one.
>> 
>> Please correct me if I'm wrong.
>>> 
>>> I'll check it ASAP, unless you do it before me.
>>> 
>>> Thanks,
>>> Paolo
>>> 
>>> [1] https://lkml.org/lkml/2020/1/31/94
>>> 
 Il giorno 2 lug 2020, alle ore 12:57, Dmitry Monakhov 
  ha scritto:
 
 commit db37a34c563b ("block, bfq: get a ref to a group when adding it to a 
 service tree")
 introduce leak forbfq_group and blkcg_gq objects because of get/put
 imbalance. See trace balow:
 -> blkg_alloc
  -> bfq_pq_alloc
-> bfqg_get (+1)
 ->bfq_activate_bfqq
 ->bfq_activate_requeue_entity
   -> __bfq_activate_entity
  ->bfq_get_entity
>> ->> ->bfqg_and_blkg_get (+1)  < : Note1
 ->bfq_del_bfqq_busy
 ->bfq_deactivate_entity+0x53/0xc0 [bfq]
   ->__bfq_deactivate_entity+0x1b8/0x210 [bfq]
 -> bfq_forget_entity(is_in_service = true)
 entity->on_st_or_in_serv = false   <=== :Note2
 if (is_in_service)
 return;  ==> do not touch reference
 -> blkcg_css_offline
 -> blkcg_destroy_blkgs
 -> blkg_destroy
  -> bfq_pd_offline
   -> __bfq_deactivate_entity
if (!entity->on_st_or_in_serv) /* true, because (Note2)
return false;
 -> bfq_pd_free
   -> bfqg_put() (-1, byt bfqg->ref == 2) because of (Note2)
 So bfq_group and blkcg_gq  will leak forever, see test-case below.
 If fact bfq_group objects reference counting are quite different
 from bfq_queue. bfq_groups object are referenced by blkcg_gq via
 blkg_policy_data pointer, so  neither nor blkg_get() neither bfqg_get
 required here.
 
 
 This patch drop commit db37a34c563b ("block, bfq: get a ref to a group 
 when adding it to a service tree")
 and add corresponding comment.
 
 ##TESTCASE_BEGIN:
 #!/bin/bash
 
 max_iters=${1:-100}
 #prep cgroup mounts
 mount -t tmpfs cgroup_root /sys/fs/cgroup
 mkdir /sys/fs/cgroup/blkio
 mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
 
 # Prepare blkdev
 grep blkio /proc/cgroups
 truncate -s 1M img
 losetup /dev/loop0 img
 echo bfq > /sys/block/loop0/queue/scheduler
 
 grep blkio /proc/cgroups
 for ((i=0;i>>> do
   mkdir -p /sys/fs/cgroup/blkio/a
   echo 0 > /sys/fs/cgroup/blkio/a/cgroup.procs
   dd if=/dev/loop0 bs=4k count=1 of=/dev/null iflag=direct 2> /dev/null
   echo 0 > /sys/fs/cgroup/blkio/cgroup.procs
   rmdir /sys/fs/cgroup/blkio/

RE: [PATCH 1/2] firmware: arm_scmi: Keep the discrete clock rates sorted

[Dien Pham]

Hi Sudeep,

I share my build warning and some in-line comment below:

  CC  drivers/firmware/arm_scmi/clock.o
drivers/firmware/arm_scmi/clock.c: In function 'rate_cmp_func':
drivers/firmware/arm_scmi/clock.c:127:12: warning: initialization discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  u64 *r1 = _r1, *r2 = _r2;
^~~
drivers/firmware/arm_scmi/clock.c:127:23: warning: initialization discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  u64 *r1 = _r1, *r2 = _r2;
   ^~~
  CC  arch/arm64/kernel/vdso.o
drivers/firmware/arm_scmi/clock.c: In function 'scmi_clock_protocol_init':
drivers/firmware/arm_scmi/clock.c:197:3: warning: 'rate' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   sort(rate, tot_rate_cnt, sizeof(*rate), rate_cmp_func, NULL);
   ^~~~

>-Original Message-
>From: Sudeep Holla  
>Sent: Wednesday, July 8, 2020 6:07 PM
>To: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; Stephen 
>Boyd 
>Cc: Sudeep Holla ; linux-kernel@vger.kernel.org; Michael 
>Turquette ; Dien Pham 
>Subject: [PATCH 1/2] firmware: arm_scmi: Keep the discrete clock rates sorted
>
>Instead of relying on the firmware to keep the clock rates sorted, let us sort 
>the list. This is not essential for clock layer but it helps to find the min 
>and max rates easily from the list.
>
>Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock 
>protocol")
>Reported-by: Dien Pham 
>Signed-off-by: Sudeep Holla 
>---
> drivers/firmware/arm_scmi/clock.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
>Hi Dien-san,
>
>If you could review/test these patches, I can queue them ASAP.
>I am planning to send the PR for ARM SoC later this week, so I need your 
>tested-by.

I applied the patch,
Although there are some build warnings, but the patch effect is ok.

>
>Regards,
>Sudeep
>
>diff --git a/drivers/firmware/arm_scmi/clock.c 
>b/drivers/firmware/arm_scmi/clock.c
>index 4c2227662b26..2dd119cdebf6 100644
>--- a/drivers/firmware/arm_scmi/clock.c
>+++ b/drivers/firmware/arm_scmi/clock.c
>@@ -5,6 +5,8 @@
>  * Copyright (C) 2018 ARM Ltd.
>  */
>
>+#include 
>+
> #include "common.h"
>
> enum scmi_clock_protocol_cmd {
>@@ -121,6 +123,13 @@ static int scmi_clock_attributes_get(const struct 
>scmi_handle *handle,
>   return ret;
> }
>
>+static int rate_cmp_func(const void *_r1, const void *_r2) {
>+  u64 *r1 = _r1, *r2 = _r2;

It is better to add 'const' as below to avoid warning.
const u64 *r1 = _r1, *r2 = _r2;

>+
>+  return r1 - r2;

r1 and r2 are u64, but returned value is 'int' type.
Do you think we should improve this ? e.g. return (int)r1 - r2;

>+}
>+
> static int
> scmi_clock_describe_rates_get(const struct scmi_handle *handle, u32 clk_id,
> struct scmi_clock_info *clk)
>@@ -184,8 +193,10 @@ scmi_clock_describe_rates_get(const struct scmi_handle 
>*handle, u32 clk_id,
>*/
>   } while (num_returned && num_remaining);
>
>-  if (rate_discrete)
>+  if (rate_discrete) {
>   clk->list.num_rates = tot_rate_cnt;
>+  sort(rate, tot_rate_cnt, sizeof(*rate), rate_cmp_func, NULL);

About warning of above line, I think it relates to below snip of code:
if (tot_rate_cnt + num_returned > SCMI_MAX_NUM_RATES) {
dev_err(handle->dev, "No. of rates > MAX_NUM_RATES");
break;
}

I see that in this case is true, it is not proceeded as error case,
If so I think you can update 'rate' for value from 'tot_rate_cnt' to 
SCMI_MAX_NUM_RATES at here.
How do you think ?

>+  }
>
>   clk->rate_discrete = rate_discrete;
>
>--
>2.17.1

Best regard.
DIEN Pham

Re: [PATCH] bus: fsl-mc: fix invalid free in fsl_mc_device_add

[Greg KH]

On Wed, Jul 08, 2020 at 11:45:24AM -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> clang static analysis flags this error
> 
> fsl-mc-bus.c:695:2: warning: Attempt to free released memory [unix.Malloc]
> kfree(mc_dev);
> ^
> 
> The problem block of code is
> 
>   mc_bus = kzalloc(sizeof(*mc_bus), GFP_KERNEL);
>   if (!mc_bus)
>   return -ENOMEM;
> 
>   mc_dev = &mc_bus->mc_dev;
> 
> mc_bus's structure contains a mc_dev element,
> freeing it later is not appropriate.
> 
> So check if mc_bus was allocated before freeing mc_dev
> 
> This is a case where checkpatch
> 
> WARNING: kfree(NULL) is safe and this check is probably not required
> + if (mc_bus)
> + kfree(mc_bus);
> 
> is wrong.
> 
> Fixes: a042fbed0290 ("staging: fsl-mc: simplify couple of deallocations")
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/bus/fsl-mc/fsl-mc-bus.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 40526da5c6a6..7390e56661a0 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -691,8 +691,10 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
>  
>  error_cleanup_dev:
>   kfree(mc_dev->regions);
> - kfree(mc_bus);
> - kfree(mc_dev);
> + if (mc_bus)
> + kfree(mc_bus);
> + else
> + kfree(mc_dev);

You should really put a comment on this saying why you need to do it
this way, otherwise someone will come along and "clean it up" again the
same way in the future.

thanks,

greg k-h

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

[Also reported by Randy Dunlap.]

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

mm/migrate.c: In function 'migrate_pages':
mm/migrate.c:1528:19: error: 'THP_MIGRATION_SUCCESS' undeclared (first use in 
this function); did you mean 'PGMIGRATE_SUCCESS'?
 1528 |   count_vm_events(THP_MIGRATION_SUCCESS, nr_thp_succeeded);
  |   ^
  |   PGMIGRATE_SUCCESS
mm/migrate.c:1528:19: note: each undeclared identifier is reported only once 
for each function it appears in
mm/migrate.c:1530:19: error: 'THP_MIGRATION_FAILURE' undeclared (first use in 
this function); did you mean 'SWP_MIGRATION_WRITE'?
 1530 |   count_vm_events(THP_MIGRATION_FAILURE, nr_thp_failed);
  |   ^
  |   SWP_MIGRATION_WRITE
mm/migrate.c:1532:19: error: 'THP_MIGRATION_SPLIT' undeclared (first use in 
this function); did you mean 'SWP_MIGRATION_WRITE'?
 1532 |   count_vm_events(THP_MIGRATION_SPLIT, nr_thp_split);
  |   ^~~
  |   SWP_MIGRATION_WRITE

Caused by commit

  f85bb1e35327 ("mm/vmstat: add events for THP migration without split")

I have reverted that commit (and its followup fix) for today.

-- 
Cheers,
Stephen Rothwell


pgpPGW1xA3Uhq.pgp
Description: OpenPGP digital signature

Re: [PATCH v2] genpd: Fix up terminology with parent/child

[Greg Kroah-Hartman]

On Wed, Jul 08, 2020 at 04:32:13PM -0700, Kees Cook wrote:
> The genpd infrastructure uses the terms master/slave, but such uses have
> no external exposures (not even in Documentation/driver-api/pm/*) and are
> not mandated by nor associated with any external specifications. Change
> the language used through-out to parent/child.
> 
> There was one possible exception in the debugfs node
> "pm_genpd/pm_genpd_summary" but its path has no hits outside of the
> kernel itself when performing a code search[1], and it seems even this
> single usage has been non-functional since it was introduced due to a
> typo in the Python ("apend" instead of correct "append"). Fix the typo
> while we're at it.
> 
> [1] https://codesearch.debian.net/
> 
> Signed-off-by: Kees Cook 

Reviewed-by: Greg Kroah-Hartman 

[PATCH] fpga: dfl: pci: add device id for Intel FPGA PAC N3000

[Xu Yilun]

Add PCIe Device ID for Intel FPGA PAC N3000.

Signed-off-by: Wu Hao 
Signed-off-by: Xu Yilun 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
---
 drivers/fpga/dfl-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/fpga/dfl-pci.c b/drivers/fpga/dfl-pci.c
index 73b5153..824aecf 100644
--- a/drivers/fpga/dfl-pci.c
+++ b/drivers/fpga/dfl-pci.c
@@ -64,6 +64,7 @@ static void cci_pci_free_irq(struct pci_dev *pcidev)
 #define PCIE_DEVICE_ID_PF_INT_5_X  0xBCBD
 #define PCIE_DEVICE_ID_PF_INT_6_X  0xBCC0
 #define PCIE_DEVICE_ID_PF_DSC_1_X  0x09C4
+#define PCIE_DEVICE_ID_PF_PAC_N30000x0B30
 /* VF Device */
 #define PCIE_DEVICE_ID_VF_INT_5_X  0xBCBF
 #define PCIE_DEVICE_ID_VF_INT_6_X  0xBCC1
@@ -76,6 +77,7 @@ static struct pci_device_id cci_pcie_id_tbl[] = {
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_VF_INT_6_X),},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_PF_DSC_1_X),},
{PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_VF_DSC_1_X),},
+   {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCIE_DEVICE_ID_PF_PAC_N3000),},
{0,}
 };
 MODULE_DEVICE_TABLE(pci, cci_pcie_id_tbl);
-- 
2.7.4

Re: [PATCH 3/4] firmware: arm_scmi: Fix scmi_event_header fields typing

[Cristian Marussi]

On Wed, Jul 08, 2020 at 10:38:08PM +0200, Arnd Bergmann wrote:
> On Wed, Jul 8, 2020 at 2:24 PM Cristian Marussi
>  wrote:
> >
> > Drop size_t in favour of fixed size u32 for consistency and shuffle
> > around fields definitions to minimize implicit padding.
> >
> > Signed-off-by: Cristian Marussi 
> 
> As you still have implicit padding at the end, I'd either make
> that explicit now, or leave the __packed attribute.

Do you mean expliciting that with a comment, right ? being the last member 
'payld'
a flexible array must be the last in order to even compile.

I'm a bit confused anyway on how the trailing padding works on a struct like
this which ends with a flexible array definition, so I was expecting that the
trailing pads would have made no difference, given that it's used to basically
give some know layout to a blob of data via casting...

Thanks

Cristian

> 
> The payld_sz is not actually force to be misaligned with the
> reordered layout, which is what's most important.
> 
>  Arnd

[PATCH] arm64: kernel: Add module symbols _text, _etext.

[sanggil2 . kim]

From: Sanggil Kim 

We have a solution to protect kernel code section(autually from _text to
_etext) by not MMU. In order to do this, we have to know the addresses
of _text and _etext at runtime.

Signed-off-by: Sanggil Kim 
---
 arch/arm64/kernel/head.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 037421c..09b405e 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -1003,3 +1003,6 @@ SYM_FUNC_START_LOCAL(__primary_switch)
adrpx0, __PHYS_OFFSET
br  x8
 SYM_FUNC_END(__primary_switch)
+
+EXPORT_SYMBOL(_text)
+EXPORT_SYMBOL(_etext)
-- 
2.7.4

Re: WARNING: at mm/mremap.c:211 move_page_tables in i386

[Arnd Bergmann]

On Thu, Jul 9, 2020 at 7:28 AM Naresh Kamboju  wrote:
>
> While running LTP mm test suite on i386 or qemu_i386 this kernel warning
> has been noticed from stable 5.4 to stable 5.7 branches and mainline 5.8.0-rc4
> and linux next.

Are you able to correlate this with any particular test case in LTP, or does
it happen for random processes?

In the log you linked to, it happens once for ksm05.c and multiple times for
thp01.c, sources here:

https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/ksm/ksm05.c
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/thp/thp01.c

Is it always these tests that trigger the warning, or sometimes others?

When you say it happens with linux-5.4 stable, does that mean you don't see
it with older versions? What is the last known working version?

I also see that you give the virtual machine 16GB of RAM, but as you are
running a 32-bit kernel without PAE, only 2.3GB end up being available,
and some other LTP tests in the log run out of memory.

You could check if the behavior changes if you give the kernel less memory,
e.g. 768MB (lowmem only), or enable CONFIG_X86_PAE to let it use the
entire 16GB.

> full test log,
> https://lkft.validation.linaro.org/scheduler/job/1541788#L9308

   Arnd

RE: [PATCH v2 2/2] clk: scmi: Fix min and max rate when registering clocks with discrete rates

[Dien Pham]

Hi Sudeep,

Thanks for your patch.

>-Original Message-
>From: Sudeep Holla  
>Sent: Thursday, July 9, 2020 3:17 PM
>To: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; Stephen 
>Boyd 
>Cc: Sudeep Holla ; linux-kernel@vger.kernel.org; Michael 
>Turquette ; Dien Pham 
>Subject: [PATCH v2 2/2] clk: scmi: Fix min and max rate when registering 
>clocks with discrete rates
>
>Currently we are not initializing the scmi clock with discrete rates 
>correctly. We fetch the min_rate and max_rate value only for clocks with 
>ranges and ignore the ones with discrete rates. This will lead to wrong 
>initialization of rate range when clock supports discrete rate.
>
>Fix this by using the first and the last rate in the sorted list of the 
>discrete clock rates while registering the clock.
>
>Link: https://lore.kernel.org/r/20200708110725.18017-2-sudeep.ho...@arm.com
>Fixes: 6d6a1d82eaef7 ("clk: add support for clocks provided by SCMI")
>Reported-by: Dien Pham 
>Signed-off-by: Sudeep Holla 
>---
> drivers/clk/clk-scmi.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
>Hi Stephen,
>
>If you are fine, I can take this via ARM SoC along with the change in firmware 
>driver. However it is also fine if you want to merge this independently as 
>there is no strict dependency. Let me know either way.
>
>v1[1]->v2:
>   - Fixed the missing ; which was sent by mistake.

I tested the patch,
I is ok and can fix my issue.

>Regards,
>Sudeep
>
>[1] https://lore.kernel.org/r/20200708110725.18017-2-sudeep.ho...@arm.com
>
>diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c index 
>c491f5de0f3f..c754dfbb73fd 100644
>--- a/drivers/clk/clk-scmi.c
>+++ b/drivers/clk/clk-scmi.c
>@@ -103,6 +103,8 @@ static const struct clk_ops scmi_clk_ops = {  static int 
>scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk)  {
>   int ret;
>+  unsigned long min_rate, max_rate;
>+
>   struct clk_init_data init = {
>   .flags = CLK_GET_RATE_NOCACHE,
>   .num_parents = 0,
>@@ -112,9 +114,23 @@ static int scmi_clk_ops_init(struct device *dev, struct 
>scmi_clk *sclk)
> 
>   sclk->hw.init = &init;
>   ret = devm_clk_hw_register(dev, &sclk->hw);
>-  if (!ret)
>-  clk_hw_set_rate_range(&sclk->hw, sclk->info->range.min_rate,
>-sclk->info->range.max_rate);
>+  if (ret)
>+  return ret;
>+
>+  if (sclk->info->rate_discrete) {
>+  int num_rates = sclk->info->list.num_rates;
>+
>+  if (num_rates <= 0)
>+  return -EINVAL;
>+
>+  min_rate = sclk->info->list.rates[0];
>+  max_rate = sclk->info->list.rates[num_rates - 1];
>+  } else {
>+  min_rate = sclk->info->range.min_rate;
>+  max_rate = sclk->info->range.max_rate;
>+  }
>+
>+  clk_hw_set_rate_range(&sclk->hw, min_rate, max_rate);
>   return ret;
> }
> 
>--
>2.17.1

Best regard,
DIEN Pham

[PATCH] edac: nxp: Add L1 and L2 error detection for A53 and A72 cores

[Alison Wang]

Add error detection for A53 and A72 cores. Hardware error injection is
supported on A53. Software error injection is supported on both.
For hardware error injection on A53 to work, proper access to
L2ACTLR_EL1, CPUACTLR_EL1 needs to be granted by EL3 firmware. This is
done by making an SMC call in the driver. Failure to enable access
disables hardware error injection. For error detection to work, another
SMC call enables access to L2ECTLR_EL1.

It is for NXP's Layerscape family LS1043A, LS1046A, LS2088A and LX2160A.

Signed-off-by: York Sun 
Signed-off-by: Alison Wang 
---
 .../bindings/edac/cortex-arm64-edac.txt   |  40 +
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/cortex_arm64_l1_l2.c | 738 ++
 drivers/edac/cortex_arm64_l1_l2.h |  54 ++
 5 files changed, 840 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.c
 create mode 100644 drivers/edac/cortex_arm64_l1_l2.h

diff --git a/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt 
b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
new file mode 100644
index ..41c840993814
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
@@ -0,0 +1,40 @@
+ARM Cortex A53 and A72 L1/L2 cache error reporting
+
+CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be
+used for checking L1 and L2 memory errors. However, only A53 supports
+double-bit error injection to L1 and L2 memory. This driver uses the
+hardware error injection when available, but also provides a way to
+inject errors by software.
+
+To use hardware error injection and the interrupt, proper access needs
+to be granted in ACTLR_EL3 (and/or ACTLR_EL2) register by EL3 firmware SMC 
call.
+
+Correctable errors do not trigger such interrupt. This driver uses
+dynamic polling internal to check for errors. The more errors detected,
+the more frequently it polls. Combining with interrupt, this driver can
+detect correctable and uncorrectable errors. However, if the
+uncorrectable errors cause system abort exception, this driver is not able to
+report errors in time.
+
+The SIP-specific SMC calls are only for NXP's Layerscape family LS1043A,
+LS1046A, LS2088A and LX2160A.
+
+The following section describes the Cortex A53/A72 EDAC DT node binding.
+
+Required properties:
+- compatible: Should be "arm,cortex-a53-edac" or "arm,cortex-a72-edac"
+- cpus: Should be a list of compatible cores
+
+Optional properties:
+- interrupts: Interrupt number if supported
+
+Example:
+   edac {
+   compatible = "arm,cortex-a53-edac";
+   cpus = <&cpu0>,
+  <&cpu1>,
+  <&cpu2>,
+  <&cpu3>;
+   interrupts = <0 108 0x4>;
+
+   };
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 7b6ec3014ba2..6317cebf0a95 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -530,4 +530,11 @@ config EDAC_DMC520
  Support for error detection and correction on the
  SoCs with ARM DMC-520 DRAM controller.
 
+config EDAC_CORTEX_ARM64_L1_L2
+   tristate "ARM Cortex A53/A72"
+   depends on ARM64 && ARCH_LAYERSCAPE
+   help
+ Support for error detection on ARM Cortex A53 and A72 with Layerscape
+ SoC family LS1043A, LS1046A, LS2088A and LX2160A.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 269e15118cea..3edba6bea350 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_EDAC_QCOM)   += qcom_edac.o
 obj-$(CONFIG_EDAC_ASPEED)  += aspeed_edac.o
 obj-$(CONFIG_EDAC_BLUEFIELD)   += bluefield_edac.o
 obj-$(CONFIG_EDAC_DMC520)  += dmc520_edac.o
+obj-$(CONFIG_EDAC_CORTEX_ARM64_L1_L2)  += cortex_arm64_l1_l2.o
diff --git a/drivers/edac/cortex_arm64_l1_l2.c 
b/drivers/edac/cortex_arm64_l1_l2.c
new file mode 100644
index ..0443384bd656
--- /dev/null
+++ b/drivers/edac/cortex_arm64_l1_l2.c
@@ -0,0 +1,738 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cortex A53 and A72 EDAC L1 and L2 cache error detection
+ *
+ * Copyright 2018-2020 NXP
+ * Author: York Sun 
+ *
+ * Partially take from a similar driver by
+ * Brijesh Singh 
+ * Copyright (c) 2015, Advanced Micro Devices
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "edac_module.h"
+#include "cortex_arm64_l1_l2.h"
+
+static int poll_msec = 1024;
+static long l1_ce_sw_inject_count, l1_ue_sw_inject_count;
+static long l2_ce_sw_inject_count, l2_ue_sw_inject_count;
+static struct cpumask compat_mask;
+static struct cpumask l1_ce_cpu_mask, l1_ue_cpu_mask;
+static struct cpumask l2_ce_cpu_mask, l2_ue_cpu_mask;
+static DEFINE_PER_CPU(unsigned long, actlr_en);
+static DEFINE_PER_CPU(un

Re: [GIT PULL] EFI fixes

[Peter Zijlstra]

On Wed, Jul 08, 2020 at 11:00:19AM -0700, Linus Torvalds wrote:
> On Wed, Jul 8, 2020 at 9:21 AM Peter Zijlstra  wrote:
> > >
> > > It's perhaps yet another reason to just skip gcc-4.8 too, since
> > > apparently 4.9 works.
> > >
> > > gcc-4.9 really has a lot of advantages. It's where (I think) gcc
> > > basically supports all C11 things, including _Generic() but also
> > > __auto_type.
> >
> > +1
> >
> > Anybody for nay, or should we just do this?
> 
> I'll just do it. Let's see if anybody screams with a good reason. I
> hate the whole "support old compilers", it ends up not only making for
> complex code, it tends to cause these unnecessary kinds of "guys, we
> tested this really well, but that crazy compiler had a very particular
> odd issue, and it wasn't in any test box.

Excellent, thanks!

Re: [PATCH v5 4/9] remoteproc: Introducing function rproc_actuate()

[Arnaud POULIQUEN]

Hi Mathieu,


On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> Introduce function rproc_actuate() that provides the same
> functionatlity as rproc_fw_boot(), but without the steps that
> involve interaction with the firmware image.  That way we can
> deal with scenarios where the remoteproc core is attaching
> to a remote processor that has already been started by another
> entity.
> 
> Signed-off-by: Mathieu Poirier 

Reviewed-by: Arnaud Pouliquen 

Thanks,
Arnaud
> ---
>  drivers/remoteproc/remoteproc_core.c | 59 +++-
>  1 file changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 1e8e66a25bd6..fd424662801f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1369,7 +1369,7 @@ static int rproc_start(struct rproc *rproc, const 
> struct firmware *fw)
>   return ret;
>  }
>  
> -static int __maybe_unused rproc_attach(struct rproc *rproc)
> +static int rproc_attach(struct rproc *rproc)
>  {
>   struct device *dev = &rproc->dev;
>   int ret;
> @@ -1490,6 +1490,63 @@ static int rproc_fw_boot(struct rproc *rproc, const 
> struct firmware *fw)
>   return ret;
>  }
>  
> +/*
> + * Attach to remote processor - similar to rproc_fw_boot() but without
> + * the steps that deal with the firmware image.
> + */
> +static int __maybe_unused rproc_actuate(struct rproc *rproc)
> +{
> + struct device *dev = &rproc->dev;
> + int ret;
> +
> + /*
> +  * if enabling an IOMMU isn't relevant for this rproc, this is
> +  * just a nop
> +  */
> + ret = rproc_enable_iommu(rproc);
> + if (ret) {
> + dev_err(dev, "can't enable iommu: %d\n", ret);
> + return ret;
> + }
> +
> + /* reset max_notifyid */
> + rproc->max_notifyid = -1;
> +
> + /* reset handled vdev */
> + rproc->nb_vdev = 0;
> +
> + /*
> +  * Handle firmware resources required to attach to a remote processor.
> +  * Because we are attaching rather than booting the remote processor,
> +  * we expect the platform driver to properly set rproc->table_ptr.
> +  */
> + ret = rproc_handle_resources(rproc, rproc_loading_handlers);
> + if (ret) {
> + dev_err(dev, "Failed to process resources: %d\n", ret);
> + goto disable_iommu;
> + }
> +
> + /* Allocate carveout resources associated to rproc */
> + ret = rproc_alloc_registered_carveouts(rproc);
> + if (ret) {
> + dev_err(dev, "Failed to allocate associated carveouts: %d\n",
> + ret);
> + goto clean_up_resources;
> + }
> +
> + ret = rproc_attach(rproc);
> + if (ret)
> + goto clean_up_resources;
> +
> + return 0;
> +
> +clean_up_resources:
> + rproc_resource_cleanup(rproc);
> +disable_iommu:
> + rproc_disable_iommu(rproc);
> + return ret;
> +}
> +
>  /*
>   * take a firmware and boot it up.
>   *
> 

Re: [PATCH 0/2] perf: Allow closing siblings' file descriptors

[Alexey Budankov]

Hi Alex,

On 08.07.2020 18:16, Alexander Shishkin wrote:
> Hi guys,
> 
> I've been looking at reducing the number of open file descriptors per perf
> session. If we retain one descriptor per event, in a large group they add
> up. At the same time, we're not actually using them for anything after the
> SET_OUTPUT and maybe SET_FILTER ioctls. So, this series is a stab at that.

PERF_EVENT_IOC_ENABLE, PERF_EVENT_IOC_DISABLE ioctls are still assumed to
work, right?

Asking w.r.t. functionality on --control fd:ctl_fd[,ack_fd] option for stat
and record modes [1].

Thanks,
Alexey

[1] 
https://lore.kernel.org/lkml/4af50c95-36f6-7a61-5a22-2949970fe...@linux.intel.com/

> 
> So, I added a new flag to the perf_event_open() that tells perf to keep
> the event around after its file descriptor gets closed, for as long as its
> group leader is alive. Since this is a new behavior, the flag is an opt-in.
> 
> I also hacked this into the perf tool (mostly perf record, but I'll hack
> stat as well if this general approach is agreeable).
> 
> Alexander Shishkin (2):
>   perf: Add closing sibling events' file descriptors
>   perf record: Support closing siblings' file descriptors
> 
>  include/linux/perf_event.h  |   7 ++
>  include/uapi/linux/perf_event.h |   1 +
>  kernel/events/core.c| 149 +---
>  tools/include/uapi/linux/perf_event.h   |   1 +
>  tools/lib/perf/evlist.c |  30 -
>  tools/lib/perf/evsel.c  |  21 
>  tools/lib/perf/include/internal/evsel.h |   4 +
>  tools/perf/builtin-record.c |  48 ++--
>  tools/perf/util/cpumap.c|   4 +
>  tools/perf/util/evlist.c|   4 +-
>  tools/perf/util/evsel.c |  17 ++-
>  tools/perf/util/evsel.h |   3 +
>  12 files changed, 234 insertions(+), 55 deletions(-)
> 

RE: [PATCH v3] scsi: ufs: Cleanup completed request without interrupt notification

[Avri Altman]

 
> 
> If somehow no interrupt notification is raised for a completed request
> and its doorbell bit is cleared by host, UFS driver needs to cleanup
> its outstanding bit in ufshcd_abort().
Theoretically, this case is already accounted for - 
See line 6407: a proper error is issued and eventually outstanding req is 
cleared.

Can you go over the scenario you are attending line by line,
And explain why ufshcd_abort does not account for it?

> 
> Otherwise, system may crash by below abnormal flow:
> 
> After this request is requeued by SCSI layer with its
> outstanding bit set, the next completed request will trigger
> ufshcd_transfer_req_compl() to handle all "completed outstanding
> bits". In this time, the "abnormal outstanding bit" will be detected
> and the "requeued request" will be chosen to execute request
> post-processing flow. This is wrong and blk_finish_request() will
> BUG_ON because this request is still "alive".
> 
> It is worth mentioning that before ufshcd_abort() cleans the timed-out
> request, driver need to check again if this request is really not
> handled by __ufshcd_transfer_req_compl() yet because it may be
> possible that the interrupt comes very lately before the cleaning.
What do you mean? Why checking the outstanding reqs isn't enough?

> 
> Signed-off-by: Stanley Chu 
> ---
>  drivers/scsi/ufs/ufshcd.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 8603b07045a6..f23fb14df9f6 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -6462,7 +6462,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
> /* command completed already */
> dev_err(hba->dev, "%s: cmd at tag %d successfully 
> cleared from
> DB.\n",
> __func__, tag);
> -   goto out;
> +   goto cleanup;
But you've arrived here only if (!(test_bit(tag, &hba->outstanding_reqs))) - 
See line 6400. 

> } else {
> dev_err(hba->dev,
> "%s: no response from device. tag = %d, err 
> %d\n",
> @@ -6496,9 +6496,14 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
> goto out;
> }
> 
> +cleanup:
> +   spin_lock_irqsave(host->host_lock, flags);
> +   if (!test_bit(tag, &hba->outstanding_reqs)) {
> +   spin_unlock_irqrestore(host->host_lock, flags);
> +   goto out;
> +   }
> scsi_dma_unmap(cmd);
> 
> -   spin_lock_irqsave(host->host_lock, flags);
> ufshcd_outstanding_req_clear(hba, tag);
> hba->lrb[tag].cmd = NULL;
> spin_unlock_irqrestore(host->host_lock, flags);
> --
> 2.18.0

[PATCH v14 0/2] Add initial support for slimport anx7625

[Xin Ji]

Hi all,

The following series add support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.


This is the v14 version, any mistakes, please let me know, I will fix it in
the next series.

Change history:
v14: Fix comments from Sam and Nicolas
 - Check flags at drm_bridge_attach
 - Use panel_bridge instead of drm_panel
 - Fix not correct return value

v13: Fix comments from Launrent Pinchart and Rob Herring
 - Picked up Rob's Reviewed-By
 - Add .detect and .get_edid interface in bridge funcs.

v12: Fix comments from Hsin-Yi Wang
 - Rebase the code on kernel 5.7, fix DRM interface not match issue.

v11: Fix comments from Rob Herring
 - Update commit message.
 - Remove unused label.

v10: Fix comments from Rob Herring, Daniel.
 - Fix dt_binding_check warning.
 - Update description.

v9: Fix comments from Sam, Nicolas, Daniel
 - Remove extcon interface.
 - Remove DPI support.
 - Fix dt_binding_check complains.
 - Code clean up and update description.

v8: Fix comments from Nicolas.
 - Fix several coding format.
 - Update description.

v7:
 - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface,
   enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D.


Xin Ji (2):
  dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
  drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

 .../bindings/display/bridge/analogix,anx7625.yaml  |   95 +
 drivers/gpu/drm/bridge/analogix/Kconfig|9 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c  | 1939 
 drivers/gpu/drm/bridge/analogix/anx7625.h  |  391 
 5 files changed, 2435 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

-- 
2.7.4

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

[Peter Zijlstra]

On Wed, Jul 08, 2020 at 07:54:34PM -0400, Waiman Long wrote:
> On 7/8/20 4:41 AM, Peter Zijlstra wrote:
> > On Tue, Jul 07, 2020 at 03:57:06PM +1000, Nicholas Piggin wrote:
> > > Yes, powerpc could certainly get more performance out of the slow
> > > paths, and then there are a few parameters to tune.
> > Can you clarify? The slow path is already in use on ARM64 which is weak,
> > so I doubt there's superfluous serialization present. And Will spend a
> > fair amount of time on making that thing guarantee forward progressm, so
> > there just isn't too much room to play.
> > 
> > > We don't have a good alternate patching for function calls yet, but
> > > that would be something to do for native vs pv.
> > Going by your jump_label implementation, support for static_call should
> > be fairly straight forward too, no?
> > 
> >https://lkml.kernel.org/r/20200624153024.794671...@infradead.org
> > 
> Speaking of static_call, I am also looking forward to it. Do you have an
> idea when that will be merged?

0day had one crash on the last round, I think Steve send a fix for that
last night and I'll go look at it.

That said, the last posting got 0 feedback, so either everybody is
really happy with it, or not interested. So let us know in the thread,
with some review feedback.

Once I get through enough of the inbox to actually find the fix and test
it, I'll also update the thread, and maybe threaten to merge it if
everybody stays silent :-)

[PATCH v14 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema

[Xin Ji]

anx7625: MIPI to DP transmitter DT schema

Signed-off-by: Xin Ji 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/analogix,anx7625.yaml  | 95 ++
 1 file changed, 95 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..60585a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+  - Xin Ji 
+
+description: |
+  The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+  designed for portable devices.
+
+properties:
+  compatible:
+items:
+  - const: analogix,anx7625
+
+  reg:
+maxItems: 1
+
+  interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+  enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+  reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description:
+  Video port for MIPI DSI input.
+
+  port@1:
+type: object
+description:
+  Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+  - compatible
+  - reg
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
+};
-- 
2.7.4

Re: [PATCH v5 5/9] remoteproc: Introducing function rproc_validate()

[Arnaud POULIQUEN]

On 7/7/20 11:00 PM, Mathieu Poirier wrote:
> Add a new function to assert the general health of the remote
> processor before handing it to the remoteproc core.
> 
> Signed-off-by: Mathieu Poirier 

Reviewed-by: Arnaud Pouliquen 

Thanks,
Arnaud

> ---
>  drivers/remoteproc/remoteproc_core.c | 41 
>  1 file changed, 41 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index fd424662801f..ad500c291d5f 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -2040,6 +2040,43 @@ struct rproc *rproc_get_by_phandle(phandle phandle)
>  #endif
>  EXPORT_SYMBOL(rproc_get_by_phandle);
>  
> +static int rproc_validate(struct rproc *rproc)
> +{
> + switch (rproc->state) {
> + case RPROC_OFFLINE:
> + /*
> +  * An offline processor without a start()
> +  * function makes no sense.
> +  */
> + if (!rproc->ops->start)
> + return -EINVAL;
> + break;
> + case RPROC_DETACHED:
> + /*
> +  * A remote processor in a detached state without an
> +  * attach() function makes not sense.
> +  */
> + if (!rproc->ops->attach)
> + return -EINVAL;
> + /*
> +  * When attaching to a remote processor the device memory
> +  * is already available and as such there is no need to have a
> +  * cached table.
> +  */
> + if (rproc->cached_table)
> + return -EINVAL;
> + break;
> + default:
> + /*
> +  * When adding a remote processor, the state of the device
> +  * can be offline or detached, nothing else.
> +  */
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * rproc_add() - register a remote processor
>   * @rproc: the remote processor handle to register
> @@ -2069,6 +2106,10 @@ int rproc_add(struct rproc *rproc)
>   if (ret < 0)
>   return ret;
>  
> + ret = rproc_validate(rproc);
> + if (ret < 0)
> + return ret;
> +
>   dev_info(dev, "%s is available\n", rproc->name);
>  
>   /* create debugfs entries */
> 

Re: [printk] 18a2dc6982: ltp.kmsg01.fail

[Sergey Senozhatsky]

On (20/07/09 15:14), kernel test robot wrote:
[..]

Took me a while to find the FAIL-ed test:

> kmsg01.c:393: INFO: TEST: read returns EPIPE when messages get overwritten
> kmsg01.c:398: INFO: first seqno: 0
> kmsg01.c:411: INFO: first seqno now: 881
> kmsg01.c:425: FAIL: read returned: 77: SUCCESS (0)

So this is seq number related
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/logging/kmsg/kmsg01.c#L383

LTP writes a gazillion (roughly, maybe a bit less than that)
filler messages to /dev/kmsg in order to cause logbuf overlap:
...
19490 [  172.301584] LTP kmsg01 FILLER MESSAGE TO OVERWRITE OTHERS
19491 [  172.308730] LTP kmsg01 FILLER MESSAGE TO OVERWRITE OTHERS
19492 [  172.313852] LTP kmsg01 FILLER MESSAGE TO OVERWRITE OTHERS
19493 [  172.320988] LTP kmsg01 FILLER MESSAGE TO OVERWRITE OTHERS
19494 [  172.325618] LTP kmsg01 FILLER MESSAGE TO OVERWRITE OTHERS
...

-ss