[PATCH] dtbs: hikey970: add wifi support

[Mauro Carvalho Chehab]

The dwmmc2 is used on Hikey 970 for WiFi support. The
hi3670.dtsi adds it, but with status="disabled".

For WiFi to work,it needs to be enabled. While here, add
the missing properties:

#address-cells = <0x1>;
#size-cells = <0x0>;

and add
ti,non-removable

To DT properties, as the WiFi support is on a non-removable slot.

Signed-off-by: Mauro Carvalho Chehab 
---
 arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts 
b/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
index f218acceec0b..a2b0d2a1d09d 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
@@ -402,6 +402,7 @@ _clk_cfg_func
 
  { /* WIFI */
bus-width = <0x4>;
+   ti,non-removable;
non-removable;
broken-cd;
cap-power-off-card;
@@ -409,8 +410,12 @@  { /* WIFI */
pinctrl-0 = <_pmx_func
 _clk_cfg_func
 _cfg_func>;
+   status = "ok";
+
/* WL_EN */
vmmc-supply = <_en>;
+   #address-cells = <0x1>;
+   #size-cells = <0x0>;
status = "ok";
 
wlcore: wlcore@2 {
-- 
2.26.2

Re: [PATCH v18 25/32] mm/mlock: remove lru_lock on TestClearPageMlocked in munlock_vma_page

[Alex Shi]

LKP reported a preemptiable issue on this patch. update and refresh
the commit log.

>From f18e8c87a045bbb8040006b6816ded1f55fa6f9c Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Sat, 25 Jul 2020 22:31:03 +0800
Subject: [PATCH] mm/mlock: remove lru_lock on TestClearPageMlocked in
 munlock_vma_page

In the func munlock_vma_page, comments mentained lru_lock needed for
serialization with split_huge_pages. But the page must be PageLocked
as well as pages in split_huge_page series funcs. Thus the PageLocked
is enough to serialize both funcs.

So we could relief the TestClearPageMlocked/hpage_nr_pages which are not
necessary under lru lock.

As to another munlock func __munlock_pagevec, which no PageLocked
protection and should remain lru protecting.

LKP found a preempt issue on __mod_zone_page_state which need change
to mod_zone_page_state. Thanks!

Reported-by: kernel test robot 
Signed-off-by: Alex Shi 
Cc: Kirill A. Shutemov 
Cc: Vlastimil Babka 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/mlock.c | 43 ---
 1 file changed, 16 insertions(+), 27 deletions(-)

diff --git a/mm/mlock.c b/mm/mlock.c
index 0448409184e3..cd88b93b0f0d 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -69,9 +69,9 @@ void clear_page_mlock(struct page *page)
 *
 * See __pagevec_lru_add_fn for more explanation.
 */
-   if (!isolate_lru_page(page)) {
+   if (!isolate_lru_page(page))
putback_lru_page(page);
-   } else {
+   else {
/*
 * We lost the race. the page already moved to evictable list.
 */
@@ -178,7 +178,6 @@ static void __munlock_isolation_failed(struct page *page)
 unsigned int munlock_vma_page(struct page *page)
 {
int nr_pages;
-   struct lruvec *lruvec;
 
/* For try_to_munlock() and to serialize with page migration */
BUG_ON(!PageLocked(page));
@@ -186,37 +185,22 @@ unsigned int munlock_vma_page(struct page *page)
VM_BUG_ON_PAGE(PageTail(page), page);
 
/*
-* Serialize split tail pages in __split_huge_page_tail() which
-* might otherwise copy PageMlocked to part of the tail pages before
-* we clear it in the head page. It also stabilizes thp_nr_pages().
-* TestClearPageLRU can't be used here to block page isolation, since
-* out of lock clear_page_mlock may interfer PageLRU/PageMlocked
-* sequence, same as __pagevec_lru_add_fn, and lead the page place to
-* wrong lru list here. So relay on PageLocked to stop lruvec change
-* in mem_cgroup_move_account().
+* Serialize split tail pages in __split_huge_page_tail() by
+* lock_page(); Do TestClearPageMlocked/PageLRU sequence like
+* clear_page_mlock().
 */
-   lruvec = lock_page_lruvec_irq(page);
-
-   if (!TestClearPageMlocked(page)) {
+   if (!TestClearPageMlocked(page))
/* Potentially, PTE-mapped THP: do not skip the rest PTEs */
-   nr_pages = 1;
-   goto unlock_out;
-   }
+   return 0;
 
nr_pages = thp_nr_pages(page);
-   __mod_zone_page_state(page_zone(page), NR_MLOCK, -nr_pages);
+   mod_zone_page_state(page_zone(page), NR_MLOCK, -nr_pages);
 
-   if (__munlock_isolate_lru_page(page, lruvec, true)) {
-   unlock_page_lruvec_irq(lruvec);
+   if (!isolate_lru_page(page))
__munlock_isolated_page(page);
-   goto out;
-   }
-   __munlock_isolation_failed(page);
-
-unlock_out:
-   unlock_page_lruvec_irq(lruvec);
+   else
+   __munlock_isolation_failed(page);
 
-out:
return nr_pages - 1;
 }
 
@@ -305,6 +289,11 @@ static void __munlock_pagevec(struct pagevec *pvec, struct 
zone *zone)
 
/* block memcg change in mem_cgroup_move_account */
lock_page_memcg(page);
+   /*
+* Serialize split tail pages in __split_huge_page_tail() which
+* might otherwise copy PageMlocked to part of the tail pages
+* before we clear it in the head page.
+*/
lruvec = relock_page_lruvec_irq(page, lruvec);
if (TestClearPageMlocked(page)) {
/*
-- 
2.17.1

Re: [PATCH] PCI/ASPM: Enable ASPM for links under VMD domain

[Kai-Heng Feng]

> On Aug 25, 2020, at 14:56, Christoph Hellwig  wrote:
> 
> On Tue, Aug 25, 2020 at 02:39:55PM +0800, Kai Heng Feng wrote:
>> Hi Christoph,
>> 
>>> On Aug 25, 2020, at 2:23 PM, Christoph Hellwig  wrote:
>>> 
>>> On Fri, Aug 21, 2020 at 08:32:20PM +0800, Kai-Heng Feng wrote:
 New Intel laptops with VMD cannot reach deeper power saving state,
 renders very short battery time.
>>> 
>>> So what about just disabling VMD given how bloody pointless it is?
>>> Hasn't anyone learned from the AHCI remapping debacle?
>>> 
>>> I'm really pissed at all this pointless crap intel comes up with just
>>> to make life hard for absolutely no gain.  Is it so hard to just leave
>>> a NVMe device as a standard NVMe device instead of f*^ everything
>>> up in the chipset to make OS support a pain and I/O slower than by
>>> doing nothing?
>> 
>> From what I can see from the hardwares at my hand, VMD only enables a PCI 
>> domain and PCI bridges behind it.
>> 
>> NVMe works as a regular NVMe under those bridges. No magic remapping happens 
>> here.
> 
> It definitively is less bad than the AHCI remapping, that is for sure.
> 
> But it still requires:
> 
> - a new OS driver just to mak the PCIe device show up
> - indirections in the irq handling
> - indirections in the DMA handling
> - hacks for ASPSM
> - hacks for X (there were a few more)
> 
> while adding absolutely no value.  Basically we have to add a large
> chunk of kernel code just to undo silicone/firmware Intel added to their
> platform to make things complicated.  I mean it is their platform and if
> they want a "make things complicated" option that is fine, but it should
> not be on by default.

Yes, I do want it to be a regular PCIe bridge... but it's not the reality here.
Almost all next-gen Intel laptops will have VMD enabled, so users are forced to 
have it.
I would really like to have this patch in upstream instead of carrying it as a 
downstream distro-only patch.

Kai-Heng

[PATCH] Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"

[Mauro Carvalho Chehab]

This patch causes a regression betwen Kernel 5.7 and 5.8 at wlcore:
with it applied, WiFi stops working, and the Kernel starts printing
this message every second:

   wlcore: PHY firmware version: Rev 8.2.0.0.242
   wlcore: firmware booted (Rev 8.9.0.0.79)
   wlcore: ERROR command execute failure 14
   [ cut here ]
   WARNING: CPU: 0 PID: 133 at drivers/net/wireless/ti/wlcore/main.c:795 
wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
   Modules linked in: wl18xx wlcore mac80211 libarc4 cfg80211 rfkill 
snd_soc_hdmi_codec crct10dif_ce wlcore_sdio adv7511 cec kirin9xx_drm(C) 
kirin9xx_dw_drm_dsi(C) drm_kms_helper drm ip_tables x_tables ipv6 nf_defrag_ipv6
   CPU: 0 PID: 133 Comm: kworker/0:1 Tainted: GWC5.8.0+ #186
   Hardware name: HiKey970 (DT)
   Workqueue: events_freezable ieee80211_restart_work [mac80211]
   pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
   pc : wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
   lr : wl12xx_queue_recovery_work+0x24/0x30 [wlcore]
   sp : 8000126c3a60
   x29: 8000126c3a60 x28: 25de
   x27: 0010 x26: 0005
   x25: 0001a5d49e80 x24: 892cf580
   x23: 0001b7c12623 x22: 0001b6fcf2e8
   x21: 0001b7e46200 x20: fffb
   x19: 0001a78e6400 x18: 0030
   x17: 0001 x16: 0001
   x15: 0001b7e46670 x14: 
   x13: 8000926c37d7 x12: 8000126c37e0
   x11: 800011e01000 x10: 8000120526d0
   x9 :  x8 : 3431206572756c69
   x7 : 6166206574756365 x6 : 0c2c
   x5 :  x4 : 0001bf1361e8
   x3 : 0001bf1790b0 x2 : 
   x1 : 0001a5d49e80 x0 : 0001
   Call trace:
wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
wl12xx_queue_recovery_work+0x24/0x30 [wlcore]
wl1271_cmd_set_sta_key+0x258/0x25c [wlcore]
wl1271_set_key+0x7c/0x2dc [wlcore]
wlcore_set_key+0xe4/0x360 [wlcore]
wl18xx_set_key+0x48/0x1d0 [wl18xx]
wlcore_op_set_key+0xa4/0x180 [wlcore]
ieee80211_key_enable_hw_accel+0xb0/0x2d0 [mac80211]
ieee80211_reenable_keys+0x70/0x110 [mac80211]
ieee80211_reconfig+0xa00/0xca0 [mac80211]
ieee80211_restart_work+0xc4/0xfc [mac80211]
process_one_work+0x1cc/0x350
worker_thread+0x13c/0x470
kthread+0x154/0x160
ret_from_fork+0x10/0x30
   ---[ end trace b1f722abf9af5919 ]---
   wlcore: WARNING could not set keys
   wlcore: ERROR Could not add or replace key
   wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-5)
   wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.0.79
   wlcore: pc: 0x0, hint_sts: 0x0040 count: 39
   wlcore: down
   wlcore: down
   ieee80211 phy0: Hardware restart was requested
   mmc_host mmc0: Bus speed (slot 0) = 40Hz (slot req 40Hz, actual 
40HZ div = 0)
   mmc_host mmc0: Bus speed (slot 0) = 2500Hz (slot req 2500Hz, actual 
2500HZ div = 0)
   wlcore: PHY firmware version: Rev 8.2.0.0.242
   wlcore: firmware booted (Rev 8.9.0.0.79)
   wlcore: ERROR command execute failure 14
   [ cut here ]

Tested on Hikey 970.

This reverts commit 2b7aadd3b9e17e8b81eeb8d9cc46756ae4658265.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/net/wireless/ti/wlcore/cmd.h  | 1 -
 drivers/net/wireless/ti/wlcore/main.c | 4 
 2 files changed, 5 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/cmd.h 
b/drivers/net/wireless/ti/wlcore/cmd.h
index 9acd8a41ea61..f2609d5b6bf7 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.h
+++ b/drivers/net/wireless/ti/wlcore/cmd.h
@@ -458,7 +458,6 @@ enum wl1271_cmd_key_type {
KEY_TKIP = 2,
KEY_AES  = 3,
KEY_GEM  = 4,
-   KEY_IGTK  = 5,
 };
 
 struct wl1271_cmd_set_keys {
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index de6c8a7589ca..ef169de99224 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3550,9 +3550,6 @@ int wlcore_set_key(struct wl1271 *wl, enum set_key_cmd 
cmd,
case WL1271_CIPHER_SUITE_GEM:
key_type = KEY_GEM;
break;
-   case WLAN_CIPHER_SUITE_AES_CMAC:
-   key_type = KEY_IGTK;
-   break;
default:
wl1271_error("Unknown key algo 0x%x", key_conf->cipher);
 
@@ -6222,7 +6219,6 @@ static int wl1271_init_ieee80211(struct wl1271 *wl)
WLAN_CIPHER_SUITE_TKIP,
WLAN_CIPHER_SUITE_CCMP,
WL1271_CIPHER_SUITE_GEM,
-   WLAN_CIPHER_SUITE_AES_CMAC,
};
 
/* The tx descriptor buffer */
-- 
2.26.2

RE: [PATCH 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

[Tian, Kevin]

> From: Lu Baolu
> Sent: Wednesday, August 26, 2020 10:58 AM
> 
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
> 
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple writes to this register.
> 
> However, in irq_remapping.c, modifications of IRE and CFI are done in one
> write. We need to do two separate writes with STS checking after each.
> 
> Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out
> security warning mess")
> Cc: Andy Lutomirski 
> Cc: Jacob Pan 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/irq_remapping.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/intel/irq_remapping.c
> b/drivers/iommu/intel/irq_remapping.c
> index 9564d23d094f..19d7e18876fe 100644
> --- a/drivers/iommu/intel/irq_remapping.c
> +++ b/drivers/iommu/intel/irq_remapping.c
> @@ -507,12 +507,16 @@ static void iommu_enable_irq_remapping(struct
> intel_iommu *iommu)
> 
>   /* Enable interrupt-remapping */
>   iommu->gcmd |= DMA_GCMD_IRE;
> - iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format
> MSIs */
>   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
> -
>   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
> readl, (sts & DMA_GSTS_IRES), sts);
> 
> + /* Block compatibility-format MSIs */
> + iommu->gcmd &= ~DMA_GCMD_CFI;
> + writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
> + IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
> +   readl, !(sts & DMA_GSTS_CFIS), sts);
> +

Better do it only when CFI is actually enabled (by checking sts).

>   /*
>* With CFI clear in the Global Command register, we should be
>* protected from dangerous (i.e. compatibility) interrupts
> --
> 2.17.1
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/2] i2c: consider devices with of_match_table during i2c device probing

[Sergey Senozhatsky]

On (20/08/26 07:08), Wolfram Sang wrote:
> On Wed, Aug 26, 2020 at 01:29:37PM +0900, Sergey Senozhatsky wrote:
> > Unlike acpi_match_device(), acpi_driver_match_device() does
> > consider devices that provide of_match_table and performs
> > of_compatible() matching for such devices. The key point here is
> > that ACPI of_compatible() matching - acpi_of_match_device() - is
> > part of ACPI and does not depend on CONFIG_OF.
> > 
> > Consider the following case:
> > o !CONFIG_OF system
> > o probing of i2c device that provides .of_match_table, but no .id_table
> > 
> >  i2c_device_probe()
> >  ...
> >if (!driver->id_table &&
> >!i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
> >!i2c_of_match_device(dev->driver->of_match_table, client)) {
> >status = -ENODEV;
> >goto put_sync_adapter;
> >}
> > 
> > i2c_of_match_device() depends on CONFIG_OF and, thus, is always false.
> > i2c_acpi_match_device() does ACPI match only, no of_comtatible() matching
> > takes place, even though the device provides .of_match_table and ACPI,
> > technically, is capable of matching such device. The result is -ENODEV.
> > Probing will succeed, however, if we'd use .of_match_table aware ACPI
> > matching.
> > 
> > Signed-off-by: Sergey Senozhatsky 
> 
> We have currently this in for-current which is even removing
> i2c_acpi_match_device():
> 
> http://patchwork.ozlabs.org/project/linux-i2c/list/?series=196990=*

Oh, nice!
Can we go a bit further and use i2c_device_match() in i2c_device_probe()
instead of a mix of APIs from different subsystems?

E.g.

if (!driver->id_table &&
-   !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
-   !i2c_of_match_device(dev->driver->of_match_table, client)) {
+   !(client && i2c_device_match(>dev, dev->driver))) {
status = -ENODEV;
goto put_sync_adapter;
}

-ss

[PATCH] drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444

[Kai-Heng Feng]

LSPCON only supports 8 bpc for RGB/YCbCr444.

Set the correct bpp otherwise it renders blank screen.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c 
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index b781bf469644..c7a44fcaade8 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -196,7 +196,8 @@ void lspcon_ycbcr420_config(struct drm_connector *connector,
crtc_state->port_clock /= 2;
crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
crtc_state->lspcon_downsampling = true;
-   }
+   } else
+   crtc_state->pipe_bpp = 24;
 }
 
 static bool lspcon_probe(struct intel_lspcon *lspcon)
-- 
2.17.1

Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs

[Joonsoo Kim]

2020년 8월 26일 (수) 오전 9:42, Andrew Morton 님이 작성:
>
> On Tue, 25 Aug 2020 14:34:32 +0900 Joonsoo Kim  wrote:
>
> > >
> > > That's a bunch more code on a very hot path to serve an obscure feature
> > > which has a single obscure callsite.
> > >
> > > Can we instead put the burden on that callsite rather than upon
> > > everyone?  For (dumb) example, teach __gup_longterm_locked() to put the
> > > page back if it's CMA and go get another one?
> >
> > Hmm... Unfortunately, it cannot ensure that we eventually get the non-CMA 
> > page.
> > I think that the only way to ensure it is to implement the
> > functionality here. We can
> > use 'unlikely' or 'static branch' to reduce the overhead for a really
> > rare case but
> > for now I have no idea how to completely remove the overhead.
>
> Gee, there must be something?  Provide the gup code with a special
> entry point which takes the page straight from __rmqueue() and bypasses
> the pcp lists?

Hmm... it seems not possible. It's allocation context API and maybe actual
allocation happens in handle_mm_fault() or it's successor. We cannot use
a special entry point for allocation there since it's a general function.

And, IMHO, making a special allocation function that bypasses the pcp list
would not be a good practice.

Thanks.

[PATCH] net: hns3: Fix for geneve tx checksum bug

[Yi Li]

when skb->encapsulation is 0, skb->ip_summed is CHECKSUM_PARTIAL
and it is udp packet, which has a dest port as the IANA assigned.
the hardware is expected to do the checksum offload, but the
hardware will not do the checksum offload when udp dest port is
6081.

This patch fixes it by doing the checksum in software.

Reported-by: Li Bing 
Signed-off-by: Yi Li 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 87776ce3539b..7d83c45369c2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hnae3.h"
 #include "hns3_enet.h"
@@ -780,7 +781,7 @@ static int hns3_get_l4_protocol(struct sk_buff *skb, u8 
*ol4_proto,
  * and it is udp packet, which has a dest port as the IANA assigned.
  * the hardware is expected to do the checksum offload, but the
  * hardware will not do the checksum offload when udp dest port is
- * 4789.
+ * 4789 or 6081.
  */
 static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
 {
@@ -789,7 +790,8 @@ static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
l4.hdr = skb_transport_header(skb);
 
if (!(!skb->encapsulation &&
- l4.udp->dest == htons(IANA_VXLAN_UDP_PORT)))
+ (l4.udp->dest == htons(IANA_VXLAN_UDP_PORT) ||
+ l4.udp->dest == htons(GENEVE_UDP_PORT
return false;
 
skb_checksum_help(skb);
-- 
2.25.3

Re: [PATCH] nvmem: mtk-efuse: Remove EFUSE register write support

[CK Hu]

Hi, Chih-En:

On Wed, 2020-08-26 at 13:01 +0800, Chih-En Hsu wrote:
> This patch is to remove function "mtk_reg_write" since
> Mediatek EFUSE hardware only supports read functionality
> for NVMEM consumers.
> 

This is a bug-fix patch, so need a 'Fixes' tag. You could refer to [1].

[1]
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-changes

Regards,
CK.

> Signed-off-by: Chih-En Hsu 
> ---
>  drivers/nvmem/mtk-efuse.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 856d9c3fc38e..6a537d959f14 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
>   return 0;
>  }
>  
> -static int mtk_reg_write(void *context,
> -  unsigned int reg, void *_val, size_t bytes)
> -{
> - struct mtk_efuse_priv *priv = context;
> - u32 *val = _val;
> - int i = 0, words = bytes / 4;
> -
> - while (words--)
> - writel(*val++, priv->base + reg + (i++ * 4));
> -
> - return 0;
> -}
> -
>  static int mtk_efuse_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>   econfig.stride = 4;
>   econfig.word_size = 4;
>   econfig.reg_read = mtk_reg_read;
> - econfig.reg_write = mtk_reg_write;
>   econfig.size = resource_size(res);
>   econfig.priv = priv;
>   econfig.dev = dev;

Re: [PATCH for v5.9] mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs

[Joonsoo Kim]

2020년 8월 25일 (화) 오후 6:43, Vlastimil Babka 님이 작성:
>
>
> On 8/25/20 6:59 AM, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> >
> > memalloc_nocma_{save/restore} APIs can be used to skip page allocation
> > on CMA area, but, there is a missing case and the page on CMA area could
> > be allocated even if APIs are used. This patch handles this case to fix
> > the potential issue.
> >
> > Missing case is an allocation from the pcplist. MIGRATE_MOVABLE pcplist
> > could have the pages on CMA area so we need to skip it if ALLOC_CMA isn't
> > specified.
> >
> > This patch implements this behaviour by checking allocated page from
> > the pcplist rather than skipping an allocation from the pcplist entirely.
> > Skipping the pcplist entirely would result in a mismatch between watermark
> > check and actual page allocation.
>
> Are you sure? I think a mismatch exists already. Pages can be on the pcplist 
> but
> they are not considered as free in the watermark check. So passing watermark
> check means there should be also pages on free lists. So skipping pcplists 
> would
> be safe, no?

You are right.

> > And, it requires to break current code
> > layering that order-0 page is always handled by the pcplist. I'd prefer
> > to avoid it so this patch uses different way to skip CMA page allocation
> > from the pcplist.
>
> Well it would be much simpler and won't affect most of allocations. Better 
> than
> flushing pcplists IMHO.

Hmm...Still, I'd prefer my approach. There are two reasons. First,
layering problem
mentioned above. In rmqueue(), there is a code for MIGRATE_HIGHATOMIC.
As the name shows, it's for high order atomic allocation. But, after
skipping pcplist
allocation as you suggested, we could get there with order 0 request.
We can also
change this code, but, I'd hope to maintain current layering. Second,
a performance
reason. After the flag for nocma is up, a burst of nocma allocation
could come. After
flushing the pcplist one times, we can use the free page on the
pcplist as usual until
the context is changed.

How about my reasoning?

Thanks.

Re: [PATCH 3/3] ARM: defconfig: Enable ax88796c driver

[Lukasz Stelmach]

It was <2020-08-25 wto 20:51>, when Krzysztof Kozlowski wrote:
> On Tue, Aug 25, 2020 at 07:03:11PM +0200, Łukasz Stelmach wrote:
>> Enable ax88796c driver for the ethernet chip on Exynos3250-based
>> ARTIK5 boards.
>> 
>> Signed-off-by: Łukasz Stelmach 
>> ---
>>  arch/arm/configs/exynos_defconfig   | 2 ++
>>  arch/arm/configs/multi_v7_defconfig | 2 ++
>>  2 files changed, 4 insertions(+)
>> 
>> Please DO NOT merge before these two
>
> Sure, it can wait but shouldn't actually DT wait? It's only defconfig so
> it does not change anything except automated systems booting these
> defconfigs... The boards might be broken by DT.

I was told, to ask for deferred merge of defconfig and it makes sense to
me. DT won't break anything if the driver isn't compiled. However, I can
see that you have a word you may decide about DT too. My point is to
wait until spi-s3c64xx patches are merged and not to break ARTIK5
boards.

>> 
>>   https://lore.kernel.org/lkml/20200821161401.11307-2-l.stelm...@samsung.com/
>>   https://lore.kernel.org/lkml/20200821161401.11307-3-l.stelm...@samsung.com/
>> 
>> diff --git a/arch/arm/configs/exynos_defconfig 
>> b/arch/arm/configs/exynos_defconfig
>> index 6e8b5ff0859c..82480b2bf545 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -107,6 +107,8 @@ CONFIG_MD=y
>>  CONFIG_BLK_DEV_DM=y
>>  CONFIG_DM_CRYPT=m
>>  CONFIG_NETDEVICES=y
>> +CONFIG_NET_VENDOR_ASIX=y
>> +CONFIG_SPI_AX88796C=y
>>  CONFIG_SMSC911X=y
>>  CONFIG_USB_RTL8150=m
>>  CONFIG_USB_RTL8152=y
>> diff --git a/arch/arm/configs/multi_v7_defconfig 
>> b/arch/arm/configs/multi_v7_defconfig
>> index e9e76e32f10f..a8b4e95d4148 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -241,6 +241,8 @@ CONFIG_SATA_HIGHBANK=y
>>  CONFIG_SATA_MV=y
>>  CONFIG_SATA_RCAR=y
>>  CONFIG_NETDEVICES=y
>> +CONFIG_NET_VENDOR_ASIX=y
>> +CONFIG_SPI_AX88796C=m
>>  CONFIG_VIRTIO_NET=y
>>  CONFIG_B53_SPI_DRIVER=m
>>  CONFIG_B53_MDIO_DRIVER=m
>> -- 
>> 2.26.2
>> 
>
>

-- 
Łukasz Stelmach
Samsung R Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

Re: [PATCH 1/2] i2c: consider devices with of_match_table during i2c device probing

[Wolfram Sang]

On Wed, Aug 26, 2020 at 01:29:37PM +0900, Sergey Senozhatsky wrote:
> Unlike acpi_match_device(), acpi_driver_match_device() does
> consider devices that provide of_match_table and performs
> of_compatible() matching for such devices. The key point here is
> that ACPI of_compatible() matching - acpi_of_match_device() - is
> part of ACPI and does not depend on CONFIG_OF.
> 
> Consider the following case:
> o !CONFIG_OF system
> o probing of i2c device that provides .of_match_table, but no .id_table
> 
>  i2c_device_probe()
>  ...
>if (!driver->id_table &&
>!i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
>!i2c_of_match_device(dev->driver->of_match_table, client)) {
>status = -ENODEV;
>goto put_sync_adapter;
>}
> 
> i2c_of_match_device() depends on CONFIG_OF and, thus, is always false.
> i2c_acpi_match_device() does ACPI match only, no of_comtatible() matching
> takes place, even though the device provides .of_match_table and ACPI,
> technically, is capable of matching such device. The result is -ENODEV.
> Probing will succeed, however, if we'd use .of_match_table aware ACPI
> matching.
> 
> Signed-off-by: Sergey Senozhatsky 

We have currently this in for-current which is even removing
i2c_acpi_match_device():

http://patchwork.ozlabs.org/project/linux-i2c/list/?series=196990=*

From a glimpse, this is basically equal but CCing Andy for the details.

> ---
>  drivers/i2c/i2c-core-acpi.c | 10 --
>  drivers/i2c/i2c-core-base.c |  2 +-
>  drivers/i2c/i2c-core.h  | 10 +++---
>  3 files changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index 2ade99b105b9..1dd152ae75e5 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -276,14 +276,12 @@ void i2c_acpi_register_devices(struct i2c_adapter *adap)
>   dev_warn(>dev, "failed to enumerate I2C slaves\n");
>  }
>  
> -const struct acpi_device_id *
> -i2c_acpi_match_device(const struct acpi_device_id *matches,
> -   struct i2c_client *client)
> +bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client)
>  {
> - if (!(client && matches))
> - return NULL;
> + if (!client)
> + return false;
>  
> - return acpi_match_device(matches, >dev);
> + return acpi_driver_match_device(>dev, dev->driver);
>  }
>  
>  static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = {
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 34a9609f256d..35ec6335852b 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -480,7 +480,7 @@ static int i2c_device_probe(struct device *dev)
>* or ACPI ID table is supplied for the probing device.
>*/
>   if (!driver->id_table &&
> - !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
> + !i2c_acpi_match_device(dev, client) &&
>   !i2c_of_match_device(dev->driver->of_match_table, client)) {
>   status = -ENODEV;
>   goto put_sync_adapter;
> diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
> index 94ff1693b391..7ee6a6e3fb8d 100644
> --- a/drivers/i2c/i2c-core.h
> +++ b/drivers/i2c/i2c-core.h
> @@ -59,19 +59,15 @@ static inline int __i2c_check_suspended(struct 
> i2c_adapter *adap)
>  }
>  
>  #ifdef CONFIG_ACPI
> -const struct acpi_device_id *
> -i2c_acpi_match_device(const struct acpi_device_id *matches,
> -   struct i2c_client *client);
> +bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client);
>  void i2c_acpi_register_devices(struct i2c_adapter *adap);
>  
>  int i2c_acpi_get_irq(struct i2c_client *client);
>  #else /* CONFIG_ACPI */
>  static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
> -static inline const struct acpi_device_id *
> -i2c_acpi_match_device(const struct acpi_device_id *matches,
> -   struct i2c_client *client)
> +bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client)
>  {
> - return NULL;
> + return false;
>  }
>  
>  static inline int i2c_acpi_get_irq(struct i2c_client *client)
> -- 
> 2.28.0
> 


signature.asc
Description: PGP signature

Re: [PATCH 1/2] i2c: consider devices with of_match_table during i2c device probing

[Sergey Senozhatsky]

On (20/08/26 13:29), Sergey Senozhatsky wrote:
> Unlike acpi_match_device(), acpi_driver_match_device() does
> consider devices that provide of_match_table and performs
> of_compatible() matching for such devices. The key point here is
> that ACPI of_compatible() matching - acpi_of_match_device() - is
> part of ACPI and does not depend on CONFIG_OF.
> 
> Consider the following case:
> o !CONFIG_OF system
> o probing of i2c device that provides .of_match_table, but no .id_table
> 
>  i2c_device_probe()
>  ...
>if (!driver->id_table &&
>!i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
>!i2c_of_match_device(dev->driver->of_match_table, client)) {
>status = -ENODEV;
>goto put_sync_adapter;
>}
> 
> i2c_of_match_device() depends on CONFIG_OF and, thus, is always false.
> i2c_acpi_match_device() does ACPI match only, no of_comtatible() matching
> takes place, even though the device provides .of_match_table and ACPI,
> technically, is capable of matching such device. The result is -ENODEV.
> Probing will succeed, however, if we'd use .of_match_table aware ACPI
> matching.

Or, alternatively, we can drop i2c_acpi_match_device() and use
i2c_device_match() in i2c_device_probe().

---

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 34a9609f256d..14bfc5c83f84 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -96,7 +96,6 @@ static int i2c_device_match(struct device *dev, struct 
device_driver *drv)
struct i2c_client   *client = i2c_verify_client(dev);
struct i2c_driver   *driver;
 
-
/* Attempt an OF style match */
if (i2c_of_match_device(drv->of_match_table, client))
return 1;
@@ -480,8 +479,7 @@ static int i2c_device_probe(struct device *dev)
 * or ACPI ID table is supplied for the probing device.
 */
if (!driver->id_table &&
-   !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
-   !i2c_of_match_device(dev->driver->of_match_table, client)) {
+   !(client && i2c_device_match(>dev, dev->driver))) {
status = -ENODEV;
goto put_sync_adapter;
}
diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
index 94ff1693b391..8ce261167a2d 100644
--- a/drivers/i2c/i2c-core.h
+++ b/drivers/i2c/i2c-core.h
@@ -59,20 +59,11 @@ static inline int __i2c_check_suspended(struct i2c_adapter 
*adap)
 }
 
 #ifdef CONFIG_ACPI
-const struct acpi_device_id *
-i2c_acpi_match_device(const struct acpi_device_id *matches,
- struct i2c_client *client);
 void i2c_acpi_register_devices(struct i2c_adapter *adap);
 
 int i2c_acpi_get_irq(struct i2c_client *client);
 #else /* CONFIG_ACPI */
 static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
-static inline const struct acpi_device_id *
-i2c_acpi_match_device(const struct acpi_device_id *matches,
- struct i2c_client *client)
-{
-   return NULL;
-}
 
 static inline int i2c_acpi_get_irq(struct i2c_client *client)
 {

[PATCH] nvmem: mtk-efuse: Remove EFUSE register write support

[Chih-En Hsu]

This patch is to remove function "mtk_reg_write" since
Mediatek EFUSE hardware only supports read functionality
for NVMEM consumers.

Signed-off-by: Chih-En Hsu 
---
 drivers/nvmem/mtk-efuse.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 856d9c3fc38e..6a537d959f14 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
return 0;
 }
 
-static int mtk_reg_write(void *context,
-unsigned int reg, void *_val, size_t bytes)
-{
-   struct mtk_efuse_priv *priv = context;
-   u32 *val = _val;
-   int i = 0, words = bytes / 4;
-
-   while (words--)
-   writel(*val++, priv->base + reg + (i++ * 4));
-
-   return 0;
-}
-
 static int mtk_efuse_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
econfig.stride = 4;
econfig.word_size = 4;
econfig.reg_read = mtk_reg_read;
-   econfig.reg_write = mtk_reg_write;
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-- 
2.18.0

[PATCH v2] dt-bindings: convert spmi.txt to spmi.yaml

[Mauro Carvalho Chehab]

Convert the SPMI bus documentation to JSON/yaml.

Signed-off-by: Mauro Carvalho Chehab 
---

v2:
- addressed issues pointed by Rob;
- made clear that group ID is a future extension, that it is not
  currently supported.

 .../bindings/mfd/qcom,spmi-pmic.txt   |  2 +-
 .../bindings/spmi/qcom,spmi-pmic-arb.txt  |  4 +-
 .../devicetree/bindings/spmi/spmi.txt | 41 --
 .../devicetree/bindings/spmi/spmi.yaml| 75 +++
 4 files changed, 78 insertions(+), 44 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spmi/spmi.txt
 create mode 100644 Documentation/devicetree/bindings/spmi/spmi.yaml

diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt 
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
index fffc8fde3302..79367a43b27d 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
@@ -37,7 +37,7 @@ Required properties:
or generalized "qcom,spmi-pmic".
 - reg: Specifies the SPMI USID slave address for this device.
For more information see:
-   Documentation/devicetree/bindings/spmi/spmi.txt
+   Documentation/devicetree/bindings/spmi/spmi.yaml
 
 Required properties for peripheral child nodes:
 - compatible:  Should contain "qcom,xxx", where "xxx" is a peripheral name.
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt 
b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
index e16b9b5afc70..ca645e21fe47 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -7,8 +7,8 @@ devices to control a single SPMI master.
 The PMIC Arbiter can also act as an interrupt controller, providing interrupts
 to slave devices.
 
-See spmi.txt for the generic SPMI controller binding requirements for child
-nodes.
+See Documentation/devicetree/bindings/spmi/spmi.yaml for the generic SPMI
+controller binding requirements for child nodes.
 
 See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
 generic interrupt controller binding documentation.
diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt 
b/Documentation/devicetree/bindings/spmi/spmi.txt
deleted file mode 100644
index 4bb10d161a27..
--- a/Documentation/devicetree/bindings/spmi/spmi.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-System Power Management Interface (SPMI) Controller
-
-This document defines a generic set of bindings for use by SPMI controllers.  A
-controller is modelled in device tree as a node with zero or more child nodes,
-each representing a unique slave on the bus.
-
-Required properties:
-- #address-cells : must be set to 2
-- #size-cells : must be set to 0
-
-Child nodes:
-
-An SPMI controller node can contain zero or more child nodes representing slave
-devices on the bus.  Child 'reg' properties are specified as an address, type
-pair.  The address must be in the range 0-15 (4 bits).  The type must be one of
-SPMI_USID (0) or SPMI_GSID (1) for Unique Slave ID or Group Slave ID 
respectively.
-These are the identifiers "statically assigned by the system integrator", as
-per the SPMI spec.
-
-Each child node must have one and only one 'reg' entry of type SPMI_USID.
-
-#include 
-
-   spmi@.. {
-   compatible = "...";
-   reg = <...>;
-
-   #address-cells = <2>;
-   #size-cells = <0>;
-
-   child@0 {
-   compatible = "...";
-   reg = <0 SPMI_USID>;
-   };
-
-   child@7 {
-   compatible = "...";
-   reg = <7 SPMI_USID
-  3 SPMI_GSID>;
-   };
-   };
diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml 
b/Documentation/devicetree/bindings/spmi/spmi.yaml
new file mode 100644
index ..0e54978245b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/spmi.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/spmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: System Power Management Interface (SPMI) Controller
+
+maintainers:
+  - Josh Cartwright 
+
+description: |
+  The System Power Management (SPMI) controller is a 2-wire bus defined
+  by the MIPI Alliance for power management control to be used on SoC designs.
+
+  SPMI controllers are modelled in device tree using a generic set of
+  bindings defined here, plus any bus controller specific properties, if
+  needed.
+
+  Each SPMI controller has zero or more child nodes (up to 16 ones), each
+  one representing an unique slave at the bus.
+
+properties:
+  $nodename:
+pattern: "spmi@.*"
+
+  reg:
+maxItems: 1
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 

Re: [PATCH v1 5/9] phy: qcom-qmp: Get dp_com I/O resource by index

[Bjorn Andersson]

On Tue 25 Aug 21:47 CDT 2020, Stephen Boyd wrote:

> The dp_com resource is always at index 1 according to the dts files in
> the kernel. Get this resource by index so that we don't need to make
> future additions to the DT binding use 'reg-names'.
> 

Afaict the DT binding for the USB/DP phy defines that there should be a
reg name of "dp_com" and the current dts files all specifies this. Am I
missing something?

PS. Why isn't this a devm_platform_ioremap_resource{,_byname}()?

Regards,
Bjorn

> Cc: Jeykumar Sankaran 
> Cc: Chandan Uddaraju 
> Cc: Vara Reddy 
> Cc: Tanmay Shah 
> Cc: Bjorn Andersson 
> Cc: Manu Gautam 
> Cc: Sandeep Maheswaram 
> Cc: Douglas Anderson 
> Cc: Sean Paul 
> Cc: Jonathan Marek 
> Cc: Dmitry Baryshkov 
> Cc: Rob Clark 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 40c051813c34..76d7a9e80f04 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -3266,8 +3266,7 @@ static int qcom_qmp_phy_probe(struct platform_device 
> *pdev)
>  
>   /* per PHY dp_com; if PHY has dp_com control block */
>   if (cfg->has_phy_dp_com_ctrl) {
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> -"dp_com");
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>   base = devm_ioremap_resource(dev, res);
>   if (IS_ERR(base))
>   return PTR_ERR(base);
> -- 
> Sent by a computer, using git, on the internet
> 

Re: [net-next v5 0/6] net: marvell: prestera: Add Switchdev driver for Prestera family ASIC device 98DX326x (AC3x)

[Chris Packham]

Hi Vadym,

On 26/08/20 12:20 am, Vadym Kochan wrote:
> Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> wireless SMB deployment.
I think there's a typo here or possibly in patch 1. The AC3x family has 
model numbers 98DX3255, 98DX3256, 98DX3257, 98DX3258, 98DX3259, 
98DX3265, 98DX3268. I'm not sure which variant you're specifically 
targeting but in patch 1 you add the PCI device 0xC804 which corresponds 
to the 98DX3255.
> Prestera Switchdev is a firmware based driver that operates via PCI bus.  The
> current implementation supports only boards designed for the Marvell Switchdev
> solution and requires special firmware.
>
> This driver implementation includes only L1, basic L2 support, and RX/TX.
>
> The core Prestera switching logic is implemented in prestera_main.c, there is
> an intermediate hw layer between core logic and firmware. It is
> implemented in prestera_hw.c, the purpose of it is to encapsulate hw
> related logic, in future there is a plan to support more devices with
> different HW related configurations.
>
> The following Switchdev features are supported:
>
>  - VLAN-aware bridge offloading
>  - VLAN-unaware bridge offloading
>  - FDB offloading (learning, ageing)
>  - Switchport configuration
>
> The original firmware image is uploaded to the linux-firmware repository.
>
> PATCH v5:
>  0) add Co-developed tags for people who was involved in development.
>
>  1) Make SPDX license as separate comment
>
>  2) Change 'u8 *' -> 'void *', It allows to avoid not-needed u8* casting.
>
>  3) Remove "," in terminated enum's.
>
>  4) Use GENMASK(end, start) where it is applicable in.
>
>  5) Remove not-needed 'u8 *' casting.
>
>  6) Apply common error-check pattern
>
>  7) Use ether_addr_copy instead of memcpy
>
>  8) Use define for maximum MAC address range (255)
>
>  9) Simplify prestera_port_state_set() in prestera_main.c by
> using separate if-blocks for state setting:
>  
>  if (is_up) {
>  ...
>  } else {
>  ...
>  }
>
>which makes logic more understandable.
>
>  10) Simplify sdma tx wait logic when checking/updating tx_ring->burst.
>
>  11) Remove not-needed packed & aligned attributes
>
>  12) Use USEC_PER_MSEC as multiplier when converting ms -> usec on calling
>  readl_poll_timeout.
>
>  13) Simplified some error path handling by simple return error code in.
>
>  14) Remove not-needed err assignment in.
>
>  15) Use dev_err() in prestera_devlink_register(...).
>
>  Patches updated:
>  [1] net: marvell: prestera: Add driver for Prestera family ASIC 
> devices
>   [2] net: marvell: prestera: Add PCI interface support
>  [3] net: marvell: prestera: Add basic devlink support
>   [4] net: marvell: prestera: Add ethtool interface support
>   [5] net: marvell: prestera: Add Switchdev driver implementation
>
> PATCH v4:
>  1) Use prestera_ prefix in netdev_ops variable.
>
>  2) Kconfig: use 'default PRESTERA' build type for CONFIG_PRESTERA_PCI to 
> be
> synced by default with prestera core module.
>
>  3) Use memcpy_xxio helpers in prestera_pci.c for IO buffer copying.
>
>  4) Generate fw image path via snprintf() instead of macroses.
>
>  5) Use pcim_ helpers in prestera_pci.c which simplified the
> probe/remove logic.
>
>  6) Removed not needed initializations of variables which are used in
> readl_poll_xxx() helpers.
>
>  7) Fixed few grammar mistakes in patch[2] description.
>
>  8) Export only prestera_ethtool_ops struct instead of each
> ethtool handler.
>
>  9) Add check for prestera_dev_check() in switchdev event handling to
> make sure there is no wrong topology.
>
>  Patches updated:
>  [1] net: marvell: prestera: Add driver for Prestera family ASIC 
> devices
>   [2] net: marvell: prestera: Add PCI interface support
>   [4] net: marvell: prestera: Add ethtool interface support
>   [5] net: marvell: prestera: Add Switchdev driver implementation
>
> PATCH v3:
>  1) Simplify __be32 type casting in prestera_dsa.c
>
>  2) Added per-patch changelog under "---" line.
>
> PATCH v2:
>  1) Use devlink_port_type_clear()
>
>  2) Add _MS prefix to timeout defines.
>
>  3) Remove not-needed packed attribute from the firmware ipc structs,
> also the firmware image needs to be uploaded too (will do it soon).
>
>  4) Introduce prestera_hw_switch_fini(), to be mirrored with init and
> do simple validation if the event handlers are unregistered.
>
>  5) Use kfree_rcu() for event handler unregistering.
>
>  6) Get rid of rcu-list usage when dealing with ports, not needed for
> now.
>
>  7) Little spelling corrections in the error/info messages.
>
>  8) Make pci probe & remove 

[PATCH 1/2] i2c: consider devices with of_match_table during i2c device probing

[Sergey Senozhatsky]

Unlike acpi_match_device(), acpi_driver_match_device() does
consider devices that provide of_match_table and performs
of_compatible() matching for such devices. The key point here is
that ACPI of_compatible() matching - acpi_of_match_device() - is
part of ACPI and does not depend on CONFIG_OF.

Consider the following case:
o !CONFIG_OF system
o probing of i2c device that provides .of_match_table, but no .id_table

 i2c_device_probe()
 ...
   if (!driver->id_table &&
   !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
   !i2c_of_match_device(dev->driver->of_match_table, client)) {
   status = -ENODEV;
   goto put_sync_adapter;
   }

i2c_of_match_device() depends on CONFIG_OF and, thus, is always false.
i2c_acpi_match_device() does ACPI match only, no of_comtatible() matching
takes place, even though the device provides .of_match_table and ACPI,
technically, is capable of matching such device. The result is -ENODEV.
Probing will succeed, however, if we'd use .of_match_table aware ACPI
matching.

Signed-off-by: Sergey Senozhatsky 
---
 drivers/i2c/i2c-core-acpi.c | 10 --
 drivers/i2c/i2c-core-base.c |  2 +-
 drivers/i2c/i2c-core.h  | 10 +++---
 3 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 2ade99b105b9..1dd152ae75e5 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -276,14 +276,12 @@ void i2c_acpi_register_devices(struct i2c_adapter *adap)
dev_warn(>dev, "failed to enumerate I2C slaves\n");
 }
 
-const struct acpi_device_id *
-i2c_acpi_match_device(const struct acpi_device_id *matches,
- struct i2c_client *client)
+bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client)
 {
-   if (!(client && matches))
-   return NULL;
+   if (!client)
+   return false;
 
-   return acpi_match_device(matches, >dev);
+   return acpi_driver_match_device(>dev, dev->driver);
 }
 
 static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = {
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 34a9609f256d..35ec6335852b 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -480,7 +480,7 @@ static int i2c_device_probe(struct device *dev)
 * or ACPI ID table is supplied for the probing device.
 */
if (!driver->id_table &&
-   !i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
+   !i2c_acpi_match_device(dev, client) &&
!i2c_of_match_device(dev->driver->of_match_table, client)) {
status = -ENODEV;
goto put_sync_adapter;
diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h
index 94ff1693b391..7ee6a6e3fb8d 100644
--- a/drivers/i2c/i2c-core.h
+++ b/drivers/i2c/i2c-core.h
@@ -59,19 +59,15 @@ static inline int __i2c_check_suspended(struct i2c_adapter 
*adap)
 }
 
 #ifdef CONFIG_ACPI
-const struct acpi_device_id *
-i2c_acpi_match_device(const struct acpi_device_id *matches,
- struct i2c_client *client);
+bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client);
 void i2c_acpi_register_devices(struct i2c_adapter *adap);
 
 int i2c_acpi_get_irq(struct i2c_client *client);
 #else /* CONFIG_ACPI */
 static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
-static inline const struct acpi_device_id *
-i2c_acpi_match_device(const struct acpi_device_id *matches,
- struct i2c_client *client)
+bool i2c_acpi_match_device(struct device *dev, struct i2c_client *client)
 {
-   return NULL;
+   return false;
 }
 
 static inline int i2c_acpi_get_irq(struct i2c_client *client)
-- 
2.28.0

Re: [PATCH] [v2] blk-mq: use BLK_MQ_NO_TAG for no tag

[Ming Lei]

On Wed, Aug 26, 2020 at 10:06:51AM +0800, Xianting Tian wrote:
> Replace various magic -1 constants for tags with BLK_MQ_NO_TAG.
> And move the definition of BLK_MQ_NO_TAG from 'block/blk-mq-tag.h'
> to 'include/linux/blk-mq.h'

All three symbols are supposed for block core internal code only, so
looks you shouldn't move them to public header.


Thanks, 
Ming

[PATCH 2/2] i2c: do not export i2c_of_match_device() symbol

[Sergey Senozhatsky]

Do not export i2c_of_match_device().

Signed-off-by: Sergey Senozhatsky 
---
 drivers/i2c/i2c-core-of.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 3ed74aa4b44b..77faa9cc05c9 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -223,7 +223,6 @@ const struct of_device_id
 
return i2c_of_match_device_sysfs(matches, client);
 }
-EXPORT_SYMBOL_GPL(i2c_of_match_device);
 
 #if IS_ENABLED(CONFIG_OF_DYNAMIC)
 static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
-- 
2.28.0

[PATCH 2/2] perf parse-events: Avoid an uninitialized read.

[Ian Rogers]

With a fake_pmu the pmu_info isn't populated by perf_pmu__check_alias.
In this case, don't try to copy the uninitialized values to the evsel.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/parse-events.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9f7260e69113..3d7a48b488ed 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1533,19 +1533,23 @@ int parse_events_add_pmu(struct parse_events_state 
*parse_state,
evsel = __add_event(list, _state->idx, , true,
get_config_name(head_config), pmu,
_terms, auto_merge_stats, NULL);
-   if (evsel) {
-   evsel->unit = info.unit;
-   evsel->scale = info.scale;
-   evsel->per_pkg = info.per_pkg;
-   evsel->snapshot = info.snapshot;
-   evsel->metric_expr = info.metric_expr;
-   evsel->metric_name = info.metric_name;
-   evsel->pmu_name = name ? strdup(name) : NULL;
-   evsel->use_uncore_alias = use_uncore_alias;
-   evsel->percore = config_term_percore(>config_terms);
-   }
-
-   return evsel ? 0 : -ENOMEM;
+   if (!evsel)
+   return -ENOMEM;
+
+   evsel->pmu_name = name ? strdup(name) : NULL;
+   evsel->use_uncore_alias = use_uncore_alias;
+   evsel->percore = config_term_percore(>config_terms);
+
+   if (parse_state->fake_pmu)
+   return 0;
+
+   evsel->unit = info.unit;
+   evsel->scale = info.scale;
+   evsel->per_pkg = info.per_pkg;
+   evsel->snapshot = info.snapshot;
+   evsel->metric_expr = info.metric_expr;
+   evsel->metric_name = info.metric_name;
+   return 0;
 }
 
 int parse_events_multi_pmu_add(struct parse_events_state *parse_state,
-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH 1/2] perf expr: Force encapsulation on expr_id_data

[Ian Rogers]

This patch resolves some undefined behavior where variables in
expr_id_data were accessed (for debugging) without being defined. To
better enforce the tagged union behavior, the struct is moved into
expr.c and accessors provided. Tag values (kinds) are explicitly
identified.

Signed-off-by: Ian Rogers 
---
 tools/perf/util/expr.c| 64 ++-
 tools/perf/util/expr.h| 17 +++---
 tools/perf/util/expr.y|  2 +-
 tools/perf/util/metricgroup.c |  4 +--
 4 files changed, 62 insertions(+), 25 deletions(-)

diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index 53482ef53c41..1ca0992db86b 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -17,6 +17,25 @@
 extern int expr_debug;
 #endif
 
+struct expr_id_data {
+   union {
+   double val;
+   struct {
+   double val;
+   const char *metric_name;
+   const char *metric_expr;
+   } ref;
+   struct expr_id  *parent;
+   };
+
+   enum {
+   EXPR_ID_DATA__VALUE,
+   EXPR_ID_DATA__REF,
+   EXPR_ID_DATA__REF_VALUE,
+   EXPR_ID_DATA__PARENT,
+   } kind;
+};
+
 static size_t key_hash(const void *key, void *ctx __maybe_unused)
 {
const char *str = (const char *)key;
@@ -48,6 +67,7 @@ int expr__add_id(struct expr_parse_ctx *ctx, const char *id)
return -ENOMEM;
 
data_ptr->parent = ctx->parent;
+   data_ptr->kind = EXPR_ID_DATA__PARENT;
 
ret = hashmap__set(>ids, id, data_ptr,
   (const void **)_key, (void **)_data);
@@ -69,7 +89,7 @@ int expr__add_id_val(struct expr_parse_ctx *ctx, const char 
*id, double val)
if (!data_ptr)
return -ENOMEM;
data_ptr->val = val;
-   data_ptr->is_ref = false;
+   data_ptr->kind = EXPR_ID_DATA__VALUE;
 
ret = hashmap__set(>ids, id, data_ptr,
   (const void **)_key, (void **)_data);
@@ -114,8 +134,7 @@ int expr__add_ref(struct expr_parse_ctx *ctx, struct 
metric_ref *ref)
 */
data_ptr->ref.metric_name = ref->metric_name;
data_ptr->ref.metric_expr = ref->metric_expr;
-   data_ptr->ref.counted = false;
-   data_ptr->is_ref = true;
+   data_ptr->kind = EXPR_ID_DATA__REF;
 
ret = hashmap__set(>ids, name, data_ptr,
   (const void **)_key, (void **)_data);
@@ -148,17 +167,30 @@ int expr__resolve_id(struct expr_parse_ctx *ctx, const 
char *id,
 
data = *datap;
 
-   pr_debug2("lookup: is_ref %d, counted %d, val %f: %s\n",
- data->is_ref, data->ref.counted, data->val, id);
-
-   if (data->is_ref && !data->ref.counted) {
-   data->ref.counted = true;
+   switch (data->kind) {
+   case EXPR_ID_DATA__VALUE:
+   pr_debug2("lookup(%s): val %f\n", id, data->val);
+   break;
+   case EXPR_ID_DATA__PARENT:
+   pr_debug2("lookup(%s): parent %s\n", id, data->parent->id);
+   break;
+   case EXPR_ID_DATA__REF:
+   pr_debug2("lookup(%s): ref metric name %s\n", id,
+   data->ref.metric_name);
pr_debug("processing metric: %s ENTRY\n", id);
-   if (expr__parse(>val, ctx, data->ref.metric_expr, 1)) {
+   data->kind = EXPR_ID_DATA__REF_VALUE;
+   if (expr__parse(>ref.val, ctx, data->ref.metric_expr, 1)) 
{
pr_debug("%s failed to count\n", id);
return -1;
}
pr_debug("processing metric: %s EXIT: %f\n", id, data->val);
+   break;
+   case EXPR_ID_DATA__REF_VALUE:
+   pr_debug2("lookup(%s): ref val %f metric name %s\n", id,
+   data->ref.val, data->ref.metric_name);
+   break;
+   default:
+   assert(0);  /* Unreachable. */
}
 
return 0;
@@ -241,3 +273,17 @@ int expr__find_other(const char *expr, const char *one,
 
return ret;
 }
+
+double expr_id_data__value(const struct expr_id_data *data)
+{
+   if (data->kind == EXPR_ID_DATA__VALUE)
+   return data->val;
+   assert(data->kind == EXPR_ID_DATA__REF_VALUE);
+   return data->ref.val;
+}
+
+struct expr_id *expr_id_data__parent(struct expr_id_data *data)
+{
+   assert(data->kind == EXPR_ID_DATA__PARENT);
+   return data->parent;
+}
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index fc2b5e824a66..dcf8d19b83c8 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -23,19 +23,7 @@ struct expr_parse_ctx {
struct expr_id  *parent;
 };
 
-struct expr_id_data {
-   union {
-   double val;
-   struct {
-   const char *metric_name;
-   const char *metric_expr;
-  

RE: [PATCH v3] exfat: integrates dir-entry getting and validation

[Namjae Jeon]

> On 2020/08/26 10:03, Namjae Jeon wrote:
> >> Second: Range validation and type validation should not be separated.
> >> When I started making this patch, I intended to add only range validation.
> >> However, after the caller gets the ep, the type validation follows.
> >> Get ep, null check of ep (= range verification), type verification is a 
> >> series of procedures.
> >> There would be no reason to keep them independent anymore.
> >> Range and type validation is enforced when the caller uses ep.
> > You can add a validate flags as argument of exfat_get_dentry_set(), e.g. 
> > none, basic and strict.
> > none : only range validation.
> > basic : range + type validation.
> > strict : range + type + checksum and name length, etc.
> 
> Currently, various types of verification will not be needed.
> Let's add it when we need it.
> >
> >>> - /* validiate cached dentries */
> >>> - for (i = 1; i < num_entries; i++) {
> >>> - ep = exfat_get_dentry_cached(es, i);
> >>> - if (!exfat_validate_entry(exfat_get_entry_type(ep), ))
> >>> + ep = exfat_get_dentry_cached(es, ENTRY_STREAM);
> >>> + if (!ep || ep->type != EXFAT_STREAM)
> >>> + goto free_es;
> >>> + es->de[ENTRY_STREAM] = ep;
> >>
> >> The value contained in stream-ext dir-entry should not be used before 
> >> validating the EntrySet
> checksum.
> >> So I would insert EntrySet checksum validation here.
> >> In that case, the checksum verification loop would be followed by the
> >> TYPE_NAME verification loop, can you acceptable?
> > Yes. That would be great.
> 
> OK.
> I'll add TYPE_NAME verification after checksum verification, in next patch.
> However, I think it is enough to validate TYPE_NAME when extracting name.
> Could you please tell me why you think you need TYPE_NAME validation here?
I've told you on previous mail. This function should return validated dentry 
set after checking
file->stream->name in sequence.
> 
> 
> BR
> ---
> Tetsuhiro Kohada 
> >

Re: [PATCH] dt-bindings: convert spmi.txt to spmi.yaml

[Mauro Carvalho Chehab]

Em Wed, 19 Aug 2020 17:08:12 -0600
Rob Herring  escreveu:

> Need to also define 'reg' constraints as defined by the bus:
> 
> properties:
>   reg:
> minItems: 1
> maxItems: 2  #??? Not sure about this. Is it 1 SPMI_USID and 1 \
> SPMI_GSID entry at most?


Each child have just one user ID (SPMI_USID). The group ID (SPMI_GSID) is an 
optional feature. From what I know, only one group ID is allowed at most.
So, maxItems: 2 makes sense.


> items:
>   items:
> - minimum: 0
>   maximum: 0xf
> - enum: [ 0, 1 ]

If I use both maxItems:2 and the above, the example produces the following
error:


/devel/v4l/temp/Documentation/devicetree/bindings/spmi/spmi.example.dt.yaml: 
spmi@0: child@7:reg: Additional items are not allowed ([3, 1] was unexpected)

(full DT file enclosed)

This seems to be some bug at the parsing logic, which seems to be refusing
to accept both "items" and "maxItems".

-

That's said, looking at the code[1], only SPMI_USID is currently supported:

err = of_property_read_u32_array(node, "reg", reg, 2);
if (err) {
dev_err(>dev,
"node %pOF err (%d) does not have 'reg' 
property\n",
node, err);
continue;
}

if (reg[1] != SPMI_USID) {
dev_err(>dev,
"node %pOF contains unsupported 'reg' entry\n",
node);
continue;
}

if (reg[0] >= SPMI_MAX_SLAVE_ID) {
dev_err(>dev, "invalid usid on node %pOF\n", 
node);
continue;
}

So, for now, using SPMI_GSID will fail.

[1] drivers/spmi/spmi.c

So, I'm inclined to define reg property as:

properties:
  reg:
minItems: 1
maxItems: 2
items:
  - minimum: 0
maximum: 0xf
  - enum: [ 0 ]
description: |
  0 means user ID address. 1 is reserved for group ID address.

And drop the group ID from the example. I'll send such version as a
second version of this patch.

Thanks,
Mauro


# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/spmi/spmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: System Power Management Interface (SPMI) Controller

maintainers:
  - Josh Cartwright 

description: |
  The System Power Management (SPMI) controller is a 2-wire bus defined
  by the MIPI Alliance for power management control to be used on SoC designs.

  SPMI controllers are modelled in device tree using a generic set of
  bindings defined here, plus any bus controller specific properties, if
  needed.

  Each SPMI controller has zero or more child nodes (up to 16 ones), each
  one representing an unique slave at the bus.

properties:
  $nodename:
pattern: "spmi@.*"

  reg:
maxItems: 1

  "#address-cells":
const: 2

  "#size-cells":
const: 0

patternProperties:
  ".*@([0-9]|1[0-5])$":
description: up to 16 child PMIC nodes
type: object

properties:
  reg:
minItems: 1
maxItems: 2
items:
  - minimum: 0
maximum: 0xf
  - enum: [ 0, 1 ]

required:
  - reg

required:
  - reg

examples:
  - |
#include 

spmi@0 {
  reg = <0 0>;

  #address-cells = <2>;
  #size-cells = <0>;

  child@0 {
reg = <0 SPMI_USID>;
  };

  child@7 {
reg = <7 SPMI_USID>,
  <3 SPMI_GSID>;
  };
};

Re: [PATCH 2/2] media: v4l2-mem2mem: simplify poll logic a bit

[Ezequiel Garcia]

Hi Alexandre,

On Tue, 25 Aug 2020 at 11:56, Alexandre Courbot  wrote:
>
> Factorize redundant checks into a single code block, remove the early
> return, and declare variables in their innermost block. Hopefully this
> makes this code a little bit easier to follow.
>

This _definitely_ makes the poll handling more readable.

Reviewed-by: Ezequiel Garcia 

See below a nitpick.

> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/media/v4l2-core/v4l2-mem2mem.c | 35 +++---
>  1 file changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
> b/drivers/media/v4l2-core/v4l2-mem2mem.c
> index 0d0192119af20..aeac9707123d0 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> @@ -841,7 +841,6 @@ static __poll_t v4l2_m2m_poll_for_data(struct file *file,
>struct poll_table_struct *wait)
>  {
> struct vb2_queue *src_q, *dst_q;
> -   struct vb2_buffer *src_vb = NULL, *dst_vb = NULL;
> __poll_t rc = 0;
> unsigned long flags;
>
> @@ -863,33 +862,29 @@ static __poll_t v4l2_m2m_poll_for_data(struct file 
> *file,
> return EPOLLERR;
>
> spin_lock_irqsave(_q->done_lock, flags);
> -   if (!list_empty(_q->done_list))
> -   src_vb = list_first_entry(_q->done_list, struct 
> vb2_buffer,
> -   done_entry);
> -   if (src_vb && (src_vb->state == VB2_BUF_STATE_DONE
> -   || src_vb->state == VB2_BUF_STATE_ERROR))
> -   rc |= EPOLLOUT | EPOLLWRNORM;
> +   if (!list_empty(_q->done_list)) {
> +   struct vb2_buffer *src_vb = list_first_entry(
> +   _q->done_list, struct vb2_buffer, done_entry);
> +   if (src_vb->state == VB2_BUF_STATE_DONE ||
> +   src_vb->state == VB2_BUF_STATE_ERROR)
> +   rc |= EPOLLOUT | EPOLLWRNORM;
> +   }
> spin_unlock_irqrestore(_q->done_lock, flags);
>
> spin_lock_irqsave(_q->done_lock, flags);
> -   if (list_empty(_q->done_list)) {
> +   if (!list_empty(_q->done_list)) {
> +   struct vb2_buffer *dst_vb = list_first_entry(
> +   _q->done_list, struct vb2_buffer, done_entry);
> +   if (dst_vb->state == VB2_BUF_STATE_DONE ||
> +   dst_vb->state == VB2_BUF_STATE_ERROR)
> +   rc |= EPOLLIN | EPOLLRDNORM;
> +   } else if (dst_q->last_buffer_dequeued) {
> /*
>  * If the last buffer was dequeued from the capture queue,
>  * return immediately. DQBUF will return -EPIPE.
>  */

The part about "returning immediately" doesn't make
much sense now. Could we rephrase this, keeping the -EPIPE
comment?

Thanks,
Ezequiel

> -   if (dst_q->last_buffer_dequeued) {
> -   spin_unlock_irqrestore(_q->done_lock, flags);
> -   rc |= EPOLLIN | EPOLLRDNORM;
> -   return rc;
> -   }
> -   }
> -
> -   if (!list_empty(_q->done_list))
> -   dst_vb = list_first_entry(_q->done_list, struct 
> vb2_buffer,
> -   done_entry);
> -   if (dst_vb && (dst_vb->state == VB2_BUF_STATE_DONE
> -   || dst_vb->state == VB2_BUF_STATE_ERROR))
> rc |= EPOLLIN | EPOLLRDNORM;
> +   }
> spin_unlock_irqrestore(_q->done_lock, flags);
>
> return rc;
> --
> 2.28.0
>

Re: [PATCH 1/2] media: v4l2-mem2mem: consider OUTPUT queue first when polling

[Ezequiel Garcia]

Hi Alexandre,

On Tue, 25 Aug 2020 at 11:56, Alexandre Courbot  wrote:
>
> If poll() is called on a m2m device with the EPOLLOUT event after the
> last buffer of the CAPTURE queue is dequeued, any buffer available on
> OUTPUT queue will never be signaled because v4l2_m2m_poll_for_data()
> starts by checking whether dst_q->last_buffer_dequeued is set and
> returns EPOLLIN in this case, without looking at the state of the OUTPUT
> queue.
>
> Fix this by checking the state of the OUTPUT queue before considering
> that early-return case.
>
> This also has the side-effect of bringing the two blocks of code dealing
> with the CAPTURE queue next to one another, and saves us one spin
> lock/unlock cycle, for what it's worth.
>
> Signed-off-by: Alexandre Courbot 

Change looks good to me.

Reviewed-by: Ezequiel Garcia 

Do you think it qualifies for -stable? The issue has been
here since the dawn of time.

Thanks,
Ezequiel

> ---
>  drivers/media/v4l2-core/v4l2-mem2mem.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
> b/drivers/media/v4l2-core/v4l2-mem2mem.c
> index 95a8f2dc5341d..0d0192119af20 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> @@ -862,6 +862,15 @@ static __poll_t v4l2_m2m_poll_for_data(struct file *file,
>  list_empty(_q->queued_list)))
> return EPOLLERR;
>
> +   spin_lock_irqsave(_q->done_lock, flags);
> +   if (!list_empty(_q->done_list))
> +   src_vb = list_first_entry(_q->done_list, struct 
> vb2_buffer,
> +   done_entry);
> +   if (src_vb && (src_vb->state == VB2_BUF_STATE_DONE
> +   || src_vb->state == VB2_BUF_STATE_ERROR))
> +   rc |= EPOLLOUT | EPOLLWRNORM;
> +   spin_unlock_irqrestore(_q->done_lock, flags);
> +
> spin_lock_irqsave(_q->done_lock, flags);
> if (list_empty(_q->done_list)) {
> /*
> @@ -870,21 +879,11 @@ static __poll_t v4l2_m2m_poll_for_data(struct file 
> *file,
>  */
> if (dst_q->last_buffer_dequeued) {
> spin_unlock_irqrestore(_q->done_lock, flags);
> -   return EPOLLIN | EPOLLRDNORM;
> +   rc |= EPOLLIN | EPOLLRDNORM;
> +   return rc;
> }
> }
> -   spin_unlock_irqrestore(_q->done_lock, flags);
>
> -   spin_lock_irqsave(_q->done_lock, flags);
> -   if (!list_empty(_q->done_list))
> -   src_vb = list_first_entry(_q->done_list, struct 
> vb2_buffer,
> -   done_entry);
> -   if (src_vb && (src_vb->state == VB2_BUF_STATE_DONE
> -   || src_vb->state == VB2_BUF_STATE_ERROR))
> -   rc |= EPOLLOUT | EPOLLWRNORM;
> -   spin_unlock_irqrestore(_q->done_lock, flags);
> -
> -   spin_lock_irqsave(_q->done_lock, flags);
> if (!list_empty(_q->done_list))
> dst_vb = list_first_entry(_q->done_list, struct 
> vb2_buffer,
> done_entry);
> --
> 2.28.0
>

drivers/mtd/maps/physmap-ixp4xx.c:47:22: sparse: sparse: incorrect type in argument 1 (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2ac69819ba9e3d8d550bb5d2d2df74848e556812
commit: 2aba2f2a704d368583e832555b25d88265e62b6d mtd: physmap_of: add a hook 
for Intel IXP4xx flash probing
date:   10 months ago
config: arm-randconfig-s032-20200826 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 2aba2f2a704d368583e832555b25d88265e62b6d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm 

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


sparse warnings: (new ones prefixed by >>)

   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
   drivers/mtd/maps/physmap-ixp4xx.c:42:16: sparse: sparse: cast to restricted 
__be16
>> drivers/mtd/maps/physmap-ixp4xx.c:47:22: sparse: sparse: incorrect type in 
>> argument 1 (different base types) @@ expected unsigned short [usertype] 
>> val @@ got restricted __be16 [usertype] @@
>> drivers/mtd/maps/physmap-ixp4xx.c:47:22: sparse: expected unsigned short 
>> [usertype] val
   drivers/mtd/maps/physmap-ixp4xx.c:47:22: sparse: got restricted __be16 
[usertype]

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2aba2f2a704d368583e832555b25d88265e62b6d
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2aba2f2a704d368583e832555b25d88265e62b6d
vim +47 drivers/mtd/maps/physmap-ixp4xx.c

44  
45  static inline void flash_write16(u16 d, void __iomem *addr)
46  {
  > 47  __raw_writew(cpu_to_be16(d), (void __iomem *)((unsigned 
long)addr ^ 0x2));
48  }
49  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

RE: [PATCH 3/3] usb: cdns3: Enable workaround for USB2.0 PHY Rx compliance test PHY lockup

[Pawel Laszczak]

>On 20-08-25 15:00:59, Roger Quadros wrote:
>> From: Pawel Laszczak 
>>
>> USB2.0 PHY hangs in Rx Compliance test when the incoming packet
>> amplitude is varied below and above the Squelch Level of
>> Receiver during the active packet multiple times.
>>
>> Version 1 of the controller allows PHY to be reset when RX fail condition
>> is detected to work around the above issue. This feature is
>> disabled by default and needs to be enabled using a bit from
>> the newly added PHYRST_CFG register. This patch enables the workaround.
>>
>> As there is no way to distinguish between the controller version
>> before the device controller is started we need to rely on a
>> DT property to decide when to apply the workaround.
>
>Pawel, it could know the controller version at cdns3_gadget_start,
>but the controller starts when it tries to bind gadget driver, at that
>time, it has already known the controller version.
>
>For me, the device controller starts is using USB_CONF.DEVEN (Device
>Enable) through usb_gadget_connect, I am not sure if it is the same
>with yours.
>

Yes in device mode driver knows controller version but this workaround 
Must be enabled also in host mode. In host mode the controller 
doesn't have access to device registers. The controller version is 
placed in device register.

Pawel

>Peter
>
>
>>
>> Signed-off-by: Pawel Laszczak 
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/cdns3/core.c |  2 ++
>>  drivers/usb/cdns3/core.h |  1 +
>>  drivers/usb/cdns3/drd.c  | 12 
>>  drivers/usb/cdns3/drd.h  |  5 -
>>  4 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index 5c1586ec7824..34b36487682b 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -443,6 +443,8 @@ static int cdns3_probe(struct platform_device *pdev)
>>  return -ENXIO;
>>  }
>>
>> +cdns->phyrst_a_enable = device_property_read_bool(dev, 
>> "cdns,phyrst-a-enable");
>> +
>>  cdns->otg_res = *res;
>>
>>  mutex_init(>mutex);
>> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
>> index 1ad1f1fe61e9..24cf0f1b5726 100644
>> --- a/drivers/usb/cdns3/core.h
>> +++ b/drivers/usb/cdns3/core.h
>> @@ -76,6 +76,7 @@ struct cdns3 {
>>  #define CDNS3_CONTROLLER_V0 0
>>  #define CDNS3_CONTROLLER_V1 1
>>  u32 version;
>> +boolphyrst_a_enable;
>>
>>  int otg_irq;
>>  int dev_irq;
>> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
>> index 6234bcd6158a..b74803e9703d 100644
>> --- a/drivers/usb/cdns3/drd.c
>> +++ b/drivers/usb/cdns3/drd.c
>> @@ -42,6 +42,18 @@ int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode 
>> mode)
>>  reg = readl(>otg_v1_regs->override);
>>  reg |= OVERRIDE_IDPULLUP;
>>  writel(reg, >otg_v1_regs->override);
>> +
>> +/*
>> + * Enable work around feature built into the
>> + * controller to address issue with RX Sensitivity
>> + * est (EL_17) for USB2 PHY. The issue only occures
>> + * for 0x0002450D controller version.
>> + */
>> +if (cdns->phyrst_a_enable) {
>> +reg = readl(>otg_v1_regs->phyrst_cfg);
>> +reg |= PHYRST_CFG_PHYRST_A_ENABLE;
>> +writel(reg, >otg_v1_regs->phyrst_cfg);
>> +}
>>  } else {
>>  reg = readl(>otg_v0_regs->ctrl1);
>>  reg |= OVERRIDE_IDPULLUP_V0;
>> diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
>> index 7e7cf7fa2dd3..f1ccae285a16 100644
>> --- a/drivers/usb/cdns3/drd.h
>> +++ b/drivers/usb/cdns3/drd.h
>> @@ -31,7 +31,7 @@ struct cdns3_otg_regs {
>>  __le32 simulate;
>>  __le32 override;
>>  __le32 susp_ctrl;
>> -__le32 reserved4;
>> +__le32 phyrst_cfg;
>>  __le32 anasts;
>>  __le32 adp_ramp_time;
>>  __le32 ctrl1;
>> @@ -153,6 +153,9 @@ struct cdns3_otg_common_regs {
>>  /* Only for CDNS3_CONTROLLER_V0 version */
>>  #define OVERRIDE_IDPULLUP_V0BIT(24)
>>
>> +/* PHYRST_CFG - bitmasks */
>> +#define PHYRST_CFG_PHYRST_A_ENABLE BIT(0)
>> +
>>  #define CDNS3_ID_PERIPHERAL 1
>>  #define CDNS3_ID_HOST   0
>>
>> --
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>
>--
>
>Thanks,
>Peter Chen

Re: [PATCH v2 1/6] xfrm/compat: Add 64=>32-bit messages translator

[kernel test robot]

Hi Dmitry,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on ipsec/master]
[also build test ERROR on kselftest/next linus/master v5.9-rc2 next-20200825]
[cannot apply to ipsec-next/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Safonov/xfrm-Add-compat-layer/20200826-095240
base:   https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git 
master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   net/xfrm/xfrm_compat.c: In function 'xfrm_nlmsg_put_compat':
>> net/xfrm/xfrm_compat.c:103:16: error: 'xfrm_msg_min' undeclared (first use 
>> in this function); did you mean 'xfrm_alg_len'?
 103 |  int src_len = xfrm_msg_min[type];
 |^~~~
 |xfrm_alg_len
   net/xfrm/xfrm_compat.c:103:16: note: each undeclared identifier is reported 
only once for each function it appears in
   net/xfrm/xfrm_compat.c: In function 'xfrm_xlate64':
   net/xfrm/xfrm_compat.c:260:34: error: 'xfrm_msg_min' undeclared (first use 
in this function); did you mean 'xfrm_alg_len'?
 260 |  attrs = nlmsg_attrdata(nlh_src, xfrm_msg_min[type]);
 |  ^~~~
 |  xfrm_alg_len
   net/xfrm/xfrm_compat.c: At top level:
>> net/xfrm/xfrm_compat.c:275:5: error: redefinition of 'xfrm_alloc_compat'
 275 | int xfrm_alloc_compat(struct sk_buff *skb)
 | ^
   In file included from net/xfrm/xfrm_compat.c:9:
   include/net/xfrm.h:2007:19: note: previous definition of 'xfrm_alloc_compat' 
was here
2007 | static inline int xfrm_alloc_compat(struct sk_buff *skb)
 |   ^
   In file included from arch/x86/include/asm/bug.h:93,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:15,
from include/linux/time.h:6,
from include/linux/compat.h:10,
from net/xfrm/xfrm_compat.c:7:
   net/xfrm/xfrm_compat.c: In function 'xfrm_alloc_compat':
   net/xfrm/xfrm_compat.c:282:38: error: 'xfrm_msg_min' undeclared (first use 
in this function); did you mean 'xfrm_alg_len'?
 282 |  if (WARN_ON_ONCE(type >= ARRAY_SIZE(xfrm_msg_min)))
 |  ^~~~
   include/asm-generic/bug.h:102:25: note: in definition of macro 'WARN_ON_ONCE'
 102 |  int __ret_warn_on = !!(condition);   \
 | ^
   net/xfrm/xfrm_compat.c:282:27: note: in expansion of macro 'ARRAY_SIZE'
 282 |  if (WARN_ON_ONCE(type >= ARRAY_SIZE(xfrm_msg_min)))
 |   ^~
>> include/linux/build_bug.h:16:51: error: bit-field '' width not an 
>> integer constant
  16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); 
})))
 |   ^
   include/asm-generic/bug.h:102:25: note: in definition of macro 'WARN_ON_ONCE'
 102 |  int __ret_warn_on = !!(condition);   \
 | ^
   include/linux/compiler.h:224:28: note: in expansion of macro 
'BUILD_BUG_ON_ZERO'
 224 | #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), 
&(a)[0]))
 |^
   include/linux/kernel.h:47:59: note: in expansion of macro '__must_be_array'
  47 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
__must_be_array(arr))
 |   
^~~
   net/xfrm/xfrm_compat.c:282:27: note: in expansion of macro 'ARRAY_SIZE'
 282 |  if (WARN_ON_ONCE(type >= ARRAY_SIZE(xfrm_msg_min)))
 |   ^~

# 
https://github.com/0day-ci/linux/commit/fa198f6763bf103396e06e12549e1dc00941a3d0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Dmitry-Safonov/xfrm-Add-compat-layer/20200826-095240
git checkout fa198f6763bf103396e06e12549e1dc00941a3d0
vim +103 net/xfrm/xfrm_compat.c

98  
99  static struct nlmsghdr *xfrm_nlmsg_put_compat(struct sk_buff *skb,
   100  const struct nlmsghdr 

[PATCH] audit: Remove redundant null check

[Xu Wang]

Because kfree_skb already checked NULL skb parameter,
so the additional check is unnecessary, just remove it.

Signed-off-by: Xu Wang 
---
 kernel/audit.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 7efaece534a9..144e1e9322a5 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -934,8 +934,7 @@ static void audit_free_reply(struct audit_reply *reply)
if (!reply)
return;
 
-   if (reply->skb)
-   kfree_skb(reply->skb);
+   kfree_skb(reply->skb);
if (reply->net)
put_net(reply->net);
kfree(reply);
-- 
2.17.1

mmotm 2020-08-25-20-59 uploaded

[akpm]

The mm-of-the-moment snapshot 2020-08-25-20-59 has been uploaded to

   https://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

https://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
https://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory https://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.9-rc2:
(patches marked "*" will be included in linux-next)

  origin.patch
* memcg-fix-use-after-free-in-uncharge_batch.patch
* mm-slub-fix-conversion-of-freelist_corrupted.patch
* maintainers-update-cavium-marvell-entries.patch
* maintainers-add-llvm-maintainers.patch
* lib-stringc-implement-stpcpy.patch
* mm-track-page-table-modifications-in-__apply_to_page_range.patch
* mm-track-page-table-modifications-in-__apply_to_page_range-fix.patch
* ipc-adjust-proc_ipc_sem_dointvec-definition-to-match-prototype.patch
* fork-adjust-sysctl_max_threads-definition-to-match-prototype.patch
* checkpatch-fix-the-usage-of-capture-group.patch
* mm-gup_benchmark-update-the-documentation-in-kconfig.patch
* mm-madvise-fix-vma-user-after-free.patch
* mm-migrate-fixup-setting-uffd_wp-flag.patch
* mm-rmap-fixup-copying-of-soft-dirty-and-uffd-ptes.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* fork-silence-a-false-postive-warning-in-__mmdrop.patch
* mm-slub-re-initialize-randomized-freelist-sequence-in-calculate_sizes.patch
* 
mm-slub-re-initialize-randomized-freelist-sequence-in-calculate_sizes-fix.patch
* mm-thp-swap-fix-allocating-cluster-for-swapfile-by-mistake.patch
* checkpatch-test-git_dir-changes.patch
* scripts-tagssh-exclude-tools-directory-from-tags-generation.patch
* ntfs-add-check-for-mft-record-size-in-superblock.patch
* fs-ocfs2-delete-repeated-words-in-comments.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* ramfs-support-o_tmpfile.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* mm-slub-branch-optimization-in-free-slowpath.patch
* mm-slub-fix-missing-alloc_slowpath-stat-when-bulk-alloc.patch
* mm-slub-make-add_full-condition-more-explicit.patch
* mm-kmemleak-rely-on-rcu-for-task-stack-scanning.patch
* x86-numa-cleanup-configuration-dependent-command-line-options.patch
* x86-numa-add-nohmat-option.patch
* x86-numa-add-nohmat-option-fix.patch
* efi-fake_mem-arrange-for-a-resource-entry-per-efi_fake_mem-instance.patch
* acpi-hmat-refactor-hmat_register_target_device-to-hmem_register_device.patch
* resource-report-parent-to-walk_iomem_res_desc-callback.patch
* mm-memory_hotplug-introduce-default-phys_to_target_node-implementation.patch
* 
mm-memory_hotplug-introduce-default-phys_to_target_node-implementation-fix.patch
* acpi-hmat-attach-a-device-for-each-soft-reserved-range.patch
* device-dax-drop-the-dax_regionpfn_flags-attribute.patch
* device-dax-move-instance-creation-parameters-to-struct-dev_dax_data.patch
* device-dax-make-pgmap-optional-for-instance-creation.patch
* device-dax-kill-dax_kmem_res.patch
* device-dax-add-an-allocation-interface-for-device-dax-instances.patch
* device-dax-introduce-seed-devices.patch
* drivers-base-make-device_find_child_by_name-compatible-with-sysfs-inputs.patch
* device-dax-add-resize-support.patch
* mm-memremap_pages-convert-to-struct-range.patch
* mm-memremap_pages-support-multiple-ranges-per-invocation.patch
* device-dax-add-dis-contiguous-resource-support.patch
* device-dax-introduce-mapping-devices.patch
* device-dax-make-align-a-per-device-property.patch
* device-dax-make-align-a-per-device-property-fix.patch
* device-dax-add-an-align-attribute.patch
* 

Re: [PATCH -next] irqchip/ti-sci-inta: Fix unsigned comparison to zero

[Lokesh Vutla]

On 26/08/20 9:24 am, YueHaibing wrote:
> ti_sci_inta_xlate_irq() return -ENOENT on fail, p_hwirq
> should be int type.
> 
> Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly 
> connecting to GIC")
> Signed-off-by: YueHaibing 


Acked-by: Lokesh Vutla 

Thanks and regards,
Lokesh

Re: [PATCH -next] irqchip/ti-sci-intr: Fix unsigned comparison to zero

[Lokesh Vutla]

On 26/08/20 9:23 am, YueHaibing wrote:
> ti_sci_intr_xlate_irq() return -ENOENT on fail, p_hwirq
> should be int type.
> 
> Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a 
> parent to INTR")
> Signed-off-by: YueHaibing 

Thanks for the patch.

Acked-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  drivers/irqchip/irq-ti-sci-intr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-ti-sci-intr.c 
> b/drivers/irqchip/irq-ti-sci-intr.c
> index cbc1758228d9..85a72b56177c 100644
> --- a/drivers/irqchip/irq-ti-sci-intr.c
> +++ b/drivers/irqchip/irq-ti-sci-intr.c
> @@ -137,8 +137,8 @@ static int ti_sci_intr_alloc_parent_irq(struct irq_domain 
> *domain,
>   struct ti_sci_intr_irq_domain *intr = domain->host_data;
>   struct device_node *parent_node;
>   struct irq_fwspec fwspec;
> - u16 out_irq, p_hwirq;
> - int err = 0;
> + int p_hwirq, err = 0;
> + u16 out_irq;
>  
>   out_irq = ti_sci_get_free_resource(intr->out_irqs);
>   if (out_irq == TI_SCI_RESOURCE_NULL)
> 

[PATCH -next] irqchip/ti-sci-inta: Fix unsigned comparison to zero

[YueHaibing]

ti_sci_inta_xlate_irq() return -ENOENT on fail, p_hwirq
should be int type.

Fixes: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly 
connecting to GIC")
Signed-off-by: YueHaibing 
---
 drivers/irqchip/irq-ti-sci-inta.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-ti-sci-inta.c 
b/drivers/irqchip/irq-ti-sci-inta.c
index d4e97605456b..05bf94b87b93 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -175,8 +175,8 @@ static struct ti_sci_inta_vint_desc 
*ti_sci_inta_alloc_parent_irq(struct irq_dom
struct irq_fwspec parent_fwspec;
struct device_node *parent_node;
unsigned int parent_virq;
-   u16 vint_id, p_hwirq;
-   int ret;
+   int p_hwirq, ret;
+   u16 vint_id;
 
vint_id = ti_sci_get_free_resource(inta->vint);
if (vint_id == TI_SCI_RESOURCE_NULL)
-- 
2.20.1

[PATCH -next] irqchip/ti-sci-intr: Fix unsigned comparison to zero

[YueHaibing]

ti_sci_intr_xlate_irq() return -ENOENT on fail, p_hwirq
should be int type.

Fixes: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent 
to INTR")
Signed-off-by: YueHaibing 
---
 drivers/irqchip/irq-ti-sci-intr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-ti-sci-intr.c 
b/drivers/irqchip/irq-ti-sci-intr.c
index cbc1758228d9..85a72b56177c 100644
--- a/drivers/irqchip/irq-ti-sci-intr.c
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -137,8 +137,8 @@ static int ti_sci_intr_alloc_parent_irq(struct irq_domain 
*domain,
struct ti_sci_intr_irq_domain *intr = domain->host_data;
struct device_node *parent_node;
struct irq_fwspec fwspec;
-   u16 out_irq, p_hwirq;
-   int err = 0;
+   int p_hwirq, err = 0;
+   u16 out_irq;
 
out_irq = ti_sci_get_free_resource(intr->out_irqs);
if (out_irq == TI_SCI_RESOURCE_NULL)
-- 
2.20.1

Re: [PATCH] arm64: dts: allwinner: Mark timer as stopped in suspend

[Samuel Holland]

On 8/18/20 4:10 AM, Maxime Ripard wrote:
> Hi!
> 
> On Sat, Aug 08, 2020 at 09:18:22PM -0500, Samuel Holland wrote:
>> When possible, system firmware on 64-bit Allwinner platforms disables
>> OSC24M during system suspend. Since this oscillator is the clock source
>> for the ARM architectural timer, this causes the timer to stop counting.
>> Therefore, the ARM architectural timer must not be marked as NONSTOP on
>> these platforms, or the time will be wrong after system resume.
>>
>> Adding the arm,no-tick-in-suspend property forces the kernel to ignore
>> the ARM architectural timer when calculating sleeptime; it falls back to
>> reading the RTC. Note that this only affects deep suspend, not s2idle.
>>
>> Signed-off-by: Samuel Holland 
> 
> Applied, thanks!
> 
> I assume it affects all the SoCs with a Cortex-A7 as well?

Yes, they all have the same ability to turn off OSC24M. Though they don't yet
have support for deep sleep.

Supposedly they can also reparent OSC24M from the crystal to IOSC, but I have
not got that to work, and IOSC belongs nowhere near timekeeping anyway (20%+
frequency error).

Ideally, we would run some MMIO counter off of LOSC during suspend. This would
be several orders of magnitude more accurate than the RTC for accounting
sleeptime. However, none of the basic timer blocks appear to work when OSC24M is
disabled and AHB1 is running off of LOSC; they count for about 10 cycles and
then stop.

The HSTIMER is the only timer block that I got working. It runs at the same
frequency as AHB1, so it would only be useful for timekeeping if we reparented
AHB1 to LOSC during Linux's suspend process before switching clock sources. I
doubt that is workable.

So the RTC is the best solution I know of for now.

> Maxime

Samuel

include/linux/string.h:377:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter

[kernel test robot]

Hi Karsten,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   2ac69819ba9e3d8d550bb5d2d2df74848e556812
commit: f3811fd7bc97587b142fed9edf8c726694220cb2 net/smc: send DELETE_LINK, ALL 
message and wait for send to complete
date:   4 months ago
config: arm-randconfig-r006-20200826 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f3811fd7bc97587b142fed9edf8c726694220cb2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

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

All errors (new ones prefixed by >>):

   net/smc/smc_llc.c: In function 'smc_llc_cli_conf_link':
   net/smc/smc_llc.c:754:31: warning: variable 'del_llc' set but not used 
[-Wunused-but-set-variable]
 754 |  struct smc_llc_msg_del_link *del_llc;
 |   ^~~
   net/smc/smc_llc.c: In function 'smc_llc_process_srv_delete_link':
   net/smc/smc_llc.c:1301:33: warning: variable 'del_llc_resp' set but not used 
[-Wunused-but-set-variable]
1301 |struct smc_llc_msg_del_link *del_llc_resp;
 | ^~~~
   In file included from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/net/tcp.h:19,
from net/smc/smc_llc.c:13:
   net/smc/smc_llc.c: In function 'smc_llc_add_pending_send':
   include/linux/compiler.h:350:38: error: call to '__compiletime_assert_241' 
declared with attribute error: must increase SMC_WR_BUF_SIZE to at least 
sizeof(struct smc_llc_msg)
 350 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^
   include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
 331 |prefix ## suffix();\
 |^~
   include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
 350 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   net/smc/smc_llc.c:348:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 348 |  BUILD_BUG_ON_MSG(
 |  ^~~~
   include/linux/compiler.h:350:38: error: call to '__compiletime_assert_242' 
declared with attribute error: must adapt SMC_WR_TX_SIZE to sizeof(struct 
smc_llc_msg); if not all smc_wr upper layer protocols use the same message size 
any more, must start to set link->wr_tx_sges[i].length on each individual 
smc_wr_tx_send()
 350 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^
   include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
 331 |prefix ## suffix();\
 |^~
   include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
 350 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
  39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
 | ^~
   net/smc/smc_llc.c:351:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 351 |  BUILD_BUG_ON_MSG(
 |  ^~~~
   In file included from include/linux/bitmap.h:9,
from include/linux/nodemask.h:95,
from include/linux/mmzone.h:17,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from include/linux/bvec.h:13,
from include/linux/skbuff.h:17,
from include/linux/tcp.h:17,
from include/net/tcp.h:20,
from net/smc/smc_llc.c:13:
   In function 'memcpy',
   inlined from 'smc_llc_send_message_wait' at net/smc/smc_llc.c:578:2,
   inlined from 'smc_llc_send_link_delete_all' at net/smc/smc_llc.c:1255:8:
>> include/linux/string.h:377:4: error: call to '__read_overflow2' declared 
>> with attribute error: detected read beyond size of object passed as 2nd 
>> parameter
 377 |__read_overflow2();
 |^~

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3811fd7bc97587b142fed9edf8c726694220cb2
git 

[PATCH 2/3] integrity: Move import of MokListRT certs to a separate routine

[Lenny Szubowicz]

Move the loading of certs from the UEFI MokListRT into a separate
routine to facilitate additional MokList functionality.

There is no visible functional change as a result of this patch.
Although the UEFI dbx certs are now loaded before the MokList certs,
they are loaded onto different key rings. So the order of the keys
on their respective key rings is the same.

Signed-off-by: Lenny Szubowicz 
---
 security/integrity/platform_certs/load_uefi.c | 63 +--
 1 file changed, 44 insertions(+), 19 deletions(-)

diff --git a/security/integrity/platform_certs/load_uefi.c 
b/security/integrity/platform_certs/load_uefi.c
index 253fb9a7fc98..547410d8ffa5 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -66,6 +66,43 @@ static __init void *get_cert_list(efi_char16_t *name, 
efi_guid_t *guid,
 }
 
 /*
+ * load_moklist_certs() - Load MokList certs
+ *
+ * Returns:Summary error status
+ *
+ * Load the certs contained in the UEFI MokListRT database into the
+ * platform trusted keyring.
+ */
+static int __init load_moklist_certs(void)
+{
+   efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
+   void *mok = NULL;
+   unsigned long moksize = 0;
+   efi_status_t status;
+   int rc = 0;
+
+   /* Get MokListRT. It might not exist, so it isn't an error
+* if we can't get it.
+*/
+   mok = get_cert_list(L"MokListRT", _var, , );
+   if (!mok) {
+   if (status == EFI_NOT_FOUND)
+   pr_debug("MokListRT variable wasn't found\n");
+   else
+   pr_info("Couldn't get UEFI MokListRT\n");
+   } else {
+   rc = parse_efi_signature_list("UEFI:MokListRT",
+ mok, moksize, get_handler_for_db);
+   if (rc)
+   pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
+   kfree(mok);
+   }
+   return rc;
+}
+
+/*
+ * load_uefi_certs() - Load certs from UEFI sources
+ *
  * Load the certs contained in the UEFI databases into the platform trusted
  * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist
  * keyring.
@@ -73,17 +110,16 @@ static __init void *get_cert_list(efi_char16_t *name, 
efi_guid_t *guid,
 static int __init load_uefi_certs(void)
 {
efi_guid_t secure_var = EFI_IMAGE_SECURITY_DATABASE_GUID;
-   efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
-   void *db = NULL, *dbx = NULL, *mok = NULL;
-   unsigned long dbsize = 0, dbxsize = 0, moksize = 0;
+   void *db = NULL, *dbx = NULL;
+   unsigned long dbsize = 0, dbxsize = 0;
efi_status_t status;
int rc = 0;
 
if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE))
return false;
 
-   /* Get db, MokListRT, and dbx.  They might not exist, so it isn't
-* an error if we can't get them.
+   /* Get db and dbx.  They might not exist, so it isn't an error
+* if we can't get them.
 */
if (!uefi_check_ignore_db()) {
db = get_cert_list(L"db", _var, , );
@@ -102,20 +138,6 @@ static int __init load_uefi_certs(void)
}
}
 
-   mok = get_cert_list(L"MokListRT", _var, , );
-   if (!mok) {
-   if (status == EFI_NOT_FOUND)
-   pr_debug("MokListRT variable wasn't found\n");
-   else
-   pr_info("Couldn't get UEFI MokListRT\n");
-   } else {
-   rc = parse_efi_signature_list("UEFI:MokListRT",
- mok, moksize, get_handler_for_db);
-   if (rc)
-   pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
-   kfree(mok);
-   }
-
dbx = get_cert_list(L"dbx", _var, , );
if (!dbx) {
if (status == EFI_NOT_FOUND)
@@ -131,6 +153,9 @@ static int __init load_uefi_certs(void)
kfree(dbx);
}
 
+   /* Load the MokListRT certs */
+   rc = load_moklist_certs();
+
return rc;
 }
 late_initcall(load_uefi_certs);
-- 
2.27.0

[PATCH 3/3] integrity: Load certs from the EFI MOK config table

[Lenny Szubowicz]

Because of system-specific EFI firmware limitations,
EFI volatile variables may not be capable of holding the
required contents of the Machine Owner Key (MOK) certificate
store. Therefore, an EFI boot loader may pass the MOK certs
via a EFI configuration table created specifically for this
purpose to avoid this firmware limitation.

An EFI configuration table is a much more primitive mechanism
compared to EFI variables and is well suited for one-way passage
of static information from a pre-OS environment to the kernel.

This patch adds the support to load certs from the MokListRT
entry in the MOK variable configuration table, if it's present.
The pre-existing support to load certs from the MokListRT EFI
variable remains and is used if the EFI MOK configuration table
isn't present or can't be successfully used.

Signed-off-by: Lenny Szubowicz 
---
 security/integrity/platform_certs/load_uefi.c | 22 +++
 1 file changed, 22 insertions(+)

diff --git a/security/integrity/platform_certs/load_uefi.c 
b/security/integrity/platform_certs/load_uefi.c
index 547410d8ffa5..2c9c847d9b62 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -72,6 +72,9 @@ static __init void *get_cert_list(efi_char16_t *name, 
efi_guid_t *guid,
  *
  * Load the certs contained in the UEFI MokListRT database into the
  * platform trusted keyring.
+ *
+ * This routine checks the EFI MOK config table first. If and only if
+ * that fails, this routine uses the MokListRT ordinary UEFI variable.
  */
 static int __init load_moklist_certs(void)
 {
@@ -79,8 +82,27 @@ static int __init load_moklist_certs(void)
void *mok = NULL;
unsigned long moksize = 0;
efi_status_t status;
+   struct efi_mokvar_table_entry *mokvar_entry = NULL;
int rc = 0;
 
+   /* First try to load certs from the EFI MOKvar config table.
+* It's not an error if the MOKvar config table doesn't exist
+* or the MokListRT entry is not found in it.
+*/
+   mokvar_entry = efi_mokvar_entry_find("MokListRT");
+   if (mokvar_entry) {
+   rc = parse_efi_signature_list("UEFI:MokListRT (MOKvar table)",
+ mokvar_entry->data,
+ mokvar_entry->data_size,
+ get_handler_for_db);
+   /* All done if that worked. */
+   if (!rc)
+   return rc;
+
+   pr_err("Couldn't parse MokListRT signatures from EFI MOKvar 
config table: %d\n",
+  rc);
+   }
+
/* Get MokListRT. It might not exist, so it isn't an error
 * if we can't get it.
 */
-- 
2.27.0

[PATCH 1/3] efi: Support for MOK variable config table

[Lenny Szubowicz]

Because of system-specific EFI firmware limitations,
EFI volatile variables may not be capable of holding the
required contents of the Machine Owner Key (MOK) certificate
store. Therefore, an EFI boot loader may pass the MOK certs
via a EFI configuration table created specifically for this
purpose to avoid this firmware limitation.

An EFI configuration table is a much more primitive mechanism
compared to EFI variables and is well suited for one-way passage
of static information from a pre-OS environment to the kernel.

This patch adds initial kernel support to recognize, parse,
and validate the EFI MOK configuration table, where named
entries contain the same data that would otherwise be provided
in a similarly named EFI variable.

Additionally, this patch creates a sysfs binary file for each
EFI MOK configuration table entry found. These are provided
for use by user space utilities such as mokutil.

A subsequent patch will load MOK certs into the trusted platform
key ring using this infrastructure.

Signed-off-by: Lenny Szubowicz 
---
 arch/x86/kernel/setup.c |   1 +
 arch/x86/platform/efi/efi.c |   3 +
 drivers/firmware/efi/Makefile   |   1 +
 drivers/firmware/efi/arm-init.c |   1 +
 drivers/firmware/efi/efi.c  |   6 +
 drivers/firmware/efi/mokvar-table.c | 360 
 include/linux/efi.h |  34 +++
 7 files changed, 406 insertions(+)
 create mode 100644 drivers/firmware/efi/mokvar-table.c

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3511736fbc74..d41be0df72f8 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1077,6 +1077,7 @@ void __init setup_arch(char **cmdline_p)
efi_fake_memmap();
efi_find_mirror();
efi_esrt_init();
+   efi_mokvar_table_init();
 
/*
 * The EFI specification says that boot service code won't be
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index d37ebe6e70d7..8a26e705cb06 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -90,6 +90,9 @@ static const unsigned long * const efi_tables[] = {
_log,
_final_log,
_rng_seed,
+#ifdef CONFIG_LOAD_UEFI_KEYS
+   _table,
+#endif
 };
 
 u64 efi_setup; /* efi setup_data physical address */
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 7a216984552b..03964e2d27c5 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_EFI_DEV_PATH_PARSER) += dev-path-parser.o
 obj-$(CONFIG_APPLE_PROPERTIES) += apple-properties.o
 obj-$(CONFIG_EFI_RCI2_TABLE)   += rci2-table.o
 obj-$(CONFIG_EFI_EMBEDDED_FIRMWARE)+= embedded-firmware.o
+obj-$(CONFIG_LOAD_UEFI_KEYS)   += mokvar-table.o
 
 fake_map-y += fake_mem.o
 fake_map-$(CONFIG_X86) += x86_fake_mem.o
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 71c445d20258..f55a92ff12c0 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -236,6 +236,7 @@ void __init efi_init(void)
 
reserve_regions();
efi_esrt_init();
+   efi_mokvar_table_init();
 
memblock_reserve(data.phys_map & PAGE_MASK,
 PAGE_ALIGN(data.size + (data.phys_map & ~PAGE_MASK)));
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3aa07c3b5136..3d4daf215e19 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -43,6 +43,9 @@ struct efi __read_mostly efi = {
.esrt   = EFI_INVALID_TABLE_ADDR,
.tpm_log= EFI_INVALID_TABLE_ADDR,
.tpm_final_log  = EFI_INVALID_TABLE_ADDR,
+#ifdef CONFIG_LOAD_UEFI_KEYS
+   .mokvar_table   = EFI_INVALID_TABLE_ADDR,
+#endif
 };
 EXPORT_SYMBOL(efi);
 
@@ -518,6 +521,9 @@ static const efi_config_table_type_t common_tables[] 
__initconst = {
{EFI_RT_PROPERTIES_TABLE_GUID,  _prop,   
"RTPROP"},
 #ifdef CONFIG_EFI_RCI2_TABLE
{DELLEMC_EFI_RCI2_TABLE_GUID,   _table_phys
},
+#endif
+#ifdef CONFIG_LOAD_UEFI_KEYS
+   {LINUX_EFI_MOK_VARIABLE_TABLE_GUID, _table,  
"MOKvar"},
 #endif
{},
 };
diff --git a/drivers/firmware/efi/mokvar-table.c 
b/drivers/firmware/efi/mokvar-table.c
new file mode 100644
index ..f12f1710f5d9
--- /dev/null
+++ b/drivers/firmware/efi/mokvar-table.c
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * mokvar-table.c
+ *
+ * Copyright (c) 2020 Red Hat
+ * Author: Lenny Szubowicz 
+ *
+ * This module contains the kernel support for the Linux EFI Machine
+ * Owner Key (MOK) variable configuration table, which is identified by
+ * the LINUX_EFI_MOK_VARIABLE_TABLE_GUID.
+ *
+ * This EFI configuration table provides a more robust alternative to
+ * EFI volatile 

[PATCH 0/3] integrity: Load certs from EFI MOK config table

[Lenny Szubowicz]

Because of system-specific EFI firmware limitations,
EFI volatile variables may not be capable of holding the
required contents of the Machine Owner Key (MOK) certificate
store. Therefore, an EFI boot loader may pass the MOK certs
via a EFI configuration table created specifically for this
purpose to avoid this firmware limitation.

An EFI configuration table is a simpler and more robust mechanism
compared to EFI variables and is well suited for one-way passage
of static information from a pre-OS environment to the kernel.

This patch set does not remove the support for loading certs
from the EFI MOK variables into the platform key ring.
However, if both the EFI MOK config table and corresponding
EFI MOK variables are present, the MOK table is used as the
source of MOK certs.

The contents of the individual named MOK config table entries are
made available to user space via read-only sysfs binary files under:

/sys/firmware/efi/mok-variables/


Lenny Szubowicz (3):
  efi: Support for MOK variable config table
  integrity: Move import of MokListRT certs to a separate routine
  integrity: Load certs from the EFI MOK config table

 arch/x86/kernel/setup.c   |   1 +
 arch/x86/platform/efi/efi.c   |   3 +
 drivers/firmware/efi/Makefile |   1 +
 drivers/firmware/efi/arm-init.c   |   1 +
 drivers/firmware/efi/efi.c|   6 +
 drivers/firmware/efi/mokvar-table.c   | 360 ++
 include/linux/efi.h   |  34 ++
 security/integrity/platform_certs/load_uefi.c |  85 -
 8 files changed, 472 insertions(+), 19 deletions(-)
 create mode 100644 drivers/firmware/efi/mokvar-table.c

-- 
2.27.0

Re: [PATCH v1 3/9] phy: qcom-qmp: Remove 'initialized' in favor of 'init_count'

[Bjorn Andersson]

On Tue 25 Aug 21:47 CDT 2020, Stephen Boyd wrote:

> We already track if any phy inside the qmp wrapper has been initialized
> by means of the struct qcom_qmp::init_count member. Let's drop the
> duplicate 'initialized' member to simplify the code a bit.
> 
> Cc: Jeykumar Sankaran 
> Cc: Chandan Uddaraju 
> Cc: Vara Reddy 
> Cc: Tanmay Shah 
> Cc: Bjorn Andersson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Cc: Manu Gautam 
> Cc: Sandeep Maheswaram 
> Cc: Douglas Anderson 
> Cc: Sean Paul 
> Cc: Jonathan Marek 
> Cc: Dmitry Baryshkov 
> Cc: Rob Clark 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 7ee9e966dc6d..4a23ba9361b3 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1844,7 +1844,6 @@ struct qmp_phy {
>   * @phys: array of per-lane phy descriptors
>   * @phy_mutex: mutex lock for PHY common block initialization
>   * @init_count: phy common block initialization count
> - * @phy_initialized: indicate if PHY has been initialized
>   * @ufs_reset: optional UFS PHY reset handle
>   */
>  struct qcom_qmp {
> @@ -1861,7 +1860,6 @@ struct qcom_qmp {
>  
>   struct mutex phy_mutex;
>   int init_count;
> - bool phy_initialized;
>  
>   struct reset_control *ufs_reset;
>  };
> @@ -2748,7 +2746,6 @@ static int qcom_qmp_phy_enable(struct phy *phy)
>   dev_err(qmp->dev, "phy initialization timed-out\n");
>   goto err_pcs_ready;
>   }
> - qmp->phy_initialized = true;
>   return 0;
>  
>  err_pcs_ready:
> @@ -2792,8 +2789,6 @@ static int qcom_qmp_phy_disable(struct phy *phy)
>  
>   qcom_qmp_phy_com_exit(qmp);
>  
> - qmp->phy_initialized = false;
> -
>   return 0;
>  }
>  
> @@ -2868,7 +2863,7 @@ static int __maybe_unused 
> qcom_qmp_phy_runtime_suspend(struct device *dev)
>   if (cfg->type != PHY_TYPE_USB3)
>   return 0;
>  
> - if (!qmp->phy_initialized) {
> + if (!qmp->init_count) {
>   dev_vdbg(dev, "PHY not initialized, bailing out\n");
>   return 0;
>   }
> @@ -2894,7 +2889,7 @@ static int __maybe_unused 
> qcom_qmp_phy_runtime_resume(struct device *dev)
>   if (cfg->type != PHY_TYPE_USB3)
>   return 0;
>  
> - if (!qmp->phy_initialized) {
> + if (!qmp->init_count) {
>   dev_vdbg(dev, "PHY not initialized, bailing out\n");
>   return 0;
>   }
> -- 
> Sent by a computer, using git, on the internet
> 

Re: [PATCH v1 2/9] phy: qcom-qmp: Move phy mode into struct qmp_phy

[Bjorn Andersson]

On Tue 25 Aug 21:47 CDT 2020, Stephen Boyd wrote:

> The phy mode pertains to the phy itself, i.e. 'struct qmp_phy', not the
> wrapper, i.e. 'struct qcom_qmp'. Move the phy mode into the phy
> structure to more accurately reflect what is going on. This also cleans
> up 'struct qcom_qmp' so that it can eventually be the place where qmp
> wrapper wide data is located, paving the way for the USB3+DP combo phy.
> 
> Cc: Jeykumar Sankaran 
> Cc: Chandan Uddaraju 
> Cc: Vara Reddy 
> Cc: Tanmay Shah 
> Cc: Bjorn Andersson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Cc: Manu Gautam 
> Cc: Sandeep Maheswaram 
> Cc: Douglas Anderson 
> Cc: Sean Paul 
> Cc: Jonathan Marek 
> Cc: Dmitry Baryshkov 
> Cc: Rob Clark 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 562053ce9455..7ee9e966dc6d 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1812,6 +1812,7 @@ struct qmp_phy_cfg {
>   * @index: lane index
>   * @qmp: QMP phy to which this lane belongs
>   * @lane_rst: lane's reset controller
> + * @mode: current PHY mode
>   */
>  struct qmp_phy {
>   struct phy *phy;
> @@ -1825,6 +1826,7 @@ struct qmp_phy {
>   unsigned int index;
>   struct qcom_qmp *qmp;
>   struct reset_control *lane_rst;
> + enum phy_mode mode;
>  };
>  
>  /**
> @@ -1843,7 +1845,6 @@ struct qmp_phy {
>   * @phy_mutex: mutex lock for PHY common block initialization
>   * @init_count: phy common block initialization count
>   * @phy_initialized: indicate if PHY has been initialized
> - * @mode: current PHY mode
>   * @ufs_reset: optional UFS PHY reset handle
>   */
>  struct qcom_qmp {
> @@ -1861,7 +1862,6 @@ struct qcom_qmp {
>   struct mutex phy_mutex;
>   int init_count;
>   bool phy_initialized;
> - enum phy_mode mode;
>  
>   struct reset_control *ufs_reset;
>  };
> @@ -2801,9 +2801,8 @@ static int qcom_qmp_phy_set_mode(struct phy *phy,
>enum phy_mode mode, int submode)
>  {
>   struct qmp_phy *qphy = phy_get_drvdata(phy);
> - struct qcom_qmp *qmp = qphy->qmp;
>  
> - qmp->mode = mode;
> + qphy->mode = mode;
>  
>   return 0;
>  }
> @@ -2816,8 +2815,8 @@ static void qcom_qmp_phy_enable_autonomous_mode(struct 
> qmp_phy *qphy)
>   void __iomem *pcs_misc = qphy->pcs_misc;
>   u32 intr_mask;
>  
> - if (qmp->mode == PHY_MODE_USB_HOST_SS ||
> - qmp->mode == PHY_MODE_USB_DEVICE_SS)
> + if (qphy->mode == PHY_MODE_USB_HOST_SS ||
> + qphy->mode == PHY_MODE_USB_DEVICE_SS)
>   intr_mask = ARCVR_DTCT_EN | ALFPS_DTCT_EN;
>   else
>   intr_mask = ARCVR_DTCT_EN | ARCVR_DTCT_EVENT_SEL;
> @@ -2863,7 +2862,7 @@ static int __maybe_unused 
> qcom_qmp_phy_runtime_suspend(struct device *dev)
>   struct qmp_phy *qphy = qmp->phys[0];
>   const struct qmp_phy_cfg *cfg = qmp->cfg;
>  
> - dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
> + dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qphy->mode);
>  
>   /* Supported only for USB3 PHY */
>   if (cfg->type != PHY_TYPE_USB3)
> @@ -2889,7 +2888,7 @@ static int __maybe_unused 
> qcom_qmp_phy_runtime_resume(struct device *dev)
>   const struct qmp_phy_cfg *cfg = qmp->cfg;
>   int ret = 0;
>  
> - dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
> + dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qphy->mode);
>  
>   /* Supported only for USB3 PHY */
>   if (cfg->type != PHY_TYPE_USB3)
> -- 
> Sent by a computer, using git, on the internet
> 

Re: [PATCH 5/9] iomap: Support arbitrarily many blocks per page

[Darrick J. Wong]

On Wed, Aug 26, 2020 at 03:26:23AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 25, 2020 at 02:02:03PM -0700, Darrick J. Wong wrote:
> > >  /*
> > > - * Structure allocated for each page when block size < PAGE_SIZE to track
> > > + * Structure allocated for each page when block size < page size to track
> > >   * sub-page uptodate status and I/O completions.
> > 
> > "for each regular page or head page of a huge page"?  Or whatever we're
> > calling them nowadays?
> 
> Well, that's what I'm calling a "page" ;-)
> 
> How about "for each page or THP"?  The fact that it's stored in the
> head page is incidental -- it's allocated for the THP.

Ok.

--D

Re: [PATCH v1 1/1] extcon: ptn5150: Add usb-typec support for Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi,

  Thank you very much for the review comments...

On 25/8/2020 6:46 pm, Chanwoo Choi wrote:

Hi,

On 8/25/20 5:31 PM, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Add usb-typec detection support for Intel LGM SoC based
boards.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
  drivers/extcon/extcon-ptn5150.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8ba706fad887..60355a1b5cb2 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -300,6 +300,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
return ret;
}
  
+	extcon_set_property_capability(info->edev, EXTCON_USB_HOST,

+  EXTCON_PROP_USB_TYPEC_POLARITY);


extcon_set_property_capability() just sets the capability
of EXTCON_PROP_USB_TYPEC_POLARITY property.

If you want to set the value (0 or 1) of EXTCON_PROP_USB_TYPEC_POLARITY,
we have to call extcon_set_property() function. But, this patch doesn't
set the any value of EXTCON_PROP_USB_TYPEC_POLARITY property.

Why do you only use extcon_set_property_capability()
without the proper extcon_set_property()?


In extcon-ptn5150.c driver, we are not setting the capability of the 
EXTCON_PROP_USB_TYPEC_POLARITY
and EXTCON_PROP_USB_VBUS, so USB-PHY driver try to get the value of 
POLARITY capability by
calling extcon_get_property(), it returns error'ed value because we 
didn't set it.


In drivers/extcon/extcon.c, below code snippet returns errored value.
/* Check whether the property is supported or not */
if (!is_extcon_property_supported(id, prop))
return -EINVAL;

To avoid the above condition, refered and followed the same from 
drivers/extcon/extcon-usbc-cros-ec.c

   extcon_set_property_capability(info->edev, EXTCON_USB,
   EXTCON_PROP_USB_VBUS);
extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
   EXTCON_PROP_USB_VBUS);
extcon_set_property_capability(info->edev, EXTCON_USB,
   EXTCON_PROP_USB_TYPEC_POLARITY);
   .


after that, we follow the same to set the property capability then no 
error'ed value,

it's working properly.

Yes, you're right we can use extcon_set_property() API as well.

I can update the code like below...
	 
extcon_set_property(info->edev,EXTCON_USB_HOST,EXTCON_PROP_USB_TYPEC_POLARITY, 
flipped);


Regards
Vadivel




/* Initialize PTN5150 device and print vendor id and version id */
ret = ptn5150_init_dev_type(info);
if (ret)

Re: [PATCH 3/3] usb: cdns3: Enable workaround for USB2.0 PHY Rx compliance test PHY lockup

[Peter Chen]

On 20-08-25 15:00:59, Roger Quadros wrote:
> From: Pawel Laszczak 
> 
> USB2.0 PHY hangs in Rx Compliance test when the incoming packet
> amplitude is varied below and above the Squelch Level of
> Receiver during the active packet multiple times.
> 
> Version 1 of the controller allows PHY to be reset when RX fail condition
> is detected to work around the above issue. This feature is
> disabled by default and needs to be enabled using a bit from
> the newly added PHYRST_CFG register. This patch enables the workaround.
> 
> As there is no way to distinguish between the controller version
> before the device controller is started we need to rely on a
> DT property to decide when to apply the workaround.

Pawel, it could know the controller version at cdns3_gadget_start,
but the controller starts when it tries to bind gadget driver, at that
time, it has already known the controller version.

For me, the device controller starts is using USB_CONF.DEVEN (Device
Enable) through usb_gadget_connect, I am not sure if it is the same
with yours.

Peter


> 
> Signed-off-by: Pawel Laszczak 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/cdns3/core.c |  2 ++
>  drivers/usb/cdns3/core.h |  1 +
>  drivers/usb/cdns3/drd.c  | 12 
>  drivers/usb/cdns3/drd.h  |  5 -
>  4 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 5c1586ec7824..34b36487682b 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -443,6 +443,8 @@ static int cdns3_probe(struct platform_device *pdev)
>   return -ENXIO;
>   }
>  
> + cdns->phyrst_a_enable = device_property_read_bool(dev, 
> "cdns,phyrst-a-enable");
> +
>   cdns->otg_res = *res;
>  
>   mutex_init(>mutex);
> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
> index 1ad1f1fe61e9..24cf0f1b5726 100644
> --- a/drivers/usb/cdns3/core.h
> +++ b/drivers/usb/cdns3/core.h
> @@ -76,6 +76,7 @@ struct cdns3 {
>  #define CDNS3_CONTROLLER_V0  0
>  #define CDNS3_CONTROLLER_V1  1
>   u32 version;
> + boolphyrst_a_enable;
>  
>   int otg_irq;
>   int dev_irq;
> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
> index 6234bcd6158a..b74803e9703d 100644
> --- a/drivers/usb/cdns3/drd.c
> +++ b/drivers/usb/cdns3/drd.c
> @@ -42,6 +42,18 @@ int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode 
> mode)
>   reg = readl(>otg_v1_regs->override);
>   reg |= OVERRIDE_IDPULLUP;
>   writel(reg, >otg_v1_regs->override);
> +
> + /*
> +  * Enable work around feature built into the
> +  * controller to address issue with RX Sensitivity
> +  * est (EL_17) for USB2 PHY. The issue only occures
> +  * for 0x0002450D controller version.
> +  */
> + if (cdns->phyrst_a_enable) {
> + reg = readl(>otg_v1_regs->phyrst_cfg);
> + reg |= PHYRST_CFG_PHYRST_A_ENABLE;
> + writel(reg, >otg_v1_regs->phyrst_cfg);
> + }
>   } else {
>   reg = readl(>otg_v0_regs->ctrl1);
>   reg |= OVERRIDE_IDPULLUP_V0;
> diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
> index 7e7cf7fa2dd3..f1ccae285a16 100644
> --- a/drivers/usb/cdns3/drd.h
> +++ b/drivers/usb/cdns3/drd.h
> @@ -31,7 +31,7 @@ struct cdns3_otg_regs {
>   __le32 simulate;
>   __le32 override;
>   __le32 susp_ctrl;
> - __le32 reserved4;
> + __le32 phyrst_cfg;
>   __le32 anasts;
>   __le32 adp_ramp_time;
>   __le32 ctrl1;
> @@ -153,6 +153,9 @@ struct cdns3_otg_common_regs {
>  /* Only for CDNS3_CONTROLLER_V0 version */
>  #define OVERRIDE_IDPULLUP_V0 BIT(24)
>  
> +/* PHYRST_CFG - bitmasks */
> +#define PHYRST_CFG_PHYRST_A_ENABLE BIT(0)
> +
>  #define CDNS3_ID_PERIPHERAL  1
>  #define CDNS3_ID_HOST0
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

-- 

Thanks,
Peter Chen

[PATCH] ptp: ptp_ines: Remove redundant null check

[Xu Wang]

Because kfree_skb already checked NULL skb parameter,
so the additional check is unnecessary, just remove it.

Signed-off-by: Xu Wang 
---
 drivers/ptp/ptp_ines.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/ptp/ptp_ines.c b/drivers/ptp/ptp_ines.c
index 7711651ff19e..2c1fb99aa37c 100644
--- a/drivers/ptp/ptp_ines.c
+++ b/drivers/ptp/ptp_ines.c
@@ -663,8 +663,7 @@ static void ines_txtstamp(struct mii_timestamper *mii_ts,
 
spin_unlock_irqrestore(>lock, flags);
 
-   if (old_skb)
-   kfree_skb(old_skb);
+   kfree_skb(old_skb);
 
schedule_delayed_work(>ts_work, 1);
 }
-- 
2.17.1

[PATCH net] drivers/net/wan/lapbether: Set network_header before transmitting

[Xie He]

Set the skb's network_header before it is passed to the underlying
Ethernet device for transmission.

This patch fixes the following issue:

When we use this driver with AF_PACKET sockets, there would be error
messages of:
   protocol 0805 is buggy, dev (Ethernet interface name)
printed in the system "dmesg" log.

This is because skbs passed down to the Ethernet device for transmission
don't have their network_header properly set, and the dev_queue_xmit_nit
function in net/core/dev.c complains about this.

Reason of setting the network_header to this place (at the end of the
Ethernet header, and at the beginning of the Ethernet payload):

Because when this driver receives an skb from the Ethernet device, the
network_header is also set at this place.

Cc: Martin Schiller 
Signed-off-by: Xie He 
---
 drivers/net/wan/lapbether.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index cc297ea9c6ec..e61616b0b91c 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.c
@@ -210,6 +210,8 @@ static void lapbeth_data_transmit(struct net_device *ndev, 
struct sk_buff *skb)
 
skb->dev = dev = lapbeth->ethdev;
 
+   skb_reset_network_header(skb);
+
dev_hard_header(skb, dev, ETH_P_DEC, bcast_addr, NULL, 0);
 
dev_queue_xmit(skb);
-- 
2.25.1

[PATCH 1/1] iommu/vt-d: Serialize IOMMU GCMD register modifications

[Lu Baolu]

The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General
Description) that:

If multiple control fields in this register need to be modified, software
must serialize the modifications through multiple writes to this register.

However, in irq_remapping.c, modifications of IRE and CFI are done in one
write. We need to do two separate writes with STS checking after each.

Fixes: af8d102f999a4 ("x86/intel/irq_remapping: Clean up x2apic opt-out 
security warning mess")
Cc: Andy Lutomirski 
Cc: Jacob Pan 
Signed-off-by: Lu Baolu 
---
 drivers/iommu/intel/irq_remapping.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel/irq_remapping.c 
b/drivers/iommu/intel/irq_remapping.c
index 9564d23d094f..19d7e18876fe 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -507,12 +507,16 @@ static void iommu_enable_irq_remapping(struct intel_iommu 
*iommu)
 
/* Enable interrupt-remapping */
iommu->gcmd |= DMA_GCMD_IRE;
-   iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format MSIs */
writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
-
IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
  readl, (sts & DMA_GSTS_IRES), sts);
 
+   /* Block compatibility-format MSIs */
+   iommu->gcmd &= ~DMA_GCMD_CFI;
+   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
+   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
+ readl, !(sts & DMA_GSTS_CFIS), sts);
+
/*
 * With CFI clear in the Global Command register, we should be
 * protected from dangerous (i.e. compatibility) interrupts
-- 
2.17.1

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

[Alison Wang]

Hi, James,

> On 25/08/2020 03:31, Alison Wang wrote:
> >> On 09/07/2020 09:22, Alison Wang wrote:
> >>> Add error detection for A53 and A72 cores. Hardware error injection
> >>> is supported on A53. Software error injection is supported on both.
> >>
> > 
> >>
> >> As we can't safely write to these registers from linux, so I think
> >> this means all the error injection and maybe SMC stuff can disappear.
> 
> > I agreed with your opinion that CPUACTLR_EL1 and L2ACTLR can't be written
> in Linux.
> 
> Well, we can't do what the TRM tells us we must before writing to that
> register.
[Alison] Right.
> 
> 
> > So the error injection can't be done in Linux. Do you mean the error
> > injection can only be done in firmware before Linux boots up? If so,
> > the system is running with error injection enabled all the time, it may be 
> > not
> a good idea too. Any suggestion?
> 
> These registers are expected to have one value, forever. The errata document
> sometimes tells us to to set or clear one of these bits to workaround an 
> issue.
> Because they can only be written to when the system is idle, typically during
> boot, this is firmware's responsibility.
> 
> I expect firmware to set the bits in ACTLR_EL3, to prevent lower exception
> levels from touching any of these registers.
> 
> 
> I don't know how the error injection on A53 or A72 works, so I don't know if
> you can leave it enabled all the time. The bit you are setting is described as
> RES0 by the A53 and A72 TRMs. I suspect I had the wrong TRM open, as my
> 'L1DEIEN' comment seems to be what your CPUACTLR_EL1[6] is called on A35.
> (35, 53? Guess how that happened!)
[Alison] Please check A53 TRM r0p4 from 
https://developer.arm.com/documentation/ddi0500/j/System-Control/AArch64-register-descriptions/CPU-Auxiliary-Control-Register--EL1?lang=en
 . 
In the CPUACTLR_EL1 bit assignments, you will find the following description.
[6] L1DEIEN 
L1 D-cache data RAM error injection enable.
0
Normal behavior, errors are not injected. This is the reset value.
1
Double-bit errors are injected on all writes to the L1 D-cache data RAMs for 
the first word of each 32-byte region.
> 
> A35's error injection says:
> | While this bit is set, double-bit errors are injected on all writes to
> | the L1 D-cache data RAMs for the first word of each 32-byte region.
> 
> You certainly can't leave this sort of thing enabled! And you can't change it 
> at
> runtime, so we can't use it.
[Alison] Ok.
> 
> 
> I think features like this are intended to be used to check the integration, 
> not
> to test the software.
> 
> 
> After I sent the original comments on this, I found Sascha's version, which 
> has
> these issues resolved:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ker
> nel.org%2Flinux-arm-kernel%2F20200813075721.27981-1-s.hauer%40pengut
> ronix.de%2Fdata=02%7C01%7Calison.wang%40nxp.com%7C3dc61602
> 25b24fce068708d848f9557e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C637339583002064849sdata=tLf6MHh5IMSBXvASkeaIANLGX
> A0J6F26hpn254a6I6c%3Dreserved=0
> 
> I think this version should work on your platform too.
[Alison] I have a look at this patch. This patch doesn't complete all the 
functions in my patch. It
is just to report errors, but error injection function is all removed.


Best Regards,
Alison Wang

Re: [mm] c566586818: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok

[Qian Cai]

> On Aug 25, 2020, at 8:44 PM, Rong Chen  wrote:
> 
> I rebuilt the kernel on commit c566586818 but the error changed to "RIP: 
> 0010:clear_page_orig+0x12/0x40",
> and the error can be reproduced on parent commit:

Catalin, any thought? Sounds like those early kmemleak allocations cause some 
sort of memory corruption?

> 
> [0.539811] Memory: 12325340K/12680692K available (10243K kernel code, 
> 2414K rwdata, 8188K rodata, 856K init, 14628K bss, 355352K reserved, 0K 
> cma-reserved)
> [4.133400] BUG: unable to handle page fault for address: 88833653e000
> [4.134130] #PF: supervisor write access in kernel mode
> [4.134694] #PF: error_code(0x0002) - not-present page
> [4.135177] PGD 3800067 P4D 3800067 PUD f000e6f2f000d445 PMD 0
> [4.135730] Thread overran stack, or stack corrupted
> [4.136192] Oops: 0002 [#1] DEBUG_PAGEALLOC PTI
> [4.136609] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 5.3.0-11792-gc5665868183fe #1
> [4.137300] RIP: 0010:clear_page_orig+0x12/0x40
> [4.137732] Code: 03 00 00 00 b0 01 5b c3 b9 00 02 00 00 31 c0 f3 48 ab c3 
> 0f 1f 44 00 00 31 c0 b9 40 00 00 00 66 0f 1f 84 00 00 00 00 00 ff c9 <48> 89 
> 07 48 89 47 08 48 89 47 10 48 89 47 18 48 89 47 20 48 89 47
> [4.139453] RSP: :8239d8e8 EFLAGS: 00010016
> [4.139939] RAX:  RBX: 0101 RCX: 
> 003f
> [4.140602] RDX:  RSI: 0001 RDI: 
> 88833653e000
> [4.141261] RBP: ea000cd94f80 R08: 82427800 R09: 
> ea000cd94f80
> [4.141956] R10: 1600 R11: 8880 R12: 
> 
> [4.142642] R13: 0001 R14: 00092000 R15: 
> 0046
> [4.143298] FS:  () GS:8243d000() 
> knlGS:
> [4.144076] CS:  0010 DS:  ES:  CR0: 80050033
> [4.144661] CR2: 88833653e000 CR3: 0242 CR4: 
> 06b0
> [4.145382] DR0:  DR1:  DR2: 
> 
> [4.146121] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [4.146829] Call Trace:
> [4.147066] Modules linked in:
> [4.147359] CR2: 88833653e000
> [4.147757] random: get_random_bytes called from init_oops_id+0x1d/0x2c 
> with crng_init=0
> 
> $ ./scripts/faddr2line vmlinux clear_page_orig+0x12/0x40
> clear_page_orig+0x12/0x40:
> clear_page_orig at arch/x86/lib/clear_page_64.S:31
> 
> 
> but I also can reproduced the lookup_address_in_pgd error in v5.9-rc2 with 
> attached config file:
> 
> [0.382789] Memory: 12313044K/12680692K available (10242K kernel code, 
> 2658K rwdata, 8916K rodata, 800K init, 24540K bss, 367392K reserved, 0K 
> cma-reserved)
> [4.027977] general protection fault, probably for non-canonical address 
> 0xf0006f728d98:  [#1] DEBUG_PAGEALLOC PTI
> [4.029094] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc2 #1
> [4.029741] RIP: 0010:lookup_address_in_pgd+0x7c/0xcc
> [4.030341] Code: 00 00 48 3d 81 00 00 00 74 6c 4c 89 df e8 9d f2 ff ff 48 
> f7 d0 4c 21 d8 a8 01 74 5a 4c 89 d6 4c 89 df e8 fd f5 ff ff 49 89 c0 <48> f7 
> 00 9f ff ff ff 74 93 41 c7 01 02 00 00 00 48 8b 08 48 89 cf
> [4.032205] RSP: :82453a08 EFLAGS: 00010082
> [4.032716] RAX: f0006f728d98 RBX: 0001 RCX: 
> f000e6f28000
> [4.033569] RDX: 8880 RSI: 88800d98 RDI: 
> f000e6f2f000d400
> [4.034474] RBP: 82453b28 R08: f0006f728d98 R09: 
> 82453a48
> [4.035125] R10: 88833664c000 R11: f000e6f2f000d445 R12: 
> 88833664c000
> [4.035836] R13: 0001 R14: 8880 R15: 
> 827806b8
> [4.036575] FS:  () GS:82641000() 
> knlGS:
> [4.037389] CS:  0010 DS:  ES:  CR0: 80050033
> [4.037961] CR2: 8883447ff000 CR3: 02622000 CR4: 
> 06b0
> [4.038677] DR0:  DR1:  DR2: 
> 
> [4.039388] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [4.040243] Call Trace:
> [4.040552] Modules linked in:
> [4.041033] random: get_random_bytes called from init_oops_id+0x1d/0x2c 
> with crng_init=0
> 
> $ ./scripts/faddr2line vmlinux lookup_address_in_pgd+0x7c/0xcc
> lookup_address_in_pgd+0x7c/0xcc:
> lookup_address_in_pgd at arch/x86/mm/pat/set_memory.c:604
> (inlined by) lookup_address_in_pgd at arch/x86/mm/pat/set_memory.c:575

Re: [PATCH v3] exfat: integrates dir-entry getting and validation

[Tetsuhiro Kohada]

On 2020/08/26 10:03, Namjae Jeon wrote:

Second: Range validation and type validation should not be separated.
When I started making this patch, I intended to add only range validation.
However, after the caller gets the ep, the type validation follows.
Get ep, null check of ep (= range verification), type verification is a series 
of procedures.
There would be no reason to keep them independent anymore.
Range and type validation is enforced when the caller uses ep.

You can add a validate flags as argument of exfat_get_dentry_set(), e.g. none, 
basic and strict.
none : only range validation.
basic : range + type validation.
strict : range + type + checksum and name length, etc.


Currently, various types of verification will not be needed.
Let's add it when we need it.
  

-   /* validiate cached dentries */
-   for (i = 1; i < num_entries; i++) {
-   ep = exfat_get_dentry_cached(es, i);
-   if (!exfat_validate_entry(exfat_get_entry_type(ep), ))
+   ep = exfat_get_dentry_cached(es, ENTRY_STREAM);
+   if (!ep || ep->type != EXFAT_STREAM)
+   goto free_es;
+   es->de[ENTRY_STREAM] = ep;


The value contained in stream-ext dir-entry should not be used before 
validating the EntrySet checksum.
So I would insert EntrySet checksum validation here.
In that case, the checksum verification loop would be followed by the TYPE_NAME 
verification loop, can
you acceptable?

Yes. That would be great.


OK.
I'll add TYPE_NAME verification after checksum verification, in next patch.
However, I think it is enough to validate TYPE_NAME when extracting name.
Could you please tell me why you think you need TYPE_NAME validation here?


BR
---
Tetsuhiro Kohada 

Re: [PATCH] iommu/vt-d:Add support for detecting ACPI device in RMRR

[Lu Baolu]

Hi Felix,

On 8/18/20 10:44 AM, FelixCuioc wrote:

Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.



If you are willing to submit a new version of this series, can you
please add the version tag (commit title) and a change log (under the
tear line)?

Best regards,
baolu


Signed-off-by: FelixCuioc 
---
  drivers/iommu/intel/dmar.c  | 74 -
  drivers/iommu/intel/iommu.c | 22 ++-
  include/linux/dmar.h| 12 +-
  3 files changed, 72 insertions(+), 36 deletions(-)

diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 93e6345f3414..024ca38dba12 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -215,7 +215,7 @@ static bool dmar_match_pci_path(struct dmar_pci_notify_info 
*info, int bus,
  }
  
  /* Return: > 0 if match found, 0 if no match found, < 0 if error happens */

-int dmar_insert_dev_scope(struct dmar_pci_notify_info *info,
+int dmar_pci_insert_dev_scope(struct dmar_pci_notify_info *info,
  void *start, void*end, u16 segment,
  struct dmar_dev_scope *devices,
  int devices_cnt)
@@ -304,7 +304,7 @@ static int dmar_pci_bus_add_dev(struct dmar_pci_notify_info 
*info)
  
  		drhd = container_of(dmaru->hdr,

struct acpi_dmar_hardware_unit, header);
-   ret = dmar_insert_dev_scope(info, (void *)(drhd + 1),
+   ret = dmar_pci_insert_dev_scope(info, (void *)(drhd + 1),
((void *)drhd) + drhd->header.length,
dmaru->segment,
dmaru->devices, dmaru->devices_cnt);
@@ -696,48 +696,56 @@ dmar_find_matched_drhd_unit(struct pci_dev *dev)
  
  	return dmaru;

  }
-
-static void __init dmar_acpi_insert_dev_scope(u8 device_number,
- struct acpi_device *adev)
+int dmar_acpi_insert_dev_scope(u8 device_number,
+   struct acpi_device *adev,
+   void *start, void *end,
+   struct dmar_dev_scope *devices,
+   int devices_cnt)
  {
-   struct dmar_drhd_unit *dmaru;
-   struct acpi_dmar_hardware_unit *drhd;
struct acpi_dmar_device_scope *scope;
struct device *tmp;
int i;
struct acpi_dmar_pci_path *path;
  
+	for (; start < end; start += scope->length) {

+   scope = start;
+   if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
+   continue;
+   if (scope->enumeration_id != device_number)
+   continue;
+   path = (void *)(scope + 1);
+   for_each_dev_scope(devices, devices_cnt, i, tmp)
+   if (tmp == NULL) {
+   devices[i].bus = scope->bus;
+   devices[i].devfn = PCI_DEVFN(path->device, 
path->function);
+   rcu_assign_pointer(devices[i].dev,
+  get_device(>dev));
+   return 1;
+   }
+   WARN_ON(i >= devices_cnt);
+   }
+   return 0;
+}
+static int dmar_acpi_bus_add_dev(u8 device_number, struct acpi_device *adev)
+{
+   struct dmar_drhd_unit *dmaru;
+   struct acpi_dmar_hardware_unit *drhd;
+   int ret = 0;
+
for_each_drhd_unit(dmaru) {
drhd = container_of(dmaru->hdr,
struct acpi_dmar_hardware_unit,
header);
+   ret = dmar_acpi_insert_dev_scope(device_number, adev, (void 
*)(drhd+1),
+   ((void 
*)drhd)+drhd->header.length,
+   dmaru->devices, 
dmaru->devices_cnt);
+   if (ret)
+   break;
+   }
+   ret = dmar_rmrr_add_acpi_dev(device_number, adev);
  
-		for (scope = (void *)(drhd + 1);

-(unsigned long)scope < ((unsigned long)drhd) + 
drhd->header.length;
-scope = ((void *)scope) + scope->length) {
-   if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_NAMESPACE)
-   continue;
-   if (scope->enumeration_id != device_number)
-   continue;
+   return ret;
  
-			path = (void *)(scope + 1);

-   pr_info("ACPI device \"%s\" under DMAR at %llx as 
%02x:%02x.%d\n",
-   dev_name(>dev), dmaru->reg_base_addr,
-   scope->bus, path->device, path->function);
-   

Re: [PATCH v1 0/9] extcon: extcon-ptn5150: Add the USB external connector support

[Ramuthevar, Vadivel MuruganX]

Hi Heikki,

 Thank you very much for the review comment...

On 25/8/2020 4:19 pm, Heikki Krogerus wrote:

On Wed, Aug 19, 2020 at 04:45:38PM +0800, Ramuthevar, Vadivel MuruganX wrote:

Hi Andy,

On 19/8/2020 3:55 pm, Andy Shevchenko wrote:

On Wed, Aug 19, 2020 at 8:38 AM Ramuthevar, Vadivel MuruganX
 wrote:

On 18/8/2020 4:40 pm, Andy Shevchenko wrote:

On Tue, Aug 18, 2020 at 02:57:18PM +0800, Ramuthevar,Vadivel MuruganX wrote:

USB external connector chip PTN5150 used on the Intel LGM SoC
boards to detect the USB type and connection.

Internally I meant you can send cleanups, but couple of patches here are the
features and were still under discussion... But here we are.


you mean asking us to implement the Heikki suggested as below..

Heikki Krogerus: register the port and the partner attached to it with
the USB Type-C connector class in the driver. Is my understaanding
right? if not, please explain it. Thanks!


When you mention somebody, don't forget to Cc them (now done by me).

Sure, Thank you


So the patches 1-5 are fine. The rest needs to be rewritten.
Already Krzysztof submitted all the patches and got approved, so we 
started sending only one patch which support to Intel LGM SoC based 
boards, Thanks!


Regards
Vadivel


thanks,

Re: [PATCH v2] x86/hotplug: Silence APIC only after all irq's are migrated

[Raj, Ashok]

Hi Thomas,

On Wed, Aug 26, 2020 at 02:40:45AM +0200, Thomas Gleixner wrote:
> Ashok,
> 
> On Thu, Aug 20 2020 at 17:42, Ashok Raj wrote:
> > When offlining CPUs, fixup_irqs() migrates all interrupts away from the
> > outgoing CPU to an online CPU. It's always possible the device sent an
> > interrupt to the previous CPU destination. Pending interrupt bit in IRR in
> > LAPIC identifies such interrupts. apic_soft_disable() will not capture any
> > new interrupts in IRR. This causes interrupts from device to be lost during
> > CPU offline. The issue was found when explicitly setting MSI affinity to a
> > CPU and immediately offlining it. It was simple to recreate with a USB
> > ethernet device and doing I/O to it while the CPU is offlined. Lost
> > interrupts happen even when Interrupt Remapping is enabled.
> 
> New lines exist for a reason. They help to structure information. For
> the content, please see below.

Will work on that :-)

> 
> > Current code does apic_soft_disable() before migrating interrupts.
> >
> > native_cpu_disable()
> > {
> > ...
> > apic_soft_disable();
> > cpu_disable_common();
> >   --> fixup_irqs(); // Too late to capture anything in IRR.
> > }
> >
> > Just flipping the above call sequence seems to hit the IRR checks
> > and the lost interrupt is fixed for both legacy MSI and when
> > interrupt remapping is enabled.
> 
> Seems to hit? Come on, we really want changelogs which are based on
> facts and not on assumptions.

What I intended to convay was by placing a debug trace_printk() at
fixup_irqs(), it was *indeed* observed. Before the change I never noticed
that path being covered.

Just my Inglish (Indian English) tricking you :-).
Will make them sensible in the next update.

> 
> Aside of that, yes that's a really subtle one and thanks for tracking it
> down! For some reason I never looked at that ordering, but now that you
> stick it in front of me, it's pretty clear that this is the root cause.
> 
> > /*
> >  * Disable the local APIC. Otherwise IPI broadcasts will reach
> >  * it. It still responds normally to INIT, NMI, SMI, and SIPI
> > -* messages.
> > +* messages. It's important to do apic_soft_disable() after
> > +* fixup_irqs(), because fixup_irqs() called from cpu_disable_common()
> > +* depends on IRR being set.
> 
> That sentence does not make sense to me.

Right, I was just stating the obvious. Since fixup_irqs() isn't called
right in that function, it was suggested to make that connection explicit.

Your writeup below is crystal.. so will replace with what you have below.


> 
> > +    After apic_soft_disable() CPU preserves
> > +* currently set IRR/ISR but new interrupts will not set IRR.
> 
> I agree with the IRR part, but ISR is simply impossible to be set in
> this situation. 

You are correct. I was trying to convey what the SDM said, but its probably
irrelavant for this discussion. 

> 
> > +* This causes interrupts sent to outgoing CPU before completion
> > +* of IRQ migration to be lost. Check SDM Vol 3 "10.4.7.2 Local
> > +* APIC State after It Has been Software Disabled" section for more
> > +* details.
> 
> Please do not use the SDM chapter number of today. It's going to be a
> different one with the next version.
> 
> Something like this perhaps?
> 
>   /*
>* Disable the local APIC. Otherwise IPI broadcasts will reach
>* it. It still responds normally to INIT, NMI, SMI, and SIPI
>* messages.
>  *
>  * Disabling the APIC must happen after cpu_disable_common()
>* which invokes fixup_irqs().
>  *
>  * Disabling the APIC preserves already set bits in IRR, but
>  * an interrupt arriving after disabling the local APIC does not
>  * set the corresponding IRR bit.
>  *
>  * fixup_irqs() scans IRR for set bits so it can raise a not
>* yet handled interrupt on the new destination CPU via an IPI
>  * but obviously it can't do so for IRR bits which are not set.
>  * IOW, interrupts arriving after disabling the local APIC will
>  * be lost.
>  */
> 
> Hmm?
> 
> The changelog wants to have a corresponding update.

Will do ...

Cheers,
Ashok

[PATCH v1 0/9] Support qcom USB3+DP combo phy (or type-c phy)

[Stephen Boyd]

This patch series is based on v11 of the msm DP driver submission[1]
plus a compliance patch[2]. In the v5 patch series review I suggested
that the DP PHY and PLL be split out of the drm driver and moved to the
qmp phy driver. This patch series does that, but it is still marked as
an RFC because there are a couple more things to do, mostly updating the
DT binding and getting agreement on how to structure the code.

Eventually I believe the qmp phy driver will need to listen for type-c
notifiers or somehow know the type-c pinout being used so this driver
can program things slightly differently. Right now, I don't have any way
to test it though, so I've left it as future work. For some more
details, the DP phy and the USB3 phy share the same physical pins on the
SoC and those pins pretty much line up with a type-c pinout modulo some
CC pins for cable orientation detection logic that lives on the PMIC. So
the DP phy can use all four lanes or it can use two lanes and the USB3
phy can use two lanes. In the hardware designs that I have access to it
is always two lanes for USB3 and two lanes for DP going through what
looks like a type-c pinout so this just hard codes that configuration in
the driver.

Here's the example node that I'm using on sc7180:

usb_1_qmpphy: phy-wrapper@88e9000 {
compatible = "qcom,sc7180-qmp-usb3-dp-phy";
reg = <0 0x088e9000 0 0x18c>, // usb pll (or serdes)
  <0 0x088e8000 0 0x38>, // dp com
  <0 0x088ea000 0 0x40>;  // dp pll (or serdes)
status = "disabled";
#address-cells = <2>;
#size-cells = <2>;
ranges;

clocks = < GCC_USB3_PRIM_PHY_AUX_CLK>,
 < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
 < GCC_USB3_PRIM_CLKREF_CLK>,
 < GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
clock-names = "aux", "cfg_ahb", "ref", "com_aux";

resets = < GCC_USB3_PHY_PRIM_BCR>,
 < GCC_USB3_DP_PHY_PRIM_BCR>;
reset-names = "phy", "common";

usb_1_ssphy: usb3-phy@88e9200 {
reg = <0 0x088e9200 0 0x128>, // tx0
  <0 0x088e9400 0 0x200>, // rx0
  <0 0x088e9c00 0 0x218>, // pcs
  <0 0x088e9600 0 0x128>, // tx1
  <0 0x088e9800 0 0x200>, // rx1
  <0 0x088e9a00 0 0x18>;  // pcs misc
#clock-cells = <0>;
#phy-cells = <0>;
clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
clock-names = "pipe0";
clock-output-names = "usb3_phy_pipe_clk_src";
};

dp_phy: dp-phy@88ea200 {
reg = <0 0x088ea200 0 0x200>, // tx0
  <0 0x088ea400 0 0x200>, // rx0
  <0 0x088eaa00 0 0x200>, // dp phy
  <0 0x088ea600 0 0x200>, // tx1
  <0 0x088ea800 0 0x200>; // rx1
#clock-cells = <1>;
#phy-cells = <0>;
};
};

I had to put the serdes register region in the wrapper node and jam the
common area (dp_com) in the middle. Sort of a mess but it was the best I
could do to make the driver changes minimially invasive. I also had to
change the node names to 'usb3-phy' and 'dp-phy' from 'phy' so that I
could differentiate the different phys in the driver. Otherwise the qmp
driver was already mostly prepared for two different phys to sit next to
each other inside the phy wrapper so it was mostly just a chore of
moving code from one place to another.

I'll also point out that I found out the DP controller driver is
resetting the aux phy settings right after it configures it. The last
patch in this series rips out the DP PHY and PLL code from the drm
driver and wires in the phy API calls instead. In that same patch I also
fixed this aux reset behavior by removing the bit that resets the aux
phy. I believe that the aux configuration is broken in the DP driver
but I fixed it now I think.

Changes from RFC 
(https://lore.kernel.org/r/20200611091919.108018-1-swb...@chromium.org)
 * New patch for DT binding
 * Rebased onto latest DP patch series

TODO:
 * Clean up phy power on sequence a bit so that it is done in one place
   instead of two
 * Allow link rate to change after phy is powered on?
 * Make the runtime PM logic detect combo phy and power down both?


Stephen Boyd (9):
  dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy information
  phy: qcom-qmp: Move phy mode into struct qmp_phy
  phy: qcom-qmp: Remove 'initialized' in favor of 'init_count'
  phy: qcom-qmp: Move 'serdes' and 'cfg' into 'struct qcom_phy'
  phy: qcom-qmp: Get dp_com I/O resource by index
  phy: qcom-qmp: Add 

[PATCH v1 5/9] phy: qcom-qmp: Get dp_com I/O resource by index

[Stephen Boyd]

The dp_com resource is always at index 1 according to the dts files in
the kernel. Get this resource by index so that we don't need to make
future additions to the DT binding use 'reg-names'.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 40c051813c34..76d7a9e80f04 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -3266,8 +3266,7 @@ static int qcom_qmp_phy_probe(struct platform_device 
*pdev)
 
/* per PHY dp_com; if PHY has dp_com control block */
if (cfg->has_phy_dp_com_ctrl) {
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "dp_com");
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
-- 
Sent by a computer, using git, on the internet

[PATCH v1 6/9] phy: qcom-qmp: Add support for DP in USB3+DP combo phy

[Stephen Boyd]

Add support for the USB3 + DisplayPort (DP) "combo" phy to the qmp phy
driver. We already have support for the USB3 part of the combo phy, so
most additions are for the DP phy.

Split up the qcom_qmp_phy{enable,disable}() functions into the phy init,
power on, power off, and exit functions that the common phy framework
expects so that the DP phy can add even more phy ops like
phy_calibrate() and phy_configure(). This allows us to initialize the DP
PHY and configure the AUX channel before powering on the PHY at the link
rate that was negotiated during link training.

The general design is as follows:

  1) DP controller calls phy_init() to initialize the PHY and configure
  the dp_com register region.

  2) DP controller calls phy_configure() to tune the link rate and
  voltage swing and pre-emphasis settings.

  3) DP controller calls phy_power_on() to enable the PLL and power on
  the phy.

  4) DP controller calls phy_configure() again to tune the voltage swing
  and pre-emphasis settings determind during link training.

  5) DP controller calls phy_calibrate() some number of times to change
  the aux settings if the aux channel times out during link training.

  6) DP controller calls phy_power_off() if the link rate is to be
  changed and goes back to step 2 to try again at a different link rate.

  5) DP controller calls phy_power_off() and then phy_exit() to power
  down the PHY when it is done.

The DP PHY contains a PLL that is different from the one used for the
USB3 PHY. Instead of a pipe clk there is a link clk and a pixel clk
output from the DP PLL after going through various dividers. Introduce
clk ops for these two clks that just tell the child clks what the
frequency of the pixel and link are. When the phy link rate is
configured we call clk_set_rate() to update the child clks in the
display clk controller on what rate is in use. The clk frequencies
always differ based on the link rate (i.e. 1.6Gb/s 2.7Gb/s, 5.4Gb/s, or
8.1Gb/s corresponding to various transmission modes like HBR1, HBR2 or
HBR3) so we simply store the link rate and use that to calculate the clk
frequencies.

The PLL enable sequence is a little different from other QMP phy PLLs so
we power on the PLL in qcom_qmp_phy_configure_dp_phy() that gets called
from phy_power_on(). This should probably be split out better so that
each phy has a way to run the final PLL/PHY enable sequence.

This code is based on a submission of this phy and PLL in the drm
subsystem.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Stephen Boyd 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Link: https://lore.kernel.org/r/20200609034623.10844-1-tan...@codeaurora.org
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 935 +---
 drivers/phy/qualcomm/phy-qcom-qmp.h |  80 +++
 2 files changed, 926 insertions(+), 89 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 76d7a9e80f04..dd77c7dfa310 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -947,6 +947,130 @@ static const struct qmp_phy_init_tbl qmp_v3_usb3_tx_tbl[] 
= {
QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x06),
 };
 
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl_rbr[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x37),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_ENABLE1, 0x0e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_BUF_ENABLE, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x0c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x69),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x6f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x08),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x1f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   

[PATCH v1 7/9] phy: qcom-qmp: Add support for sc7180 DP phy

[Stephen Boyd]

Add the necessary compatible strings and phy data for the sc7180 USB3+DP
combo phy.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Link: https://lore.kernel.org/r/20200609034623.10844-1-tan...@codeaurora.org
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 47 +
 1 file changed, 47 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index dd77c7dfa310..84fba3437a20 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1071,6 +1071,24 @@ static const struct qmp_phy_init_tbl 
qmp_v3_dp_serdes_tbl_hbr3[] = {
QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
 };
 
+static const struct qmp_phy_init_tbl qmp_v3_dp_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TRANSCEIVER_BIAS_EN, 0x1a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_VMODE_CTRL1, 0x40),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_PRE_STALL_LDO_BOOST_EN, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_INTERFACE_SELECT, 0x3d),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_CLKBUF_ENABLE, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RESET_TSYNC_EN, 0x03),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TRAN_DRVR_EMP_EN, 0x03),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_PARRATE_REC_DETECT_IDLE_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TX_INTERFACE_MODE, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TX_BAND, 0x4),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TX_POL_INV, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TX_DRV_LVL, 0x38),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_TX_EMP_POST1_LVL, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
 static const struct qmp_phy_init_tbl qmp_v3_usb3_rx_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x0f),
@@ -2337,6 +2355,28 @@ static const struct qmp_phy_cfg sc7180_usb3phy_cfg = {
.is_dual_lane_phy   = true,
 };
 
+static const struct qmp_phy_cfg sc7180_dpphy_cfg = {
+   .type   = PHY_TYPE_DP,
+   .nlanes = 1,
+
+   .tx_tbl = qmp_v3_dp_tx_tbl,
+   .tx_tbl_num = ARRAY_SIZE(qmp_v3_dp_tx_tbl),
+   .clk_list   = qmp_v3_phy_clk_l,
+   .num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
+   .reset_list = sc7180_usb3phy_reset_l,
+   .num_resets = ARRAY_SIZE(sc7180_usb3phy_reset_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
+
+   .has_phy_dp_com_ctrl= true,
+   .is_dual_lane_phy   = true,
+};
+
+static const struct qmp_phy_combo_cfg sc7180_usb3dpphy_cfg = {
+   .usb_cfg= _usb3phy_cfg,
+   .dp_cfg = _dpphy_cfg,
+};
+
 static const struct qmp_phy_cfg qmp_v3_usb3_uniphy_cfg = {
.type   = PHY_TYPE_USB3,
.nlanes = 1,
@@ -3891,6 +3931,9 @@ static const struct of_device_id 
qcom_qmp_phy_of_match_table[] = {
}, {
.compatible = "qcom,sc7180-qmp-usb3-phy",
.data = _usb3phy_cfg,
+   }, {
+   .compatible = "qcom,sc7180-qmp-usb3-dp-phy",
+   /* It's a combo phy */
}, {
.compatible = "qcom,sdm845-qhp-pcie-phy",
.data = _qhp_pciephy_cfg,
@@ -3933,6 +3976,10 @@ static const struct of_device_id 
qcom_qmp_phy_of_match_table[] = {
 MODULE_DEVICE_TABLE(of, qcom_qmp_phy_of_match_table);
 
 static const struct of_device_id qcom_qmp_combo_phy_of_match_table[] = {
+   {
+   .compatible = "qcom,sc7180-qmp-usb3-dp-phy",
+   .data = _usb3dpphy_cfg,
+   },
{ }
 };
 
-- 
Sent by a computer, using git, on the internet

[PATCH v1 2/9] phy: qcom-qmp: Move phy mode into struct qmp_phy

[Stephen Boyd]

The phy mode pertains to the phy itself, i.e. 'struct qmp_phy', not the
wrapper, i.e. 'struct qcom_qmp'. Move the phy mode into the phy
structure to more accurately reflect what is going on. This also cleans
up 'struct qcom_qmp' so that it can eventually be the place where qmp
wrapper wide data is located, paving the way for the USB3+DP combo phy.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 562053ce9455..7ee9e966dc6d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1812,6 +1812,7 @@ struct qmp_phy_cfg {
  * @index: lane index
  * @qmp: QMP phy to which this lane belongs
  * @lane_rst: lane's reset controller
+ * @mode: current PHY mode
  */
 struct qmp_phy {
struct phy *phy;
@@ -1825,6 +1826,7 @@ struct qmp_phy {
unsigned int index;
struct qcom_qmp *qmp;
struct reset_control *lane_rst;
+   enum phy_mode mode;
 };
 
 /**
@@ -1843,7 +1845,6 @@ struct qmp_phy {
  * @phy_mutex: mutex lock for PHY common block initialization
  * @init_count: phy common block initialization count
  * @phy_initialized: indicate if PHY has been initialized
- * @mode: current PHY mode
  * @ufs_reset: optional UFS PHY reset handle
  */
 struct qcom_qmp {
@@ -1861,7 +1862,6 @@ struct qcom_qmp {
struct mutex phy_mutex;
int init_count;
bool phy_initialized;
-   enum phy_mode mode;
 
struct reset_control *ufs_reset;
 };
@@ -2801,9 +2801,8 @@ static int qcom_qmp_phy_set_mode(struct phy *phy,
 enum phy_mode mode, int submode)
 {
struct qmp_phy *qphy = phy_get_drvdata(phy);
-   struct qcom_qmp *qmp = qphy->qmp;
 
-   qmp->mode = mode;
+   qphy->mode = mode;
 
return 0;
 }
@@ -2816,8 +2815,8 @@ static void qcom_qmp_phy_enable_autonomous_mode(struct 
qmp_phy *qphy)
void __iomem *pcs_misc = qphy->pcs_misc;
u32 intr_mask;
 
-   if (qmp->mode == PHY_MODE_USB_HOST_SS ||
-   qmp->mode == PHY_MODE_USB_DEVICE_SS)
+   if (qphy->mode == PHY_MODE_USB_HOST_SS ||
+   qphy->mode == PHY_MODE_USB_DEVICE_SS)
intr_mask = ARCVR_DTCT_EN | ALFPS_DTCT_EN;
else
intr_mask = ARCVR_DTCT_EN | ARCVR_DTCT_EVENT_SEL;
@@ -2863,7 +2862,7 @@ static int __maybe_unused 
qcom_qmp_phy_runtime_suspend(struct device *dev)
struct qmp_phy *qphy = qmp->phys[0];
const struct qmp_phy_cfg *cfg = qmp->cfg;
 
-   dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
+   dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qphy->mode);
 
/* Supported only for USB3 PHY */
if (cfg->type != PHY_TYPE_USB3)
@@ -2889,7 +2888,7 @@ static int __maybe_unused 
qcom_qmp_phy_runtime_resume(struct device *dev)
const struct qmp_phy_cfg *cfg = qmp->cfg;
int ret = 0;
 
-   dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
+   dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qphy->mode);
 
/* Supported only for USB3 PHY */
if (cfg->type != PHY_TYPE_USB3)
-- 
Sent by a computer, using git, on the internet

[PATCH v1 3/9] phy: qcom-qmp: Remove 'initialized' in favor of 'init_count'

[Stephen Boyd]

We already track if any phy inside the qmp wrapper has been initialized
by means of the struct qcom_qmp::init_count member. Let's drop the
duplicate 'initialized' member to simplify the code a bit.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 7ee9e966dc6d..4a23ba9361b3 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1844,7 +1844,6 @@ struct qmp_phy {
  * @phys: array of per-lane phy descriptors
  * @phy_mutex: mutex lock for PHY common block initialization
  * @init_count: phy common block initialization count
- * @phy_initialized: indicate if PHY has been initialized
  * @ufs_reset: optional UFS PHY reset handle
  */
 struct qcom_qmp {
@@ -1861,7 +1860,6 @@ struct qcom_qmp {
 
struct mutex phy_mutex;
int init_count;
-   bool phy_initialized;
 
struct reset_control *ufs_reset;
 };
@@ -2748,7 +2746,6 @@ static int qcom_qmp_phy_enable(struct phy *phy)
dev_err(qmp->dev, "phy initialization timed-out\n");
goto err_pcs_ready;
}
-   qmp->phy_initialized = true;
return 0;
 
 err_pcs_ready:
@@ -2792,8 +2789,6 @@ static int qcom_qmp_phy_disable(struct phy *phy)
 
qcom_qmp_phy_com_exit(qmp);
 
-   qmp->phy_initialized = false;
-
return 0;
 }
 
@@ -2868,7 +2863,7 @@ static int __maybe_unused 
qcom_qmp_phy_runtime_suspend(struct device *dev)
if (cfg->type != PHY_TYPE_USB3)
return 0;
 
-   if (!qmp->phy_initialized) {
+   if (!qmp->init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -2894,7 +2889,7 @@ static int __maybe_unused 
qcom_qmp_phy_runtime_resume(struct device *dev)
if (cfg->type != PHY_TYPE_USB3)
return 0;
 
-   if (!qmp->phy_initialized) {
+   if (!qmp->init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
-- 
Sent by a computer, using git, on the internet

[PATCH v1 4/9] phy: qcom-qmp: Move 'serdes' and 'cfg' into 'struct qcom_phy'

[Stephen Boyd]

The serdes I/O region is where the PLL for the phy is controlled.
Sometimes the PLL is shared between multiple phys, for example in the
PCIe case where there are three phys inside the same wrapper. Other
times the PLL is for a single phy, i.e. some USB3 phys. To complete the
trifecta we have the USB3+DP combo phy where the USB3 and DP phys each
have their own serdes region because they have their own PLL while they
both share a common I/O region pertaining to the USB type-c pinout and
cable orientation.

Let's move the serdes iomem pointer into 'struct qmp_phy' so that we can
correlate PLL control to the phy that uses it. This allows us to support
the USB3+DP combo phy in this driver. This isn't a problem for the
3-lane/phy PCIe phy because there is a common init function that is the
only place the serdes region is programmed.

Furthermore, move the configuration data that contains most of the
register programming sequences to the qmp phy struct. This data isn't
qmp wrapper specific. It is phy specific data used to tune various
settings for things like pre-emphasis, bias, etc.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 113 ++--
 1 file changed, 56 insertions(+), 57 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 4a23ba9361b3..40c051813c34 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1802,6 +1802,8 @@ struct qmp_phy_cfg {
  * struct qmp_phy - per-lane phy descriptor
  *
  * @phy: generic phy
+ * @cfg: phy specific configuration
+ * @serdes: iomapped memory space for phy's serdes (i.e. PLL)
  * @tx: iomapped memory space for lane's tx
  * @rx: iomapped memory space for lane's rx
  * @pcs: iomapped memory space for lane's pcs
@@ -1816,6 +1818,8 @@ struct qmp_phy_cfg {
  */
 struct qmp_phy {
struct phy *phy;
+   const struct qmp_phy_cfg *cfg;
+   void __iomem *serdes;
void __iomem *tx;
void __iomem *rx;
void __iomem *pcs;
@@ -1833,14 +1837,12 @@ struct qmp_phy {
  * struct qcom_qmp - structure holding QMP phy block attributes
  *
  * @dev: device
- * @serdes: iomapped memory space for phy's serdes
  * @dp_com: iomapped memory space for phy's dp_com control block
  *
  * @clks: array of clocks required by phy
  * @resets: array of resets required by phy
  * @vregs: regulator supplies bulk data
  *
- * @cfg: phy specific configuration
  * @phys: array of per-lane phy descriptors
  * @phy_mutex: mutex lock for PHY common block initialization
  * @init_count: phy common block initialization count
@@ -1848,14 +1850,12 @@ struct qmp_phy {
  */
 struct qcom_qmp {
struct device *dev;
-   void __iomem *serdes;
void __iomem *dp_com;
 
struct clk_bulk_data *clks;
struct reset_control **resets;
struct regulator_bulk_data *vregs;
 
-   const struct qmp_phy_cfg *cfg;
struct qmp_phy **phys;
 
struct mutex phy_mutex;
@@ -2478,8 +2478,8 @@ static void qcom_qmp_phy_configure(void __iomem *base,
 static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 {
struct qcom_qmp *qmp = qphy->qmp;
-   const struct qmp_phy_cfg *cfg = qmp->cfg;
-   void __iomem *serdes = qmp->serdes;
+   const struct qmp_phy_cfg *cfg = qphy->cfg;
+   void __iomem *serdes = qphy->serdes;
void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
int ret, i;
@@ -2510,7 +2510,7 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
ret = reset_control_deassert(qmp->resets[i]);
if (ret) {
dev_err(qmp->dev, "%s reset deassert failed\n",
-   qmp->cfg->reset_list[i]);
+   qphy->cfg->reset_list[i]);
goto err_rst;
}
}
@@ -2592,10 +2592,11 @@ static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
return ret;
 }
 
-static int qcom_qmp_phy_com_exit(struct qcom_qmp *qmp)
+static int qcom_qmp_phy_com_exit(struct qmp_phy *qphy)
 {
-   const struct qmp_phy_cfg *cfg = qmp->cfg;
-   void __iomem *serdes = qmp->serdes;
+   struct qcom_qmp *qmp = qphy->qmp;
+   const struct qmp_phy_cfg *cfg = qphy->cfg;
+   void __iomem *serdes = qphy->serdes;
int i = cfg->num_resets;
 
mutex_lock(>phy_mutex);
@@ -2630,7 +2631,7 @@ static int qcom_qmp_phy_enable(struct phy *phy)
 {
struct qmp_phy *qphy = phy_get_drvdata(phy);
struct qcom_qmp *qmp = qphy->qmp;
-   const struct qmp_phy_cfg *cfg = qmp->cfg;
+   const struct qmp_phy_cfg *cfg = qphy->cfg;
void __iomem *tx = qphy->tx;
void __iomem *rx = 

[PATCH v1 8/9] clk: qcom: dispcc: Update DP clk ops for phy design

[Stephen Boyd]

The clk_rcg2_dp_determine_rate() function is used for the DP pixel clk.
This function should return the rate that can be achieved by the pixel
clk in 'struct clk_rate_request::rate' and match the logic similar to
what is seen in clk_rcg2_dp_set_rate(). But that isn't the case. Instead
the code merely bubbles the rate request up to the parent of the pixel
clk and doesn't try to do a rational approximation of the rate that
would be achieved by picking some m/n value for the RCG.

Let's change this logic so that we can assume the parent clk frequency
is fixed (it is because it's the VCO of the DP PLL that is configured
based on the link rate) and so that we can calculate what the m/n value
will be and adjust the req->rate appropriately.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Stephen Boyd 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/clk/qcom/clk-rcg2.c  | 19 +--
 drivers/clk/qcom/dispcc-sc7180.c |  3 ---
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 357159fe85b5..59a5a0f261f3 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1182,14 +1182,21 @@ static int clk_rcg2_dp_set_rate_and_parent(struct 
clk_hw *hw,
 static int clk_rcg2_dp_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
 {
-   struct clk_rate_request parent_req = *req;
-   int ret;
+   struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+   unsigned long num, den;
+   u64 tmp;
 
-   ret = __clk_determine_rate(clk_hw_get_parent(hw), _req);
-   if (ret)
-   return ret;
+   /* Parent rate is a fixed phy link rate */
+   rational_best_approximation(req->best_parent_rate, req->rate,
+   GENMASK(rcg->mnd_width - 1, 0),
+   GENMASK(rcg->mnd_width - 1, 0), , );
+
+   if (!num || !den)
+   return -EINVAL;
 
-   req->best_parent_rate = parent_req.rate;
+   tmp = req->best_parent_rate * num;
+   do_div(tmp, den);
+   req->rate = tmp;
 
return 0;
 }
diff --git a/drivers/clk/qcom/dispcc-sc7180.c b/drivers/clk/qcom/dispcc-sc7180.c
index 0a5d395bce93..f487515701e3 100644
--- a/drivers/clk/qcom/dispcc-sc7180.c
+++ b/drivers/clk/qcom/dispcc-sc7180.c
@@ -202,7 +202,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_crypto_clk_src = {
.name = "disp_cc_mdss_dp_crypto_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
-   .flags = CLK_SET_RATE_PARENT,
.ops = _byte2_ops,
},
 };
@@ -216,7 +215,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_link_clk_src = {
.name = "disp_cc_mdss_dp_link_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
-   .flags = CLK_SET_RATE_PARENT,
.ops = _byte2_ops,
},
 };
@@ -230,7 +228,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_pixel_clk_src = {
.name = "disp_cc_mdss_dp_pixel_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
-   .flags = CLK_SET_RATE_PARENT,
.ops = _dp_ops,
},
 };
-- 
Sent by a computer, using git, on the internet

[PATCH v1 1/9] dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy information

[Stephen Boyd]

This binding only describes the USB phy inside the USB3 + DP "combo"
phy. Add information for the DP phy and describe the sub-nodes that
represent the DP and USB3 phys that exist inside the combo wrapper.
Remove reg-names from required properties because it isn't required nor
used by the kernel driver.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: 
Cc: Rob Herring 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 .../bindings/phy/qcom,qmp-usb3-dp-phy.yaml| 91 +--
 1 file changed, 81 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml 
b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
index ef8ae9f73092..4154f5748d39 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
@@ -17,13 +17,15 @@ properties:
   - qcom,sdm845-qmp-usb3-phy
   reg:
 items:
-  - description: Address and length of PHY's common serdes block.
+  - description: Address and length of PHY's USB serdes block.
   - description: Address and length of the DP_COM control block.
+  - description: Address and length of PHY's DP serdes block.
 
   reg-names:
 items:
-  - const: reg-base
+  - const: usb
   - const: dp_com
+  - const: dp
 
   "#clock-cells":
 enum: [ 1, 2 ]
@@ -74,16 +76,74 @@ properties:
 
 #Required nodes:
 patternProperties:
-  "^phy@[0-9a-f]+$":
+  "^usb3-phy@[0-9a-f]+$":
 type: object
 description:
-  Each device node of QMP phy is required to have as many child nodes as
-  the number of lanes the PHY has.
+  The USB3 PHY.
+
+properties:
+  reg:
+items:
+  - description: Address and length of TX.
+  - description: Address and length of RX.
+  - description: Address and length of PCS.
+  - description: Address and length of TX2.
+  - description: Address and length of RX2.
+  - description: Address and length of pcs_misc.
+
+  clocks:
+items:
+  - description: pipe clock
+
+  clock-names:
+items:
+  - const: pipe0
+
+  clock-output-names:
+items:
+  - const: usb3_phy_pipe_clk_src
+
+  '#clock-cells':
+const: 0
+
+  '#phy-cells':
+const: 0
+
+required:
+  - reg
+  - clocks
+  - clock-names
+  - '#clock-cells'
+  - '#phy-cells'
+
+  "^dp-phy@[0-9a-f]+$":
+type: object
+description:
+  The DP PHY.
+
+properties:
+  reg:
+items:
+  - description: Address and length of TX.
+  - description: Address and length of RX.
+  - description: Address and length of PCS.
+  - description: Address and length of TX2.
+  - description: Address and length of RX2.
+
+  '#clock-cells':
+const: 1
+
+  '#phy-cells':
+const: 0
+
+required:
+  - reg
+  - '#clock-cells'
+  - '#phy-cells'
 
 required:
   - compatible
   - reg
-  - reg-names
   - "#clock-cells"
   - "#address-cells"
   - "#size-cells"
@@ -103,12 +163,13 @@ examples:
 usb_1_qmpphy: phy-wrapper@88e9000 {
 compatible = "qcom,sdm845-qmp-usb3-phy";
 reg = <0x088e9000 0x18c>,
-  <0x088e8000 0x10>;
-reg-names = "reg-base", "dp_com";
+  <0x088e8000 0x10>,
+  <0x088ea000 0x40>;
+reg-names = "usb", "dp_com", "dp";
 #clock-cells = <1>;
 #address-cells = <1>;
 #size-cells = <1>;
-ranges = <0x0 0x088e9000 0x1000>;
+ranges = <0x0 0x088e9000 0x2000>;
 
 clocks = < GCC_USB3_PRIM_PHY_AUX_CLK>,
  < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
@@ -123,7 +184,7 @@ examples:
 vdda-phy-supply = <_usb2_ss_1p2>;
 vdda-pll-supply = <_usb2_ss_core>;
 
-phy@200 {
+usb3-phy@200 {
 reg = <0x200 0x128>,
   <0x400 0x200>,
   <0xc00 0x218>,
@@ -136,4 +197,14 @@ examples:
 clock-names = "pipe0";
 clock-output-names = "usb3_phy_pipe_clk_src";
 };
+
+dp-phy@88ea200 {
+reg = <0xa200 0x200>,
+  <0xa400 0x200>,
+  <0xaa00 0x200>,
+  <0xa600 0x200>,
+  <0xa800 0x200>;
+#clock-cells = <1>;
+#phy-cells = <0>;
+};
 };
-- 
Sent by a computer, using git, on the internet

Re: [External] Re: [PATCH] mm/hugetlb: Fix a race between hugetlb sysctl handlers

[Muchun Song]

On Wed, Aug 26, 2020 at 8:03 AM Mike Kravetz  wrote:
>
> On 8/24/20 8:01 PM, Muchun Song wrote:
> > On Tue, Aug 25, 2020 at 5:21 AM Mike Kravetz  
> > wrote:
> >>
> >> I too am looking at this now and do not completely understand the race.
> >> It could be that:
> >>
> >> hugetlb_sysctl_handler_common
> >> ...
> >> table->data = 
> >>
> >> and, do_proc_doulongvec_minmax()
> >> ...
> >> return __do_proc_doulongvec_minmax(table->data, table, write, ...
> >> with __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, ...
> >> ...
> >> i = (unsigned long *) data;
> >> ...
> >> *i = val;
> >>
> >> So, __do_proc_doulongvec_minmax can be dereferencing and writing to the 
> >> pointer
> >> in one thread when hugetlb_sysctl_handler_common is setting it in another?
> >
> > Yes, you are right.
> >
> >>
> >> Another confusing part of the message is the stack trace which includes
> >> ...
> >>  ? set_max_huge_pages+0x3da/0x4f0
> >>  ? alloc_pool_huge_page+0x150/0x150
> >>
> >> which are 'downstream' from these routines.  I don't understand why these
> >> are in the trace.
> >
> > I am also confused. But this issue can be reproduced easily by letting more
> > than one thread write to `/proc/sys/vm/nr_hugepages`. With this patch 
> > applied,
> > the issue can not be reproduced and disappears.
>
> There certainly is an issue here as one thread can modify data in another.
> However, I am having a hard time seeing what causes the 'kernel NULL pointer
> dereference'.

If you write 0 to '/proc/sys/vm/nr_hugepages', you will get the
kernel NULL pointer dereference, address: 

If you write 1024 to '/proc/sys/vm/nr_hugepages', you will get the
kernel NULL pointer dereference, address: 0400

The address of dereference is the value which you write to the
'/proc/sys/vm/nr_hugepages'.

>
> I tried to reproduce the issue myself but was unsuccessful.  I have 16 threads
> writing to /proc/sys/vm/nr_hugepages in an infinite loop.  After several hours
> running, I did not hit the issue.  Just curious, what architecture is the
> system?  any special config or compiler options?
>
> If you can easily reproduce, can you post the detailed oops message?
>
> The 'NULL pointer' seems strange because after the first assignment to
> table->data the value should never be NULL.  Certainly it can be modified
> by another thread, but I can not see how it can be NULL.  At the beginning
> of __do_proc_doulongvec_minmax, there is a check for NULL pointer with:

CPU0: CPU1:
  proc_sys_write
hugetlb_sysctl_handler  proc_sys_call_handler
hugetlb_sysctl_handler_common hugetlb_sysctl_handler
  table->data =hugetlb_sysctl_handler_common
  table->data = 
proc_doulongvec_minmax
  do_proc_doulongvec_minmax sysctl_head_finish
__do_proc_doulongvec_minmax
  i = table->data;
  *i = val; // corrupt CPU1 stack

If the val is 0, you will see the NULL.

>
> if (!data || !table->maxlen || !*lenp || (*ppos && !write)) {
> *lenp = 0;
> return 0;
> }
>
> I looked at the code my compiler produced for __do_proc_doulongvec_minmax.
> It appears to use the same value/register for the pointer throughout the
> routine.  IOW, I do not see how the pointer can be NULL for the assignment
> when the routine does:
>
> *i = val;
>
> Again, your analysis/patch points out a real issue.  I just want to get
> a better understanding to make sure there is not another issue causing
> the NULL pointer dereference.

Below is my test script. There are 8 threads to execute the following script.
In my qemu, it is easy to panic. Thanks.

#!/bin/sh

while :
do
echo 128 > /proc/sys/vm/nr_hugepages
echo 0 > /proc/sys/vm/nr_hugepages
done

> --
> Mike Kravetz



-- 
Yours,
Muchun

[PATCH v1 9/9] drm/msm/dp: Use qmp phy for DP PLL and PHY

[Stephen Boyd]

Make the necessary changes to the DP driver to use the qmp phy from the
common phy framework instead of rolling our own in the drm subsystem.
This also removes the PLL code and adds proper includes so things build.

Cc: Jeykumar Sankaran 
Cc: Chandan Uddaraju 
Cc: Vara Reddy 
Cc: Tanmay Shah 
Cc: Bjorn Andersson 
Cc: Manu Gautam 
Cc: Sandeep Maheswaram 
Cc: Douglas Anderson 
Cc: Sean Paul 
Cc: Jonathan Marek 
Cc: Dmitry Baryshkov 
Cc: Rob Clark 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/Makefile|   4 +-
 drivers/gpu/drm/msm/dp/dp_aux.c |   7 +-
 drivers/gpu/drm/msm/dp/dp_catalog.c | 253 +--
 drivers/gpu/drm/msm/dp/dp_catalog.h |   7 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c|  47 +-
 drivers/gpu/drm/msm/dp/dp_display.c |  17 -
 drivers/gpu/drm/msm/dp/dp_display.h |   3 -
 drivers/gpu/drm/msm/dp/dp_link.c|   2 +
 drivers/gpu/drm/msm/dp/dp_panel.c   |   1 +
 drivers/gpu/drm/msm/dp/dp_parser.c  |  12 +-
 drivers/gpu/drm/msm/dp/dp_parser.h  |  12 +-
 drivers/gpu/drm/msm/dp/dp_pll.c |  99 ---
 drivers/gpu/drm/msm/dp/dp_pll.h |  61 --
 drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 930 
 drivers/gpu/drm/msm/dp/dp_pll_private.h |  89 ---
 drivers/gpu/drm/msm/dp/dp_power.c   |  39 +-
 drivers/gpu/drm/msm/dp/dp_power.h   |   9 -
 17 files changed, 78 insertions(+), 1514 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
 delete mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
 delete mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
 delete mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 6d31188cc776..af868e791210 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -109,9 +109,7 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_link.o \
dp/dp_panel.o \
dp/dp_parser.o \
-   dp/dp_power.o \
-   dp/dp_pll.o \
-   dp/dp_pll_10nm.o
+   dp/dp_power.o
 
 msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 5aaa4b50c303..1d03f13a0cb0 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 
 #include "dp_reg.h"
 #include "dp_aux.h"
@@ -357,8 +358,7 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
if (aux->native) {
aux->retry_cnt++;
if (!(aux->retry_cnt % retry_count))
-   dp_catalog_aux_update_cfg(aux->catalog,
-   PHY_AUX_CFG1);
+   dp_catalog_aux_update_cfg(aux->catalog);
dp_catalog_aux_reset(aux->catalog);
}
usleep_range(400, 500); /* at least 400us to next try */
@@ -415,7 +415,7 @@ void dp_aux_reconfig(struct drm_dp_aux *dp_aux)
 
aux = container_of(dp_aux, struct dp_aux_private, dp_aux);
 
-   dp_catalog_aux_update_cfg(aux->catalog, PHY_AUX_CFG1);
+   dp_catalog_aux_update_cfg(aux->catalog);
dp_catalog_aux_reset(aux->catalog);
 }
 
@@ -430,7 +430,6 @@ void dp_aux_init(struct drm_dp_aux *dp_aux)
 
aux = container_of(dp_aux, struct dp_aux_private, dp_aux);
 
-   dp_catalog_aux_setup(aux->catalog);
dp_catalog_aux_enable(aux->catalog, true);
aux->retry_cnt = 0;
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index f92a8e37a312..66074c44766e 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -8,8 +8,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "dp_catalog.h"
 #include "dp_reg.h"
@@ -128,83 +131,6 @@ static inline void dp_write_ahb(struct dp_catalog_private 
*catalog,
writel(data, catalog->io->dp_controller.base + offset);
 }
 
-static inline void dp_write_phy(struct dp_catalog_private *catalog,
-  u32 offset, u32 data)
-{
-   offset += DP_PHY_REG_OFFSET;
-   /*
-* To make sure phy reg writes happens before any other operation,
-* this function uses writel() instread of writel_relaxed()
-*/
-   writel(data, catalog->io->phy_reg.base + offset);
-}
-
-static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
-  u32 offset)
-{
-   offset += DP_PHY_REG_OFFSET;
-   /*
-* To make sure phy reg writes happens before any other operation,
-* this function uses writel() instread of writel_relaxed()
-*/
-   return readl_relaxed(catalog->io->phy_reg.base + offset);
-}
-
-static inline void dp_write_pll(struct dp_catalog_private *catalog,
-  u32 offset, u32 data)
-{
-   

Re: Packet gets stuck in NOLOCK pfifo_fast qdisc

[Kehuan Feng]

Hi Hillf,

Thanks for the patch.
I just tried it and it looks better than previous one. The issue
appeared only once over ~30 mins stressing (without the patch , it
shows up within 1 mins in usual, so I feel like we are getting close
to the final fix)
(pasted the modifications on my tree in case of any missing)

--- ./include/net/sch_generic.h.orig 2020-08-21 15:13:51.787952710 +0800
+++ ./include/net/sch_generic.h 2020-08-26 09:41:04.647173869 +0800
@@ -79,6 +79,7 @@
 #define TCQ_F_INVISIBLE 0x80 /* invisible by default in dump */
 #define TCQ_F_NOLOCK 0x100 /* qdisc does not require locking */
 #define TCQ_F_OFFLOADED 0x200 /* qdisc is offloaded to HW */
+ int pkt_seq;
  u32 limit;
  const struct Qdisc_ops *ops;
  struct qdisc_size_table __rcu *stab;
--- ./include/net/pkt_sched.h.orig 2020-08-21 15:13:51.787952710 +0800
+++ ./include/net/pkt_sched.h 2020-08-26 09:42:14.491377514 +0800
@@ -117,8 +117,15 @@
 static inline void qdisc_run(struct Qdisc *q)
 {
  if (qdisc_run_begin(q)) {
+ q->pkt_seq = 0;
+
  __qdisc_run(q);
  qdisc_run_end(q);
+
+ /* reschedule qdisc if there are packets enqueued */
+ if (q->pkt_seq != 0)
+ __netif_schedule(q);
+
  }
 }

--- ./net/core/dev.c.orig 2020-03-19 16:31:27.0 +0800
+++ ./net/core/dev.c 2020-08-26 09:47:57.783165885 +0800
@@ -2721,6 +2721,7 @@

  local_irq_save(flags);
  sd = this_cpu_ptr(_data);
+ q->pkt_seq = 0;
  q->next_sched = NULL;
  *sd->output_queue_tailp = q;
  sd->output_queue_tailp = >next_sched;
--- ./net/sched/sch_generic.c.orig 2020-08-24 22:02:04.589830751 +0800
+++ ./net/sched/sch_generic.c 2020-08-26 09:43:40.987852551 +0800
@@ -403,6 +403,9 @@
  */
  quota -= packets;
  if (quota <= 0 || need_resched()) {
+ /* info caller to reschedule qdisc outside q->seqlock */
+ q->pkt_seq = 1;
+
  __netif_schedule(q);
  break;
  }


Hillf Danton  于2020年8月26日周三 上午12:26写道：
>
>
> Hi Feng,
>
> On Tue, 25 Aug 2020 15:14:12 +0800 Fengkehuan Feng wrote:
> > Hi Hillf,
> >
> > I just tried the updated version and the system can boot up now.
>
> Thanks again for your testing.
>
> > It does mitigate the issue a lot but still couldn't get rid of it
> > thoroughly. It seems to me like the effect of Cong's patch.
>
> Your echoes show we're still march in the dark and let's try another
> direction in which qdisc is rescheduled outside seqlock to make sure
> tx softirq is raised when there're more packets on the pfifo_fast to
> be transmitted.
>
> CPU0CPU1
> 
> seqlock
> test __QDISC_STATE_SCHED
> raise tx softirq
> clear __QDISC_STATE_SCHED
> try seqlock
> __qdisc_run(q);
> sequnlock
> sequnlock
>
>
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -79,6 +79,7 @@ struct Qdisc {
>  #define TCQ_F_INVISIBLE0x80 /* invisible by default in dump 
> */
>  #define TCQ_F_NOLOCK   0x100 /* qdisc does not require locking */
>  #define TCQ_F_OFFLOADED0x200 /* qdisc is offloaded to HW */
> +   int pkt_seq;
> u32 limit;
> const struct Qdisc_ops  *ops;
> struct qdisc_size_table __rcu *stab;
> --- a/include/net/pkt_sched.h
> +++ b/include/net/pkt_sched.h
> @@ -118,6 +118,8 @@ void __qdisc_run(struct Qdisc *q);
>  static inline void qdisc_run(struct Qdisc *q)
>  {
> if (qdisc_run_begin(q)) {
> +   q->pkt_seq = 0;
> +
> /* NOLOCK qdisc must check 'state' under the qdisc seqlock
>  * to avoid racing with dev_qdisc_reset()
>  */
> @@ -125,6 +127,10 @@ static inline void qdisc_run(struct Qdis
> likely(!test_bit(__QDISC_STATE_DEACTIVATED, >state)))
> __qdisc_run(q);
> qdisc_run_end(q);
> +
> +   /* reschedule qdisc if there are packets enqueued */
> +   if (q->pkt_seq != 0)
> +   __netif_schedule(q);
> }
>  }
>
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -384,6 +384,8 @@ void __qdisc_run(struct Qdisc *q)
> while (qdisc_restart(q, )) {
> quota -= packets;
> if (quota <= 0) {
> +   /* info caller to reschedule qdisc outside q->seqlock 
> */
> +   q->pkt_seq = 1;
> __netif_schedule(q);
> break;
> }
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3031,6 +3031,7 @@ static void __netif_reschedule(struct Qd
>
> local_irq_save(flags);
> sd = this_cpu_ptr(_data);
> +   q->pkt_seq = 0;
> q->next_sched = NULL;
> *sd->output_queue_tailp = q;
> sd->output_queue_tailp = >next_sched;
> --
>

Re: [PATCH bpf-next v4 03/30] bpf: memcg-based memory accounting for bpf maps

[Roman Gushchin]

On Tue, Aug 25, 2020 at 04:27:09PM -0700, Shakeel Butt wrote:
> On Fri, Aug 21, 2020 at 8:01 AM Roman Gushchin  wrote:
> >
> > This patch enables memcg-based memory accounting for memory allocated
> > by __bpf_map_area_alloc(), which is used by most map types for
> > large allocations.
> >
> > If a map is updated from an interrupt context, and the update
> > results in memory allocation, the memory cgroup can't be determined
> > from the context of the current process. To address this case,
> > bpf map preserves a pointer to the memory cgroup of the process,
> > which created the map. This memory cgroup is charged for allocations
> > from interrupt context.
> >
> > Following patches in the series will refine the accounting for
> > some map types.
> >
> > Signed-off-by: Roman Gushchin 
> > ---
> >  include/linux/bpf.h  |  4 
> >  kernel/bpf/helpers.c | 37 -
> >  kernel/bpf/syscall.c | 27 ++-
> >  3 files changed, 66 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index a9b7185a6b37..b5f178afde94 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -34,6 +34,7 @@ struct btf_type;
> >  struct exception_table_entry;
> >  struct seq_operations;
> >  struct bpf_iter_aux_info;
> > +struct mem_cgroup;
> >
> >  extern struct idr btf_idr;
> >  extern spinlock_t btf_idr_lock;
> > @@ -138,6 +139,9 @@ struct bpf_map {
> > u32 btf_value_type_id;
> > struct btf *btf;
> > struct bpf_map_memory memory;
> > +#ifdef CONFIG_MEMCG_KMEM
> > +   struct mem_cgroup *memcg;
> > +#endif
> > char name[BPF_OBJ_NAME_LEN];
> > u32 btf_vmlinux_value_type_id;
> > bool bypass_spec_v1;
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index be43ab3e619f..f8ce7bc7003f 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "../../lib/kstrtox.h"
> >
> > @@ -41,11 +42,45 @@ const struct bpf_func_proto bpf_map_lookup_elem_proto = 
> > {
> > .arg2_type  = ARG_PTR_TO_MAP_KEY,
> >  };
> >
> > +#ifdef CONFIG_MEMCG_KMEM
> > +static __always_inline int __bpf_map_update_elem(struct bpf_map *map, void 
> > *key,
> > +void *value, u64 flags)
> > +{
> > +   struct mem_cgroup *old_memcg;
> > +   bool in_interrupt;
> > +   int ret;
> > +
> > +   /*
> > +* If update from an interrupt context results in a memory 
> > allocation,
> > +* the memory cgroup to charge can't be determined from the context
> > +* of the current task. Instead, we charge the memory cgroup, which
> > +* contained a process created the map.
> > +*/
> > +   in_interrupt = in_interrupt();
> > +   if (in_interrupt)
> > +   old_memcg = memalloc_use_memcg(map->memcg);
> > +
> 
> The memcg_kmem_bypass() will bypass all __GFP_ACCOUNT allocations even
> before looking at current->active_memcg, so, this patch will be a
> noop.

Good point. Looks like it's a good example of kmem accounting from an interrupt
context, which we've discussed on the Plumbers session.

It means we need some more work on the mm side.

Thanks!

Re: [Phishing Risk] [External] Re: [PATCH] mm/hugetlb: Fix a race between hugetlb sysctl handlers

[Muchun Song]

HI Andi,

On Tue, Aug 25, 2020 at 11:34 PM Andi Kleen  wrote:
>
> > Fixes: e5ff215941d5 ("hugetlb: multiple hstates for multiple page sizes")
>
> I don't think the Fixes line is correct. The original patch
> just used a global variable and didn't have this race.
> It must have been added later in some other patch that added
> hugetlb_sysctl_handler_common.

I don't agree with you. The 'e5ff215941d5' is not used a global
variable. Below is the code snippet of this patch. Thanks.

@@ -1037,8 +1109,19 @@ int hugetlb_sysctl_handler(struct ctl_table
*table, int write,
   struct file *file, void __user *buffer,
   size_t *length, loff_t *ppos)
 {
+   struct hstate *h = _hstate;
+   unsigned long tmp;

Here is a local variable of tmp.

+
+   if (!write)
+   tmp = h->max_huge_pages;
+
+   table->data = 
+   table->maxlen = sizeof(unsigned long);
proc_doulongvec_minmax(table, write, file, buffer, length, ppos);
-   max_huge_pages = set_max_huge_pages(max_huge_pages);
+
+   if (write)
+   h->max_huge_pages = set_max_huge_pages(h, tmp);
+
return 0;
 }


>
> -Andi



-- 
Yours,
Muchun

drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 'of_rkvdec_match'

[kernel test robot]

Hi Boris,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   abb3438d69fb6dd5baa4ae23eafbf5b87945eff1
commit: cd33c830448baf7b1e94da72eca069e3e1d050c9 media: rkvdec: Add the rkvdec 
driver
date:   4 months ago
config: x86_64-randconfig-r001-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout cd33c830448baf7b1e94da72eca069e3e1d050c9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 
>> 'of_rkvdec_match' [-Wunused-const-variable]
   static const struct of_device_id of_rkvdec_match[] = {
^
   1 warning generated.

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd33c830448baf7b1e94da72eca069e3e1d050c9
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cd33c830448baf7b1e94da72eca069e3e1d050c9
vim +/of_rkvdec_match +967 drivers/staging/media/rkvdec/rkvdec.c

   966  
 > 967  static const struct of_device_id of_rkvdec_match[] = {
   968  { .compatible = "rockchip,rk3399-vdec" },
   969  { /* sentinel */ }
   970  };
   971  MODULE_DEVICE_TABLE(of, of_rkvdec_match);
   972  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 5/9] iomap: Support arbitrarily many blocks per page

[Matthew Wilcox]

On Tue, Aug 25, 2020 at 02:02:03PM -0700, Darrick J. Wong wrote:
> >  /*
> > - * Structure allocated for each page when block size < PAGE_SIZE to track
> > + * Structure allocated for each page when block size < page size to track
> >   * sub-page uptodate status and I/O completions.
> 
> "for each regular page or head page of a huge page"?  Or whatever we're
> calling them nowadays?

Well, that's what I'm calling a "page" ;-)

How about "for each page or THP"?  The fact that it's stored in the
head page is incidental -- it's allocated for the THP.

RE: [PATCH 3/5] i2c: aspeed: Mask IRQ status to relevant bits

[Ryan Chen]

> -Original Message-
> From: Tao Ren [mailto:rentao.b...@gmail.com]
> Sent: Wednesday, August 26, 2020 4:05 AM
> To: Eddie James 
> Cc: Joel Stanley ; devicetree ;
> linux-aspeed ; dmitry.torok...@gmail.com;
> Brendan Higgins ; Linux Kernel Mailing List
> ; Rob Herring ;
> linux-...@vger.kernel.org; linux-in...@vger.kernel.org; Ryan Chen
> 
> Subject: Re: [PATCH 3/5] i2c: aspeed: Mask IRQ status to relevant bits
> 
> On Tue, Aug 25, 2020 at 02:47:51PM -0500, Eddie James wrote:
> >
> > On 8/25/20 1:38 AM, Joel Stanley wrote:
> > > On Thu, 20 Aug 2020 at 16:12, Eddie James 
> wrote:
> > > > Mask the IRQ status to only the bits that the driver checks. This
> > > > prevents excessive driver warnings when operating in slave mode
> > > > when additional bits are set that the driver doesn't handle.
> > > >
> > > > Signed-off-by: Eddie James 
> > > > ---
> > > >   drivers/i2c/busses/i2c-aspeed.c | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/i2c/busses/i2c-aspeed.c
> > > > b/drivers/i2c/busses/i2c-aspeed.c index 31268074c422..abf40f2af8b4
> > > > 100644
> > > > --- a/drivers/i2c/busses/i2c-aspeed.c
> > > > +++ b/drivers/i2c/busses/i2c-aspeed.c
> > > > @@ -604,6 +604,7 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq,
> void *dev_id)
> > > >  writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE,
> > > > bus->base + ASPEED_I2C_INTR_STS_REG);
> > > >  readl(bus->base + ASPEED_I2C_INTR_STS_REG);
> > > > +   irq_received &= 0xf000;
> > > >  irq_remaining = irq_received;
> > > This would defeat the check for irq_remaining. I don't think we want to do
> this.
> > >
> > > Can you explain why these bits are being set in slave mode?
> >
> >
> > No, I don't have any documentation for the bits that are masked off
> > here, so I don't know why they would get set.
> >
> > The check for irq_remaining is still useful for detecting that the
> > driver state machine might be out of sync with what the master is doing.
> 
> I have a similar patch in my local tree, and the reason being: AST2600 I2C
> Controller may set I2CD10[25:24] to report Current Slave Parking Status
> (defined in new register I2CS24) even though the new register mode is off. The
> 2 bits can be ignored in legacy mode, and Ryan from ASPEED could confirm it.
Yes, in AST2600 i2cd10[25:24] will be the same with new mode register 
i2cs24[25:24]
Thanks Tao.
> 
> 
> Cheers,
> 
> Tao

[PATCH] [v2] blk-mq: use BLK_MQ_NO_TAG for no tag

[Xianting Tian]

Replace various magic -1 constants for tags with BLK_MQ_NO_TAG.
And move the definition of BLK_MQ_NO_TAG from 'block/blk-mq-tag.h'
to 'include/linux/blk-mq.h'

Signed-off-by: Xianting Tian 
---
 block/blk-core.c   | 4 ++--
 block/blk-mq-sched.c   | 2 +-
 block/blk-mq-tag.h | 6 --
 include/linux/blk-mq.h | 8 +++-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index d9d632639..c7eaf7504 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -116,8 +116,8 @@ void blk_rq_init(struct request_queue *q, struct request 
*rq)
rq->__sector = (sector_t) -1;
INIT_HLIST_NODE(>hash);
RB_CLEAR_NODE(>rb_node);
-   rq->tag = -1;
-   rq->internal_tag = -1;
+   rq->tag = BLK_MQ_NO_TAG;
+   rq->internal_tag = BLK_MQ_NO_TAG;
rq->start_time_ns = ktime_get_ns();
rq->part = NULL;
refcount_set(>ref, 1);
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index a19cdf159..439481f59 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -522,7 +522,7 @@ void blk_mq_sched_insert_request(struct request *rq, bool 
at_head,
goto run;
}
 
-   WARN_ON(e && (rq->tag != -1));
+   WARN_ON(e && (rq->tag != BLK_MQ_NO_TAG));
 
if (blk_mq_sched_bypass_insert(hctx, !!e, rq)) {
/*
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index b1acac518..8fc48aa72 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -45,12 +45,6 @@ static inline struct sbq_wait_state *bt_wait_ptr(struct 
sbitmap_queue *bt,
return sbq_wait_ptr(bt, >wait_index);
 }
 
-enum {
-   BLK_MQ_NO_TAG   = -1U,
-   BLK_MQ_TAG_MIN  = 1,
-   BLK_MQ_TAG_MAX  = BLK_MQ_NO_TAG - 1,
-};
-
 extern bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *);
 extern void __blk_mq_tag_idle(struct blk_mq_hw_ctx *);
 
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 9d2d5ad36..2499d8aae 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -209,6 +209,12 @@ enum hctx_type {
HCTX_MAX_TYPES,
 };
 
+enum {
+   BLK_MQ_NO_TAG   = -1U,
+   BLK_MQ_TAG_MIN  = 1,
+   BLK_MQ_TAG_MAX  = BLK_MQ_NO_TAG - 1,
+};
+
 /**
  * struct blk_mq_tag_set - tag set that can be shared between request queues
  * @map:  One or more ctx -> hctx mappings. One map exists for each
@@ -569,7 +575,7 @@ static inline void *blk_mq_rq_to_pdu(struct request *rq)
 static inline blk_qc_t request_to_qc_t(struct blk_mq_hw_ctx *hctx,
struct request *rq)
 {
-   if (rq->tag != -1)
+   if (rq->tag != BLK_MQ_NO_TAG)
return rq->tag | (hctx->queue_num << BLK_QC_T_SHIFT);
 
return rq->internal_tag | (hctx->queue_num << BLK_QC_T_SHIFT) |
-- 
2.17.1

Re: [PATCH] thermal: sysfs: fall back to vzalloc for cooling device's statistics

[Yue Hu]

On Mon, 24 Aug 2020 12:40:35 +0200
Daniel Lezcano  wrote:

> On 18/08/2020 08:30, Yue Hu wrote:
> > From: Yue Hu 
> > 
> > We observed warning about kzalloc() when register thermal cooling device
> > in backlight_device_register(). backlight display can be a cooling device
> > since reducing screen brightness will can help reduce temperature.
> > 
> > However, ->get_max_state of backlight will assign max brightness of 1024
> > to states. The memory size can be getting 1MB+ due to states * states.  
> 
> What are the benefits of a 1024 states cooling device ? Is the
> difference noticeable with a such small step ?

Okay, this issue is happened under MSM/Android platform. QCOM spmi wled driver
will define the max brightness. We needs to fix the issue to get thermal 
statistics.

Thx.

> 
> 
> > That is so large to trigger kmalloc() warning.
> > 
> > So, let's remove it and try vzalloc() if kzalloc() fails.
> > 
> > Signed-off-by: Yue Hu 
> > ---
> >  drivers/thermal/thermal_sysfs.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/thermal/thermal_sysfs.c 
> > b/drivers/thermal/thermal_sysfs.c
> > index aa99edb..9bae0b6 100644
> > --- a/drivers/thermal/thermal_sysfs.c
> > +++ b/drivers/thermal/thermal_sysfs.c
> > @@ -16,6 +16,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -919,7 +921,9 @@ static void cooling_device_stats_setup(struct 
> > thermal_cooling_device *cdev)
> > var += sizeof(*stats->time_in_state) * states;
> > var += sizeof(*stats->trans_table) * states * states;
> >  
> > -   stats = kzalloc(var, GFP_KERNEL);
> > +   stats = kzalloc(var, GFP_KERNEL | __GFP_NOWARN);
> > +   if (!stats)
> > +   stats = vzalloc(var);
> > if (!stats)
> > return;
> >  
> > @@ -938,7 +942,7 @@ static void cooling_device_stats_setup(struct 
> > thermal_cooling_device *cdev)
> >  
> >  static void cooling_device_stats_destroy(struct thermal_cooling_device 
> > *cdev)
> >  {
> > -   kfree(cdev->stats);
> > +   kvfree(cdev->stats);
> > cdev->stats = NULL;
> >  }
> >  
> >   
> 
> 

Re: [PATCH] block: convert tasklets to use new tasklet_setup() API

[Allen Pais]

On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
 wrote:
>
> On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > [...]
> > > > > Since both threads seem to have petered out, let me suggest in
> > > > > kernel.h:
> > > > >
> > > > > #define cast_out(ptr, container, member) \
> > > > > container_of(ptr, typeof(*container), member)
> > > > >
> > > > > It does what you want, the argument order is the same as
> > > > > container_of with the only difference being you name the
> > > > > containing structure instead of having to specify its type.
> > > >
> > > > Not to incessantly bike shed on the naming, but I don't like
> > > > cast_out, it's not very descriptive. And it has connotations of
> > > > getting rid of something, which isn't really true.
> > >
> > > Um, I thought it was exactly descriptive: you're casting to the
> > > outer container.  I thought about following the C++ dynamic casting
> > > style, so out_cast(), but that seemed a bit pejorative.  What about
> > > outer_cast()?
> > >
> > > > FWIW, I like the from_ part of the original naming, as it has
> > > > some clues as to what is being done here. Why not just
> > > > from_container()? That should immediately tell people what it
> > > > does without having to look up the implementation, even before
> > > > this becomes a part of the accepted coding norm.
> > >
> > > I'm not opposed to container_from() but it seems a little less
> > > descriptive than outer_cast() but I don't really care.  I always
> > > have to look up container_of() when I'm using it so this would just
> > > be another macro of that type ...
> > >
> >
> >  So far we have a few which have been suggested as replacement
> > for from_tasklet()
> >
> > - out_cast() or outer_cast()
> > - from_member().
> > - container_from() or from_container()
> >
> > from_container() sounds fine, would trimming it a bit work? like
> > from_cont().
>
> I'm fine with container_from().  It's the same form as container_of()
> and I think we need urgent agreement to not stall everything else so
> the most innocuous name is likely to get the widest acceptance.

Kees,

  Will you be  sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.

Thanks.

[PATCH v2 0/6] xfrm: Add compat layer

[Dmitry Safonov]

Changes since v1:
- reworked patches set to use translator
- separated the compat layer into xfrm_compat.c,
  compiled under XFRM_USER_COMPAT config
- 32-bit messages now being sent in frag_list (like wext-core does)
- instead of __packed add compat_u64 members in compat structures
- selftest reworked to kselftest lib API
- added netlink dump testing to the selftest

XFRM is disabled for compatible users because of the UABI difference.
The difference is in structures paddings and in the result the size
of netlink messages differ.

Possibility for compatible application to manage xfrm tunnels was
disabled by: the commmit 19d7df69fdb2 ("xfrm: Refuse to insert 32 bit
userspace socket policies on 64 bit systems") and the commit 74005991b78a
("xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host").

This is my second attempt to resolve the xfrm/compat problem by adding
the 64=>32 and 32=>64 bit translators those non-visibly to a user
provide translation between compatible user and kernel.
Previous attempt was to interrupt the message ABI according to a syscall
by xfrm_user, which resulted in over-complicated code [1].

Florian Westphal provided the idea of translator and some draft patches
in the discussion. In these patches, his idea is reused and some of his
initial code is also present.

There were a couple of attempts to solve xfrm compat problem:
https://lkml.org/lkml/2017/1/20/733
https://patchwork.ozlabs.org/patch/44600/
http://netdev.vger.kernel.narkive.com/2Gesykj6/patch-net-next-xfrm-correctly-parse-netlink-msg-from-32bits-ip-command-on-64bits-host

All the discussions end in the conclusion that xfrm should have a full
compatible layer to correctly work with 32-bit applications on 64-bit
kernels:
https://lkml.org/lkml/2017/1/23/413
https://patchwork.ozlabs.org/patch/433279/

In some recent lkml discussion, Linus said that it's worth to fix this
problem and not giving people an excuse to stay on 32-bit kernel:
https://lkml.org/lkml/2018/2/13/752

There is also an selftest for ipsec tunnels.
It doesn't depend on any library and compat version can be easy
build with: make CFLAGS=-m32 net/ipsec

Patches as a .git branch:
https://github.com/0x7f454c46/linux/tree/xfrm-compat-v2

[1]: https://lkml.kernel.org/r/20180726023144.31066-1-d...@arista.com

Cc: "David S. Miller" 
Cc: Florian Westphal 
Cc: Herbert Xu 
Cc: Jakub Kicinski 
Cc: Steffen Klassert 
Cc: Stephen Suryaputra 
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: net...@vger.kernel.org

Dmitry Safonov (6):
  xfrm/compat: Add 64=>32-bit messages translator
  xfrm/compat: Attach xfrm dumps to 64=>32 bit translator
  netlink/compat: Append NLMSG_DONE/extack to frag_list
  xfrm/compat: Add 32=>64-bit messages translator
  xfrm/compat: Translate 32-bit user_policy from sockptr
  selftest/net/xfrm: Add test for ipsec tunnel

 MAINTAINERS|1 +
 include/net/xfrm.h |   32 +
 net/netlink/af_netlink.c   |   48 +-
 net/xfrm/Kconfig   |   11 +
 net/xfrm/Makefile  |1 +
 net/xfrm/xfrm_compat.c |  609 +++
 net/xfrm/xfrm_state.c  |   11 +-
 net/xfrm/xfrm_user.c   |   79 +-
 tools/testing/selftests/net/.gitignore |1 +
 tools/testing/selftests/net/Makefile   |1 +
 tools/testing/selftests/net/ipsec.c| 2195 
 11 files changed, 2953 insertions(+), 36 deletions(-)
 create mode 100644 net/xfrm/xfrm_compat.c
 create mode 100644 tools/testing/selftests/net/ipsec.c

-- 
2.27.0

[PATCH v2 4/6] xfrm/compat: Add 32=>64-bit messages translator

[Dmitry Safonov]

XFRM is disabled for compatible users because of the UABI difference.
The difference is in structures paddings and in the result the size
of netlink messages differ.

Possibility for compatible application to manage xfrm tunnels was
disabled by: the commmit 19d7df69fdb2 ("xfrm: Refuse to insert 32 bit
userspace socket policies on 64 bit systems") and the commit 74005991b78a
("xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host").

This is my second attempt to resolve the xfrm/compat problem by adding
the 64=>32 and 32=>64 bit translators those non-visibly to a user
provide translation between compatible user and kernel.
Previous attempt was to interrupt the message ABI according to a syscall
by xfrm_user, which resulted in over-complicated code [1].

Florian Westphal provided the idea of translator and some draft patches
in the discussion. Here his idea is reused and some of his initial
code is also present.

Provide the user-to-kernel translator under XFRM_USER_COMPAT, that
creates for 32-bit xfrm-user message a 64-bit translation.
The translation is afterwards reused by xfrm_user code just as if
userspace had sent 64-bit message.

[1]: https://lkml.kernel.org/r/20180726023144.31066-1-d...@arista.com
Signed-off-by: Dmitry Safonov 
---
 include/net/xfrm.h |  11 ++
 net/xfrm/Kconfig   |   3 +-
 net/xfrm/xfrm_compat.c | 276 +
 net/xfrm/xfrm_user.c   |  50 +---
 4 files changed, 321 insertions(+), 19 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9febf4f5d2ea..242e690674c6 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -2000,10 +2000,15 @@ static inline int xfrm_tunnel_check(struct sk_buff 
*skb, struct xfrm_state *x,
return 0;
 }
 
+extern const struct nla_policy xfrma_policy[XFRMA_MAX+1];
+
 #ifdef CONFIG_XFRM_USER_COMPAT
 extern int xfrm_alloc_compat(struct sk_buff *skb);
 extern int __xfrm_alloc_compat(struct sk_buff *skb, const struct nlmsghdr 
*nlh);
 extern const int xfrm_msg_min[XFRM_NR_MSGTYPES];
+extern struct nlmsghdr *xfrm_user_rcv_msg_compat(const struct nlmsghdr *nlh,
+   int maxtype, const struct nla_policy *policy,
+   struct netlink_ext_ack *extack);
 #else
 static inline int xfrm_alloc_compat(struct sk_buff *skb)
 {
@@ -2014,6 +2019,12 @@ static inline int __xfrm_alloc_compat(struct sk_buff 
*skb,
 {
return 0;
 }
+static inline struct nlmsghdr *xfrm_user_rcv_msg_compat(const struct nlmsghdr 
*nlh,
+   int maxtype, const struct nla_policy *policy,
+   struct netlink_ext_ack *extack)
+{
+   return ERR_PTR(-EOPNOTSUPP);
+}
 #endif
 
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index e79b48dab61b..3adf31a83a79 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -30,7 +30,8 @@ config XFRM_USER
 
 config XFRM_USER_COMPAT
tristate "Compatible ABI support"
-   depends on XFRM_USER && COMPAT_FOR_U64_ALIGNMENT
+   depends on XFRM_USER && COMPAT_FOR_U64_ALIGNMENT && \
+   HAVE_EFFICIENT_UNALIGNED_ACCESS
select WANT_COMPAT_NETLINK_MESSAGES
help
  Transformation(XFRM) user configuration interface like IPsec
diff --git a/net/xfrm/xfrm_compat.c b/net/xfrm/xfrm_compat.c
index b34c8b56a571..79daa7f47d5a 100644
--- a/net/xfrm/xfrm_compat.c
+++ b/net/xfrm/xfrm_compat.c
@@ -96,6 +96,39 @@ static const int compat_msg_min[XFRM_NR_MSGTYPES] = {
[XFRM_MSG_MAPPING - XFRM_MSG_BASE] = XMSGSIZE(xfrm_user_mapping)
 };
 
+static const struct nla_policy compat_policy[XFRMA_MAX+1] = {
+   [XFRMA_SA]  = { .len = XMSGSIZE(compat_xfrm_usersa_info)},
+   [XFRMA_POLICY]  = { .len = 
XMSGSIZE(compat_xfrm_userpolicy_info)},
+   [XFRMA_LASTUSED]= { .type = NLA_U64},
+   [XFRMA_ALG_AUTH_TRUNC]  = { .len = sizeof(struct xfrm_algo_auth)},
+   [XFRMA_ALG_AEAD]= { .len = sizeof(struct xfrm_algo_aead) },
+   [XFRMA_ALG_AUTH]= { .len = sizeof(struct xfrm_algo) },
+   [XFRMA_ALG_CRYPT]   = { .len = sizeof(struct xfrm_algo) },
+   [XFRMA_ALG_COMP]= { .len = sizeof(struct xfrm_algo) },
+   [XFRMA_ENCAP]   = { .len = sizeof(struct xfrm_encap_tmpl) },
+   [XFRMA_TMPL]= { .len = sizeof(struct xfrm_user_tmpl) },
+   [XFRMA_SEC_CTX] = { .len = sizeof(struct xfrm_sec_ctx) },
+   [XFRMA_LTIME_VAL]   = { .len = sizeof(struct xfrm_lifetime_cur) },
+   [XFRMA_REPLAY_VAL]  = { .len = sizeof(struct xfrm_replay_state) },
+   [XFRMA_REPLAY_THRESH]   = { .type = NLA_U32 },
+   [XFRMA_ETIMER_THRESH]   = { .type = NLA_U32 },
+   [XFRMA_SRCADDR] = { .len = sizeof(xfrm_address_t) },
+   [XFRMA_COADDR]  = { .len = sizeof(xfrm_address_t) },
+   [XFRMA_POLICY_TYPE] = { .len = sizeof(struct xfrm_userpolicy_type)},
+   [XFRMA_MIGRATE] = { .len = sizeof(struct 

[PATCH v2 1/6] xfrm/compat: Add 64=>32-bit messages translator

[Dmitry Safonov]

XFRM is disabled for compatible users because of the UABI difference.
The difference is in structures paddings and in the result the size
of netlink messages differ.

Possibility for compatible application to manage xfrm tunnels was
disabled by: the commmit 19d7df69fdb2 ("xfrm: Refuse to insert 32 bit
userspace socket policies on 64 bit systems") and the commit 74005991b78a
("xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host").

This is my second attempt to resolve the xfrm/compat problem by adding
the 64=>32 and 32=>64 bit translators those non-visibly to a user
provide translation between compatible user and kernel.
Previous attempt was to interrupt the message ABI according to a syscall
by xfrm_user, which resulted in over-complicated code [1].

Florian Westphal provided the idea of translator and some draft patches
in the discussion. In these patches, his idea is reused and some of his
initial code is also present.

Provide the kernel-to-user translator under XFRM_USER_COMPAT, that
creates for 64-bit xfrm-user message a 32-bit translation and puts it
in skb's frag_list. net/compat.c layer provides MSG_CMSG_COMPAT to
decide if the message should be taken from skb or frag_list.
(used by wext-core which has also an ABI difference)

Kernel sends 64-bit xfrm messages to the userspace for:
- multicast (monitor events)
- netlink dumps

Wire up the translator to xfrm_nlmsg_multicast().

[1]: https://lkml.kernel.org/r/20180726023144.31066-1-d...@arista.com
Signed-off-by: Dmitry Safonov 
---
 include/net/xfrm.h |  10 ++
 net/xfrm/Kconfig   |  10 ++
 net/xfrm/Makefile  |   1 +
 net/xfrm/xfrm_compat.c | 302 +
 net/xfrm/xfrm_user.c   |   9 +-
 5 files changed, 331 insertions(+), 1 deletion(-)
 create mode 100644 net/xfrm/xfrm_compat.c

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 2737d24ec244..9810b5090338 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -2000,6 +2000,16 @@ static inline int xfrm_tunnel_check(struct sk_buff *skb, 
struct xfrm_state *x,
return 0;
 }
 
+#ifdef CONFIG_XFRM_USER_COMPAT
+extern int xfrm_alloc_compat(struct sk_buff *skb);
+extern const int xfrm_msg_min[XFRM_NR_MSGTYPES];
+#else
+static inline int xfrm_alloc_compat(struct sk_buff *skb)
+{
+   return 0;
+}
+#endif
+
 #if IS_ENABLED(CONFIG_IPV6)
 static inline bool xfrm6_local_dontfrag(const struct sock *sk)
 {
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 5b9a5ab48111..e79b48dab61b 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -28,6 +28,16 @@ config XFRM_USER
 
  If unsure, say Y.
 
+config XFRM_USER_COMPAT
+   tristate "Compatible ABI support"
+   depends on XFRM_USER && COMPAT_FOR_U64_ALIGNMENT
+   select WANT_COMPAT_NETLINK_MESSAGES
+   help
+ Transformation(XFRM) user configuration interface like IPsec
+ used by compatible Linux applications.
+
+ If unsure, say N.
+
 config XFRM_INTERFACE
tristate "Transformation virtual interface"
depends on XFRM && IPV6
diff --git a/net/xfrm/Makefile b/net/xfrm/Makefile
index 2d4bb4b9f75e..494aa744bfb9 100644
--- a/net/xfrm/Makefile
+++ b/net/xfrm/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_XFRM) := xfrm_policy.o xfrm_state.o xfrm_hash.o \
 obj-$(CONFIG_XFRM_STATISTICS) += xfrm_proc.o
 obj-$(CONFIG_XFRM_ALGO) += xfrm_algo.o
 obj-$(CONFIG_XFRM_USER) += xfrm_user.o
+obj-$(CONFIG_XFRM_USER_COMPAT) += xfrm_compat.o
 obj-$(CONFIG_XFRM_IPCOMP) += xfrm_ipcomp.o
 obj-$(CONFIG_XFRM_INTERFACE) += xfrm_interface.o
 obj-$(CONFIG_XFRM_ESPINTCP) += espintcp.o
diff --git a/net/xfrm/xfrm_compat.c b/net/xfrm/xfrm_compat.c
new file mode 100644
index ..b9eb65dde0db
--- /dev/null
+++ b/net/xfrm/xfrm_compat.c
@@ -0,0 +1,302 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * XFRM compat layer
+ * Author: Dmitry Safonov 
+ * Based on code and translator idea by: Florian Westphal 
+ */
+#include 
+#include 
+#include 
+
+struct compat_xfrm_lifetime_cfg {
+   compat_u64 soft_byte_limit, hard_byte_limit;
+   compat_u64 soft_packet_limit, hard_packet_limit;
+   compat_u64 soft_add_expires_seconds, hard_add_expires_seconds;
+   compat_u64 soft_use_expires_seconds, hard_use_expires_seconds;
+}; /* same size on 32bit, but only 4 byte alignment required */
+
+struct compat_xfrm_lifetime_cur {
+   compat_u64 bytes, packets, add_time, use_time;
+}; /* same size on 32bit, but only 4 byte alignment required */
+
+struct compat_xfrm_userpolicy_info {
+   struct xfrm_selector sel;
+   struct compat_xfrm_lifetime_cfg lft;
+   struct compat_xfrm_lifetime_cur curlft;
+   __u32 priority, index;
+   u8 dir, action, flags, share;
+   /* 4 bytes additional padding on 64bit */
+};
+
+struct compat_xfrm_usersa_info {
+   struct xfrm_selector sel;
+   struct xfrm_id id;
+   xfrm_address_t saddr;
+   struct compat_xfrm_lifetime_cfg lft;
+   struct compat_xfrm_lifetime_cur curlft;
+   struct 

[PATCH v2 5/6] xfrm/compat: Translate 32-bit user_policy from sockptr

[Dmitry Safonov]

XFRM is disabled for compatible users because of the UABI difference.
The difference is in structures paddings and in the result the size
of netlink messages differ.

Possibility for compatible application to manage xfrm tunnels was
disabled by: the commmit 19d7df69fdb2 ("xfrm: Refuse to insert 32 bit
userspace socket policies on 64 bit systems") and the commit 74005991b78a
("xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host").

This is my second attempt to resolve the xfrm/compat problem by adding
the 64=>32 and 32=>64 bit translators those non-visibly to a user
provide translation between compatible user and kernel.
Previous attempt was to interrupt the message ABI according to a syscall
by xfrm_user, which resulted in over-complicated code [1].

Florian Westphal provided the idea of translator and some draft patches
in the discussion. In these patches, his idea is reused and some of his
initial code is also present.

Provide compat_xfrm_userpolicy_info translation for xfrm setsocketopt().
Reallocate buffer and put the missing padding for 64-bit message.

[1]: https://lkml.kernel.org/r/20180726023144.31066-1-d...@arista.com
Signed-off-by: Dmitry Safonov 
---
 include/net/xfrm.h |  5 +
 net/xfrm/xfrm_compat.c | 25 +
 net/xfrm/xfrm_state.c  | 11 ---
 3 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 242e690674c6..633c210bd2dd 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -2009,6 +2009,7 @@ extern const int xfrm_msg_min[XFRM_NR_MSGTYPES];
 extern struct nlmsghdr *xfrm_user_rcv_msg_compat(const struct nlmsghdr *nlh,
int maxtype, const struct nla_policy *policy,
struct netlink_ext_ack *extack);
+extern int xfrm_user_policy_compat(u8 **pdata32, int optlen);
 #else
 static inline int xfrm_alloc_compat(struct sk_buff *skb)
 {
@@ -2025,6 +2026,10 @@ static inline struct nlmsghdr 
*xfrm_user_rcv_msg_compat(const struct nlmsghdr *n
 {
return ERR_PTR(-EOPNOTSUPP);
 }
+static inline int xfrm_user_policy_compat(u8 **pdata32, int optlen)
+{
+   return -EOPNOTSUPP;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/xfrm/xfrm_compat.c b/net/xfrm/xfrm_compat.c
index 79daa7f47d5a..990eecfc4c0e 100644
--- a/net/xfrm/xfrm_compat.c
+++ b/net/xfrm/xfrm_compat.c
@@ -582,3 +582,28 @@ struct nlmsghdr *xfrm_user_rcv_msg_compat(const struct 
nlmsghdr *h32,
 
return h64;
 }
+
+int xfrm_user_policy_compat(u8 **pdata32, int optlen)
+{
+   struct compat_xfrm_userpolicy_info *p = (void *)*pdata32;
+   u8 *src_templates, *dst_templates;
+   u8 *data64;
+
+   if (optlen < sizeof(*p))
+   return -EINVAL;
+
+   data64 = kmalloc_track_caller(optlen + 4, GFP_USER | __GFP_NOWARN);
+   if (!data64)
+   return -ENOMEM;
+
+   memcpy(data64, *pdata32, sizeof(*p));
+   memset(data64 + sizeof(*p), 0, 4);
+
+   src_templates = *pdata32 + sizeof(*p);
+   dst_templates = data64 + sizeof(*p) + 4;
+   memcpy(dst_templates, src_templates, optlen - sizeof(*p));
+
+   kfree(*pdata32);
+   *pdata32 = data64;
+   return 0;
+}
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 69520ad3d83b..053e6fe6ea7a 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2271,9 +2271,6 @@ int xfrm_user_policy(struct sock *sk, int optname, 
sockptr_t optval, int optlen)
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
 
-   if (in_compat_syscall())
-   return -EOPNOTSUPP;
-
if (sockptr_is_null(optval) && !optlen) {
xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
@@ -2288,6 +2285,14 @@ int xfrm_user_policy(struct sock *sk, int optname, 
sockptr_t optval, int optlen)
if (IS_ERR(data))
return PTR_ERR(data);
 
+   if (in_compat_syscall()) {
+   err = xfrm_user_policy_compat(, optlen);
+   if (err) {
+   kfree(data);
+   return err;
+   }
+   }
+
err = -EINVAL;
rcu_read_lock();
list_for_each_entry_rcu(km, _km_list, list) {
-- 
2.27.0

[PATCH v2 3/6] netlink/compat: Append NLMSG_DONE/extack to frag_list

[Dmitry Safonov]

Modules those use netlink may supply a 2nd skb, (via frag_list)
that contains an alternative data set meant for applications
using 32bit compatibility mode.

In such a case, netlink_recvmsg will use this 2nd skb instead of the
original one.

Without this patch, such compat applications will retrieve
all netlink dump data, but will then get an unexpected EOF.

Cc: Johannes Berg 
Signed-off-by: Florian Westphal 
Signed-off-by: Dmitry Safonov 
---
 net/netlink/af_netlink.c | 48 
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index b5f30d7d30d0..b096f2b4a50d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2186,13 +2186,36 @@ EXPORT_SYMBOL(__nlmsg_put);
  * It would be better to create kernel thread.
  */
 
+static int netlink_dump_done(struct netlink_sock *nlk, struct sk_buff *skb,
+struct netlink_callback *cb,
+struct netlink_ext_ack *extack)
+{
+   struct nlmsghdr *nlh;
+
+   nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, 
sizeof(nlk->dump_done_errno),
+  NLM_F_MULTI | cb->answer_flags);
+   if (WARN_ON(!nlh))
+   return -ENOBUFS;
+
+   nl_dump_check_consistent(cb, nlh);
+   memcpy(nlmsg_data(nlh), >dump_done_errno,
+   sizeof(nlk->dump_done_errno));
+
+   if (extack->_msg && nlk->flags & NETLINK_F_EXT_ACK) {
+   nlh->nlmsg_flags |= NLM_F_ACK_TLVS;
+   if (!nla_put_string(skb, NLMSGERR_ATTR_MSG, extack->_msg))
+   nlmsg_end(skb, nlh);
+   }
+
+   return 0;
+}
+
 static int netlink_dump(struct sock *sk)
 {
struct netlink_sock *nlk = nlk_sk(sk);
struct netlink_ext_ack extack = {};
struct netlink_callback *cb;
struct sk_buff *skb = NULL;
-   struct nlmsghdr *nlh;
struct module *module;
int err = -ENOBUFS;
int alloc_min_size;
@@ -2258,22 +2281,19 @@ static int netlink_dump(struct sock *sk)
return 0;
}
 
-   nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE,
-  sizeof(nlk->dump_done_errno),
-  NLM_F_MULTI | cb->answer_flags);
-   if (WARN_ON(!nlh))
+   if (netlink_dump_done(nlk, skb, cb, ))
goto errout_skb;
 
-   nl_dump_check_consistent(cb, nlh);
-
-   memcpy(nlmsg_data(nlh), >dump_done_errno,
-  sizeof(nlk->dump_done_errno));
-
-   if (extack._msg && nlk->flags & NETLINK_F_EXT_ACK) {
-   nlh->nlmsg_flags |= NLM_F_ACK_TLVS;
-   if (!nla_put_string(skb, NLMSGERR_ATTR_MSG, extack._msg))
-   nlmsg_end(skb, nlh);
+#ifdef CONFIG_COMPAT_NETLINK_MESSAGES
+   /* frag_list skb's data is used for compat tasks
+* and the regular skb's data for normal (non-compat) tasks.
+* See netlink_recvmsg().
+*/
+   if (unlikely(skb_shinfo(skb)->frag_list)) {
+   if (netlink_dump_done(nlk, skb_shinfo(skb)->frag_list, cb, 
))
+   goto errout_skb;
}
+#endif
 
if (sk_filter(sk, skb))
kfree_skb(skb);
-- 
2.27.0

[PATCH v2 2/6] xfrm/compat: Attach xfrm dumps to 64=>32 bit translator

[Dmitry Safonov]

XFRM is disabled for compatible users because of the UABI difference.
The difference is in structures paddings and in the result the size
of netlink messages differ.

Possibility for compatible application to manage xfrm tunnels was
disabled by: the commmit 19d7df69fdb2 ("xfrm: Refuse to insert 32 bit
userspace socket policies on 64 bit systems") and the commit 74005991b78a
("xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host").

This is my second attempt to resolve the xfrm/compat problem by adding
the 64=>32 and 32=>64 bit translators those non-visibly to a user
provide translation between compatible user and kernel.
Previous attempt was to interrupt the message ABI according to a syscall
by xfrm_user, which resulted in over-complicated code [1].

Florian Westphal provided the idea of translator and some draft patches
in the discussion. In these patches, his idea is reused and some of his
initial code is also present.

Currently nlmsg_unicast() is used by functions that dump structures that
can be different in size for compat tasks, see dump_one_state() and
dump_one_policy().

The following nlmsg_unicast() users exist today in xfrm:

 Function  |Message can be different
   |   in size on compat
---|--
xfrm_get_spdinfo() |   N
xfrm_get_sadinfo() |   N
xfrm_get_sa()  |   Y
xfrm_alloc_userspi()   |   Y
xfrm_get_policy()  |   Y
xfrm_get_ae()  |   N

Besides, dump_one_state() and dump_one_policy() can be used by filtered
netlink dump for XFRM_MSG_GETSA, XFRM_MSG_GETPOLICY.

Just as for xfrm multicast, allocate frag_list for compat skb journey
down to recvmsg() which will give user the desired skb according to
syscall bitness.

[1]: https://lkml.kernel.org/r/20180726023144.31066-1-d...@arista.com
Signed-off-by: Dmitry Safonov 
---
 include/net/xfrm.h |  6 ++
 net/xfrm/xfrm_compat.c | 10 --
 net/xfrm/xfrm_user.c   | 20 
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 9810b5090338..9febf4f5d2ea 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -2002,12 +2002,18 @@ static inline int xfrm_tunnel_check(struct sk_buff 
*skb, struct xfrm_state *x,
 
 #ifdef CONFIG_XFRM_USER_COMPAT
 extern int xfrm_alloc_compat(struct sk_buff *skb);
+extern int __xfrm_alloc_compat(struct sk_buff *skb, const struct nlmsghdr 
*nlh);
 extern const int xfrm_msg_min[XFRM_NR_MSGTYPES];
 #else
 static inline int xfrm_alloc_compat(struct sk_buff *skb)
 {
return 0;
 }
+static inline int __xfrm_alloc_compat(struct sk_buff *skb,
+ const struct nlmsghdr *nlh)
+{
+   return 0;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/xfrm/xfrm_compat.c b/net/xfrm/xfrm_compat.c
index b9eb65dde0db..b34c8b56a571 100644
--- a/net/xfrm/xfrm_compat.c
+++ b/net/xfrm/xfrm_compat.c
@@ -272,9 +272,8 @@ static int xfrm_xlate64(struct sk_buff *dst, const struct 
nlmsghdr *nlh_src)
return 0;
 }
 
-int xfrm_alloc_compat(struct sk_buff *skb)
+int __xfrm_alloc_compat(struct sk_buff *skb, const struct nlmsghdr *nlh_src)
 {
-   const struct nlmsghdr *nlh_src = nlmsg_hdr(skb);
u16 type = nlh_src->nlmsg_type - XFRM_MSG_BASE;
struct sk_buff *new = NULL;
int err;
@@ -300,3 +299,10 @@ int xfrm_alloc_compat(struct sk_buff *skb)
 
return 0;
 }
+
+int xfrm_alloc_compat(struct sk_buff *skb)
+{
+   const struct nlmsghdr *nlh_src = nlmsg_hdr(skb);
+
+   return __xfrm_alloc_compat(skb, nlh_src);
+}
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 90c57d4a0b47..d135c6949336 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -992,6 +992,13 @@ static int dump_one_state(struct xfrm_state *x, int count, 
void *ptr)
return err;
}
nlmsg_end(skb, nlh);
+
+   err = __xfrm_alloc_compat(skb, nlh);
+   if (err) {
+   nlmsg_cancel(skb, nlh);
+   return err;
+   }
+
return 0;
 }
 
@@ -1365,6 +1372,12 @@ static int xfrm_alloc_userspi(struct sk_buff *skb, 
struct nlmsghdr *nlh,
goto out;
}
 
+   err = xfrm_alloc_compat(skb);
+   if (err) {
+   kfree_skb(resp_skb);
+   goto out;
+   }
+
err = nlmsg_unicast(net->xfrm.nlsk, resp_skb, NETLINK_CB(skb).portid);
 
 out:
@@ -1795,6 +1808,13 @@ static int dump_one_policy(struct xfrm_policy *xp, int 
dir, int count, void *ptr
return err;
}
nlmsg_end(skb, nlh);
+
+   err = __xfrm_alloc_compat(skb, nlh);
+   if (err) {
+   nlmsg_cancel(skb, nlh);
+ 

[PATCH v2 6/6] selftest/net/xfrm: Add test for ipsec tunnel

[Dmitry Safonov]

It's an exhaustive testing for ipsec: covering all encryption/
authentication/compression algorithms. The tests are run in two
network namespaces, connected by veth interfaces. To make exhaustive
testing less time-consuming, the tests are run in parallel tasks,
specified by parameter to the selftest.

As the patches set adds support for xfrm in compatible tasks, there are
tests to check structures that differ in size between 64-bit and 32-bit
applications.
The selftest doesn't use libnl so that it can be easily compiled as
compatible application and don't require compatible .so.

Here is a diagram of the selftest:

   ---
   |  selftest   |
   |  (parent)   |
   ---
  ||
  | (pipe) |
  --
 /   |  |   \
   /-   /\   -\
   |  /-  -\  |
  -|--||--|-
  |   -   --   -   |
  |   | child |   | child |  NS A  | child |   | child |   |
  |   -   --   -   |
  ---|||-|--
   veth0veth1veth2 vethN
-|||-|--
|          |
| | gr.child |  | gr.child | NS B  | gr.child |   | gr.child | |
|          |


The parent sends the description of a test (xfrm parameters) to the
child, the child and grand child setup a tunnel over veth interface and
test it by sending udp packets.

Cc: Shuah Khan 
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Dmitry Safonov 
---
 MAINTAINERS|1 +
 tools/testing/selftests/net/.gitignore |1 +
 tools/testing/selftests/net/Makefile   |1 +
 tools/testing/selftests/net/ipsec.c| 2195 
 4 files changed, 2198 insertions(+)
 create mode 100644 tools/testing/selftests/net/ipsec.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 3b186ade3597..f485d551bd1e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12110,6 +12110,7 @@ F:  net/ipv6/ipcomp6.c
 F: net/ipv6/xfrm*
 F: net/key/
 F: net/xfrm/
+F: tools/testing/selftests/net/ipsec.c
 
 NETWORKING [IPv4/IPv6]
 M: "David S. Miller" 
diff --git a/tools/testing/selftests/net/.gitignore 
b/tools/testing/selftests/net/.gitignore
index 742c499328b2..61ae899cfc17 100644
--- a/tools/testing/selftests/net/.gitignore
+++ b/tools/testing/selftests/net/.gitignore
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
+ipsec
 msg_zerocopy
 socket
 psock_fanout
diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index 9491bbaa0831..edd4ac632dc8 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -29,6 +29,7 @@ TEST_GEN_FILES += tcp_fastopen_backup_key
 TEST_GEN_FILES += fin_ack_lat
 TEST_GEN_FILES += reuseaddr_ports_exhausted
 TEST_GEN_FILES += hwtstamp_config rxtimestamp timestamping txtimestamp
+TEST_GEN_FILES += ipsec
 TEST_GEN_PROGS = reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
 TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls
 
diff --git a/tools/testing/selftests/net/ipsec.c 
b/tools/testing/selftests/net/ipsec.c
new file mode 100644
index ..17ced7d6ce25
--- /dev/null
+++ b/tools/testing/selftests/net/ipsec.c
@@ -0,0 +1,2195 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ipsec.c - Check xfrm on veth inside a net-ns.
+ * Copyright (c) 2018 Dmitry Safonov
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../kselftest.h"
+
+#define printk(fmt, ...)   \
+   ksft_print_msg("%d[%u] " fmt "\n", getpid(), __LINE__, ##__VA_ARGS__)
+
+#define pr_err(fmt, ...)   printk(fmt ": %m", ##__VA_ARGS__)
+
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+
+#define IPV4_STR_SZ16  /* xxx.xxx.xxx.xxx is longest + \0 */
+#define MAX_PAYLOAD2048
+#define XFRM_ALGO_KEY_BUF_SIZE 512
+#define MAX_PROCESSES  (1 << 14) /* /16 mask divided by /30 subnets */
+#define INADDR_A   ((in_addr_t) 0x0a00) /* 10.0.0.0 */
+#define INADDR_B   ((in_addr_t) 0xc0a8) /* 

Re: fsl_espi errors on v5.7.15

[Chris Packham]

On 26/08/20 10:22 am, Chris Packham wrote:
> On 25/08/20 7:22 pm, Heiner Kallweit wrote:
>
> 
>> I've been staring at spi-fsl-espi.c for while now and I think I've
>>> identified a couple of deficiencies that may or may not be related 
>>> to my
>>> issue.
>>>
>>> First I think the 'Transfer done but SPIE_DON isn't set' message can be
>>> generated spuriously. In fsl_espi_irq() we read the ESPI_SPIE register.
>>> We also write back to it to clear the current events. We re-read it in
>>> fsl_espi_cpu_irq() and complain when SPIE_DON is not set. But we can
>>> naturally end up in that situation if we're doing a large read. 
>>> Consider
>>> the messages for reading a block of data from a spi-nor chip
>>>
>>>    tx = READ_OP + ADDR
>>>    rx = data
>>>
>>> We setup the transfer and pump out the tx_buf. The first interrupt goes
>>> off and ESPI_SPIE has SPIM_DON and SPIM_RXT set. We empty the rx fifo,
>>> clear ESPI_SPIE and wait for the next interrupt. The next interrupt
>>> fires and this time we have ESPI_SPIE with just SPIM_RXT set. This
>>> continues until we've received all the data and we finish with 
>>> ESPI_SPIE
>>> having only SPIM_RXT set. When we re-read it we complain that SPIE_DON
>>> isn't set.
>>>
>>> The other deficiency is that we only get an interrupt when the 
>>> amount of
>>> data in the rx fifo is above FSL_ESPI_RXTHR. If there are fewer than
>>> FSL_ESPI_RXTHR left to be received we will never pull them out of 
>>> the fifo.
>>>
>> SPIM_DON will trigger an interrupt once the last characters have been
>> transferred, and read the remaining characters from the FIFO.
>
> The T2080RM that I have says the following about the DON bit
>
> "Last character was transmitted. The last character was transmitted 
> and a new command can be written for the next frame."
>
> That does at least seem to fit with my assertion that it's all about 
> the TX direction. But the fact that it doesn't happen all the time 
> throws some doubt on it.
>
>> I think the reason I'm seeing some variability is because of how fast
>>> (or slow) the interrupts get processed and how fast the spi-nor chip 
>>> can
>>> fill the CPUs rx fifo.
>>>
>> To rule out timing issues at high bus frequencies I initially asked
>> for re-testing at lower frequencies. If you e.g. limit the bus to 1 MHz
>> or even less, then timing shouldn't be an issue.
> Yes I've currently got spi-max-frequency = <100>; in my dts. I 
> would also expect a slower frequency would fit my "DON is for TX" 
> narrative.
>> Last relevant functional changes have been done almost 4 years ago.
>> And yours is the first such report I see. So question is what could 
>> be so
>> special with your setup that it seems you're the only one being 
>> affected.
>> The scenarios you describe are standard, therefore much more people
>> should be affected in case of a driver bug.
> Agreed. But even on my hardware (which may have a latent issue despite 
> being in the field for going on 5 years) the issue only triggers under 
> some fairly specific circumstances.
>> You said that kernel config impacts how frequently the issue happens.
>> Therefore question is what's the diff in kernel config, and how could
>> the differences be related to SPI.
>
> It did seem to be somewhat random. Things like CONFIG_PREEMPT have an 
> impact but every time I found something that seemed to be having an 
> impact I've been able to disprove it. I actually think its about how 
> busy the system is which may or may not affect when we get round to 
> processing the interrupts.
>
> I have managed to get the 'Transfer done but SPIE_DON isn't set!' to 
> occur on the T2080RDB.
>
> I've had to add the following to expose the environment as a mtd 
> partition
>
> diff --git a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi 
> b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
> index ff87e67c70da..fbf95fc1fd68 100644
> --- a/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t208xrdb.dtsi
> @@ -116,6 +116,15 @@ flash@0 {
>     compatible = "micron,n25q512ax3", 
> "jedec,spi-nor";
>     reg = <0>;
>     spi-max-frequency = <1000>; /* 
> input clock */
> +
> +   partition@u-boot {
> +    reg = <0x 0x0010>;
> +    label = "u-boot";
> +    };
> +    partition@u-boot-env {
> +    reg = <0x0010 0x0001>;
> +    label = "u-boot-env";
> +    };
>     };
>     };
>
> And I'm using the following script to poke at the environment (warning 
> if anyone does try this and the bug hits it can render your u-boot 
> environment invalid).
>
> cat flash/fw_env_test.sh
> #!/bin/sh
>
> generate_fw_env_config()
> {
>   cat 

[PATCH] selftests: kvm: Fix assert failure in single-step test

[Yang Weijiang]

This is a follow-up patch to fix an issue left in commit:
98b0bf02738004829d7e26d6cb47b2e469aaba86
selftests: kvm: Use a shorter encoding to clear RAX

With the change in the commit, we also need to modify "xor" instruction
length from 3 to 2 in array ss_size accordingly to pass below check:

for (i = 0; i < (sizeof(ss_size) / sizeof(ss_size[0])); i++) {
target_rip += ss_size[i];
CLEAR_DEBUG();
debug.control = KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_SINGLESTEP;
debug.arch.debugreg[7] = 0x0400;
APPLY_DEBUG();
vcpu_run(vm, VCPU_ID);
TEST_ASSERT(run->exit_reason == KVM_EXIT_DEBUG &&
run->debug.arch.exception == DB_VECTOR &&
run->debug.arch.pc == target_rip &&
run->debug.arch.dr6 == target_dr6,
"SINGLE_STEP[%d]: exit %d exception %d rip 0x%llx "
"(should be 0x%llx) dr6 0x%llx (should be 0x%llx)",
i, run->exit_reason, run->debug.arch.exception,
run->debug.arch.pc, target_rip, run->debug.arch.dr6,
target_dr6);
}

Reported-by: kernel test robot 
Signed-off-by: Yang Weijiang 
---
 tools/testing/selftests/kvm/x86_64/debug_regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/x86_64/debug_regs.c 
b/tools/testing/selftests/kvm/x86_64/debug_regs.c
index b8d14f9db5f9..2fc6b3af81a1 100644
--- a/tools/testing/selftests/kvm/x86_64/debug_regs.c
+++ b/tools/testing/selftests/kvm/x86_64/debug_regs.c
@@ -73,7 +73,7 @@ int main(void)
int i;
/* Instruction lengths starting at ss_start */
int ss_size[4] = {
-   3,  /* xor */
+   2,  /* xor */
2,  /* cpuid */
5,  /* mov */
2,  /* rdmsr */
-- 
2.17.2

Re: [LKP] Re: [x86/mce] 1de08dccd3: will-it-scale.per_process_ops -14.1% regression

[Feng Tang]

On Wed, Aug 26, 2020 at 12:44:37AM +0800, Luck, Tony wrote:
> > These 2 variables are accessed in 2 hot call stacks (for this 288 CPU
> > Xeon Phi platform):
> 
> This might be the key element of "weirdness" for this system. It
> has 288 CPUs ... cache alignment problems are often not too bad
> on "small" systems. The as you scale up to bigger machines you
> suddenly hit some critical point and performance drops dramatically.
> 
> It's good that you are picking up tips on how to bisect these and diagnose
> the underlying problem. Number of cores is going to keep increasing, so
> we will keep finding new issues like this.

Yes, now we have one more bullet for shooting this kind of strange
performance changes :)

Thanks,
Feng

> -Tony

[PATCH v3 0/2] Control over userfaultfd kernel-fault handling

[Lokesh Gidra]

This patch series is split from [1]. The other series enables SELinux
support for userfaultfd file descriptors so that its creation and
movement can be controlled.

It has been demonstrated on various occasions that suspending kernel
code execution for an arbitrary amount of time at any access to
userspace memory (copy_from_user()/copy_to_user()/...) can be exploited
to change the intended behavior of the kernel. For instance, handling
page faults in kernel-mode using userfaultfd has been exploited in [2, 3].
Likewise, FUSE, which is similar to userfaultfd in this respect, has been
exploited in [4, 5] for similar outcome.

This small patch series adds a new flag to userfaultfd(2) that allows
callers to give up the ability to handle kernel-mode faults with the
resulting UFFD file object. It then adds a 'user-mode only' option to
the unprivileged_userfaultfd sysctl knob to require unprivileged
callers to use this new flag.

The purpose of this new interface is to decrease the chance of an
unprivileged userfaultfd user taking advantage of userfaultfd to
enhance security vulnerabilities by lengthening the race window in
kernel code.

[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dan...@google.com/
[2] https://duasynt.com/blog/linux-kernel-heap-spray
[3] https://duasynt.com/blog/cve-2016-6187-heap-off-by-one-exploit
[4] 
https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html
[5] https://bugs.chromium.org/p/project-zero/issues/detail?id=808

Changes since v2:

  - Removed 'uffd_flags' and directly used 'UFFD_USER_MODE_ONLY' in
userfaultfd().

Changes since v1:

  - Added external references to the threats from allowing unprivileged
users to handle page faults from kernel-mode.
  - Removed the new sysctl knob restricting handling of page
faults from kernel-mode, and added an option for the same
in the existing 'unprivileged_userfaultfd' knob.

Lokesh Gidra (2):
  Add UFFD_USER_MODE_ONLY
  Add user-mode only option to unprivileged_userfaultfd sysctl knob

 Documentation/admin-guide/sysctl/vm.rst | 10 +++---
 fs/userfaultfd.c| 16 +---
 include/uapi/linux/userfaultfd.h|  9 +
 kernel/sysctl.c |  2 +-
 4 files changed, 30 insertions(+), 7 deletions(-)

-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH v3 2/2] Add user-mode only option to unprivileged_userfaultfd sysctl knob

[Lokesh Gidra]

A third option is added to 'unprivileged_userfaultfd' sysctl knob.
When the knob is set to 2, it allows unprivileged users to call
userfaultfd, like when it is set to 1, but with the restriction that
page faults from only user-mode can be handled. In this mode,
an unprivileged user (without SYS_CAP_PTRACE capability) must pass
UFFD_USER_MODE_ONLY to userfaultd or the API will fail with EPERM.

This facility allows administrators to reduce the likelihood that
an attacker with access to userfaultfd can delay faulting kernel
code to widen timing windows for other exploits.

Signed-off-by: Daniel Colascione 
Signed-off-by: Lokesh Gidra 
---
 Documentation/admin-guide/sysctl/vm.rst | 10 +++---
 fs/userfaultfd.c| 10 --
 kernel/sysctl.c |  2 +-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/vm.rst 
b/Documentation/admin-guide/sysctl/vm.rst
index 4b9d2e8e9142..23d6feb79f5c 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -872,9 +872,13 @@ unprivileged_userfaultfd
 
 
 This flag controls whether unprivileged users can use the userfaultfd
-system calls.  Set this to 1 to allow unprivileged users to use the
-userfaultfd system calls, or set this to 0 to restrict userfaultfd to only
-privileged users (with SYS_CAP_PTRACE capability).
+system calls.  Set this to 0 to restrict userfaultfd to only privileged
+users (with SYS_CAP_PTRACE capability), set this to 1 to allow unprivileged
+users to use the userfaultfd system calls, or set this to 2 to restrict
+unprivileged users to handle page faults in user mode only. In the last case,
+users without SYS_CAP_PTRACE must pass UFFD_USER_MODE_ONLY in order for
+userfaultfd to succeed.  Prohibiting use of userfaultfd for handling faults
+from kernel mode may make certain vulnerabilities more difficult to exploit.
 
 The default value is 1.
 
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 3191434057f3..26cb87cf492d 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -1972,8 +1972,14 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)
struct userfaultfd_ctx *ctx;
int fd;
 
-   if (!sysctl_unprivileged_userfaultfd && !capable(CAP_SYS_PTRACE))
-   return -EPERM;
+   switch (sysctl_unprivileged_userfaultfd) {
+   case 2:
+   if (flags & UFFD_USER_MODE_ONLY)
+   break;
+   case 0:
+   if (!capable(CAP_SYS_PTRACE))
+   return -EPERM;
+   }
 
BUG_ON(!current->mm);
 
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 287862f91717..7e94215dfff5 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -3119,7 +3119,7 @@ static struct ctl_table vm_table[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec_minmax,
.extra1 = SYSCTL_ZERO,
-   .extra2 = SYSCTL_ONE,
+   .extra2 = ,
},
 #endif
{ }
-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH v3 1/2] Add UFFD_USER_MODE_ONLY

[Lokesh Gidra]

userfaultfd handles page faults from both user and kernel code.
Add a new UFFD_USER_MODE_ONLY flag for userfaultfd(2) that makes
the resulting userfaultfd object refuse to handle faults from kernel
mode, treating these faults as if SIGBUS were always raised, causing
the kernel code to fail with EFAULT.

A future patch adds a knob allowing administrators to give some
processes the ability to create userfaultfd file objects only if they
pass UFFD_USER_MODE_ONLY, reducing the likelihood that these processes
will exploit userfaultfd's ability to delay kernel page faults to open
timing windows for future exploits.

Signed-off-by: Daniel Colascione 
Signed-off-by: Lokesh Gidra 
---
 fs/userfaultfd.c | 6 +-
 include/uapi/linux/userfaultfd.h | 9 +
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 0e4a3837da52..3191434057f3 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -405,6 +405,9 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned 
long reason)
 
if (ctx->features & UFFD_FEATURE_SIGBUS)
goto out;
+   if ((vmf->flags & FAULT_FLAG_USER) == 0 &&
+   ctx->flags & UFFD_USER_MODE_ONLY)
+   goto out;
 
/*
 * If it's already released don't get it. This avoids to loop
@@ -1975,10 +1978,11 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)
BUG_ON(!current->mm);
 
/* Check the UFFD_* constants for consistency.  */
+   BUILD_BUG_ON(UFFD_USER_MODE_ONLY & UFFD_SHARED_FCNTL_FLAGS);
BUILD_BUG_ON(UFFD_CLOEXEC != O_CLOEXEC);
BUILD_BUG_ON(UFFD_NONBLOCK != O_NONBLOCK);
 
-   if (flags & ~UFFD_SHARED_FCNTL_FLAGS)
+   if (flags & ~(UFFD_SHARED_FCNTL_FLAGS | UFFD_USER_MODE_ONLY))
return -EINVAL;
 
ctx = kmem_cache_alloc(userfaultfd_ctx_cachep, GFP_KERNEL);
diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index e7e98bde221f..5f2d88212f7c 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -257,4 +257,13 @@ struct uffdio_writeprotect {
__u64 mode;
 };
 
+/*
+ * Flags for the userfaultfd(2) system call itself.
+ */
+
+/*
+ * Create a userfaultfd that can handle page faults only in user mode.
+ */
+#define UFFD_USER_MODE_ONLY 1
+
 #endif /* _LINUX_USERFAULTFD_H */
-- 
2.28.0.297.g1956fa8f8d-goog

Re: [PATCH v5] kernel/trace: Add DISALLOW_TRACE_PRINTK make option

[Steven Rostedt]

On Tue, 25 Aug 2020 08:38:27 +0800
Nicolas Boichat  wrote:

> This already works. I'll be honest, I'm not 100% sure why (and if
> fully intentional)...
> 
> The CFLAGS end up in 3 generated assembly files:
> # grep -R DISALLOW_TRACE_PRINTK * | grep -v ".cmd:"
> arch/x86/kernel/asm-offsets.s:# -imultiarch x86_64-linux-gnu -D
> __KERNEL__ -D DISALLOW_TRACE_PRINTK
> kernel/bounds.s:# -imultiarch x86_64-linux-gnu -D __KERNEL__ -D
> DISALLOW_TRACE_PRINTK
> scripts/mod/devicetable-offsets.s:# -D DISALLOW_TRACE_PRINTK
> (along with all *.cmd files)
> 
> and I suspect some/all of those force a complete kernel rebuild.

Yeah, I believe that the modification of CFLAGS causes a recompile of
the entire kernel.

Thanks!

-- Steve

[PATCH] exfat: fix pointer error checking

[Tetsuhiro Kohada]

Fix missing result check of exfat_build_inode().
And use PTR_ERR_OR_ZERO instead of PTR_ERR.

Signed-off-by: Tetsuhiro Kohada 
---
 fs/exfat/namei.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 2aff6605fecc..0b12033e1577 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -578,7 +578,8 @@ static int exfat_create(struct inode *dir, struct dentry 
*dentry, umode_t mode,
 
i_pos = exfat_make_i_pos();
inode = exfat_build_inode(sb, , i_pos);
-   if (IS_ERR(inode))
+   err = PTR_ERR_OR_ZERO(inode);
+   if (err)
goto unlock;
 
inode_inc_iversion(inode);
@@ -745,10 +746,9 @@ static struct dentry *exfat_lookup(struct inode *dir, 
struct dentry *dentry,
 
i_pos = exfat_make_i_pos();
inode = exfat_build_inode(sb, , i_pos);
-   if (IS_ERR(inode)) {
-   err = PTR_ERR(inode);
+   err = PTR_ERR_OR_ZERO(inode);
+   if (err)
goto unlock;
-   }
 
i_mode = inode->i_mode;
alias = d_find_alias(inode);
@@ -890,10 +890,9 @@ static int exfat_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
 
i_pos = exfat_make_i_pos();
inode = exfat_build_inode(sb, , i_pos);
-   if (IS_ERR(inode)) {
-   err = PTR_ERR(inode);
+   err = PTR_ERR_OR_ZERO(inode);
+   if (err)
goto unlock;
-   }
 
inode_inc_iversion(inode);
inode->i_mtime = inode->i_atime = inode->i_ctime =
-- 
2.25.1

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

[Rob Clark]

On Tue, Aug 25, 2020 at 5:24 PM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, Aug 25, 2020 at 3:54 PM Rob Clark  wrote:
> >
> > On Tue, Aug 25, 2020 at 3:23 PM Doug Anderson  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Aug 25, 2020 at 12:01 PM Sai Prakash Ranjan
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 2020-08-25 21:40, Doug Anderson wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan
> > > > >  wrote:
> > > > >>
> > > > >> Currently the non-strict or lazy mode of TLB invalidation can only be
> > > > >> set
> > > > >> for all or no domains. This works well for development platforms 
> > > > >> where
> > > > >> setting to non-strict/lazy mode is fine for performance reasons but 
> > > > >> on
> > > > >> production devices, we need a more fine grained control to allow only
> > > > >> certain peripherals to support this mode where we can be sure that it
> > > > >> is
> > > > >> safe. So add support to filter non-strict/lazy mode based on the
> > > > >> device
> > > > >> names that are passed via cmdline parameter "iommu.nonstrict_device".
> > > > >>
> > > > >> Example:
> > > > >> iommu.nonstrict_device="7c4000.sdhci,a60.dwc3,6048000.etr"
> > >
> > > Just curious: are device names like this really guaranteed to be
> > > stable across versions?
> > >
> > >
> > > > > I have an inherent dislike of jamming things like this onto the
> > > > > command line.  IMHO the command line is the last resort for specifying
> > > > > configuration and generally should be limited to some specialized
> > > > > debug options and cases where the person running the kernel needs to
> > > > > override a config that was set by the person (or company) compiling
> > > > > the kernel.  Specifically, having a long/unwieldy command line makes
> > > > > it harder to use for the case when an end user actually wants to use
> > > > > it to override something.  It's also just another place to look for
> > > > > config.
> > > > >
> > > >
> > > > Good thing about command line parameters are that they are optional,
> > > > they do
> > > > not specify any default behaviour (I mean they are not mandatory to be
> > > > set
> > > > for the system to be functional), so I would like to view it as an
> > > > optional
> > > > config. And this command line parameter (nonstrict_device) is strictly
> > > > optional
> > > > with default being strict already set in the driver.
> > > >
> > > > They can be passed from the bootloader via chosen node for DT platforms
> > > > or choose
> > > > a new *bootconfig* as a way to pass the cmdline but finally it does boil
> > > > down to
> > > > just another config.
> > >
> > > Never looked at bootconfig.  Unfortunately it seems to require
> > > initramfs so that pretty much means it's out for my usage.  :(
> > >
> > >
> > > > I agree with general boolean or single value command line parameters
> > > > being just
> > > > more messy which could just be Kconfigs instead but for multiple value
> > > > parameters
> > > > like these do not fit in Kconfig.
> > > >
> > > > As you might already know, command line also gives an advantage to the
> > > > end user
> > > > to configure system without building kernel, for this specific command
> > > > line its
> > > > very useful because the performance bump is quite noticeable when the
> > > > iommu.strict
> > > > is off. Now for end user who would not be interested in building entire
> > > > kernel(majority)
> > > > and just cares about good speeds or throughput can find this very
> > > > beneficial.
> > > > I am not talking about one specific OS usecase here but more in general
> > > > term.
> > > >
> > > > > The other problem is that this doesn't necessarily scale very well.
> > > > > While it works OK for embedded cases it doesn't work terribly well for
> > > > > distributions.  I know that in an out-of-band thread you indicated
> > > > > that it doesn't break anything that's not already broken (AKA this
> > > > > doesn't fix the distro case but it doesn't make it worse), it would be
> > > > > better to come up with a more universal solution.
> > > > >
> > > >
> > > > Is the universal solution here referring to fix all the command line
> > > > parameters
> > > > in the kernel or this specific command line? Are we going to remove any
> > > > more
> > > > addition to the cmdline ;)
> > >
> > > There are very few cases where a kernel command line parameter is the
> > > only way to configure something.  Most of the time it's just there to
> > > override a config.  I wouldn't suggest removing those.  I just don't
> > > want a kernel command line parameter to be the primary way to enable
> > > something.
> > >
> > >
> > > > So possible other solution is the *bootconfig* which is again just
> > > > another place
> > > > to look for a config. So thing is that this universal solution would
> > > > result in
> > > > just more new fancy ways of passing configs or adding such configs to
> > > > the drivers
> > > > or subsystems in kernel 

RE: [PATCH v3] exfat: integrates dir-entry getting and validation

[Namjae Jeon]

> Second: Range validation and type validation should not be separated.
> When I started making this patch, I intended to add only range validation.
> However, after the caller gets the ep, the type validation follows.
> Get ep, null check of ep (= range verification), type verification is a 
> series of procedures.
> There would be no reason to keep them independent anymore.
> Range and type validation is enforced when the caller uses ep.
You can add a validate flags as argument of exfat_get_dentry_set(), e.g. none, 
basic and strict.
none : only range validation.
basic : range + type validation.
strict : range + type + checksum and name length, etc.
 
> > -   /* validiate cached dentries */
> > -   for (i = 1; i < num_entries; i++) {
> > -   ep = exfat_get_dentry_cached(es, i);
> > -   if (!exfat_validate_entry(exfat_get_entry_type(ep), ))
> > +   ep = exfat_get_dentry_cached(es, ENTRY_STREAM);
> > +   if (!ep || ep->type != EXFAT_STREAM)
> > +   goto free_es;
> > +   es->de[ENTRY_STREAM] = ep;
> 
> The value contained in stream-ext dir-entry should not be used before 
> validating the EntrySet checksum.
> So I would insert EntrySet checksum validation here.
> In that case, the checksum verification loop would be followed by the 
> TYPE_NAME verification loop, can
> you acceptable?
Yes. That would be great.

Thanks!
> 
> 
> > diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h index
> > 44dc04520175..0e4cc8ba2f8e 100644
> > --- a/fs/exfat/exfat_fs.h
> > +++ b/fs/exfat/exfat_fs.h
> > @@ -33,6 +33,12 @@ enum {
> > NLS_NAME_OVERLEN,   /* the length is over than its limit */
> >   };
> >
> > +enum {
> > +   ENTRY_FILE,
> > +   ENTRY_STREAM,
> > +   ENTRY_NAME,
> > +};
> 
> This is necessary!
> With this, some magic numbers will be gone.
> But, I think it's better to use a name that can be recognized as an 
> offset/index in the EntrySet.
> And, I think it's better to define this in "exfat_raw.h"
Okay, You can rename it and move it to there.

Re: [patch V9 21/39] x86/irq: Convey vector as argument and not in ptregs

[Brian Gerst]

On Tue, Aug 25, 2020 at 8:04 PM Alexander Graf  wrote:
>
> Hi Andy,
>
> On 26.08.20 01:41, Andy Lutomirski wrote:
> >
> > On Tue, Aug 25, 2020 at 4:18 PM Alexander Graf  wrote:
> >>
> >> Hi Thomas,
> >>
> >> On 25.08.20 12:28, Thomas Gleixner wrote:
> >>> void irq_complete_move(struct irq_cfg *cfg)
> > {
> >  __irq_complete_move(cfg, ~get_irq_regs()->orig_ax);
> > }
> >
> >>> Alex,
> >>>
> >>> On Mon, Aug 24 2020 at 19:29, Alexander Graf wrote:
>  I'm currently trying to understand a performance regression with
>  ScyllaDB on i3en.3xlarge (KVM based VM on Skylake) which we reliably
>  bisected down to this commit:
> 
>   https://github.com/scylladb/scylla/issues/7036
> 
>  What we're seeing is that syscalls such as membarrier() take forever
>  (0-10 µs would be normal):
> >>> ...
>  That again seems to stem from a vastly slowed down
>  smp_call_function_many_cond():
> 
>  Samples: 218K of event 'cpu-clock', 4000 Hz
>  Overhead  Shared ObjectSymbol
>   94.51%  [kernel] [k] smp_call_function_many_cond
>    0.76%  [kernel] [k] __do_softirq
>    0.32%  [kernel] [k] native_queued_spin_lock_slowpath
>  [...]
> 
>  which is stuck in
> 
>    │ csd_lock_wait():
>    │ smp_cond_load_acquire(>flags, !(VAL &
>   0.00 │   mov0x8(%rcx),%edx
>   0.00 │   and$0x1,%edx
>    │ ↓ je 2b9
>    │ rep_nop():
>   0.70 │2af:   pause
>    │ csd_lock_wait():
>  92.82 │   mov0x8(%rcx),%edx
>   6.48 │   and$0x1,%edx
>   0.00 │ ↑ jne2af
>   0.00 │2b9: ↑ jmp282
> 
> 
>  Given the patch at hand I was expecting lost IPIs, but I can't quite see
>  anything getting lost.
> >>>
> >>> I have no idea how that patch should be related to IPI and smp function
> >>> calls. It's changing the way how regular device interrupts and their
> >>> spurious counterpart are handled and not the way how IPIs are
> >>> handled. They are handled by direct vectors and do not go through
> >>> do_IRQ() at all.
> >>>
> >>> Aside of that the commit just changes the way how the interrupt vector
> >>> of a regular device interrupt is stored and conveyed. The extra read and
> >>> write on the cache hot stack is hardly related to anything IPI.
> >>
> >> I am as puzzled as you are, but the bisect is very clear: 79b9c183021e
> >> works fast and 633260fa1 (as well as mainline) shows the weird behavior
> >> above.
> >>
> >> It gets even better. This small (demonstrative only, mangled) patch on
> >> top of 633260fa1 also resolves the performance issue:
> >>
> >> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> >> index c766936..7e91e9a 100644
> >> --- a/arch/x86/kernel/irq.c
> >> +++ b/arch/x86/kernel/irq.c
> >> @@ -239,6 +239,7 @@ __visible void __irq_entry do_IRQ(struct pt_regs
> >> *regs, unsigned long vector)
> >>   * lower 8 bits.
> >>   */
> >>  vector &= 0xFF;
> >> +   regs->orig_ax = ~vector;
> >>
> >>  /* entering_irq() tells RCU that we're not quiescent.  Check it. 
> >> */
> >>  RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
> >>
> >>
> >> To me that sounds like some irq exit code somewhere must still be
> >> looking at orig_ax to decide on something - and that something is wrong
> >> now that we removed the negation of the vector. It also seems to have an
> >> impact on remote function calls.
> >>
> >> I'll have a deeper look tomorrow again if I can find any such place, but
> >> I wouldn't mind if anyone could point me into the right direction
> >> earlier :).
> >
> > How about this:
> >
> > void irq_complete_move(struct irq_cfg *cfg)
> > {
> >  __irq_complete_move(cfg, ~get_irq_regs()->orig_ax);
> > }
> >
> > in arch/x86/kernel/apic/vector.c.
> >
>
> Thanks a lot, I stumbled over the same thing just after I sent the email
> as well and had been trying to see if I can quickly patch it up before I
> fall asleep :).
>
> The code path above is used by the APIC vector move (irqbalance) logic,
> which explains why not everyone was seeing issues.
>
> So with 633260fa1 applied, we never get out of moving state for our IRQ
> because orig_ax is always -1. That means we send an IPI to the cleanup
> vector on every single device interrupt, completely occupying the poor
> CPU that we moved the IRQ from.
>
> I've confirmed that the patch below fixes the issue and will send a
> proper, more complete patch on top of mainline with fancy description
> and stable tag tomorrow.
>
>
> Alex
>
>
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index e7434cd..a474e6e 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -734,7 +734,6 @@ SYM_CODE_START_LOCAL(common_spurious)
> call

Re: [PATCH v18 00/32] per memcg lru_lock

[Daniel Jordan]

On Tue, Aug 25, 2020 at 11:26:58AM +0800, Alex Shi wrote:
> 在 2020/8/25 上午9:56, Daniel Jordan 写道:
> > Alex, do you have a pointer to the modified readtwice case?
> 
> Sorry, no. my developer machine crashed, so I lost case my container and 
> modified
> case. I am struggling to get my container back from a account problematic 
> repository. 
> 
> But some testing scripts is here, generally, the original readtwice case will
> run each of threads on each of cpus. The new case will run one container on 
> each cpus,
> and just run one readtwice thead in each of containers.

Ok, what you've sent so far gives me an idea of what you did.  My readtwice
changes were similar, except I used the cgroup interface directly instead of
docker and shared a filesystem between all the cgroups whereas it looks like
you had one per memcg.  30 second runs on 5.9-rc2 and v18 gave 11% more data
read with v18.  This was using 16 cgroups (32 dd tasks) on a 40 CPU, 2 socket
machine.

> > Even better would be a description of the problem you're having in 
> > production
> > with lru_lock.  We might be able to create at least a simulation of it to 
> > show
> > what the expected improvement of your real workload is.
> 
> we are using thousands memcgs in a machine, but as a simulation, I guess 
> above case
> could be helpful to show the problem.

Using thousands of memcgs to do what?  Any particulars about the type of
workload?  Surely it's more complicated than page cache reads :)

> > I ran a few benchmarks on v17 last week (sysbench oltp readonly, kerndevel 
> > from
> > mmtests, a memcg-ized version of the readtwice case I cooked up) and then 
> > today
> > discovered there's a chance I wasn't running the right kernels, so I'm 
> > redoing
> > them on v18.

Neither kernel compile nor git checkout in the root cgroup changed much, just
0.31% slower on elapsed time for the compile, so no significant regressions
there.  Now for sysbench again.

Re: [patch V9 21/39] x86/irq: Convey vector as argument and not in ptregs

[Thomas Gleixner]

On Tue, Aug 25 2020 at 16:41, Andy Lutomirski wrote:
> How about this:
>
> void irq_complete_move(struct irq_cfg *cfg)
> {
> __irq_complete_move(cfg, ~get_irq_regs()->orig_ax);
> }
>
> in arch/x86/kernel/apic/vector.c.

Duh

linux-next: build failure after merge of the drm-misc tree

[Stephen Rothwell]

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/qxl/qxl_display.c: In function 
'qxl_display_read_client_monitors_config':
include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function 
'drm_drv_uses_atomic_modeset' [-Werror=implicit-function-declaration]
  167 |  if (!drm_drv_uses_atomic_modeset(dev))\
  |   ^~~
drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
drivers/gpu/drm/qxl/qxl_display.c:189:35: error: macro 
"DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
  189 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |   ^
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END" 
defined here
  194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
  | 
drivers/gpu/drm/qxl/qxl_display.c:189:2: error: 'DRM_MODESET_LOCK_ALL_END' 
undeclared (first use in this function)
  189 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |  ^~~~
drivers/gpu/drm/qxl/qxl_display.c:189:2: note: each undeclared identifier is 
reported only once for each function it appears in
drivers/gpu/drm/qxl/qxl_display.c:187:2: error: label 'modeset_lock_fail' used 
but not defined
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry' 
defined but not used [-Wunused-label]
  170 | modeset_lock_retry:   \
  | ^~
drivers/gpu/drm/qxl/qxl_display.c:187:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  187 |  DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
drivers/gpu/drm/qxl/qxl_display.c: In function 'qxl_framebuffer_surface_dirty':
drivers/gpu/drm/qxl/qxl_display.c:434:35: error: macro 
"DRM_MODESET_LOCK_ALL_END" requires 3 arguments, but only 2 given
  434 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |   ^
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:194: note: macro "DRM_MODESET_LOCK_ALL_END" 
defined here
  194 | #define DRM_MODESET_LOCK_ALL_END(dev, ctx, ret)\
  | 
drivers/gpu/drm/qxl/qxl_display.c:434:2: error: 'DRM_MODESET_LOCK_ALL_END' 
undeclared (first use in this function)
  434 |  DRM_MODESET_LOCK_ALL_END(ctx, ret);
  |  ^~~~
drivers/gpu/drm/qxl/qxl_display.c:411:2: error: label 'modeset_lock_fail' used 
but not defined
  411 |  DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~
In file included from include/drm/drm_crtc.h:36,
 from include/drm/drm_atomic.h:31,
 from drivers/gpu/drm/qxl/qxl_display.c:29:
include/drm/drm_modeset_lock.h:170:1: warning: label 'modeset_lock_retry' 
defined but not used [-Wunused-label]
  170 | modeset_lock_retry:   \
  | ^~
drivers/gpu/drm/qxl/qxl_display.c:411:2: note: in expansion of macro 
'DRM_MODESET_LOCK_ALL_BEGIN'
  411 |  DRM_MODESET_LOCK_ALL_BEGIN(fb->dev, ctx, 
DRM_MODESET_ACQUIRE_INTERRUPTIBLE, ret);
  |  ^~

Caused by commit

  bbaac1354cc9 ("drm/qxl: Replace deprecated function in qxl_display")

interacting with commit

  77ef38574beb ("drm/modeset-lock: Take the modeset BKL for legacy drivers")

from the drm-misc-fixes tree.

drivers/gpu/drm/qxl/qxl_display.c manages to include
drm/drm_modeset_lock.h by some indirect route, but fails to have
drm/drm_drv.h similarly included.  In fact, drm/drm_modeset_lock.h should
have included drm/drm_drv.h since it uses things declared there, and
drivers/gpu/drm/qxl/qxl_display.c should include drm/drm_modeset_lock.h
similarly.

I have added the following hack patch for today.

From: Stephen Rothwell 
Date: Wed, 26 Aug 2020 10:40:18 +1000
Subject: [PATCH] fix interaction with drm-misc-fix commit

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index fa79688013b7..6063f3a15329 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -26,6 +26,7 @@
 #include 
 

Re: [PATCH 2/4] MIPS: Loongson2ef: Remove specific mc146818rtc.h

[Jiaxun Yang]

在 2020/8/25 下午5:09, Thomas Bogendoerfer 写道:

Loonson2ef's mc146818rtc.h is the same as the generic one -> remove it.

Signed-off-by: Thomas Bogendoerfer 


Acked-by: Jiaxun Yang 


---
  .../include/asm/mach-loongson2ef/mc146818rtc.h | 36 --
  1 file changed, 36 deletions(-)
  delete mode 100644 arch/mips/include/asm/mach-loongson2ef/mc146818rtc.h

diff --git a/arch/mips/include/asm/mach-loongson2ef/mc146818rtc.h 
b/arch/mips/include/asm/mach-loongson2ef/mc146818rtc.h
deleted file mode 100644
index 00d602629a55..
--- a/arch/mips/include/asm/mach-loongson2ef/mc146818rtc.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1998, 2001, 03, 07 by Ralf Baechle (r...@linux-mips.org)
- *
- * RTC routines for PC style attached Dallas chip.
- */
-#ifndef __ASM_MACH_LOONGSON2EF_MC146818RTC_H
-#define __ASM_MACH_LOONGSON2EF_MC146818RTC_H
-
-#include 
-
-#define RTC_PORT(x)(0x70 + (x))
-#define RTC_IRQ8
-
-static inline unsigned char CMOS_READ(unsigned long addr)
-{
-   outb_p(addr, RTC_PORT(0));
-   return inb_p(RTC_PORT(1));
-}
-
-static inline void CMOS_WRITE(unsigned char data, unsigned long addr)
-{
-   outb_p(addr, RTC_PORT(0));
-   outb_p(data, RTC_PORT(1));
-}
-
-#define RTC_ALWAYS_BCD 0
-
-#ifndef mc146818_decode_year
-#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 
1970)
-#endif
-
-#endif /* __ASM_MACH_LOONGSON2EF_MC146818RTC_H */

Re: [PATCH 3/4] soundwire: SDCA: add helper macro to access controls

[Bard liao]

On 8/26/2020 1:16 AM, Pierre-Louis Bossart wrote:

The upcoming SDCA (SoundWire Device Class Audio) specification defines
a hierarchical encoding to interface with Class-defined capabilities.

The specification is not yet accessible to the general public but this
information is released with explicit permission from the MIPI Board
to avoid delays with SDCA support on Linux platforms.

A block of 64 MBytes of register addresses are allocated to SDCA
controls, starting at address 0x4000. The 26 LSBs which identify
individual controls are set based on the following variables:

- Function Number. An SCDA device can be split in up to 8 independent
   Functions. Each of these Functions is described in the SDCA
   specification, e.g. Smart Amplifier, Smart Microphone, Simple
   Microphone, Jack codec, HID, etc.

- Entity Number.  Within each Function,  an Entity is  an identifiable
   block.  Up   to  127  Entities   are  connected  in   a  pre-defined
   graph  (similar to  USB), with  Entity0 reserved  for Function-level
   configurations.  In  contrast  to  USB, the  SDCA  spec  pre-defines
   Function Types, topologies, and allowed  options, i.e. the degree of
   freedom  is not  unlimited to  limit  the possibility  of errors  in
   descriptors leading to software quirks.

- Control Selector. Within each Entity, the SDCA specification defines
   48 controls such as Mute, Gain, AGC, etc, and 16 implementation
   defined ones. Some Control Selectors might be used for low-level
   platform setup, and other exposed to applications and users. Note
   that the same Control Selector capability, e.g. Latency control,
   might be located at different offsets in different entities, the
   Control Selector mapping is Entity-specific.

- Control Number. Some Control Selectors allow channel-specific values
   to be set, with up to 64 channels allowed. This is mostly used for
   volume control.

- Current/Next values. Some Control Selectors are
   'Dual-Ranked'. Software may either update the Current value directly
   for immediate effect. Alternatively, software may write into the
   'Next' values and update the SoundWire 1.2 'Commit Groups' register
   to copy 'Next' values into 'Current' ones in a synchronized
   manner. This is different from bank switching which is typically
   used to change the bus configuration only.

- MBQ. the Multi-Byte Quantity bit is used to provide atomic updates
   when accessing more that one byte, for example a 16-bit volume
   control would be updated consistently, the intermediate values
   mixing old MSB with new LSB are not applied.

These 6 parameters are used to build a 32-bit address to access the
desired Controls. Because of address range, paging is required, but
the most often used parameter values are placed in the lower 16 bits
of the address. This helps to keep the paging registers constant while
updating Controls for a specific Device/Function.

Reviewed-by: Rander Wang 
Reviewed-by: Guennadi Liakhovetski 
Reviewed-by: Kai Vehmanen 
Signed-off-by: Pierre-Louis Bossart 


Acked-by: Bard Liao 

[PATCH V2] drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()

[Yu Kuai]

If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux()
doesn't have a corresponding put_device(). Thus add put_device()
to fix the exception handling for this function implementation.

Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
Signed-off-by: Yu Kuai 
---
Changes from V1:
 - correct misues of at_dma_xlate() in commit message.

 drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ced9a8287dd8..e40c542254f6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1433,14 +1433,18 @@ static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon 
*tcon,
if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
ret = sun8i_tcon_top_set_hdmi_src(>dev, id);
-   if (ret)
+   if (ret) {
+   put_device(>dev);
return ret;
+   }
}
 
if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP)) {
ret = sun8i_tcon_top_de_config(>dev, tcon->id, id);
-   if (ret)
+   if (ret) {
+   put_device(>dev);
return ret;
+   }
}
 
return 0;
-- 
2.25.4