date:20210203

On 29-01-21, 14:07, Steen Hegelund wrote:
> Provide a new ethernet phy configuration structure, that
> allow PHYs used for ethernet to be configured with
> speed, media type and clock information.

This lgtm, Kishon ?

> 
> Signed-off-by: Lars Povlsen 
> Signed-off-by: Steen Hegelund 
> Reviewed-by: Andrew Lunn 
> Reviewed-by: Alexandre Belloni 
> ---
>  drivers/phy/phy-core.c  | 30 ++
>  include/linux/phy/phy.h | 26 ++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 71cb10826326..ccb575b13777 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -373,6 +373,36 @@ int phy_set_mode_ext(struct phy *phy, enum phy_mode 
> mode, int submode)
>  }
>  EXPORT_SYMBOL_GPL(phy_set_mode_ext);
>  
> +int phy_set_media(struct phy *phy, enum phy_media media)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_media)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_media(phy, media);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_media);
> +
> +int phy_set_speed(struct phy *phy, int speed)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->set_speed)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->set_speed(phy, speed);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_set_speed);
> +
>  int phy_reset(struct phy *phy)
>  {
>   int ret;
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e435bdb0bab3..e4fd69a1faa7 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -44,6 +44,12 @@ enum phy_mode {
>   PHY_MODE_DP
>  };
>  
> +enum phy_media {
> + PHY_MEDIA_DEFAULT,
> + PHY_MEDIA_SR,
> + PHY_MEDIA_DAC,
> +};
> +
>  /**
>   * union phy_configure_opts - Opaque generic phy configuration
>   *
> @@ -64,6 +70,8 @@ union phy_configure_opts {
>   * @power_on: powering on the phy
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
> + * @set_media: set the media type of the phy (optional)
> + * @set_speed: set the speed of the phy (optional)
>   * @reset: resetting the phy
>   * @calibrate: calibrate the phy
>   * @release: ops to be performed while the consumer relinquishes the PHY
> @@ -75,6 +83,8 @@ struct phy_ops {
>   int (*power_on)(struct phy *phy);
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode, int submode);
> + int (*set_media)(struct phy *phy, enum phy_media media);
> + int (*set_speed)(struct phy *phy, int speed);
>  
>   /**
>* @configure:
> @@ -215,6 +225,8 @@ int phy_power_off(struct phy *phy);
>  int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
>  #define phy_set_mode(phy, mode) \
>   phy_set_mode_ext(phy, mode, 0)
> +int phy_set_media(struct phy *phy, enum phy_media media);
> +int phy_set_speed(struct phy *phy, int speed);
>  int phy_configure(struct phy *phy, union phy_configure_opts *opts);
>  int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
>union phy_configure_opts *opts);
> @@ -344,6 +356,20 @@ static inline int phy_set_mode_ext(struct phy *phy, enum 
> phy_mode mode,
>  #define phy_set_mode(phy, mode) \
>   phy_set_mode_ext(phy, mode, 0)
>  
> +static inline int phy_set_media(struct phy *phy, enum phy_media media)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
> +static inline int phy_set_speed(struct phy *phy, int speed)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline enum phy_mode phy_get_mode(struct phy *phy)
>  {
>   return PHY_MODE_INVALID;
> -- 
> 2.30.0

-- 
~Vinod

[PATCH] fscache: rectify minor kernel-doc issues

2021-02-03 Thread Lukas Bulwahn

The command './scripts/kernel-doc -none include/linux/fscache.h' reports
some minor mismatches of the kernel-doc and function signature, which are
easily resolved.

Rectify the kernel-doc, such that no issues remain for fscache.h.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on current master and next-20210202

David, please pick the quick kernel-doc fix.

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

diff --git a/include/linux/fscache.h b/include/linux/fscache.h
index 3f177faa0ac2..7e1f12e52baf 100644
--- a/include/linux/fscache.h
+++ b/include/linux/fscache.h
@@ -418,7 +418,7 @@ int fscache_pin_cookie(struct fscache_cookie *cookie)
 }
 
 /**
- * fscache_pin_cookie - Unpin a data-storage cache object in its cache
+ * fscache_unpin_cookie - Unpin a data-storage cache object in its cache
  * @cookie: The cookie representing the cache object
  *
  * Permit data-storage cache objects to be unpinned from the cache.
@@ -490,7 +490,7 @@ void fscache_wait_on_invalidate(struct fscache_cookie 
*cookie)
 /**
  * fscache_reserve_space - Reserve data space for a cached object
  * @cookie: The cookie representing the cache object
- * @i_size: The amount of space to be reserved
+ * @size: The amount of space to be reserved
  *
  * Reserve an amount of space in the cache for the cache object attached to a
  * cookie so that a write to that object within the space can always be
-- 
2.17.1

Re: [PATCH v6 3/7] phy: phy-hi3670-usb3: move driver from staging into phy

On 27-01-21, 20:08, Mauro Carvalho Chehab wrote:
> The phy USB3 driver for Hisilicon 970 (hi3670) is ready
> for mainstream. Mode it from staging into the main driver's
> phy/ directory.

I guess Greg will pick this, so:

Acked-By: Vinod Koul 

-- 
~Vinod

Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error

2021-02-03 Thread Christian König


Am 03.02.21 um 21:20 schrieb Suren Baghdasaryan:

[SNIP]
If there is a reason to set this flag other than historical use of
carveout memory then we wanted to catch such cases and fix the drivers
that moved to using dmabuf heaps. However maybe there are other
reasons and if so I would be very grateful if someone could explain
them. That would help me to come up with a better solution.


Well one major reason for this is to prevent accounting of DMA-buf pages.

So you are going in circles here and trying to circumvent an intentional 
behavior.


Daniel is right that this is the completely wrong approach and we need 
to take a step back and think about it on a higher level.


Going to replay to his mail as well.

Regards,
Christian.

[PATCH] scsi: isci: Remove redundant initialization of variable 'status'

This patch removes unneeded return variables.
It fixes the following warning detected by coccinelle:
./drivers/scsi/isci/request.c:1483:17-23: Unneeded variable: "status".
Return "SCI_SUCCESS" on line 1503
./drivers/scsi/isci/request.c:2157:17-23: Unneeded variable: "status".
Return "SCI_SUCCESS" on line 2177

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/scsi/isci/request.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index 6e08179..8676282 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -1480,8 +1480,6 @@ static enum sci_status 
sci_stp_request_pio_data_in_copy_data(
 stp_request_pio_await_h2d_completion_tc_event(struct isci_request *ireq,
  u32 completion_code)
 {
-   enum sci_status status = SCI_SUCCESS;
-
switch (SCU_GET_COMPLETION_TL_STATUS(completion_code)) {
case SCU_MAKE_COMPLETION_STATUS(SCU_TASK_DONE_GOOD):
ireq->scu_status = SCU_TASK_DONE_GOOD;
@@ -1500,7 +1498,7 @@ static enum sci_status 
sci_stp_request_pio_data_in_copy_data(
break;
}
 
-   return status;
+   return SCI_SUCCESS;
 }
 
 static enum sci_status
@@ -2154,8 +2152,6 @@ static enum sci_status 
stp_request_udma_await_tc_event(struct isci_request *ireq
 static enum sci_status atapi_raw_completion(struct isci_request *ireq, u32 
completion_code,
  enum sci_base_request_states 
next)
 {
-   enum sci_status status = SCI_SUCCESS;
-
switch (SCU_GET_COMPLETION_TL_STATUS(completion_code)) {
case SCU_MAKE_COMPLETION_STATUS(SCU_TASK_DONE_GOOD):
ireq->scu_status = SCU_TASK_DONE_GOOD;
@@ -2174,7 +2170,7 @@ static enum sci_status atapi_raw_completion(struct 
isci_request *ireq, u32 compl
break;
}
 
-   return status;
+   return SCI_SUCCESS;
 }
 
 static enum sci_status atapi_data_tc_completion_handler(struct isci_request 
*ireq,
-- 
1.8.3.1

Re: [PATCH v4 0/5] Promote Hikey 970 USB phy out of staging

On 26-01-21, 18:49, Greg Kroah-Hartman wrote:
> On Tue, Jan 19, 2021 at 11:44:38AM +0100, Mauro Carvalho Chehab wrote:
> > Hi Vinod/Rob,
> > 
> > This series moves  the Hikey 970 USB PHY driver out of staging.
> > 
> > Patches 1 to 4 contain the fixes from staging. Patch 5 moves the
> > driver from staging:
> > 
> > $ git show 82ce73ac9a38 --summary
> > ...
> >  rename drivers/staging/hikey9xx/phy-hi3670-usb3.yaml => 
> > Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml (100%)
> >  rename drivers/{staging/hikey9xx => phy/hisilicon}/phy-hi3670-usb3.c 
> > (100%)
> > 
> > I opted to use --no-renames on this series in order to make easier to
> > review via e-mail, as the entire driver and DT bindings will be seen
> > at the last patch on this series.
> 
> First 4 patches applied to my tree, thanks.

I have acked the last one, pls apply that one too

-- 
~Vinod

[PATCH v2 2/2] drivers/clocksource: Fixup csky,mptimer compile error with CPU_CK610

2021-02-03 Thread guoren

From: Guo Ren 

The timer-mp-csky.c only could support CPU_CK860 and it will
compile error with CPU_CK610.

It has been selected in arch/csky/Kconfig.

Signed-off-by: Guo Ren 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
---
 drivers/clocksource/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

---
v2: Drop the string after bool,
as suggested by Marc Zyngier 

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 14c7c4712478..d39e6ca86d25 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -662,7 +662,7 @@ config CLINT_TIMER
  driver is usually used for NoMMU RISC-V systems.
 
 config CSKY_MP_TIMER
-   bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
+   bool
depends on CSKY
select TIMER_OF
help
-- 
2.17.1

[PATCH v2 1/2] drivers/irqchip: Fixup csky,mpintc compile error with CPU_CK610

2021-02-03 Thread guoren

From: Guo Ren 

The irq-csky-mpintc.c only could support CPU_CK860 and it will
compile error with CPU_CK610.

It has beed selected in arch/csky/Kconfig

Signed-off-by: Guo Ren 
Cc: Marc Zyngier 
---
 drivers/irqchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

---
v2: Drop the string after bool,
as suggested by Marc Zyngier 

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b147f22a78f4..53abecb8c792 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -432,7 +432,7 @@ config QCOM_PDC
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
 config CSKY_MPINTC
-   bool "C-SKY Multi Processor Interrupt Controller"
+   bool
depends on CSKY
help
  Say yes here to enable C-SKY SMP interrupt controller driver used
-- 
2.17.1

Re: [PATCH v4 5/5] phy: phy-hi3670-usb3: move driver from staging into phy

On 19-01-21, 11:44, Mauro Carvalho Chehab wrote:
> The phy USB3 driver for Hisilicon 970 (hi3670) is ready
> for mainstream. Mode it from staging into the main driver's
> phy/ directory.

Acked-By: Vinod Koul 

I think it makes sense if Greg applies this as well

-- 
~Vinod

Re: [PATCH v8 0/2] Kbuild: DWARF v5 support

On Wed, Feb 3, 2021 at 10:58 PM Sedat Dilek  wrote:
>
> I guess I need to test harder to get a Tested-by credit :-)?

You're right Sedat, I'm sorry.  Your testing is invaluable; thank you
for taking the time to help and credit is a powerful incentive.

It can be difficult to know whether to carry forward tags or not when
a patch is revised.

Keeping track whether someone sent an explicit Tested By vs including
it based on feedback that implied they tried it.  If you've tested v7
or v8, please reply explicitly with tested by tags, or perhaps
Masahiro can apply those for you.

It can be difficult to know what's broken if you apply too many out of
tree patches though.
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names

2021-02-03 Thread Drew Fustini

On Thu, Feb 04, 2021 at 08:58:20AM +0200, Tony Lindgren wrote:
> * Drew Fustini  [210127 02:04]:
> > Based on linux-gpio discussion [1], it is best practice to make the
> > gpio-line-names unique. Generic names like "[ethernet]" are replaced
> > with the name of the unique signal on the AM3358 SoC ball corresponding
> > to the gpio line. "[NC]" is also renamed to the standard "NC" name to
> > represent "not connected".
> > 
> > [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/
> 
> So are these needed for v5.12 as fixes, or can these wait until after
> the merge window for v5.13?
> 
> Regards,
> 
> Tony

I suppose it depends on if/when the patches to make gpio lines unique
go in.  I believe the last response from Linus W. was in mid-December
and indicated he holding off merging as it was immature [1]

Thanks,
Drew

[1] 
https://lore.kernel.org/linux-gpio/cacrpkdbxrhcdgx-ybbny7cmob0dznhi1eta3qnc71ztoyb3...@mail.gmail.com/

[PATCH net-next] xfrm: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/xfrm/xfrm_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index d0c32a8fcc4a..ad63a6c77edd 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2444,7 +2444,7 @@ static int xfrm_do_migrate(struct sk_buff *skb, struct 
nlmsghdr *nlh,
encap = kmemdup(nla_data(attrs[XFRMA_ENCAP]),
sizeof(*encap), GFP_KERNEL);
if (!encap)
-   return 0;
+   return -ENOMEM;
}
 
err = xfrm_migrate(>sel, pi->dir, type, m, n, kmp, net, encap);
-- 
2.22.0

Re: [PATCH V7 6/6] of: unittest: Statically apply overlays using fdtoverlay

2021-02-03 Thread Viresh Kumar

On 03-02-21, 19:54, Rob Herring wrote:
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index b00855b247e0..886d2e6c58f0 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -66,6 +66,9 @@ multi-used   := $(multi-used-y) $(multi-used-m)
>  real-obj-y := $(foreach m, $(obj-y), $(if $(strip $($(m:.o=-objs)) 
> $($(m:.o=-y)) $($(m:.o=-))),$($(m:.o=-objs)) $($(m:.o=-y)),$(m)))
>  real-obj-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) 
> $($(m:.o=-y)) $($(m:.o=-m)) $($(m:.o=-))),$($(m:.o=-objs)) $($(m:.o=-y)) 
> $($(m:.o=-m)),$(m)))
>  
> +real-dtb-y := $(foreach m,$(dtb-y), $(if $(strip 
> $($(m:.dtb=-dtbs))),$($(m:.dtb=-dtbs)),))
> +dtb-y += $(real-dtb-y)
> +
>  always-y += $(always-m)
>  
>  # hostprogs-always-y += foo
> @@ -332,6 +335,15 @@ $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
>  $(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE
>   $(call if_changed_dep,dtc)
>  
> +
> +quiet_cmd_fdtoverlay = DTOVL   $@
> +  cmd_fdtoverlay = $(objtree)/scripts/dtc/fdtoverlay -o $@ -i 
> $(real-prereqs)
> +
> +.SECONDEXPANSION:
> +
> +$(obj)/%.dtb: $$(addprefix $$(obj)/,$$(%-dtbs)) FORCE
> + $(call if_changed,fdtoverlay)
> +
>  DT_CHECKER ?= dt-validate
>  DT_BINDING_DIR := Documentation/devicetree/bindings
>  # DT_TMP_SCHEMA may be overridden from 
> Documentation/devicetree/bindings/Makefile

Thanks, this simplifies it greatly for platform guys.

-- 
viresh

[PATCH v2] firewire: convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning:

./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or
sprintf.

Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong 
---
Changes in v2:
  - Modified print format.

 drivers/firewire/core-device.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 80db43a..25508a8 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev,
struct fw_device *device = fw_device(dev->parent);
struct fw_unit *unit = fw_unit(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n",
-   (int)(unit->directory - device->config_rom));
+   return sysfs_emit(buf, "%td\n", unit->directory - device->config_rom);
 }
 
 static struct device_attribute fw_unit_attributes[] = {
@@ -403,8 +402,7 @@ static ssize_t guid_show(struct device *dev,
int ret;
 
down_read(_device_rwsem);
-   ret = snprintf(buf, PAGE_SIZE, "0x%08x%08x\n",
-  device->config_rom[3], device->config_rom[4]);
+   ret = sysfs_emit(buf, "0x%08x%08x\n", device->config_rom[3], 
device->config_rom[4]);
up_read(_device_rwsem);
 
return ret;
-- 
1.8.3.1

Re: [PATCH] ath11k: remove h from printk format specifier

2021-02-03 Thread Kalle Valo

t...@redhat.com wrote:

> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
>   unnecessary %h[xudi] and %hh[xudi]")
> 
> Standard integer promotion is already done and %hx and %hhx is useless
> so do not encourage the use of %hh[xudi] or %h[xudi].
> 
> Signed-off-by: Tom Rix 
> Signed-off-by: Kalle Valo 

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

bb2d2dfd3c93 ath11k: remove h from printk format specifier

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20210128144928.2557605-1-t...@redhat.com/

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

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

2021-02-03 Thread Hans de Goede

Hi Stephen, Andy,

On 2/4/21 6:13 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drivers-x86 tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/platform/x86/intel_scu_wdt.c: In function 'register_mid_wdt':
> drivers/platform/x86/intel_scu_wdt.c:66:28: warning: assignment discards 
> 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>66 |  wdt_dev.dev.platform_data = (const struct intel_mid_wdt_pdata 
> *)id->driver_data;
>   |^
> 
> Introduced by commit
> 
>   a507e5d90f3d ("platform/x86: intel_scu_wdt: Get rid of custom x86 model 
> comparison")

Thank you for the bug report.

Andy can you send me a fix for this please ?

Regards,

Hans

Re: [PATCH] ath10k: remove h from printk format specifier

2021-02-03 Thread Kalle Valo

t...@redhat.com wrote:

> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
>   unnecessary %h[xudi] and %hh[xudi]")
> 
> Standard integer promotion is already done and %hx and %hhx is useless
> so do not encourage the use of %hh[xudi] or %h[xudi].
> 
> Signed-off-by: Tom Rix 
> Signed-off-by: Kalle Valo 

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

779750bb153d ath10k: remove h from printk format specifier

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20210127222344.2445641-1-t...@redhat.com/

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

[PATCH net-next] net: sched: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/sched/em_nbyte.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/em_nbyte.c b/net/sched/em_nbyte.c
index 2c1192a2ee5e..a83b237cbeb0 100644
--- a/net/sched/em_nbyte.c
+++ b/net/sched/em_nbyte.c
@@ -31,7 +31,7 @@ static int em_nbyte_change(struct net *net, void *data, int 
data_len,
em->datalen = sizeof(*nbyte) + nbyte->len;
em->data = (unsigned long)kmemdup(data, em->datalen, GFP_KERNEL);
if (em->data == 0UL)
-   return -ENOBUFS;
+   return -ENOMEM;
 
return 0;
 }
-- 
2.22.0

Re: [PATCH] kprobes: Warn if the kprobe is reregistered

2021-02-03 Thread Ananth N Mavinakayanahalli


On 2/3/21 8:29 PM, Masami Hiramatsu wrote:

Warn if the kprobe is reregistered, since there must be
a software bug (actively used resource must not be re-registered)
and caller must be fixed.

Signed-off-by: Masami Hiramatsu 


Acked-by: Ananth N Mavinakayanahalli

[PATCH v1] vdpa/mlx5: Restore the hardware used index after change map

When a change of memory map occurs, the hardware resources are destroyed
and then re-created again with the new memory map. In such case, we need
to restore the hardware available and used indices. The driver failed to
restore the used index which is added here.

Also, since the driver also fails to reset the available and used
indices upon device reset, fix this here to avoid regression caused by
the fact that used index may not be zero upon device reset.

Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen 
---
v0 -> v1:
Clear indices upon device reset

 drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 88dde3455bfd..b5fe6d2ad22f 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+   u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+   u16 used_idx;
int fw_state;
 
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev, 
struct mlx5_vdpa_virtque
 
obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, obj_context);
MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, 
mvq->avail_idx);
+   MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, 
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context, queue_feature_bit_mask_12_3,
 get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, 
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net *ndev, struct 
mlx5_vdpa_virtqueue *m
 struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+   u16 used_index;
 };
 
 static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct 
mlx5_vdpa_virtqueue *mvq,
@@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net *ndev, 
struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
attr->available_index = MLX5_GET(virtio_net_q_object, obj_context, 
hw_available_index);
+   attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, 
hw_used_index);
kfree(out);
return 0;
 
@@ -1535,6 +1540,16 @@ static void teardown_virtqueues(struct mlx5_vdpa_net 
*ndev)
}
 }
 
+static void clear_virtqueues(struct mlx5_vdpa_net *ndev)
+{
+   int i;
+
+   for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
+   ndev->vqs[i].avail_idx = 0;
+   ndev->vqs[i].used_idx = 0;
+   }
+}
+
 /* TODO: cross-endian support */
 static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev *mvdev)
 {
@@ -1610,6 +1625,7 @@ static int save_channel_info(struct mlx5_vdpa_net *ndev, 
struct mlx5_vdpa_virtqu
return err;
 
ri->avail_index = attr.available_index;
+   ri->used_index = attr.used_index;
ri->ready = mvq->ready;
ri->num_ent = mvq->num_ent;
ri->desc_addr = mvq->desc_addr;
@@ -1654,6 +1670,7 @@ static void restore_channels_info(struct mlx5_vdpa_net 
*ndev)
continue;
 
mvq->avail_idx = ri->avail_index;
+   mvq->used_idx = ri->used_index;
mvq->ready = ri->ready;
mvq->num_ent = ri->num_ent;
mvq->desc_addr = ri->desc_addr;
@@ -1768,6 +1785,7 @@ static void mlx5_vdpa_set_status(struct vdpa_device 
*vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device reset\n");
teardown_driver(ndev);
+   clear_virtqueues(ndev);
mlx5_vdpa_destroy_mr(>mvdev);
ndev->mvdev.status = 0;
ndev->mvdev.mlx_features = 0;
-- 
2.29.2

[PATCH] scsi: lpfc: Remove unneeded return variable

This patch removes unneeded return variables, using only
'1' instead.
It fixes the following warning detected by coccinelle:

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/scsi/lpfc/lpfc_sli.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 95caad7..31f97f6 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -3376,7 +3376,6 @@ struct lpfc_hbq_init *lpfc_hbq_defs[] = {
  struct lpfc_iocbq *saveq)
 {
struct lpfc_iocbq *cmdiocbp;
-   int rc = 1;
unsigned long iflag;
 
cmdiocbp = lpfc_sli_iocbq_lookup(phba, pring, saveq);
@@ -3501,7 +3500,7 @@ struct lpfc_hbq_init *lpfc_hbq_defs[] = {
}
}
 
-   return rc;
+   return 1;
 }
 
 /**
-- 
1.8.3.1

Re: [PATCH 1/2] quota: Add mountpath based quota support

2021-02-03 Thread Christoph Hellwig

On Tue, Feb 02, 2021 at 07:02:41PM +0100, Jan Kara wrote:
> Hum, let me think out loud. The path we pass to Q_QUOTAON is a path to
> quota file - unless the filesystem stores quota in hidden files in which
> case this argument is just ignored. You're right we could require that
> specifically for Q_QUOTAON, the mountpoint path would actually need to
> point to the quota file if it is relevant, otherwise anywhere in the
> appropriate filesystem. We don't allow quota file to reside on a different
> filesystem (for a past decade or so) so it should work fine.
> 
> So the only problem I have is whether requiring the mountpoint argument to
> point quota file for Q_QUOTAON isn't going to be somewhat confusing to
> users. At the very least it would require some careful explanation in the
> manpage to explain the difference between quotactl_path() and quotactl()
> in this regard. But is saving the second path for Q_QUOTAON really worth the
> bother?

I find the doubled path argument a really horrible API, so I'd pretty
strongly prefer to avoid that.

> > Given how cheap quotactl_cmd_onoff and quotactl_cmd_write are we
> > could probably simplify this down do:
> > 
> > if (quotactl_cmd_write(cmd)) {
> 
> This needs to be (quotactl_cmd_write(cmd) || quotactl_cmd_onoff(cmd)).
> Otherwise I agree what you suggest is somewhat more readable given how
> small the function is.

The way I read quotactl_cmd_write, it only special cases a few commands
and returns 0 there, so we should not need the extra quotactl_cmd_onoff
call, as all those commands are not explicitly listed.

Re: [PATCH] ceph: minor coding style tweaks

2021-02-03 Thread Joe Perches

On Thu, 2021-02-04 at 14:32 +0800, Zhiyuan Dai wrote:
> Fixed some coding style issues, improve code reading.

Might describe the patch does 3 things:

o Move the pointer location
struct foo* bar; -> struct foo *bar;
o Move brace position
  from
struct foo
{
  to
struct foo {
o Alignment to open parenthesis

And one more comment:

> diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
[]
> @@ -309,8 +309,8 @@ static int ceph_fill_dirfrag(struct inode *inode,
>  
>  static int frag_tree_split_cmp(const void *l, const void *r)
>  {
> - struct ceph_frag_tree_split *ls = (struct ceph_frag_tree_split*)l;
> - struct ceph_frag_tree_split *rs = (struct ceph_frag_tree_split*)r;
> + struct ceph_frag_tree_split *ls = (struct ceph_frag_tree_split *)l;
> + struct ceph_frag_tree_split *rs = (struct ceph_frag_tree_split *)r;

It's unnecessary to cast void pointers and it's bad form to lose
the const qualifier.

const struct ceph_frag_tree_split *ls = l;
const struct ceph_frag_tree_split *rs = r;

>   return ceph_frag_compare(le32_to_cpu(ls->frag),
>    le32_to_cpu(rs->frag));
>  }

[PATCH v4 1/1] mm/highmem: Remove deprecated kmap_atomic

2021-02-03 Thread Prathu Baronia

From: Ira Weiny 

kmap_atomic() is being deprecated in favor of kmap_local_page().

Replace the uses of kmap_atomic() within the highmem code.

On profiling clear_huge_page() using ftrace an improvement
of 62% was observed on the below setup.

Setup:-
Below data has been collected on Qualcomm's SM7250 SoC THP enabled
(kernel v4.19.113) with only CPU-0(Cortex-A55) and CPU-7(Cortex-A76)
switched on and set to max frequency, also DDR set to perf governor.

FTRACE Data:-

Base data:-
Number of iterations: 48
Mean of allocation time: 349.5 us
std deviation: 74.5 us

v4 data:-
Number of iterations: 48
Mean of allocation time: 131 us
std deviation: 32.7 us

The following simple userspace experiment to allocate
100MB(BUF_SZ) of pages and writing to it gave us a good insight,
we observed an improvement of 42% in allocation and writing timings.
-
Test code snippet
-
  clock_start();
  buf = malloc(BUF_SZ); /* Allocate 100 MB of memory */

for(i=0; i < BUF_SZ_PAGES; i++)
{
*((int *)(buf + (i*PAGE_SIZE))) = 1;
}
  clock_end();
-

Malloc test timings for 100MB anon allocation:-

Base data:-
Number of iterations: 100
Mean of allocation time: 31831 us
std deviation: 4286 us

v4 data:-
Number of iterations: 100
Mean of allocation time: 18193 us
std deviation: 4915 us

Signed-off-by: Ira Weiny 
Signed-off-by: Prathu Baronia 
[Updated commit text with test data]
---
 include/linux/highmem.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d2c70d3772a3..9a202c7e4e26 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -146,9 +146,9 @@ static inline void invalidate_kernel_vmap_range(void 
*vaddr, int size)
 #ifndef clear_user_highpage
 static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
 {
-   void *addr = kmap_atomic(page);
+   void *addr = kmap_local_page(page);
clear_user_page(addr, vaddr, page);
-   kunmap_atomic(addr);
+   kunmap_local(addr);
 }
 #endif
 
@@ -199,9 +199,9 @@ alloc_zeroed_user_highpage_movable(struct vm_area_struct 
*vma,
 
 static inline void clear_highpage(struct page *page)
 {
-   void *kaddr = kmap_atomic(page);
+   void *kaddr = kmap_local_page(page);
clear_page(kaddr);
-   kunmap_atomic(kaddr);
+   kunmap_local(kaddr);
 }
 
 /*
@@ -216,7 +216,7 @@ static inline void zero_user_segments(struct page *page,
unsigned start1, unsigned end1,
unsigned start2, unsigned end2)
 {
-   void *kaddr = kmap_atomic(page);
+   void *kaddr = kmap_local_page(page);
unsigned int i;
 
BUG_ON(end1 > page_size(page) || end2 > page_size(page));
@@ -227,7 +227,7 @@ static inline void zero_user_segments(struct page *page,
if (end2 > start2)
memset(kaddr + start2, 0, end2 - start2);
 
-   kunmap_atomic(kaddr);
+   kunmap_local(kaddr);
for (i = 0; i < compound_nr(page); i++)
flush_dcache_page(page + i);
 }
@@ -252,11 +252,11 @@ static inline void copy_user_highpage(struct page *to, 
struct page *from,
 {
char *vfrom, *vto;
 
-   vfrom = kmap_atomic(from);
-   vto = kmap_atomic(to);
+   vfrom = kmap_local_page(from);
+   vto = kmap_local_page(to);
copy_user_page(vto, vfrom, vaddr, to);
-   kunmap_atomic(vto);
-   kunmap_atomic(vfrom);
+   kunmap_local(vto);
+   kunmap_local(vfrom);
 }
 
 #endif
@@ -267,11 +267,11 @@ static inline void copy_highpage(struct page *to, struct 
page *from)
 {
char *vfrom, *vto;
 
-   vfrom = kmap_atomic(from);
-   vto = kmap_atomic(to);
+   vfrom = kmap_local_page(from);
+   vto = kmap_local_page(to);
copy_page(vto, vfrom);
-   kunmap_atomic(vto);
-   kunmap_atomic(vfrom);
+   kunmap_local(vto);
+   kunmap_local(vfrom);
 }
 
 #endif
-- 
2.17.1

[PATCH v4 0/1] mm/highmem: Remove deprecated kmap_atomic

2021-02-03 Thread Prathu Baronia

Updated the commit text.

Changelog:
Added my test data to Ira's v3 patch.

Ira Weiny (1):
  mm/highmem: Remove deprecated kmap_atomic

 include/linux/highmem.h | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

-- 
2.17.1

Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order

2021-02-03 Thread Vincent Guittot

On Wed, 3 Feb 2021 at 12:10, Bharata B Rao  wrote:
>
> On Wed, Jan 27, 2021 at 12:04:01PM +0100, Vlastimil Babka wrote:
> > On 1/27/21 10:10 AM, Christoph Lameter wrote:
> > > On Tue, 26 Jan 2021, Will Deacon wrote:
> > >
> > >> > Hm, but booting the secondaries is just a software (kernel) action? 
> > >> > They are
> > >> > already physically there, so it seems to me as if the cpu_present_mask 
> > >> > is not
> > >> > populated correctly on arm64, and it's just a mirror of 
> > >> > cpu_online_mask?
> > >>
> > >> I think the present_mask retains CPUs if they are hotplugged off, whereas
> > >> the online mask does not. We can't really do any better on arm64, as 
> > >> there's
> > >> no way of telling that a CPU is present until we've seen it.
> > >
> > > The order of each page in a kmem cache --and therefore also the number
> > > of objects in a slab page-- can be different because that information is
> > > stored in the page struct.
> > >
> > > Therefore it is possible to retune the order while the cache is in 
> > > operaton.
> >
> > Yes, but it's tricky to do the retuning safely, e.g. if freelist 
> > randomization
> > is enabled, see [1].
> >
> > But as a quick fix for the regression, the heuristic idea could work 
> > reasonably
> > on all architectures?
> > - if num_present_cpus() is > 1, trust that it doesn't have the issue such as
> > arm64, and use it
> > - otherwise use nr_cpu_ids
> >
> > Long-term we can attempt to do the retuning safe, or decide that number of 
> > cpus
> > shouldn't determine the order...
> >
> > [1] 
> > https://lore.kernel.org/linux-mm/d7fb9425-9a62-c7b8-604d-5828d7e6b...@suse.cz/
>
> So what is preferrable here now? Above or other quick fix or reverting
> the original commit?

I'm fine with whatever the solution as long as we can use keep using
nr_cpu_ids when other values like num_present_cpus, don't reflect
correctly the system

Regards,
Vincent

>
> Regards,
> Bharata.

AW: [PATCH v1] leds: lp50xx: add setting of default intensity from DT

2021-02-03 Thread Sven Schuchmann

Helo Pavel,

> > > Yes, sounds reasonable. Could we get default intensity of 100% on all
> > > channels if nothing else is specified?
> > >
> > > Or maybe simply "if intensity is not specified, start with 100%, and
> > > use explicit =0 if other color is expected".
> > >
> > Mh, if someone is already using the led driver and updates to a newer kernel
> > we would then turn on all leds per default to the maximum intensity during 
> > boot
> > until they are set the way they should be from userspace. I don't know if 
> > this
> > is what we want? If yes, sure, we could set them to maximum per
> > default.
> 
> Not really. If they don't have trigger configured, nothing will happen.

Oops, you are right, my fault.

> 
> > Also if we want to use Percentage Values (%) for setting the intensity
> > I think this should also be done for the userspace interfaces and
> > not only from DT.
> 
> We don't want to use percentages in the API (but let me still use
> percentages in discussion).

No Problem.

Best Regards,

   Sven

[PATCH] x86: Remove HPET_EMULATE_RTC depends on RTC

2021-02-03 Thread Anand K Mistry

The RTC config option was removed in commit f52ef24be21a ("rtc/alpha:
remove legacy rtc driver")

Signed-off-by: Anand K Mistry 
---

 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..37775478d86f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -890,7 +890,7 @@ config HPET_TIMER
 
 config HPET_EMULATE_RTC
def_bool y
-   depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || 
RTC_DRV_CMOS=y)
+   depends on HPET_TIMER && (RTC_DRV_CMOS=m || RTC_DRV_CMOS=y)
 
 config APB_TIMER
def_bool y if X86_INTEL_MID
-- 
2.30.0.365.g02bc693789-goog

[PATCH net-next] net: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/mpls/af_mpls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index f2868a8a50c3..7e73611c48dd 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -1427,7 +1427,7 @@ static int mpls_dev_sysctl_register(struct net_device 
*dev,
 free:
kfree(table);
 out:
-   return -ENOBUFS;
+   return -ENOMEM;
 }
 
 static void mpls_dev_sysctl_unregister(struct net_device *dev,
-- 
2.22.0

AW: [PATCH v1] leds: lp50xx: add setting of default intensity from DT

2021-02-03 Thread Sven Schuchmann

Hello Pavel, hello Marek

> > Is the property default-intensity documented in DT bindings?

I updated the documentation in leds-lp50xx.yaml. Is it this what you mean?

> > Wouldn't it be better if the property was used in the multi-led node
> > instead of the channel node? I.e.
> >   multi-led@3 {
> > color = ;
> > default-intensity = <100 0 0>;
> >   };
> 
> Yes, this would be better.

Sound good, I will see what I can do here.

Regards, Sven

Re: [PATCH RFC v1 2/6] swiotlb: convert variables to arrays

2021-02-03 Thread Christoph Hellwig

On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> This patch converts several swiotlb related variables to arrays, in
> order to maintain stat/status for different swiotlb buffers. Here are
> variables involved:
> 
> - io_tlb_start and io_tlb_end
> - io_tlb_nslabs and io_tlb_used
> - io_tlb_list
> - io_tlb_index
> - max_segment
> - io_tlb_orig_addr
> - no_iotlb_memory
> 
> There is no functional change and this is to prepare to enable 64-bit
> swiotlb.

Claire Chang (on Cc) already posted a patch like this a month ago,
which looks much better because it actually uses a struct instead
of all the random variables.

[PATCH net-next] dccp: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/dccp/feat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/dccp/feat.c b/net/dccp/feat.c
index 788dd629c420..4cb813bee7b4 100644
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -371,7 +371,7 @@ static int dccp_feat_clone_sp_val(dccp_feat_val *fval, u8 
const *val, u8 len)
fval->sp.vec = kmemdup(val, len, gfp_any());
if (fval->sp.vec == NULL) {
fval->sp.len = 0;
-   return -ENOBUFS;
+   return -ENOMEM;
}
}
return 0;
-- 
2.22.0

Re: [PATCH v2] x86/fault: Send a SIGBUS to user process always for hwpoison page access.

2021-02-03 Thread 堀口　直也

Hi Aili,

On Mon, Feb 01, 2021 at 04:17:49PM +0800, Aili Yao wrote:
> When one page is already hwpoisoned by AO action, process may not be
> killed, the process mapping this page may make a syscall include this
> page and result to trigger a VM_FAULT_HWPOISON fault, if it's in kernel
> mode it may be fixed by fixup_exception. Current code will just return
> error code to user process.
> 
> This is not sufficient, we should send a SIGBUS to the process and log
> the info to console, as we can't trust the process will handle the error
> correctly.
> 
> Suggested-by: Feng Yang 
> Signed-off-by: Aili Yao 
> ---
...

> @@ -662,12 +662,32 @@ no_context(struct pt_regs *regs, unsigned long 
> error_code,
>* In this case we need to make sure we're not recursively
>* faulting through the emulate_vsyscall() logic.
>*/
> +
> + if (IS_ENABLED(CONFIG_MEMORY_FAILURE) &&
> + fault & (VM_FAULT_HWPOISON|VM_FAULT_HWPOISON_LARGE)) {
> + unsigned int lsb = 0;
> +
> + pr_err("MCE: Killing %s:%d due to hardware memory 
> corruption fault at %lx\n",
> + current->comm, current->pid, address);
> +
> + sanitize_error_code(address, _code);
> + set_signal_archinfo(address, error_code);
> +
> + if (fault & VM_FAULT_HWPOISON_LARGE)
> + lsb = 
> hstate_index_to_shift(VM_FAULT_GET_HINDEX(fault));
> + if (fault & VM_FAULT_HWPOISON)
> + lsb = PAGE_SHIFT;
> +
> + force_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, 
> lsb);

This part contains some duplicated code with do_sigbus(), so some refactoring 
(like
adding a common function) would be more helpful.

Thanks,
Naoya Horiguchi

[PATCH net-next] ipv6: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/ipv6/addrconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8b6eb384bac7..347b95bc00fd 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -6943,7 +6943,7 @@ static int __addrconf_sysctl_register(struct net *net, 
char *dev_name,
 free:
kfree(table);
 out:
-   return -ENOBUFS;
+   return -ENOMEM;
 }
 
 static void __addrconf_sysctl_unregister(struct net *net,
-- 
2.22.0

[PATCH] scsi: ipr: Remove unneeded return variable

This patch removes unneeded return variables, using only
'0' instead.
It fixes the following warning detected by coccinelle:
./drivers/scsi/ipr.c:9508:5-7: Unneeded variable: "rc". Return "0" on
line 9524

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/scsi/ipr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index e451102..8eced7c 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -9505,7 +9505,6 @@ static pci_ers_result_t ipr_pci_error_detected(struct 
pci_dev *pdev,
  **/
 static int ipr_probe_ioa_part2(struct ipr_ioa_cfg *ioa_cfg)
 {
-   int rc = 0;
unsigned long host_lock_flags = 0;
 
ENTER;
@@ -9521,7 +9520,7 @@ static int ipr_probe_ioa_part2(struct ipr_ioa_cfg 
*ioa_cfg)
spin_unlock_irqrestore(ioa_cfg->host->host_lock, host_lock_flags);
 
LEAVE;
-   return rc;
+   return 0;
 }
 
 /**
-- 
1.8.3.1

[PATCH net-next] net: ipv4: Return the correct errno code

When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF.

Signed-off-by: Zheng Yongjun 
---
 net/ipv4/devinet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 123a6d39438f..fa586e915621 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2582,7 +2582,7 @@ static int __devinet_sysctl_register(struct net *net, 
char *dev_name,
 free:
kfree(t);
 out:
-   return -ENOBUFS;
+   return -ENOMEM;
 }
 
 static void __devinet_sysctl_unregister(struct net *net,
-- 
2.22.0

Re: Kernel version numbers after 4.9.255 and 4.4.255

2021-02-03 Thread Jiri Slaby


On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:

On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:

Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit numbers for LINUX_VERSION_CODE and
KERNEL_VERSION() macros, and must stay in range 0...255.
These 8-bit limits are hardcoded in both kernel source and
userspace ABI.

After 4.9.255 and 4.4.255, your scripts should be
incrementing a number in EXTRAVERSION= in top-level
linux Makefile.


Should already be fixed in linux-next, right?


I assume you mean:
commit 537896fabed11f8d976d1aacdb977213c7b3
Author: Sasha Levin 
Date:   Mon Jan 18 14:54:53 2021 -0500

kbuild: give the SUBLEVEL more room in KERNEL_VERSION

That would IMO break userspace as definition of kernel version has 
changed. And that one is UAPI/ABI (see 
include/generated/uapi/linux/version.h) as Jari writes. For example will 
glibc still work:

http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l14

? Or gcc 10 (11 will have this differently):
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf.c;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l165

and

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/bpf/bpf-helpers.h;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l53

It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + 
Z) assumptions all around the world. So this doesn't look like a good idea.


thanks,
--
js
suse labs

Re: [v6 PATCH 03/11] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation

2021-02-03 Thread Kirill Tkhai

On 03.02.2021 20:20, Yang Shi wrote:
> Since memcg_shrinker_map_size just can be changed under holding shrinker_rwsem
> exclusively, the read side can be protected by holding read lock, so it sounds
> superfluous to have a dedicated mutex.
> 
> Kirill Tkhai suggested use write lock since:
> 
>   * We want the assignment to shrinker_maps is visible for 
> shrink_slab_memcg().
>   * The rcu_dereference_protected() dereferrencing in shrink_slab_memcg(), but
> in case of we use READ lock in alloc_shrinker_maps(), the dereferrencing
> is not actually protected.
>   * READ lock makes alloc_shrinker_info() racy against memory allocation fail.
> alloc_shrinker_info()->free_shrinker_info() may free memory right after
> shrink_slab_memcg() dereferenced it. You may say
> shrink_slab_memcg()->mem_cgroup_online() protects us from it? Yes, sure,
> but this is not the thing we want to remember in the future, since this
> spreads modularity.
> 
> And a test with heavy paging workload didn't show write lock makes things 
> worse.
> 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Yang Shi 

Acked-by: Kirill Tkhai 

> ---
>  mm/vmscan.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 96b08c79f18d..e4ddaaaeffe2 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -187,7 +187,6 @@ static DECLARE_RWSEM(shrinker_rwsem);
>  #ifdef CONFIG_MEMCG
>  
>  static int memcg_shrinker_map_size;
> -static DEFINE_MUTEX(memcg_shrinker_map_mutex);
>  
>  static void free_shrinker_map_rcu(struct rcu_head *head)
>  {
> @@ -200,8 +199,6 @@ static int expand_one_shrinker_map(struct mem_cgroup 
> *memcg,
>   struct memcg_shrinker_map *new, *old;
>   int nid;
>  
> - lockdep_assert_held(_shrinker_map_mutex);
> -
>   for_each_node(nid) {
>   old = rcu_dereference_protected(
>   mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true);
> @@ -249,7 +246,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg)
>   if (mem_cgroup_is_root(memcg))
>   return 0;
>  
> - mutex_lock(_shrinker_map_mutex);
> + down_write(_rwsem);
>   size = memcg_shrinker_map_size;
>   for_each_node(nid) {
>   map = kvzalloc_node(sizeof(*map) + size, GFP_KERNEL, nid);
> @@ -260,7 +257,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg)
>   }
>   rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, map);
>   }
> - mutex_unlock(_shrinker_map_mutex);
> + up_write(_rwsem);
>  
>   return ret;
>  }
> @@ -275,9 +272,8 @@ static int expand_shrinker_maps(int new_id)
>   if (size <= old_size)
>   return 0;
>  
> - mutex_lock(_shrinker_map_mutex);
>   if (!root_mem_cgroup)
> - goto unlock;
> + goto out;
>  
>   memcg = mem_cgroup_iter(NULL, NULL, NULL);
>   do {
> @@ -286,13 +282,13 @@ static int expand_shrinker_maps(int new_id)
>   ret = expand_one_shrinker_map(memcg, size, old_size);
>   if (ret) {
>   mem_cgroup_iter_break(NULL, memcg);
> - goto unlock;
> + goto out;
>   }
>   } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> -unlock:
> +out:
>   if (!ret)
>   memcg_shrinker_map_size = size;
> - mutex_unlock(_shrinker_map_mutex);
> +
>   return ret;
>  }
>  
>

[PATCH] crypto: picoxcell - convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning:

 ./drivers/crypto/picoxcell_crypto.c:1201:8-16: WARNING: use scnprintf
or sprintf.

Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong 
---
 drivers/crypto/picoxcell_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/picoxcell_crypto.c 
b/drivers/crypto/picoxcell_crypto.c
index 84f9c16..d7a7def 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1198,7 +1198,7 @@ static ssize_t spacc_stat_irq_thresh_show(struct device 
*dev,
 {
struct spacc_engine *engine = spacc_dev_to_engine(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%u\n", engine->stat_irq_thresh);
+   return sysfs_emit(buf, "%u\n", engine->stat_irq_thresh);
 }
 
 static ssize_t spacc_stat_irq_thresh_store(struct device *dev,
-- 
1.8.3.1

Re: [v6 PATCH 02/11] mm: vmscan: consolidate shrinker_maps handling code

2021-02-03 Thread Kirill Tkhai

On 03.02.2021 20:20, Yang Shi wrote:
> The shrinker map management is not purely memcg specific, it is at the 
> intersection
> between memory cgroup and shrinkers.  It's allocation and assignment of a 
> structure,
> and the only memcg bit is the map is being stored in a memcg structure.  So 
> move the
> shrinker_maps handling code into vmscan.c for tighter integration with 
> shrinker code,
> and remove the "memcg_" prefix.  There is no functional change.
> 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Yang Shi 

Acked-by: Kirill Tkhai 

> ---
>  include/linux/memcontrol.h |  11 ++--
>  mm/huge_memory.c   |   4 +-
>  mm/list_lru.c  |   6 +-
>  mm/memcontrol.c| 129 +---
>  mm/vmscan.c| 131 -
>  5 files changed, 141 insertions(+), 140 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index eeb0b52203e9..1739f17e0939 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1581,10 +1581,9 @@ static inline bool 
> mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
>   return false;
>  }
>  
> -extern int memcg_expand_shrinker_maps(int new_id);
> -
> -extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> -int nid, int shrinker_id);
> +int alloc_shrinker_maps(struct mem_cgroup *memcg);
> +void free_shrinker_maps(struct mem_cgroup *memcg);
> +void set_shrinker_bit(struct mem_cgroup *memcg, int nid, int shrinker_id);
>  #else
>  #define mem_cgroup_sockets_enabled 0
>  static inline void mem_cgroup_sk_alloc(struct sock *sk) { };
> @@ -1594,8 +1593,8 @@ static inline bool 
> mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
>   return false;
>  }
>  
> -static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> -   int nid, int shrinker_id)
> +static inline void set_shrinker_bit(struct mem_cgroup *memcg,
> + int nid, int shrinker_id)
>  {
>  }
>  #endif
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 9237976abe72..05190d7f32ae 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2823,8 +2823,8 @@ void deferred_split_huge_page(struct page *page)
>   ds_queue->split_queue_len++;
>  #ifdef CONFIG_MEMCG
>   if (memcg)
> - memcg_set_shrinker_bit(memcg, page_to_nid(page),
> -deferred_split_shrinker.id);
> + set_shrinker_bit(memcg, page_to_nid(page),
> +  deferred_split_shrinker.id);
>  #endif
>   }
>   spin_unlock_irqrestore(_queue->split_queue_lock, flags);
> diff --git a/mm/list_lru.c b/mm/list_lru.c
> index fe230081690b..628030fa5f69 100644
> --- a/mm/list_lru.c
> +++ b/mm/list_lru.c
> @@ -125,8 +125,8 @@ bool list_lru_add(struct list_lru *lru, struct list_head 
> *item)
>   list_add_tail(item, >list);
>   /* Set shrinker bit if the first element was added */
>   if (!l->nr_items++)
> - memcg_set_shrinker_bit(memcg, nid,
> -lru_shrinker_id(lru));
> + set_shrinker_bit(memcg, nid,
> +  lru_shrinker_id(lru));
>   nlru->nr_items++;
>   spin_unlock(>lock);
>   return true;
> @@ -548,7 +548,7 @@ static void memcg_drain_list_lru_node(struct list_lru 
> *lru, int nid,
>  
>   if (src->nr_items) {
>   dst->nr_items += src->nr_items;
> - memcg_set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru));
> + set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru));
>   src->nr_items = 0;
>   }
>  
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 1bdb93ee8e72..f5c9a0d2160b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -397,129 +397,6 @@ DEFINE_STATIC_KEY_FALSE(memcg_kmem_enabled_key);
>  EXPORT_SYMBOL(memcg_kmem_enabled_key);
>  #endif
>  
> -static int memcg_shrinker_map_size;
> -static DEFINE_MUTEX(memcg_shrinker_map_mutex);
> -
> -static void memcg_free_shrinker_map_rcu(struct rcu_head *head)
> -{
> - kvfree(container_of(head, struct memcg_shrinker_map, rcu));
> -}
> -
> -static int memcg_expand_one_shrinker_map(struct mem_cgroup *memcg,
> -  int size, int old_size)
> -{
> - struct memcg_shrinker_map *new, *old;
> - int nid;
> -
> - lockdep_assert_held(_shrinker_map_mutex);
> -
> - for_each_node(nid) {
> - old = rcu_dereference_protected(
> - mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true);
> - /* Not yet online memcg */
> - if (!old)
> - return 0;
> -
> - new = kvmalloc_node(sizeof(*new) + size, GFP_KERNEL, nid);
> -

Re: [PATCH] bpf: Hoise pahole version checks into Kconfig

2021-02-03 Thread Sedat Dilek

On Thu, Jan 14, 2021 at 12:07 AM Nathan Chancellor
 wrote:
>
> On Wed, Jan 13, 2021 at 02:38:27PM -0800, Andrii Nakryiko wrote:
> > Hm.. Just saw Linus proposing using $(error-if) in Kconfig for an
> > unrelated issue ([0]). If we can make this work, then it would catch
> > such issue early on, yet won't have any downsides of hiding
> > CONFIG_DEBUG_INFO_BTF if pahole is too old. WDYT?
> >
> >   [0] 
> > https://lore.kernel.org/lkml/CAHk-=wh-+TMHPTFo1qs-MYyK7tZh-OQovA=pP3=e06acvp6...@mail.gmail.com/
>
> Yes, I think that would be exactly what we want because DEBUG_INFO_BTF
> could cause the build to error if PAHOLE_VERSION is not >= 116. I will
> try to keep an eye on that thread to see how it goes then respin this
> based on anything that comes from it.
>

For BPF/pahole testing (see [1]) with CONFIG_DEBUG_INFO_DWARF5=y I did:

$ git diff
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b0840d192e95..f15b37143165 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -272,7 +272,7 @@ config DEBUG_INFO_DWARF5
   bool "Generate DWARF Version 5 debuginfo"
   depends on GCC_VERSION >= 5 || CC_IS_CLANG
   depends on CC_IS_GCC ||
$(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC)
$(CLANG_FLAGS))
-   depends on !DEBUG_INFO_BTF
+   depends on !DEBUG_INFO_BTF || (DEBUG_INFO_BTF && PAHOLE_VERSION >= 120)
   help
 Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
 5.0+ accepts the -gdwarf-5 flag but only had partial support for some

Thanks again for that patch.

- Sedat -

[1] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/log/?h=tmp.1.20

Re: [v6 PATCH 01/11] mm: vmscan: use nid from shrink_control for tracepoint

2021-02-03 Thread Kirill Tkhai

On 03.02.2021 20:20, Yang Shi wrote:
> The tracepoint's nid should show what node the shrink happens on, the start 
> tracepoint
> uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint 
> if the
> shrinker is not NUMA aware, so the traceing log may show the shrink happens 
> on one
> node but end up on the other node.  It seems confusing.  And the following 
> patch
> will remove using nid directly in do_shrink_slab(), this patch also helps 
> cleanup
> the code.
> 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Yang Shi 

Acked-by: Kirill Tkhai 

> ---
>  mm/vmscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b1b574ad199d..b512dd5e3a1c 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -535,7 +535,7 @@ static unsigned long do_shrink_slab(struct shrink_control 
> *shrinkctl,
>   else
>   new_nr = atomic_long_read(>nr_deferred[nid]);
>  
> - trace_mm_shrink_slab_end(shrinker, nid, freed, nr, new_nr, total_scan);
> + trace_mm_shrink_slab_end(shrinker, shrinkctl->nid, freed, nr, new_nr, 
> total_scan);
>   return freed;
>  }
>  
>

Re: [PATCH] add chan->cl check in mbox_chan_received_data()

2021-02-03 Thread Yao Haidong

 Oh, I see, thank you

2021-02-01 14:28 GMT+08:00, Jassi Brar :
> On Thu, Jan 7, 2021 at 5:53 AM haidong yao  wrote:
>>
>> Hi Jassi Brar
>>
>> Thank you very much for your reply.
>>
>> Look at the function sprd_mbox_outbox_isr .
>>
>> Chan is !NULL.
>>
>> chan->cl is NULL when the client driver not loaded, the controller
>> driver don't know the client driver loaded successfully, so, I do not
>> use mbox_free_channel.
>>
>> Here,How do you know chan->cl is ok?
>>
> The channel is supposed to get/send data _only_ if it is being used by a
> client.
> Which you can mark in .startup() and .shutdown().
>
> Checking for chan->cl will make your symptoms disappear but that is
> not the right fix for the issue.
> The right fix is to EITHER not cause Rx/Tx interrupt on a channel not
> being used, OR not send it to upper layers.
>
> thanks.
>

Re: [PATCH] vdpa/mlx5: Restore the hardware used index after change map

On Wed, Feb 03, 2021 at 12:33:26PM -0800, Si-Wei Liu wrote:
> On Tue, Feb 2, 2021 at 10:48 PM Eli Cohen  wrote:
> >
> > On Tue, Feb 02, 2021 at 09:14:02AM -0800, Si-Wei Liu wrote:
> > > On Tue, Feb 2, 2021 at 6:34 AM Eli Cohen  wrote:
> > > >
> > > > When a change of memory map occurs, the hardware resources are destroyed
> > > > and then re-created again with the new memory map. In such case, we need
> > > > to restore the hardware available and used indices. The driver failed to
> > > > restore the used index which is added here.
> > > >
> > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 
> > > > devices")
> > > > Signed-off-by: Eli Cohen 
> > > > ---
> > > > This patch is being sent again a single patch the fixes hot memory
> > > > addtion to a qemy process.
> > > >
> > > >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index 88dde3455bfd..839f57c64a6f 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
> > > > u64 device_addr;
> > > > u64 driver_addr;
> > > > u16 avail_index;
> > > > +   u16 used_index;
> > > > bool ready;
> > > > struct vdpa_callback cb;
> > > > bool restore;
> > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
> > > > u32 virtq_id;
> > > > struct mlx5_vdpa_net *ndev;
> > > > u16 avail_idx;
> > > > +   u16 used_idx;
> > > > int fw_state;
> > > >
> > > > /* keep last in the struct */
> > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtque
> > > >
> > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, 
> > > > obj_context);
> > > > MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, 
> > > > mvq->avail_idx);
> > > > +   MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, 
> > > > mvq->used_idx);
> > >
> > > The saved indexes will apply to the new virtqueue object whenever it
> > > is created. In virtio spec, these indexes will reset back to zero when
> > > the virtio device is reset. But I don't see how it's done today. IOW,
> > > I don't see where avail_idx and used_idx get cleared from the mvq for
> > > device reset via set_status().
> > >
> >
> > Right, but this is not strictly related to this patch. I will post
> > another patch to fix this.
> 
> Better to post these two patches in a series.Or else it may cause VM
> reboot problem as that is where the device gets reset. The avail_index
> did not as the correct value will be written to by driver right after,
> but used_idx introduced by this patch is supplied by device hence this
> patch alone would introduce regression.
> 

Thinking it over, I think this should be all fixed in a single patch.
This fix alone introduces a regerssion as you pointed and there's no
point in fixing it in another patch.

> >
> > BTW, can you describe a secnario that would cause a reset (through
> > calling set_status()) that happens after the VQ has been used?
> 
> You can try reboot the guest, that'll be the easy way to test.
> 
> -Siwei
> 
> >
> > > -Siwei
> > >
> > >
> > > > MLX5_SET(virtio_net_q_object, obj_context, 
> > > > queue_feature_bit_mask_12_3,
> > > >  get_features_12_3(ndev->mvdev.actual_features));
> > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, 
> > > > virtio_q_context);
> > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqueue *m
> > > >  struct mlx5_virtq_attr {
> > > > u8 state;
> > > > u16 available_index;
> > > > +   u16 used_index;
> > > >  };
> > > >
> > > >  static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct 
> > > > mlx5_vdpa_virtqueue *mvq,
> > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqueu
> > > > memset(attr, 0, sizeof(*attr));
> > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
> > > > attr->available_index = MLX5_GET(virtio_net_q_object, 
> > > > obj_context, hw_available_index);
> > > > +   attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, 
> > > > hw_used_index);
> > > > kfree(out);
> > > > return 0;
> > > >
> > > > @@ -1610,6 +1615,7 @@ static int save_channel_info(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqu
> > > > return err;
> > > >
> > > > ri->avail_index = attr.available_index;
> > > > +   ri->used_index = attr.used_index;
> > > > ri->ready = mvq->ready;
> > > > ri->num_ent = mvq->num_ent;
> > > > ri->desc_addr = mvq->desc_addr;
> > > > @@ -1654,6 +1660,7 @@ static void

[PATCH] scsi: qla4xxx: Remove unneeded return variable

This patch removes unneeded return variables, using only
'0' instead.
It fixes the following warning detected by coccinelle:
./drivers/scsi/qla4xxx/ql4_os.c:3642:5-7: Unneeded variable: "rc".
Return "0" on line 3741

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/scsi/qla4xxx/ql4_os.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index a4b014e..ed92534 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -3639,7 +3639,6 @@ static int qla4xxx_copy_to_fwddb_param(struct 
iscsi_bus_flash_session *sess,
   struct dev_db_entry *fw_ddb_entry)
 {
uint16_t options;
-   int rc = 0;
 
options = le16_to_cpu(fw_ddb_entry->options);
SET_BITVAL(conn->is_fw_assigned_ipv6,  options, BIT_11);
@@ -3738,7 +3737,7 @@ static int qla4xxx_copy_to_fwddb_param(struct 
iscsi_bus_flash_session *sess,
 
COPY_ISID(fw_ddb_entry->isid, sess->isid);
 
-   return rc;
+   return 0;
 }
 
 static void qla4xxx_copy_to_sess_conn_params(struct iscsi_conn *conn,
-- 
1.8.3.1

Re: [PATCH v2 1/2] platform/chrome: cros_ec: Import Type C control command

2021-02-03 Thread Benson Leung

Hi Prashant,

On Tue, 2 Feb 2021 18:15:37 -0800, Prashant Malani wrote:
> This command is used to communicate with the Chrome Embedded Controller
> (EC) regarding USB Type C events and state.
> 
> These header updates are included in the latest Chrome OS EC headers [1]
> 
> [1]
> https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h

Applied, thanks!

[1/2] platform/chrome: cros_ec: Import Type C control command
  commit: 3ec28d3673362076444e290bdb0d94ec6432dc09
[2/2] platform/chrome: cros_ec_typec: Clear Type C disc events
  commit: d521119c8b0d70b91971d632430ec1143e5d2e26

Best regards,
-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[PATCH] usb: host: ehci: remove casting dma_alloc_coherent

2021-02-03 Thread Xu Wang

Remove casting the values returned by dma_alloc_coherent.

Signed-off-by: Xu Wang 
---
 drivers/usb/host/ehci-mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 6361d81272bc..769329032257 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -185,7 +185,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
}
 
/* Hardware periodic table */
-   ehci->periodic = 
+   ehci->periodic =
dma_alloc_coherent(ehci_to_hcd(ehci)->self.sysdev,
ehci->periodic_size * sizeof(__le32),
>periodic_dma, flags);
-- 
2.17.1

[rcu:willy-maple 175/202] mm/ksm.c:979 unmerge_and_remove_all_rmap_items() error: uninitialized symbol 'mm'.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
willy-maple
head:   7e346d2845b4bd77663394f39fa70456e0084c86
commit: 3fd77bfa4f25fa2e3caec024c69168bf6a0ca8d7 [175/202] mm/ksm: Use maple 
tree iterators instead of vma linked list
config: x86_64-randconfig-m001-20210202 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
mm/ksm.c:979 unmerge_and_remove_all_rmap_items() error: uninitialized symbol 
'mm'.

vim +/mm +979 mm/ksm.c

d952b79136a6c3 Hugh Dickins  2009-09-21   965  static int 
unmerge_and_remove_all_rmap_items(void)
31dbd01f314364 Izik Eidus2009-09-21   966  {
31dbd01f314364 Izik Eidus2009-09-21   967   struct mm_slot *mm_slot;
31dbd01f314364 Izik Eidus2009-09-21   968   struct mm_struct *mm;
31dbd01f314364 Izik Eidus2009-09-21   969   struct vm_area_struct 
*vma;
d952b79136a6c3 Hugh Dickins  2009-09-21   970   int err = 0;
31dbd01f314364 Izik Eidus2009-09-21   971  
d952b79136a6c3 Hugh Dickins  2009-09-21   972   
spin_lock(_mmlist_lock);
9ba6929480088a Hugh Dickins  2009-09-21   973   ksm_scan.mm_slot = 
list_entry(ksm_mm_head.mm_list.next,
d952b79136a6c3 Hugh Dickins  2009-09-21   974   
struct mm_slot, mm_list);
d952b79136a6c3 Hugh Dickins  2009-09-21   975   
spin_unlock(_mmlist_lock);
d952b79136a6c3 Hugh Dickins  2009-09-21   976  
9ba6929480088a Hugh Dickins  2009-09-21   977   for (mm_slot = 
ksm_scan.mm_slot;
3fd77bfa4f25fa Liam R. Howlett   2021-01-04   978   mm_slot 
!= _mm_head; mm_slot = ksm_scan.mm_slot, mm = mm_slot->mm) {
3fd77bfa4f25fa Liam R. Howlett   2021-01-04  @979   MA_STATE(mas, 
>mm_mt, 0, 0);
   
^^
Not initialized on the first iteration through the loop?

3fd77bfa4f25fa Liam R. Howlett   2021-01-04   980  
d8ed45c5dcd455 Michel Lespinasse 2020-06-08   981   
mmap_read_lock(mm);
3fd77bfa4f25fa Liam R. Howlett   2021-01-04   982   mas_set(, 
0);
3fd77bfa4f25fa Liam R. Howlett   2021-01-04   983   
mas_for_each(, vma, ULONG_MAX) {
9ba6929480088a Hugh Dickins  2009-09-21   984   if 
(ksm_test_exit(mm))
9ba6929480088a Hugh Dickins  2009-09-21   985   
break;
31dbd01f314364 Izik Eidus2009-09-21   986   if 
(!(vma->vm_flags & VM_MERGEABLE) || !vma->anon_vma)
31dbd01f314364 Izik Eidus2009-09-21   987   
continue;
d952b79136a6c3 Hugh Dickins  2009-09-21   988   err = 
unmerge_ksm_pages(vma,
d952b79136a6c3 Hugh Dickins  2009-09-21   989   
vma->vm_start, vma->vm_end);
9ba6929480088a Hugh Dickins  2009-09-21   990   if (err)
9ba6929480088a Hugh Dickins  2009-09-21   991   
goto error;
31dbd01f314364 Izik Eidus2009-09-21   992   }
9ba6929480088a Hugh Dickins  2009-09-21   993  
6514d511dbe5a7 Hugh Dickins  2009-12-14   994   
remove_trailing_rmap_items(mm_slot, _slot->rmap_list);
d8ed45c5dcd455 Michel Lespinasse 2020-06-08   995   
mmap_read_unlock(mm);
d952b79136a6c3 Hugh Dickins  2009-09-21   996  
d952b79136a6c3 Hugh Dickins  2009-09-21   997   
spin_lock(_mmlist_lock);
9ba6929480088a Hugh Dickins  2009-09-21   998   
ksm_scan.mm_slot = list_entry(mm_slot->mm_list.next,
d952b79136a6c3 Hugh Dickins  2009-09-21   999   
struct mm_slot, mm_list);
9ba6929480088a Hugh Dickins  2009-09-21  1000   if 
(ksm_test_exit(mm)) {
4ca3a69bcb6875 Sasha Levin   2013-02-22  1001   
hash_del(_slot->link);
9ba6929480088a Hugh Dickins  2009-09-21  1002   
list_del(_slot->mm_list);
9ba6929480088a Hugh Dickins  2009-09-21  1003   
spin_unlock(_mmlist_lock);
9ba6929480088a Hugh Dickins  2009-09-21  1004  
9ba6929480088a Hugh Dickins  2009-09-21  1005   
free_mm_slot(mm_slot);
9ba6929480088a Hugh Dickins  2009-09-21  1006   
clear_bit(MMF_VM_MERGEABLE, >flags);
9ba6929480088a Hugh Dickins  2009-09-21  1007   
mmdrop(mm);
7496fea9a6bf64 Zhou Chengming2016-05-12  1008   } else
d952b79136a6c3 Hugh Dickins  2009-09-21  1009   
spin_unlock(_mmlist_lock);
31dbd01f314364 Izik Eidus2009-09-21  1010   }
31dbd01f314364 Izik Eidus2009-09-21  1011  
cbf86cfe04a664 Hugh Dickins  2013-02-22  1012   /* Clean up stable 
nodes, but don't worry if some

[PATCH v4 2/2] iommu: add Unisoc IOMMU basic driver

2021-02-03 Thread Chunyan Zhang

From: Chunyan Zhang 

This IOMMU module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.

Signed-off-by: Chunyan Zhang 
---
 drivers/iommu/Kconfig  |  12 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/sprd-iommu.c | 599 +
 3 files changed, 612 insertions(+)
 create mode 100644 drivers/iommu/sprd-iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f61310..2ef0b3918440 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -408,4 +408,16 @@ config VIRTIO_IOMMU
 
  Say Y here if you intend to run this kernel as a guest.
 
+config SPRD_IOMMU
+   tristate "Unisoc IOMMU Support"
+   depends on ARCH_SPRD || COMPILE_TEST
+   select IOMMU_API
+   help
+ Support for IOMMU on Unisoc's SoCs, this IOMMU can be used by
+ Unisoc's multimedia devices, such as display, Image codec(jpeg)
+ and a few signal processors, including VSP(video), GSP(graphic),
+ ISP(image), and CPP(camera pixel processor), etc.
+
+ Say Y here if you want to use the multimedia devices listed above.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 61bd30cd8369..5925b6af2123 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
 obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
 obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
 obj-$(CONFIG_IOMMU_SVA_LIB) += iommu-sva-lib.o
+obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
new file mode 100644
index ..022fe62027c0
--- /dev/null
+++ b/drivers/iommu/sprd-iommu.c
@@ -0,0 +1,599 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Unisoc IOMMU driver
+ *
+ * Copyright (C) 2020 Unisoc, Inc.
+ * Author: Chunyan Zhang 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SPRD_IOMMU_PAGE_SHIFT  12
+#define SPRD_IOMMU_PAGE_SIZE   SZ_4K
+
+#define SPRD_EX_CFG0x0
+#define SPRD_IOMMU_VAOR_BYPASS BIT(4)
+#define SPRD_IOMMU_GATE_EN BIT(1)
+#define SPRD_IOMMU_EN  BIT(0)
+#define SPRD_EX_UPDATE 0x4
+#define SPRD_EX_FIRST_VPN  0x8
+#define SPRD_EX_VPN_RANGE  0xc
+#define SPRD_EX_FIRST_PPN  0x10
+#define SPRD_EX_DEFAULT_PPN0x14
+
+#define SPRD_IOMMU_VERSION 0x0
+#define SPRD_VERSION_MASK  GENMASK(15, 8)
+#define SPRD_VERSION_SHIFT 0x8
+#define SPRD_VAU_CFG   0x4
+#define SPRD_VAU_UPDATE0x8
+#define SPRD_VAU_AUTH_CFG  0xc
+#define SPRD_VAU_FIRST_PPN 0x10
+#define SPRD_VAU_DEFAULT_PPN_RD0x14
+#define SPRD_VAU_DEFAULT_PPN_WR0x18
+#define SPRD_VAU_FIRST_VPN 0x1c
+#define SPRD_VAU_VPN_RANGE 0x20
+
+enum sprd_iommu_version {
+   SPRD_IOMMU_EX,
+   SPRD_IOMMU_VAU,
+};
+
+/*
+ * struct sprd_iommu_device - high-level sprd IOMMU device representation,
+ * including hardware information and configuration, also driver data, etc
+ *
+ * @ver: sprd IOMMU IP version
+ * @prot_page_va: protect page base virtual address
+ * @prot_page_pa: protect page base physical address, data would be
+ *   written to here while translation fault
+ * @base: mapped base address for accessing registers
+ * @reg_offset: some IOMMU shares the same range of registers with the 
multimedia
+ * device which use it, this represents the IOMMU register offset
+ * @dev: pointer to basic device structure
+ * @iommu: IOMMU core representation
+ * @group: IOMMU group
+ * @eb: gate clock which controls IOMMU access
+ */
+struct sprd_iommu_device {
+   enum sprd_iommu_version ver;
+   u32 *prot_page_va;
+   dma_addr_t  prot_page_pa;
+   struct regmap   *base;
+   unsigned intreg_offset;
+   struct device   *dev;
+   struct iommu_device iommu;
+   struct iommu_group  *group;
+   struct clk  *eb;
+};
+
+struct sprd_iommu_domain {
+   spinlock_t  pgtlock; /* lock for page table */
+   struct iommu_domain domain;
+   u32 *pgt_va; /* page table virtual address base */
+   dma_addr_t  pgt_pa; /* page table physical address base */
+   struct sprd_iommu_device*sdev;
+};
+
+static const struct iommu_ops sprd_iommu_ops;
+
+static struct sprd_iommu_domain *to_sprd_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct sprd_iommu_domain, domain);
+}
+
+static inline void
+sprd_iommu_write(struct sprd_iommu_device *sdev, unsigned int reg, u32 val)
+{
+   regmap_write(sdev->base, sdev->reg_offset + reg, val);
+}
+
+static inline u32
+sprd_iommu_read(struct

Re: [PATCH 03/14] cxl/mem: Find device capabilities

2021-02-03 Thread Christoph Hellwig

On Wed, Feb 03, 2021 at 01:23:31PM -0800, Dan Williams wrote:
> > I'd prefer to keep the helpers for now as I do find them helpful, and so far
> > nobody else who has touched the code has complained. If you feel strongly, I
> > will change it.
> 
> After seeing the options, I think I'd prefer to not have to worry what
> extra magic is happening with cxl_read_mbox_reg32()
> 
> cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CAPS_OFFSET);
> 
> readl(cxlm->mbox_regs + CXLDEV_MB_CAPS_OFFSET);
> 
> The latter is both shorter and more idiomatic.

Same here.  That being said I know some driver maintainers like
wrappers, my real main irk was the macro magic to generate them.

Re: [PATCH] platform/chrome: cros_ec_typec: Decouple partner removal

2021-02-03 Thread Benson Leung

Hi Prashant,

On Tue, 2 Feb 2021 14:40:01 -0800, Prashant Malani wrote:
> Currently, we return if there is no partner present when
> !PD_CTRL_RESP_ENABLED_CONNECTED, without proceeding further. This ties
> partner removal to cable removal, whereas the two should be independent.
> 
> Update the check to remove a partner if one was registered, but continue
> after that instead of returning.

Applied to for-kernelci, thanks!

[1/1] platform/chrome: cros_ec_typec: Decouple partner removal
  commit: d9f12f9e6c3695c32e681e9d266c4dc1c9016f66

Best regards,
-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[PATCH v4 1/2] dt-bindings: iommu: add bindings for sprd IOMMU

2021-02-03 Thread Chunyan Zhang

From: Chunyan Zhang 

This IOMMU module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.

Signed-off-by: Chunyan Zhang 
---
 .../devicetree/bindings/iommu/sprd,iommu.yaml | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml

diff --git a/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml 
b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
new file mode 100644
index ..36abd2187a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright 2020 Unisoc Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iommu/sprd,iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Unisoc IOMMU and Multi-media MMU
+
+maintainers:
+  - Chunyan Zhang 
+
+properties:
+  compatible:
+enum:
+  - sprd,iommu-v1
+
+  "#iommu-cells":
+const: 0
+description:
+  Unisoc IOMMUs are all single-master IOMMU devices, therefore no
+  additional information needs to associate with its master device.
+  Please refer to the generic bindings document for more details,
+  Documentation/devicetree/bindings/iommu/iommu.txt
+
+  reg:
+maxItems: 1
+description:
+  Not required if 'sprd,iommu-regs' is defined.
+
+  clocks:
+description:
+  Reference to a gate clock phandle, since access to some of IOMMUs are
+  controlled by gate clock, but this is not required.
+
+  sprd,iommu-regs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description:
+  Reference to a syscon phandle plus 1 cell, the syscon defines the
+  register range used by IOMMU and multimedia device, the cell
+  defines the offset for IOMMU registers. Since IOMMU module shares
+  the same register range with the multimedia device which uses it.
+
+required:
+  - compatible
+  - "#iommu-cells"
+
+oneOf:
+  - required:
+  - reg
+  - required:
+  - sprd,iommu-regs
+
+additionalProperties: false
+
+examples:
+  - |
+iommu_disp: iommu-disp {
+  compatible = "sprd,iommu-v1";
+  sprd,iommu-regs = <_regs 0x800>;
+  #iommu-cells = <0>;
+};
+
+  - |
+iommu_jpg: iommu-jpg {
+  compatible = "sprd,iommu-v1";
+  sprd,iommu-regs = <_regs 0x300>;
+  #iommu-cells = <0>;
+  clocks = <_gate 1>;
+};
+
+...
-- 
2.25.1

[PATCH v4 0/2] Add Unisoc IOMMU basic driver

2021-02-03 Thread Chunyan Zhang

From: Chunyan Zhang 

Changes since v3:
* Rebased on iommu/next, and fixed compile error reported by kernel test robot 
;
* %s/iommu/IOMMU/ properly in the whole patchset.

Changes since v2:
* Added a WARN and return 0 if an invalid iova was passed to 
sprd_iommu_iova_to_phys();
* Changed the name of sprd_iommu_write();
* Revised CONFIG_SPRD_IOMMU help graph in Kconfig.
* Revised comments for the struct sprd_iommu_device;
* Converted to use "GPL" instread of "GPL v2", they are same as 
license-rules.rst shows.

Changes since v1:
* Fixed compile errors reported by kernel test robot .
* Changed to use syscon to get mapped registers for iommu and media devices to 
avoid double map issue.
* Addressed Robin's comments:
- Added including offset in the returned physical address if the input virtual 
address isn't page-aligned;
- Added platform_device_put() after calling of_find_device_by_node();
- Removed iommu register offset from driver, it will be defined as the cell of 
DT reference to syscon phandle;
- Removed multi compatible strings which are not needed;
- Added comments for the function sprd_iommu_clk_enable();
- Added clocks property in bindings;
- Set device_driver.suppress_bind_attrs to disable unbind the devices via sysfs;
- A few trivial fixes.

Changes since RFC v2:
* Addressed Robin's comments:
- Add COMPILE_TEST support;
- Use DMA allocator for PTE;
- Revised to avoid resource leak issue;
- Added ->iotlb_sync implemented;
- Moved iommu group allocation to probe;
- Changed some function names to make them sprd specific;
* Added support for more iommu instance;

Changes since RFC v1:
* Rebased on v5.11-rc1;
* Changed sprd-iommu to tristate;
* Removed check for args_count of iommu OF node, since there's no args
  for sprd-iommu device node;
* Added another IP version (i.e. vau);
* Removed unnecessary configs selection from CONFIG_SPRD_IOMMU;
* Changed to get zeroed pages.

Chunyan Zhang (2):
  dt-bindings: iommu: add bindings for sprd IOMMU
  iommu: add Unisoc IOMMU basic driver

 .../devicetree/bindings/iommu/sprd,iommu.yaml |  72 +++
 drivers/iommu/Kconfig |  12 +
 drivers/iommu/Makefile|   1 +
 drivers/iommu/sprd-iommu.c| 599 ++
 4 files changed, 684 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml
 create mode 100644 drivers/iommu/sprd-iommu.c

-- 
2.25.1

[next] Unable to handle kernel NULL pointer dereference at - pc : gpiodevice_release

2021-02-03 Thread Naresh Kamboju

While running kselftest gpio mockup test case on qualcomm dragonboard 410c
the following kernel crash reported on Linux next tag 20210203.

# selftests: gpio: gpio-mockup.sh
# 1.  Module load tests
# 1.1.  dynamic allocation of gpio
# ./gpio-mockup.sh: line 106: ./gpio-mockup-cdev: No such file or directory
# test failed: line value is 127 when 1 was expected
# GPIO gpio-mockup test FAIL
[  124.539778] Unable to handle kernel NULL pointer dereference at
virtual address 05a8
[  124.539864] Mem abort info:
[  124.547998]   ESR = 0x9606
[  124.550188]   EC = 0x25: DABT (current EL), IL = 32 bits
[  124.553473]   SET = 0, FnV = 0
[  124.558926]   EA = 0, S1PTW = 0
[  124.561646] Data abort info:
[  124.564863]   ISV = 0, ISS = 0x0006
[  124.567933]   CM = 0, WnR = 0
[  124.571507] user pgtable: 4k pages, 48-bit VAs, pgdp=8b721000
[  124.574694] [05a8] pgd=91cd2003,
p4d=91cd2003, pud=917ac003, pmd=
[  124.581396] Internal error: Oops: 9606 [#1] PREEMPT SMP
[  124.591499] Modules linked in: gpio_mockup(-) snd_soc_hdmi_codec
adv7511 cec rfkill snd_soc_msm8916_analog qcom_spmi_temp_alarm
qcom_pon rtc_pm8xxx msm snd_soc_lpass_apq8016 snd_soc_lpass_cpu
snd_soc_lpass_platform snd_soc_msm8916_digital qcom_camss
videobuf2_dma_sg snd_soc_apq8016_sbc v4l2_fwnode snd_soc_qcom_common
videobuf2_memops videobuf2_v4l2 mdt_loader videobuf2_common
drm_kms_helper qnoc_msm8916 qcom_rng i2c_qcom_cci icc_smd_rpm
crct10dif_ce socinfo rmtfs_mem display_connector drm qrtr ns fuse
[  124.619092] CPU: 0 PID: 5055 Comm: modprobe Not tainted
5.11.0-rc6-next-20210203 #1
[  124.641324] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[  124.648877] pstate: 8005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[  124.655819] pc : gpiodevice_release+0x38/0x80
[  124.661806] lr : device_release+0x3c/0x98
[  124.666058] sp : 800013f23b30
[  124.670051] x29: 800013f23b30 x28: 157baf80
[  124.673351] x27:  x26: 
[  124.678734] x25: 0045 x24: 0b5d6cd0
[  124.684029] x23: 800013f23c88 x22: 
[  124.689324] x21: 0fb5f080 x20: 02334e00
[  124.694619] x19:  x18: 800012dd6a50
[  124.699914] x17:  x16: 
[  124.705210] x15: 000694e0 x14: 
[  124.710512] x13: 0001 x12: e107
[  124.715799] x11: e10a x10: 800012d34a50
[  124.721096] x9 : 80001344a000 x8 : 512c1926
[  124.726391] x7 : 0cb44760 x6 : 800013f23a40
[  124.731685] x5 : dead0100 x4 : dead0122
[  124.736981] x3 : 800012891000 x2 : 2be62a0e7519e400
[  124.742275] x1 : 800010829ad0 x0 : 800012a694e0
[  124.747571] Call trace:
[  124.752862]  gpiodevice_release+0x38/0x80
[  124.755035]  device_release+0x3c/0x98
[  124.759201]  kobject_put+0x90/0x220
[  124.762846]  put_device+0x24/0x30
[  124.766145]  gpiochip_remove+0xf4/0x120
[  124.769618]  devm_gpio_chip_release+0x20/0x30
[  124.773263]  devm_action_release+0x20/0x30
[  124.77]  release_nodes+0x150/0x248
[  124.781771]  devres_release_all+0x3c/0x60
[  124.785503]  device_release_driver_internal+0x128/0x1f0
[  124.789584]  driver_detach+0x5c/0xe8
[  124.794618]  bus_remove_driver+0x64/0x118
[  124.798439]  driver_unregister+0x34/0x60
[  124.802344]  platform_driver_unregister+0x20/0x30
[  124.806339]  gpio_mockup_exit+0x30/0x3d0 [gpio_mockup]
[  124.810939]  __arm64_sys_delete_module+0x1c8/0x2b8
[  124.815973]  el0_svc_common+0x88/0x1b8
[  124.820745]  do_el0_svc+0x38/0x90
[  124.824478]  el0_svc+0x1c/0x28
[  124.827864]  el0_sync_handler+0x8c/0xb0
[  124.830815]  el0_sync+0x13c/0x140
[  124.834555] Code: f2fbd5a4 90011200 91124000 91014000 (f942d663)
[  124.838029] ---[ end trace 15e9a0840604e538 ]---

Reported-by: Naresh Kamboju 

full test log link,
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210203/testrun/3878290/suite/linux-log-parser/test/check-kernel-oops-2224485/log

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
  git describe: next-20210203
  kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/config
  build: 
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/
vmlinux: 
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-next/952/vmlinux


-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 1/3] kunit: add kunit.filter_glob cmdline option to filter suites

Hi Daniel,

url:
https://github.com/0day-ci/linux/commits/Daniel-Latypov/kunit-support-running-subsets-of-test-suites-from/20210204-074405
base:   88bb507a74ea7d75fa49edd421eaa710a7d80598
config: x86_64-randconfig-m001-20210202 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
lib/kunit/executor.c:110 kunit_run_all_tests() error: double free of 
'suite_set.start'

vim +110 lib/kunit/executor.c

8c0d884986ba22 Brendan Higgins 2020-08-04   96  int kunit_run_all_tests(void)
aac35468ca20a3 Alan Maguire2020-08-04   97  {
aac35468ca20a3 Alan Maguire2020-08-04   98  struct kunit_suite * 
const * const *suites;
aac35468ca20a3 Alan Maguire2020-08-04   99  
d5554dd78a454b Daniel Latypov  2021-02-03  100  struct suite_set 
suite_set = kunit_filter_suites();
45dcbb6f5ef78b Brendan Higgins 2020-08-04  101  
d5554dd78a454b Daniel Latypov  2021-02-03  102  
kunit_print_tap_header(_set);
d5554dd78a454b Daniel Latypov  2021-02-03  103  
d5554dd78a454b Daniel Latypov  2021-02-03  104  for (suites = 
suite_set.start; suites < suite_set.end; suites++)
aac35468ca20a3 Alan Maguire2020-08-04  105  
__kunit_test_suites_init(*suites);
aac35468ca20a3 Alan Maguire2020-08-04  106  
d5554dd78a454b Daniel Latypov  2021-02-03  107  if (filter_glob) { /* a 
copy was made of each array */
d5554dd78a454b Daniel Latypov  2021-02-03  108  for (suites = 
suite_set.start; suites < suite_set.end; suites++)
 

This will free "suite_set.start" will in the first iteration through the
loop

d5554dd78a454b Daniel Latypov  2021-02-03  109  
kfree(suites);
d5554dd78a454b Daniel Latypov  2021-02-03 @110  
kfree(suite_set.start);
  
^^^
and then double free it.

d5554dd78a454b Daniel Latypov  2021-02-03  111  }
d5554dd78a454b Daniel Latypov  2021-02-03  112  
aac35468ca20a3 Alan Maguire2020-08-04  113  return 0;
aac35468ca20a3 Alan Maguire2020-08-04  114  }

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


.config.gz
Description: application/gzip

[PATCH] crypto: cavium: remove casting dma_alloc_coherent

2021-02-03 Thread Xu Wang

Remove casting the values returned by dma_alloc_coherent.

Signed-off-by: Xu Wang 
---
 drivers/crypto/cavium/cpt/cptvf_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c 
b/drivers/crypto/cavium/cpt/cptvf_main.c
index f016448e43bb..112b12a32542 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -233,10 +233,10 @@ static int alloc_command_queues(struct cpt_vf *cptvf,
 
c_size = (rem_q_size > qcsize_bytes) ? qcsize_bytes :
rem_q_size;
-   curr->head = (u8 *)dma_alloc_coherent(>dev,
- c_size + 
CPT_NEXT_CHUNK_PTR_SIZE,
- >dma_addr,
- GFP_KERNEL);
+   curr->head = dma_alloc_coherent(>dev,
+   c_size + 
CPT_NEXT_CHUNK_PTR_SIZE,
+   >dma_addr,
+   GFP_KERNEL);
if (!curr->head) {
dev_err(>dev, "Command Q (%d) chunk (%d) 
allocation failed\n",
i, queue->nchunks);
-- 
2.17.1

Re: [PATCH v15 04/14] KVM: x86: Add #CP support in guest exception dispatch

2021-02-03 Thread Yang Weijiang

On Wed, Feb 03, 2021 at 01:46:42PM -0800, Sean Christopherson wrote:
> On Wed, Feb 03, 2021, Yang Weijiang wrote:
> > Add handling for Control Protection (#CP) exceptions, vector 21, used
> > and introduced by Intel's Control-Flow Enforcement Technology (CET).
> > relevant CET violation case.  See Intel's SDM for details.
> > 
> > Signed-off-by: Yang Weijiang 
> > ---
> >  arch/x86/include/uapi/asm/kvm.h | 1 +
> >  arch/x86/kvm/x86.c  | 1 +
> >  arch/x86/kvm/x86.h  | 2 +-
> >  3 files changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/include/uapi/asm/kvm.h 
> > b/arch/x86/include/uapi/asm/kvm.h
> > index 8e76d3701db3..507263d1d0b2 100644
> > --- a/arch/x86/include/uapi/asm/kvm.h
> > +++ b/arch/x86/include/uapi/asm/kvm.h
> > @@ -32,6 +32,7 @@
> >  #define MC_VECTOR 18
> >  #define XM_VECTOR 19
> >  #define VE_VECTOR 20
> > +#define CP_VECTOR 21
> >  
> >  /* Select x86 specific features in  */
> >  #define __KVM_HAVE_PIT
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 99f787152d12..d9d3bae40a8c 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -436,6 +436,7 @@ static int exception_class(int vector)
> > case NP_VECTOR:
> > case SS_VECTOR:
> > case GP_VECTOR:
> > +   case CP_VECTOR:
> > return EXCPT_CONTRIBUTORY;
> > default:
> > break;
> > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> > index c5ee0f5ce0f1..bdbd0b023ecc 100644
> > --- a/arch/x86/kvm/x86.h
> > +++ b/arch/x86/kvm/x86.h
> > @@ -116,7 +116,7 @@ static inline bool 
> > x86_exception_has_error_code(unsigned int vector)
> >  {
> > static u32 exception_has_error_code = BIT(DF_VECTOR) | BIT(TS_VECTOR) |
> > BIT(NP_VECTOR) | BIT(SS_VECTOR) | BIT(GP_VECTOR) |
> > -   BIT(PF_VECTOR) | BIT(AC_VECTOR);
> > +   BIT(PF_VECTOR) | BIT(AC_VECTOR) | BIT(CP_VECTOR);
> 
> These need to be conditional on CET being exposed to the guest.  TBD 
> exceptions
> are non-contributory and don't have an error code.  Found when running unit
> tests in L1 with a kvm/queue as L1, but an older L0.  cr4_guest_rsvd_bits can 
> be
> used to avoid guest_cpuid_has() lookups.
> 
> The SDM also gets this wrong.  Section 26.2.1.3, VM-Entry Control Fields, 
> needs
> to be updated to add #CP to the list.
> 
>   — The field's deliver-error-code bit (bit 11) is 1 if each of the following
> holds: (1) the interruption type is hardware exception; (2) bit 0
> (corresponding to CR0.PE) is set in the CR0 field in the guest-state area;
> (3) IA32_VMX_BASIC[56] is read as 0 (see Appendix A.1); and (4) the vector
> indicates one of the following exceptions: #DF (vector 8), #TS (10),
> #NP (11), #SS (12), #GP (13), #PF (14), or #AC (17).
> 
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index dbca1687ae8e..0b6dab6915a3 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -2811,7 +2811,7 @@ static int nested_check_vm_entry_controls(struct 
> kvm_vcpu *vcpu,
> /* VM-entry interruption-info field: deliver error code */
> should_have_error_code =
> intr_type == INTR_TYPE_HARD_EXCEPTION && prot_mode &&
> -   x86_exception_has_error_code(vector);
> +   x86_exception_has_error_code(vcpu, vector);
> if (CC(has_error_code != should_have_error_code))
> return -EINVAL;
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 28fea7ff7a86..0288d6a364bd 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -437,17 +437,20 @@ EXPORT_SYMBOL_GPL(kvm_spurious_fault);
>  #define EXCPT_CONTRIBUTORY 1
>  #define EXCPT_PF   2
> 
> -static int exception_class(int vector)
> +static int exception_class(struct kvm_vcpu *vcpu, int vector)
>  {
> switch (vector) {
> case PF_VECTOR:
> return EXCPT_PF;
> +   case CP_VECTOR:
> +   if (vcpu->arch.cr4_guest_rsvd_bits & X86_CR4_CET)
> +   return EXCPT_BENIGN;
> +   return EXCPT_CONTRIBUTORY;
> case DE_VECTOR:
> case TS_VECTOR:
> case NP_VECTOR:
> case SS_VECTOR:
> case GP_VECTOR:
> -   case CP_VECTOR:
> return EXCPT_CONTRIBUTORY;
> default:
> break;
> @@ -588,8 +591,8 @@ static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
> kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> return;
> }
> -   class1 = exception_class(prev_nr);
> -   class2 = exception_class(nr);
> +   class1 = exception_class(vcpu, prev_nr);
> +   class2 = exception_class(vcpu, nr);
> if ((class1 == EXCPT_CONTRIBUTORY && class2 == EXCPT_CONTRIBUTORY)
> || (class1 == EXCPT_PF && class2 != EXCPT_BENIGN)) {
> /*
> diff --git

[PATCH] mmc: cavium: Replace spin_lock_irqsave with spin_lock in hard IRQ

2021-02-03 Thread Xiaofei Tan

It is redundant to do irqsave and irqrestore in hardIRQ context, where
it has been in a irq-disabled context.

Signed-off-by: Xiaofei Tan 
---
 drivers/mmc/host/cavium.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
index c5da3aa..4bb8f28 100644
--- a/drivers/mmc/host/cavium.c
+++ b/drivers/mmc/host/cavium.c
@@ -436,12 +436,11 @@ irqreturn_t cvm_mmc_interrupt(int irq, void *dev_id)
 {
struct cvm_mmc_host *host = dev_id;
struct mmc_request *req;
-   unsigned long flags = 0;
u64 emm_int, rsp_sts;
bool host_done;
 
if (host->need_irq_handler_lock)
-   spin_lock_irqsave(>irq_handler_lock, flags);
+   spin_lock(>irq_handler_lock);
else
__acquire(>irq_handler_lock);
 
@@ -504,7 +503,7 @@ irqreturn_t cvm_mmc_interrupt(int irq, void *dev_id)
host->release_bus(host);
 out:
if (host->need_irq_handler_lock)
-   spin_unlock_irqrestore(>irq_handler_lock, flags);
+   spin_unlock(>irq_handler_lock);
else
__release(>irq_handler_lock);
return IRQ_RETVAL(emm_int != 0);
-- 
2.8.1

[PATCH v4 2/2] nbd: share exception handling code by goto put_nbd

2021-02-03 Thread Sun Ke

Replace the following two statements by the statement “goto put_nbd;”

nbd_put(nbd);
return 0;

Signed-off-by: Sun Ke 
---
 drivers/block/nbd.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 3c9b3bf3f4c2..ecae81e43122 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -2029,12 +2029,11 @@ static int nbd_genl_disconnect(struct sk_buff *skb, 
struct genl_info *info)
}
mutex_unlock(>config_lock);
mutex_unlock(_index_mutex);
-   if (!refcount_inc_not_zero(>config_refs)) {
-   nbd_put(nbd);
-   return 0;
-   }
+   if (!refcount_inc_not_zero(>config_refs))
+   goto put_nbd;
nbd_disconnect_and_put(nbd);
nbd_config_put(nbd);
+put_nbd:
nbd_put(nbd);
return 0;
 }
-- 
2.25.4

[PATCH v4 1/2] nbd: Fix NULL pointer in flush_workqueue

2021-02-03 Thread Sun Ke

Open /dev/nbdX first, the config_refs will be 1 and
the pointers in nbd_device are still null. Disconnect
/dev/nbdX, then reference a null recv_workq. The
protection by config_refs in nbd_genl_disconnect is useless.

[  656.366194] BUG: kernel NULL pointer dereference, address: 0020
[  656.368943] #PF: supervisor write access in kernel mode
[  656.369844] #PF: error_code(0x0002) - not-present page
[  656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0
[  656.371693] Oops: 0002 [#1] SMP
[  656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 
5.11.0-rc5-00040-g76c057c84d28 #1
[  656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[  656.375904] RIP: 0010:mutex_lock+0x29/0x60
[  656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 
7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00  48 0f 
b1 55 d
[  656.378934] RSP: 0018:c95eb9b0 EFLAGS: 00010246
[  656.379350] RAX:  RBX:  RCX: 
[  656.379915] RDX: 888104cf2600 RSI: aae8f452 RDI: 0020
[  656.380473] RBP: 0020 R08:  R09: 88813bd6b318
[  656.381039] R10: 00c7 R11: fefefefefefefeff R12: 888102710b40
[  656.381599] R13: c95eb9e0 R14: b2930680 R15: 88810770ef00
[  656.382166] FS:  7fdf117ebb40() GS:88813bd4() 
knlGS:
[  656.382806] CS:  0010 DS:  ES:  CR0: 80050033
[  656.383261] CR2: 0020 CR3: 000100c84000 CR4: 06e0
[  656.383819] DR0:  DR1:  DR2: 
[  656.384370] DR3:  DR6: fffe0ff0 DR7: 0400
[  656.384927] Call Trace:
[  656.385111]  flush_workqueue+0x92/0x6c0
[  656.385395]  nbd_disconnect_and_put+0x81/0xd0
[  656.385716]  nbd_genl_disconnect+0x125/0x2a0
[  656.386034]  genl_family_rcv_msg_doit.isra.0+0x102/0x1b0
[  656.386422]  genl_rcv_msg+0xfc/0x2b0
[  656.386685]  ? nbd_ioctl+0x490/0x490
[  656.386954]  ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0
[  656.387354]  netlink_rcv_skb+0x62/0x180
[  656.387638]  genl_rcv+0x34/0x60
[  656.387874]  netlink_unicast+0x26d/0x590
[  656.388162]  netlink_sendmsg+0x398/0x6c0
[  656.388451]  ? netlink_rcv_skb+0x180/0x180
[  656.388750]  sys_sendmsg+0x1da/0x320
[  656.389038]  ? sys_recvmsg+0x130/0x220
[  656.389334]  ___sys_sendmsg+0x8e/0xf0
[  656.389605]  ? ___sys_recvmsg+0xa2/0xf0
[  656.389889]  ? handle_mm_fault+0x1671/0x21d0
[  656.390201]  __sys_sendmsg+0x6d/0xe0
[  656.390464]  __x64_sys_sendmsg+0x23/0x30
[  656.390751]  do_syscall_64+0x45/0x70
[  656.391017]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs")
Signed-off-by: Sun Ke 
---
v4: Share exception handling code for if branches
v3: Do not use unlock and add put_nbd.
v2: Use jump target unlock.
---
 drivers/block/nbd.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e6ea5d344f87..3c9b3bf3f4c2 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -2014,17 +2014,20 @@ static int nbd_genl_disconnect(struct sk_buff *skb, 
struct genl_info *info)
mutex_lock(_index_mutex);
nbd = idr_find(_index_idr, index);
if (!nbd) {
-   mutex_unlock(_index_mutex);
printk(KERN_ERR "nbd: couldn't find device at index %d\n",
   index);
-   return -EINVAL;
+   goto unlock_index;
}
-   if (!refcount_inc_not_zero(>refs)) {
-   mutex_unlock(_index_mutex);
+   mutex_lock(>config_lock);
+   if (!refcount_inc_not_zero(>refs) || !nbd->recv_workq) {
+   mutex_unlock(>config_lock);
printk(KERN_ERR "nbd: device at index %d is going down\n",
   index);
+unlock_index:
+   mutex_unlock(_index_mutex);
return -EINVAL;
}
+   mutex_unlock(>config_lock);
mutex_unlock(_index_mutex);
if (!refcount_inc_not_zero(>config_refs)) {
nbd_put(nbd);
-- 
2.25.4

[PATCH v4 0/2] fix a NULL pointer bug and simplify the code

2021-02-03 Thread Sun Ke

v4: Share exception handling code for if branches and 
move put_nbd adjustment to a separate patch.
v3: Do not use unlock and add put_nbd.
v2: Use jump target unlock.

Sun Ke (2):
  nbd: Fix NULL pointer in flush_workqueue
  nbd: share exception handling code by goto put_nbd

 drivers/block/nbd.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

-- 
2.25.4

Re: [PATCH v5 3/3] PM / devfreq: Add required OPPs support to passive governor

2021-02-03 Thread Hsin-Yi Wang

On Thu, Feb 4, 2021 at 10:49 AM Viresh Kumar  wrote:
>
> On 03-02-21, 17:24, Hsin-Yi Wang wrote:
> > From: Saravana Kannan 
> >
> > Look at the required OPPs of the "parent" device to determine the OPP that
> > is required from the slave device managed by the passive governor. This
> > allows having mappings between a parent device and a slave device even when
> > they don't have the same number of OPPs.
> >
> > Signed-off-by: Saravana Kannan 
> > Acked-by: MyungJoo Ham 
> > Acked-by: Chanwoo Choi 
> > Signed-off-by: Hsin-Yi Wang 
> > ---
> >  drivers/devfreq/governor_passive.c | 20 +++-
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/devfreq/governor_passive.c 
> > b/drivers/devfreq/governor_passive.c
> > index 63332e4a65ae8..8d92b1964f9c3 100644
> > --- a/drivers/devfreq/governor_passive.c
> > +++ b/drivers/devfreq/governor_passive.c
> > @@ -19,7 +19,7 @@ static int devfreq_passive_get_target_freq(struct devfreq 
> > *devfreq,
> >   = (struct devfreq_passive_data *)devfreq->data;
> >   struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
> >   unsigned long child_freq = ULONG_MAX;
> > - struct dev_pm_opp *opp;
> > + struct dev_pm_opp *opp = NULL, *p_opp = NULL;
>
> I would initialize p_opp to ERR_PTR(-ENODEV) to avoid using
> IS_ERR_OR_NULL. There is no need to initialize opp as well.
>
> >   int i, count, ret = 0;
> >
> >   /*
> > @@ -56,13 +56,20 @@ static int devfreq_passive_get_target_freq(struct 
> > devfreq *devfreq,
> >* list of parent device. Because in this case, *freq is temporary
> >* value which is decided by ondemand governor.
> >*/
> > - opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> > - if (IS_ERR(opp)) {
> > - ret = PTR_ERR(opp);
> > + p_opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> > + if (IS_ERR(p_opp)) {
> > + ret = PTR_ERR(p_opp);
> >   goto out;
>
> Perhaps just return from here, the goto is useless here.
>
> >   }
> >
> > - dev_pm_opp_put(opp);
> > + if (devfreq->opp_table && parent_devfreq->opp_table)
> > + opp = dev_pm_opp_xlate_required_opp(parent_devfreq->opp_table,
> > + devfreq->opp_table, 
> > p_opp);
> > + if (opp) {
>
> This needs to be part of the above if block itself, else the opp will
> always be NULL, isn't it ?
>
> > + *freq = dev_pm_opp_get_freq(opp);
> > + dev_pm_opp_put(opp);
> > + goto out;
> > + }
> >
> >   /*
> >* Get the OPP table's index of decided freqeuncy by governor
> > @@ -89,6 +96,9 @@ static int devfreq_passive_get_target_freq(struct devfreq 
> > *devfreq,
> >   *freq = child_freq;
> >
> >  out:
> > + if (!IS_ERR_OR_NULL(opp))
>
> you should be checking for p_opp here, isn't it ? And perhaps we don't
> need this check as well as p_opp can't be invalid here.
>
> > + dev_pm_opp_put(p_opp);
> > +
> >   return ret;
> >  }
> >
> > --
> > 2.30.0.365.g02bc693789-goog
>
Thanks for the review. I'll fix them and send next version

> --
> viresh

Re: [PATCH 1/2] dt-bindings: phy: qcom,qmp: Add SC8180X USB phy

On 20-01-21, 17:43, Bjorn Andersson wrote:
> Add compatibles for the Qualcomm QMP PHY binding for the SuperSpeed USB
> phys found in the SC8180x platform.

Applied, thanks

-- 
~Vinod

Re: [PATCH 1/2] dt-bindings: phy: qcom,qmp: Add SC8180X UFS to the QMP binding

On 20-01-21, 14:45, Bjorn Andersson wrote:
> Add compatible for the SC8180x UFS PHY to the QMP binding.

Applied, thanks

-- 
~Vinod

Re: [PATCH] vdpa/mlx5: Restore the hardware used index after change map

On Wed, Feb 03, 2021 at 12:33:26PM -0800, Si-Wei Liu wrote:
> On Tue, Feb 2, 2021 at 10:48 PM Eli Cohen  wrote:
> >
> > On Tue, Feb 02, 2021 at 09:14:02AM -0800, Si-Wei Liu wrote:
> > > On Tue, Feb 2, 2021 at 6:34 AM Eli Cohen  wrote:
> > > >
> > > > When a change of memory map occurs, the hardware resources are destroyed
> > > > and then re-created again with the new memory map. In such case, we need
> > > > to restore the hardware available and used indices. The driver failed to
> > > > restore the used index which is added here.
> > > >
> > > > Fixes 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 
> > > > devices")
> > > > Signed-off-by: Eli Cohen 
> > > > ---
> > > > This patch is being sent again a single patch the fixes hot memory
> > > > addtion to a qemy process.
> > > >
> > > >  drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index 88dde3455bfd..839f57c64a6f 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
> > > > u64 device_addr;
> > > > u64 driver_addr;
> > > > u16 avail_index;
> > > > +   u16 used_index;
> > > > bool ready;
> > > > struct vdpa_callback cb;
> > > > bool restore;
> > > > @@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
> > > > u32 virtq_id;
> > > > struct mlx5_vdpa_net *ndev;
> > > > u16 avail_idx;
> > > > +   u16 used_idx;
> > > > int fw_state;
> > > >
> > > > /* keep last in the struct */
> > > > @@ -804,6 +806,7 @@ static int create_virtqueue(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtque
> > > >
> > > > obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, 
> > > > obj_context);
> > > > MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, 
> > > > mvq->avail_idx);
> > > > +   MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, 
> > > > mvq->used_idx);
> > >
> > > The saved indexes will apply to the new virtqueue object whenever it
> > > is created. In virtio spec, these indexes will reset back to zero when
> > > the virtio device is reset. But I don't see how it's done today. IOW,
> > > I don't see where avail_idx and used_idx get cleared from the mvq for
> > > device reset via set_status().
> > >
> >
> > Right, but this is not strictly related to this patch. I will post
> > another patch to fix this.
> 
> Better to post these two patches in a series.Or else it may cause VM
> reboot problem as that is where the device gets reset. The avail_index
> did not as the correct value will be written to by driver right after,
> but used_idx introduced by this patch is supplied by device hence this
> patch alone would introduce regression.
> 

OK, will do.

> >
> > BTW, can you describe a secnario that would cause a reset (through
> > calling set_status()) that happens after the VQ has been used?
> 
> You can try reboot the guest, that'll be the easy way to test.
> 

Thanks!

> -Siwei
> 
> >
> > > -Siwei
> > >
> > >
> > > > MLX5_SET(virtio_net_q_object, obj_context, 
> > > > queue_feature_bit_mask_12_3,
> > > >  get_features_12_3(ndev->mvdev.actual_features));
> > > > vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, 
> > > > virtio_q_context);
> > > > @@ -1022,6 +1025,7 @@ static int connect_qps(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqueue *m
> > > >  struct mlx5_virtq_attr {
> > > > u8 state;
> > > > u16 available_index;
> > > > +   u16 used_index;
> > > >  };
> > > >
> > > >  static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct 
> > > > mlx5_vdpa_virtqueue *mvq,
> > > > @@ -1052,6 +1056,7 @@ static int query_virtqueue(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqueu
> > > > memset(attr, 0, sizeof(*attr));
> > > > attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
> > > > attr->available_index = MLX5_GET(virtio_net_q_object, 
> > > > obj_context, hw_available_index);
> > > > +   attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, 
> > > > hw_used_index);
> > > > kfree(out);
> > > > return 0;
> > > >
> > > > @@ -1610,6 +1615,7 @@ static int save_channel_info(struct mlx5_vdpa_net 
> > > > *ndev, struct mlx5_vdpa_virtqu
> > > > return err;
> > > >
> > > > ri->avail_index = attr.available_index;
> > > > +   ri->used_index = attr.used_index;
> > > > ri->ready = mvq->ready;
> > > > ri->num_ent = mvq->num_ent;
> > > > ri->desc_addr = mvq->desc_addr;
> > > > @@ -1654,6 +1660,7 @@ static void restore_channels_info(struct 
> > > > mlx5_vdpa_net *ndev)
> > > > continue;
> > > >
> > > > mvq->avail_idx = ri->avail_index;

[PATCH] net: bridge: mcast: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

2021-02-03 Thread Xu Wang

Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).

net/bridge/br_multicast.c:1246:9-16: WARNING: ERR_CAST can be used with mp
Generated by: scripts/coccinelle/api/err_cast.cocci

Signed-off-by: Xu Wang 
---
 net/bridge/br_multicast.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 257ac4e25f6d..dfbb4dd01fa9 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1243,7 +1243,7 @@ __br_multicast_add_group(struct net_bridge *br,
 
mp = br_multicast_new_group(br, group);
if (IS_ERR(mp))
-   return ERR_PTR(PTR_ERR(mp));
+   return ERR_CAST(mp);
 
if (!port) {
br_multicast_host_join(mp, true);
-- 
2.17.1

Re: [PATCH] firewire: convert sysfs sprintf/snprintf family to sysfs_emit

2021-02-03 Thread Joe Perches

On Thu, 2021-02-04 at 14:50 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
> 
> ./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or
> sprintf.
[]
> diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
[]
> @@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev,
>   struct fw_device *device = fw_device(dev->parent);
>   struct fw_unit *unit = fw_unit(dev);
>  
> 
> - return snprintf(buf, PAGE_SIZE, "%d\n",
> - (int)(unit->directory - device->config_rom));
> + return sysfs_emit(buf, "%d\n", (int)(unit->directory - 
> device->config_rom));

Perhaps this should use the ptrdiff_t qualifier '%td' instead:

return sysfs_emit(buf, "%td\n", unit->directory - device->config_rom);

[rcu:willy-maple 164/202] fs/proc/task_mmu.c:941 show_smaps_rollup() error: uninitialized symbol 'vma_start'.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
willy-maple
head:   7e346d2845b4bd77663394f39fa70456e0084c86
commit: c4e6b1dfcb6f997eb870e859ab84ca9f39572eab [164/202] fs/proc/task_mmu: 
Stop using linked list and highest_vm_end
config: x86_64-randconfig-m001-20210202 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
fs/proc/task_mmu.c:941 show_smaps_rollup() error: uninitialized symbol 
'vma_start'.

vim +/vma_start +941 fs/proc/task_mmu.c

258f669e7e88c1 Vlastimil Babka   2018-08-21  839  static int 
show_smaps_rollup(struct seq_file *m, void *v)
258f669e7e88c1 Vlastimil Babka   2018-08-21  840  {
258f669e7e88c1 Vlastimil Babka   2018-08-21  841struct 
proc_maps_private *priv = m->private;
258f669e7e88c1 Vlastimil Babka   2018-08-21  842struct mem_size_stats 
mss;
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  843struct mm_struct *mm = 
priv->mm;
258f669e7e88c1 Vlastimil Babka   2018-08-21  844struct vm_area_struct 
*vma;
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  845unsigned long 
vma_start, last_vma_end = 0;
258f669e7e88c1 Vlastimil Babka   2018-08-21  846int ret = 0;
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  847MA_STATE(mas, 
>mm_mt, 0, 0);
258f669e7e88c1 Vlastimil Babka   2018-08-21  848  
258f669e7e88c1 Vlastimil Babka   2018-08-21  849priv->task = 
get_proc_task(priv->inode);
258f669e7e88c1 Vlastimil Babka   2018-08-21  850if (!priv->task)
258f669e7e88c1 Vlastimil Babka   2018-08-21  851return -ESRCH;
258f669e7e88c1 Vlastimil Babka   2018-08-21  852  
258f669e7e88c1 Vlastimil Babka   2018-08-21  853if (!mm || 
!mmget_not_zero(mm)) {
258f669e7e88c1 Vlastimil Babka   2018-08-21  854ret = -ESRCH;
258f669e7e88c1 Vlastimil Babka   2018-08-21  855goto 
out_put_task;
258f669e7e88c1 Vlastimil Babka   2018-08-21  856}
258f669e7e88c1 Vlastimil Babka   2018-08-21  857  
258f669e7e88c1 Vlastimil Babka   2018-08-21  858memset(, 0, 
sizeof(mss));
258f669e7e88c1 Vlastimil Babka   2018-08-21  859  
d8ed45c5dcd455 Michel Lespinasse 2020-06-08  860ret = 
mmap_read_lock_killable(mm);
a26a9781554857 Konstantin Khlebnikov 2019-07-11  861if (ret)
a26a9781554857 Konstantin Khlebnikov 2019-07-11  862goto out_put_mm;
a26a9781554857 Konstantin Khlebnikov 2019-07-11  863  
258f669e7e88c1 Vlastimil Babka   2018-08-21  864
hold_task_mempolicy(priv);
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  865vma = mas_find(, 0);
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  866  
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  867if (vma)
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  868vma_start = 
vma->vm_start;

"vma_start" not initialized on else path.

258f669e7e88c1 Vlastimil Babka   2018-08-21  869  
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  870mas_set(, 0);
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  871mas_for_each(, vma, 
-1) {
03b4b1149308b0 Chinwen Chang 2020-10-13  872
smap_gather_stats(vma, , 0);
258f669e7e88c1 Vlastimil Babka   2018-08-21  873last_vma_end = 
vma->vm_end;
ff9f47f6f00cfe Chinwen Chang 2020-10-13  874  
ff9f47f6f00cfe Chinwen Chang 2020-10-13  875/*
ff9f47f6f00cfe Chinwen Chang 2020-10-13  876 * Release 
mmap_lock temporarily if someone wants to
ff9f47f6f00cfe Chinwen Chang 2020-10-13  877 * access it 
for write request.
ff9f47f6f00cfe Chinwen Chang 2020-10-13  878 */
ff9f47f6f00cfe Chinwen Chang 2020-10-13  879if 
(mmap_lock_is_contended(mm)) {
c4e6b1dfcb6f99 Liam R. Howlett   2021-01-04  880
mas_pause();
ff9f47f6f00cfe Chinwen Chang 2020-10-13  881
mmap_read_unlock(mm);
ff9f47f6f00cfe Chinwen Chang 2020-10-13  882ret = 
mmap_read_lock_killable(mm);
ff9f47f6f00cfe Chinwen Chang 2020-10-13  883if 
(ret) {
ff9f47f6f00cfe Chinwen Chang 2020-10-13  884
release_task_mempolicy(priv);
ff9f47f6f00cfe Chinwen Chang 2020-10-13  885
goto out_put_mm;
ff9f47f6f00cfe Chinwen Chang 2020-10-13  886}
ff9f47f6f00cfe Chinwen Chang 2020-10-13  887  
ff9f47f6f00cfe Chinwen Chang 2020-10-13  888/*
ff9f47f6f00cfe Chinwen Chang 2020-10-13  889 * 
After dropping the lock, there are four cases to
ff9f47f6f00cfe Chinwen Chang 2020-10-13  890 * 
consider. See the following example for explanation.
ff9f47f6f00cfe Chinwen Chang 2020-10-13  891

[PATCH] media: atomisp: Remove unneeded return variable

This patch removes unneeded return variables, using only
'0' instead.
It fixes the following warning detected by coccinelle:
./drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8: Unneeded
variable: "err". Return "0" on line 44

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/staging/media/atomisp/pci/sh_css_mipi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c 
b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
index d5ae7f0..de8ee45 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
@@ -36,12 +36,10 @@
 int
 ia_css_mipi_frame_specify(const unsigned int size_mem_words,
  const bool contiguous) {
-   int err = 0;
-
my_css.size_mem_words = size_mem_words;
(void)contiguous;
 
-   return err;
+   return 0;
 }
 
 /*
-- 
1.8.3.1

[RFC 3/3] dma-contiguous: Type cast MAX_ORDER as unsigned int

Type cast MAX_ORDER as unsigned int to fix the following build warning.

In file included from ./include/linux/kernel.h:14,
 from ./include/asm-generic/bug.h:20,
 from ./arch/arm64/include/asm/bug.h:26,
 from ./include/linux/bug.h:5,
 from ./include/linux/mmdebug.h:5,
 from ./arch/arm64/include/asm/memory.h:166,
 from ./arch/arm64/include/asm/page.h:42,
 from kernel/dma/contiguous.c:46:
kernel/dma/contiguous.c: In function ‘rmem_cma_setup’:
./include/linux/minmax.h:18:28: warning: comparison of distinct pointer
types lacks a cast
  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^~
./include/linux/minmax.h:32:4: note: in expansion of macro ‘__typecheck’
   (__typecheck(x, y) && __no_side_effects(x, y))
^~~
./include/linux/minmax.h:42:24: note: in expansion of macro ‘__safe_cmp’
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
./include/linux/minmax.h:58:19: note: in expansion of macro
‘__careful_cmp’
 #define max(x, y) __careful_cmp(x, y, >)
   ^
kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’
  phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);

Cc: Christoph Hellwig 
Cc: Marek Szyprowski 
Cc: Robin Murphy 
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 kernel/dma/contiguous.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 3d63d91cba5c..1c2782349d71 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = {
 
 static int __init rmem_cma_setup(struct reserved_mem *rmem)
 {
-   phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
+   phys_addr_t align = PAGE_SIZE << max((unsigned int)MAX_ORDER - 1, 
pageblock_order);
phys_addr_t mask = align - 1;
unsigned long node = rmem->fdt_node;
bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
-- 
2.20.1

[rcu:willy-maple 137/202] mm/mmap.c:1895 mmap_region() error: uninitialized symbol 'next'.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
willy-maple
head:   7e346d2845b4bd77663394f39fa70456e0084c86
commit: 059c8a0bb9679195f39e18eaa5b3f548f13e7226 [137/202] mm/mmap: Change 
mmap_region to use maple tree state
config: x86_64-randconfig-m001-20210202 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
mm/mmap.c:1895 mmap_region() error: uninitialized symbol 'next'.

vim +/next +1895 mm/mmap.c

0165ab443556bd Miklos Szeredi2007-07-15  1753  unsigned long 
mmap_region(struct file *file, unsigned long addr,
897ab3e0c49e24 Mike Rapoport 2017-02-24  1754   unsigned long 
len, vm_flags_t vm_flags, unsigned long pgoff,
897ab3e0c49e24 Mike Rapoport 2017-02-24  1755   struct 
list_head *uf)
0165ab443556bd Miklos Szeredi2007-07-15  1756  {
0165ab443556bd Miklos Szeredi2007-07-15  1757   struct mm_struct *mm = 
current->mm;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1758   struct vm_area_struct 
*vma = NULL;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1759   struct vm_area_struct 
*prev, *next;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1760   pgoff_t pglen = len >> 
PAGE_SHIFT;
0165ab443556bd Miklos Szeredi2007-07-15  1761   unsigned long charged = 
0;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1762   unsigned long end = 
addr + len;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1763   unsigned long 
merge_start = addr, merge_end = end;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1764   pgoff_t vm_pgoff;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1765   int error;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1766   MA_STATE(mas, 
>mm_mt, addr, end - 1);
0165ab443556bd Miklos Szeredi2007-07-15  1767  
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1768   /* Check against 
address space limit. */
84638335900f19 Konstantin Khlebnikov 2016-01-14  1769   if (!may_expand_vm(mm, 
vm_flags, len >> PAGE_SHIFT)) {
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1770   unsigned long 
nr_pages;
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1771  
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1772   /*
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1773* MAP_FIXED 
may remove pages of mappings that intersects with
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1774* requested 
mapping. Account for the pages it would unmap.
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1775*/
059c8a0bb96791 Liam R. Howlett   2020-11-10  1776   nr_pages = 
count_vma_pages_range(mm, addr, end);
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1777  
84638335900f19 Konstantin Khlebnikov 2016-01-14  1778   if 
(!may_expand_vm(mm, vm_flags,
84638335900f19 Konstantin Khlebnikov 2016-01-14  1779   
(len >> PAGE_SHIFT) - nr_pages))
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1780   return 
-ENOMEM;
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1781   }
e8420a8ece80b3 Cyril Hrubis  2013-04-29  1782  
059c8a0bb96791 Liam R. Howlett   2020-11-10  1783   /* Unmap any existing 
mapping in the area */
059c8a0bb96791 Liam R. Howlett   2020-11-10  1784   if (do_munmap(mm, addr, 
len, uf))
^1da177e4c3f41 Linus Torvalds2005-04-16  1785   return -ENOMEM;
059c8a0bb96791 Liam R. Howlett   2020-11-10  1786  
^1da177e4c3f41 Linus Torvalds2005-04-16  1787   /*
^1da177e4c3f41 Linus Torvalds2005-04-16  1788* Private writable 
mapping: check memory availability
^1da177e4c3f41 Linus Torvalds2005-04-16  1789*/
5a6fe125950676 Mel Gorman2009-02-10  1790   if 
(accountable_mapping(file, vm_flags)) {
^1da177e4c3f41 Linus Torvalds2005-04-16  1791   charged = len 
>> PAGE_SHIFT;
191c542442fdf5 Al Viro   2012-02-13  1792   if 
(security_vm_enough_memory_mm(mm, charged))
^1da177e4c3f41 Linus Torvalds2005-04-16  1793   return 
-ENOMEM;
^1da177e4c3f41 Linus Torvalds2005-04-16  1794   vm_flags |= 
VM_ACCOUNT;
^1da177e4c3f41 Linus Torvalds2005-04-16  1795   }
^1da177e4c3f41 Linus Torvalds2005-04-16  1796  
^1da177e4c3f41 Linus Torvalds2005-04-16  1797  
059c8a0bb96791 Liam R. Howlett   2020-11-10  1798   if (vm_flags & 
VM_SPECIAL) {
059c8a0bb96791 Liam R. Howlett   2020-11-10  1799   prev = 
mas_prev(, 0);
059c8a0bb96791 Liam R. Howlett   2020-11-10  1800   goto 
cannot_expand;

"next" not initialized on this path.

059c8a0bb96791 Liam R. Howlett   2020-11-10  1801   }
059c8a0bb96791 Liam R. Howlett   2020-11-10  1802  
059c8a0bb96791 Liam R. Howlett   2020-11-10  1803   /* Attempt to expand an 
old mapping */
059c8a0bb96791

[RFC 2/3] arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE

MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable
for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled
or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be
greater than MAX_ORDER, making it unusable as pageblock_order.

This enables HUGETLB_PAGE_SIZE_VARIABLE making pageblock_order a variable
rather than the compile time constant HUGETLB_PAGE_ORDER which could break
MAX_ORDER rule for certain configurations.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 arch/arm64/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 175914f2f340..c4acf8230f20 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1918,6 +1918,10 @@ config ARCH_ENABLE_THP_MIGRATION
def_bool y
depends on TRANSPARENT_HUGEPAGE
 
+config HUGETLB_PAGE_SIZE_VARIABLE
+   def_bool y
+   depends on HUGETLB_PAGE
+
 menu "Power management options"
 
 source "kernel/power/Kconfig"
-- 
2.20.1

[RFC 1/3] mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER

With HUGETLB_PAGE_SIZE_VARIABLE enabled, pageblock_order cannot be assigned
as HUGETLB_PAGE_ORDER when it is greater than or equal to MAX_ORDER during
set_pageblock_order(). Otherwise  the following warning is triggered during
boot as detected on an arm64 platform.

WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
Modules linked in:
CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
Hardware name: linux,dummy-virt (DT)
[8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--)
[8.811732] pc : __fragmentation_index+0xa4/0xc0
[8.812555] lr : fragmentation_index+0xf8/0x138
[8.813360] sp : 864079b0
[8.813958] x29: 864079b0 x28: 0372
[8.814901] x27: 7682 x26: 8000135b3948
[8.815847] x25: 1fffe00010c80f48 x24: 
[8.816805] x23:  x22: 000d
[8.817764] x21: 0030 x20: 0005ffcb4d58
[8.818712] x19: 000b x18: 
[8.819656] x17:  x16: 
[8.820613] x15:  x14: 8000114c6258
[8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9
[8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9
[8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf
[8.824415] x7 : 0001 x6 : 41b58ab3
[8.825359] x5 : 600010c80f48 x4 : dfff8000
[8.826313] x3 : 8000102be670 x2 : 0007
[8.827259] x1 : 86407a60 x0 : 000d
[8.828218] Call trace:
[8.828667]  __fragmentation_index+0xa4/0xc0
[8.829436]  fragmentation_index+0xf8/0x138
[8.830194]  compaction_suitable+0x98/0xb8
[8.830934]  wakeup_kcompactd+0xdc/0x128
[8.831640]  balance_pgdat+0x71c/0x7a0
[8.832327]  kswapd+0x31c/0x520
[8.832902]  kthread+0x224/0x230
[8.833491]  ret_from_fork+0x10/0x30
[8.834150] ---[ end trace 472836f79c15516b ]---

The above warning happens because pageblock_order exceeds MAX_ORDER, caused
by large HUGETLB_PAGE_ORDER on certain platforms like arm64. Lets prevent
the scenario by first checking HUGETLB_PAGE_ORDER against MAX_ORDER, before
its assignment as pageblock_order.

Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 mm/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 519a60d5b6f7..36473f2fa683 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6798,7 +6798,7 @@ void __init set_pageblock_order(void)
if (pageblock_order)
return;
 
-   if (HPAGE_SHIFT > PAGE_SHIFT)
+   if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER))
order = HUGETLB_PAGE_ORDER;
else
order = MAX_ORDER - 1;
-- 
2.20.1

Re: [PATCH] bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD

2021-02-03 Thread Tony Lindgren

* Grygorii Strashko  [210128 21:16]:
> The main purpose of l3 IRQs is to catch OCP bus access errors and identify
> corresponding code places by showing call stack, so it's important to
> handle L3 interconnect errors as fast as possible. On RT these IRQs will
> became threaded and will be scheduled mach more late from the moment actual
> error occurred so showing completely useless information.
> 
> Hence, mark l3 IRQs as IRQF_NO_THREAD so they will not be forced threaded
> on RT or if force_irqthreads = true.
> 
> Fixes: 0ee7261c9212 ("drivers: bus: Move the OMAP interconnect driver to 
> drivers/bus/")

Thanks applying into fixes.

Tony

[RFC 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE

The following warning gets triggered while trying to boot a 64K page size
without THP config kernel on arm64 platform.

WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
Modules linked in:
CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
Hardware name: linux,dummy-virt (DT)
[8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--)
[8.811732] pc : __fragmentation_index+0xa4/0xc0
[8.812555] lr : fragmentation_index+0xf8/0x138
[8.813360] sp : 864079b0
[8.813958] x29: 864079b0 x28: 0372
[8.814901] x27: 7682 x26: 8000135b3948
[8.815847] x25: 1fffe00010c80f48 x24: 
[8.816805] x23:  x22: 000d
[8.817764] x21: 0030 x20: 0005ffcb4d58
[8.818712] x19: 000b x18: 
[8.819656] x17:  x16: 
[8.820613] x15:  x14: 8000114c6258
[8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9
[8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9
[8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf
[8.824415] x7 : 0001 x6 : 41b58ab3
[8.825359] x5 : 600010c80f48 x4 : dfff8000
[8.826313] x3 : 8000102be670 x2 : 0007
[8.827259] x1 : 86407a60 x0 : 000d
[8.828218] Call trace:
[8.828667]  __fragmentation_index+0xa4/0xc0
[8.829436]  fragmentation_index+0xf8/0x138
[8.830194]  compaction_suitable+0x98/0xb8
[8.830934]  wakeup_kcompactd+0xdc/0x128
[8.831640]  balance_pgdat+0x71c/0x7a0
[8.832327]  kswapd+0x31c/0x520
[8.832902]  kthread+0x224/0x230
[8.833491]  ret_from_fork+0x10/0x30
[8.834150] ---[ end trace 472836f79c15516b ]---

This warning comes from __fragmentation_index() when the requested order
is greater than MAX_ORDER.

static int __fragmentation_index(unsigned int order,
 struct contig_page_info *info)
{
unsigned long requested = 1UL << order;

if (WARN_ON_ONCE(order >= MAX_ORDER)) <= Triggered here
return 0;

Digging it further reveals that pageblock_order has been assigned a value
which is greater than MAX_ORDER failing the above check. But why this
happened ? Because HUGETLB_PAGE_ORDER for the given config on arm64 is
greater than MAX_ORDER.

The solution involves enabling HUGETLB_PAGE_SIZE_VARIABLE which would make
pageblock_order a variable instead of constant HUGETLB_PAGE_ORDER. But that
change alone also did not really work as pageblock_order still got assigned
as HUGETLB_PAGE_ORDER in set_pageblock_order(). HUGETLB_PAGE_ORDER needs to
be less than MAX_ORDER for its appropriateness as pageblock_order otherwise
just fallback to MAX_ORDER - 1 as before. While here it also fixes a build
problem via type casting MAX_ORDER in rmem_cma_setup().

This series applies in v5.11-rc6 and has been slightly tested on arm64. But
looking for some early feedbacks particularly with respect to concerns in
subscribing HUGETLB_PAGE_SIZE_VARIABLE on a platform where the hugetlb page
size is config dependent but not really a runtime variable. Even though it
appears that HUGETLB_PAGE_SIZE_VARIABLE is used only while computing the
pageblock_order, could there be other implications ?

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Robin Murphy 
Cc: Marek Szyprowski 
Cc: Christoph Hellwig 
Cc: Andrew Morton 
Cc: linux-arm-ker...@lists.infradead.org
Cc: io...@lists.linux-foundation.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org

Anshuman Khandual (3):
  mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
  arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
  dma-contiguous: Type cast MAX_ORDER as unsigned int

 arch/arm64/Kconfig  | 4 
 kernel/dma/contiguous.c | 2 +-
 mm/page_alloc.c | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.20.1

Re: [PATCH v8 0/2] Kbuild: DWARF v5 support

2021-02-03 Thread Sedat Dilek

On Thu, Feb 4, 2021 at 7:40 AM Nick Desaulniers  wrote:
>
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> DWARF5 wins significantly in terms of size and especially so when mixed
> with compression (CONFIG_DEBUG_INFO_COMPRESSED).
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
>
> Patch 1 is a cleanup that lays the ground work and isn't DWARF
> v5 specific.
> Patch 2 implements Kconfig and Kbuild support for DWARFv5.
>
> Changes from v7:
> (Strictly commit message changes)
> * Pick up Nathan's reviewed by tags for both patches.
> * Add note about only modifying compiler dwarf info, not assembler dwarf
>   info, as per Nathan.
> * Add link to Red Hat bug report and Chris' reported by on patch 2.
> * Add more info from Jakub on patch 2 commit message.
> * Reorder info about validating version, noting the tree is not "clean"
>   in the sense that parts mess up existing CFLAGS, or don't use
>   DEBUG_CFLAGS. I will not be adding such cleanups to this series. They
>   can be done AFTER.
> * Update note about 2.35.2 (rather than include the full text Jakub
>   wrote on it in 
> https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulni...@google.com/#23727667).
> * Add note that GCC 11 has changed the implicit default version.
>

I have intensively tested a lot of versions of this series and some
other issues reported and got fixed.

So my comments for followers:

[ Download v8 with b4 ]

link="https://lore.kernel.org/r/20210204064037.1281726-1-ndesaulni...@google.com;
b4 -d am $link

[ Pre-Patch before applying v8 ]

"kbuild: Remove $(cc-option,-gdwarf-4) dependency from DEBUG_INFO_DWARF4"

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44

[ DEBUG_CFLAGS thread and fix ]

https://marc.info/?t=16123389346=1=2
https://marc.info/?l=linux-kbuild=161233892923723=2

Feel free to be more verbose and include links (to patches).

I guess I need to test harder to get a Tested-by credit :-)?

Thanks for v8, I will use it for some testing with BTF/pahole.

- Sedat -

> Changes from v6:
> * Reorder sections from linker script to match order from BFD's internal
>   linker script.
> * Add .debug_names section, as per Fangrui.
> * Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1
>   choice. GCC's implicit default version of DWARF has been DWARF v4
>   since ~4.8.
> * Modify the test script to check for the presence of
>   https://sourceware.org/bugzilla/show_bug.cgi?id=27195.
> * Drop the clang without integrated assembler block in
>   0002. Bumps the version requirement for GAS to 2.35.2, which isn't
>   released yet (but should be released soon).  Folks looking to test
>   with clang but without the integrated assembler should fetch
>   binutils-gdb, build it from source, add a symlink to
>   binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix
>   binutils-gdb/gas/as to their $PATH when building the kernel.
>
> Changes from v5:
> * Drop previous patch 1, it has been accepted into kbuild:
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44
> * Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of
>   additional complexity. Drop it that part of the patch. We can revisit
>   clang without the integrated assembler setting -Wa,-gdwarf-4 later.
>   That is a separate problem from generally supporting DWARF v5.
> * Rework the final patch for clang without the integrated assembler.
>   -Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will
>   not accept the assembler directives clang produces from C code when
>   generating asm.
>
> Changes from v4:
> * drop set -e from script as per Nathan.
> * add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat.
> * Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and
>   Masahiro. Sorry it took me a few tries to understand the point (I
>   might still not), but it looks much cleaner this way. Sorry Nathan, I
>   did not carry forward your previous reviews as a result, but I would
>   appreciate if you could look again.
> * Add Nathan's reviewed by tag to patch 1.
> * Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5
>   binutils addition later, and BTF issue.
> * I still happen to see a pahole related error spew for the combination
>   of:
>   * LLVM=1
>   * LLVM_IAS=1
>   * CONFIG_DEBUG_INFO_DWARF4
>   * CONFIG_DEBUG_INFO_BTF
>   Though they're non-fatal to the build. I'm not sure yet why removing
>   any one of the above prevents the warning spew. Maybe we'll need a v6.
>
> Changes from v3:
>
> Changes as per Arvind:
> * only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
> * add -gdwarf-5 to Kconfig shell script.
> * only run Kconfig shell script for Clang.
>
> Apologies to Sedat and Nathan; I appreciate previous testing/review, but
> I did no carry

Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names

2021-02-03 Thread Tony Lindgren

* Drew Fustini  [210127 02:04]:
> Based on linux-gpio discussion [1], it is best practice to make the
> gpio-line-names unique. Generic names like "[ethernet]" are replaced
> with the name of the unique signal on the AM3358 SoC ball corresponding
> to the gpio line. "[NC]" is also renamed to the standard "NC" name to
> represent "not connected".
> 
> [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/

So are these needed for v5.12 as fixes, or can these wait until after
the merge window for v5.13?

Regards,

Tony

Re: [PATCH] kprobes: Warn if the kprobe is reregistered

2021-02-03 Thread Naveen N . Rao

On 2021/02/03 11:59PM, Masami Hiramatsu wrote:
> Warn if the kprobe is reregistered, since there must be
> a software bug (actively used resource must not be re-registered)
> and caller must be fixed.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/kprobes.c |   13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

Suggested-by: Naveen N. Rao 
Acked-by: Naveen N. Rao 


Thanks,
Naveen

Re: [PATCH v2 3/3] arch/arm/configs: Enable VMSPLIT_2G in imx_v6_v7_defconfig

2021-02-03 Thread Alistair Francis

On Tue, Feb 2, 2021 at 11:50 PM Arnd Bergmann  wrote:
>
> On Wed, Feb 3, 2021 at 3:37 AM Alistair Francis  wrote:
> >
> > On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo  wrote:
> > >
> > > On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote:
> > > > The reMarkable2 requires VMSPLIT_2G, so lets set this in the
> > > > imx_v6_v7_defconfig.
> > >
> > > Hmm, why is VMSPLIT_2G required by reMarkable2?
> >
> > I'm not too sure. It's difficult to debug problems as I only have a
> > UART but without this I don't see any kernel prints so it seems like
> > the kernel doesn't get very far. I haven't had any luck with earlycon
> > on the device so I don't know how I can get more information.
>
> In the dts file, I can see that the machine has 1GB of RAM at
> contiguous addresses. My first guess would be a problem with
> highmem, as this configuration means that with VMSPLIT_3G
> there are 768MB of lowmem and 256MB of highmem.
>
> Can you try these two things to narrow the problem down
> further?
>
> a) disable CONFIG_HIGHMEM when using VMSPLIT_3G
> b) use VMSPLIT_3G_OPT

Thanks Arnd,

I was working on testing the config changes you mentioned, but it
seems like all of them work now.

VMSPLIT_2G: Boots to userspace

VMSPLIT_3G && HIGHMEM: Boots to userspace

VMSPLIT_3G && !HIGHMEM: Boots to userspace

VMSPLIT_3G_OPT && HIGHMEM:Boots to userspace

>
> If both of them solve the problem, then highmem is likely
> the root cause. One possible issue might be that the boot
> loader loads the initramfs or the dtb into a location outside
> of the first 768 MB of lowmem where it is unreachable
> in the VMSPLIT_3G configuration.

It boots with u-boot, which I am building so I can change these addresses.

I'm guessing that I have changed the addresses at some point and now
it works. I'm going to drop this patch.

Alistair

>
> Arnd

Re: [PATCH] x86: Add a prompt for HPET_EMULATE_RTC

2021-02-03 Thread Anand K. Mistry

On Thu, 4 Feb 2021 at 17:30, Randy Dunlap  wrote:
>
> On 2/3/21 10:13 PM, Anand K. Mistry wrote:
> >> Hi,
> >>
> >> When you run "make olddefconfig", should this "depends on"
> >> line evaluate to true or false?
> >
> > True. RTC_DRV_CMOS=y by default on x86 systems and HPET_TIMER also
> > appears to default yes (on x86-64 if I'm reading this right).
> >
> > Oddly, the RTC config option doesn't appear to exist. Probably a separate 
> > issue.
>
> Yes, just a separate simple patch.
>
> >> I.e., what are the settings of these symbols in the old .config file?
> >>
> >>
> >> depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || 
> >> RTC_DRV_CMOS=y)
> >
> > Actually, none of these options are set in the old config.
> > RTC_DRV_CMOS and HPET_TIMER appear to default to yes.
> >
> >  % grep HPET .config
> > CONFIG_HPET=y
> > # CONFIG_HPET_EMULATE_RTC is not set
> > # CONFIG_HPET_MMAP is not set
> >  % grep RTC .config
> > CONFIG_RTC_CLASS=y
> > # CONFIG_HPET_EMULATE_RTC is not set
> > CONFIG_PM_TRACE_RTC=y
> > # CONFIG_RTC_HCTOSYS is not set
> >
> >>
> >> If not, is there some out-of-tree driver involved?
> >
> > No out of tree drivers involved. I tried this on a vanilla 5.11-rc6.
> >
> >> I'm having a little trouble seeing why this is needed.
> >
> > So am I. But this is the magic that lets me keep
> > CONFIG_HPET_EMULATE_RTC from the old config. I did manage to trace
> > where the option is being overridden in the conf tool, but the
> > reasoning why is beyond my knowledge.
>
> Can you post the .config that you are feeding to 'make olddefconfig', please.
> I'll take a look (or the x86 guys can do so).

Sure. Here it is:

#
# Config options generated by splitconfig
#
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ASHMEM=y
CONFIG_AUDIT=y
CONFIG_BFQ_GROUP_IOSCHED=y
CONFIG_BINFMT_MISC=y
CONFIG_BLK_CGROUP=y
# CONFIG_BLK_DEBUG_FS is not set
CONFIG_BLK_DEV_DM=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=m
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_SYSCALL=y
CONFIG_BRIDGE=m
CONFIG_BT=m
CONFIG_BT_FEATURE_DEBUG=y
CONFIG_BT_FEATURE_DEBUG_FUNC_NAMES=y
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y
CONFIG_BT_HCIBTUSB_INTERVAL=y
CONFIG_BT_HCIVHCI=m
CONFIG_BT_HIDP=m
CONFIG_BT_RFCOMM=m
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_CFG80211=m
CONFIG_CFG80211_CERTIFICATION_ONUS=y
CONFIG_CFG80211_DEBUGFS=y
# CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not set
CONFIG_CFG80211_WEXT=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_BPF=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_SCHED=y
CONFIG_CHROME_PLATFORMS=y
CONFIG_CLS_U32_MARK=y
# CONFIG_COMPAT_BRK is not set
CONFIG_CONFIGFS_FS=y
CONFIG_CONNECTOR=y
CONFIG_CPUSETS=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_TEO=y
CONFIG_CRC7=m
CONFIG_CROS_EC=y
CONFIG_CROS_EC_PD_UPDATE=y
CONFIG_CROS_EC_SENSORHUB=m
CONFIG_CROS_EC_SPI=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_DAX=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_CREDENTIALS=y
CONFIG_DEBUG_DEVRES=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF4=y
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEFAULT_HOSTNAME="localhost"
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_DM_CRYPT=y
CONFIG_DM_FLAKEY=m
CONFIG_DM_INIT=y
CONFIG_DM_INTEGRITY=m
CONFIG_DM_THIN_PROVISIONING=y
CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_CHROMEOS=y
# CONFIG_DNOTIFY is not set
CONFIG_DRM=y
CONFIG_DRM_DP_AUX_CHARDEV=y
CONFIG_DRM_EVDI=m
# CONFIG_DRM_FBDEV_EMULATION is not set
CONFIG_DRM_UDL=y
CONFIG_DRM_VGEM=y
CONFIG_ECRYPT_FS=y
CONFIG_EMBEDDED=y
CONFIG_ENCRYPTED_KEYS=y
CONFIG_ERROR_ON_WARNING=y
CONFIG_ESD_FS=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_FANOTIFY=y
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FORTIFY_SOURCE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_VERITY=y
CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUSE_FS=m
CONFIG_GOOGLE_COREBOOT_TABLE=y
CONFIG_GOOGLE_FIRMWARE=y
CONFIG_GOOGLE_MEMCONSOLE_COREBOOT=y
CONFIG_GOOGLE_VPD=y
CONFIG_HARDENED_USERCOPY=y
CONFIG_HFSPLUS_FS=m
CONFIG_HIDRAW=y
CONFIG_HID_APPLE=m
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=y
CONFIG_HID_HOLTEK=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=m
CONFIG_HID_LOGITECH_DJ=m
CONFIG_HID_MAGICMOUSE=m
CONFIG_HID_MICROSOFT=m
CONFIG_HID_MULTITOUCH=y
CONFIG_HID_PLANTRONICS=m
CONFIG_HID_PRIMAX=m
CONFIG_HID_QUICKSTEP=m
CONFIG_HID_SONY=m
CONFIG_HID_THINGM=m
CONFIG_HID_WACOM=m
CONFIG_HID_WIIMOTE=m
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
CONFIG_HW_RANDOM=y

Re: [PATCH 1/2] vdpa/mlx5: Avoid unnecessary query virtqueue

On Wed, Feb 03, 2021 at 03:19:40PM -0800, Si-Wei Liu wrote:
> On Tue, Feb 2, 2021 at 9:16 PM Jason Wang  wrote:
> >
> >
> > On 2021/2/3 上午1:54, Si-Wei Liu wrote:
> > > On Tue, Feb 2, 2021 at 1:23 AM Eli Cohen  wrote:
> > >> On Tue, Feb 02, 2021 at 12:38:51AM -0800, Si-Wei Liu wrote:
> > >>> Thanks Eli and Jason for clarifications. See inline.
> > >>>
> > >>> On Mon, Feb 1, 2021 at 11:06 PM Eli Cohen  wrote:
> >  On Tue, Feb 02, 2021 at 02:02:25PM +0800, Jason Wang wrote:
> > > On 2021/2/2 下午12:15, Si-Wei Liu wrote:
> > >> On Mon, Feb 1, 2021 at 7:13 PM Jason Wang  
> > >> wrote:
> > >>> On 2021/2/2 上午3:17, Si-Wei Liu wrote:
> >  On Mon, Feb 1, 2021 at 10:51 AM Si-Wei Liu 
> >   wrote:
> > > On Thu, Jan 28, 2021 at 5:46 AM Eli Cohen  wrote:
> > >> suspend_vq should only suspend the VQ on not save the current 
> > >> available
> > >> index. This is done when a change of map occurs when the driver 
> > >> calls
> > >> save_channel_info().
> > > Hmmm, suspend_vq() is also called by teardown_vq(), the latter of
> > > which doesn't save the available index as save_channel_info() 
> > > doesn't
> > > get called in that path at all. How does it handle the case that
> > > aget_vq_state() is called from userspace (e.g. QEMU) while the
> > > hardware VQ object was torn down, but userspace still wants to 
> > > access
> > > the queue index?
> > >
> > > Refer to 
> > > https://lore.kernel.org/netdev/1601583511-15138-1-git-send-email-si-wei@oracle.com/
> > >
> > > vhost VQ 0 ring restore failed: -1: Resource temporarily 
> > > unavailable (11)
> > > vhost VQ 1 ring restore failed: -1: Resource temporarily 
> > > unavailable (11)
> > >
> > > QEMU will complain with the above warning while VM is being 
> > > rebooted
> > > or shut down.
> > >
> > > Looks to me either the kernel driver should cover this 
> > > requirement, or
> > > the userspace has to bear the burden in saving the index and not 
> > > call
> > > into kernel if VQ is destroyed.
> >  Actually, the userspace doesn't have the insights whether virt 
> >  queue
> >  will be destroyed if just changing the device status via 
> >  set_status().
> >  Looking at other vdpa driver in tree i.e. ifcvf it doesn't behave 
> >  like
> >  so. Hence this still looks to me to be Mellanox specifics and
> >  mlx5_vdpa implementation detail that shouldn't expose to userspace.
> > >>> So I think we can simply drop this patch?
> > >> Yep, I think so. To be honest I don't know why it has anything to do
> > >> with the memory hotplug issue.
> > >
> > > Eli may know more, my understanding is that, during memory hotplut, 
> > > qemu
> > > need to propagate new memory mappings via set_map(). For mellanox, it 
> > > means
> > > it needs to rebuild memory keys, so the virtqueue needs to be 
> > > suspended.
> > >
> >  I think Siwei was asking why the first patch was related to the hotplug
> >  issue.
> > >>> I was thinking how consistency is assured when saving/restoring this
> > >>> h/w avail_index against the one in the virtq memory, particularly in
> > >>> the region_add/.region_del() context (e.g. the hotplug case). Problem
> > >>> is I don't see explicit memory barrier when guest thread updates the
> > >>> avail_index, how does the device make sure the h/w avail_index is
> > >>> uptodate while guest may race with updating the virtq's avail_index in
> > >>> the mean while? Maybe I completely miss something obvious?
> > >> DKIM-Signature: v1; arsa-sha256; crelaxed/relaxed; dnvidia.com; sn1;
> > >>  t 12257780; bhHnB0z4VEKwRS3WGY8d836MJgxu5Eln/jbFZlNXVxc08;
> > >>  hX-PGP-Universal:Date:From:To:CC:Subject:Message-ID:References:
> > >>   MIME-Version:Content-Type:Content-Disposition:
> > >>   
> > >> Content-Transfer-Encoding:In-Reply-To:User-Agent:X-Originating-IP:
> > >>   X-ClientProxiedBy;
> > >>  
> > >> bgGmb8+rcn3/rKzKQ/7QzSnghWzZ+FAU0XntsRZYGQ66sFvT7zsYPHogG3LIWNY77t
> > >>   
> > >> wNHPw7GCJrNaH3nEXPbOp0FMOZw4Kv4W7UPuYPobbLeTkvuPAidjB8dM42vz+1X61t
> > >>   
> > >> 9IVQT9X4hnAxRjI5CqZOo41GS4Tl1X+ykGoA+VE80BR/R/+nQ3tXDVULfppzeB+vu3
> > >>   
> > >> TWnnpaZ2GyoNyPlMiyVRkHdXzDVgA4uQHxwHn7otGK5J4lzyu8KrFyQtiP+f6hfu5v
> > >>   
> > >> crJkYS8e9A+rfzUmKWuyHcKcmhPhAVJ4XdpzZcDXXlMHVxG7nR1o88xttC6D1+oNIP
> > >>   9xHI3DkNBpEuA
> > >> If you're asking about syncronization upon hot plug of memory, the
> > >> hardware always goes to read the available index from memory when a new
> > >> hardware object is associted with a virtqueue. You can argue then that
> > >> you don't need to restore the

RE: [RFC PATCH v1 0/4] vfio: Add IOPF support for VFIO passthrough

2021-02-03 Thread Tian, Kevin

> From: Shenming Lu 
> Sent: Tuesday, February 2, 2021 2:42 PM
> 
> On 2021/2/1 15:56, Tian, Kevin wrote:
> >> From: Alex Williamson 
> >> Sent: Saturday, January 30, 2021 6:58 AM
> >>
> >> On Mon, 25 Jan 2021 17:03:58 +0800
> >> Shenming Lu  wrote:
> >>
> >>> Hi,
> >>>
> >>> The static pinning and mapping problem in VFIO and possible solutions
> >>> have been discussed a lot [1, 2]. One of the solutions is to add I/O
> >>> page fault support for VFIO devices. Different from those relatively
> >>> complicated software approaches such as presenting a vIOMMU that
> >> provides
> >>> the DMA buffer information (might include para-virtualized
> optimizations),
> >>> IOPF mainly depends on the hardware faulting capability, such as the
> PCIe
> >>> PRI extension or Arm SMMU stall model. What's more, the IOPF support
> in
> >>> the IOMMU driver is being implemented in SVA [3]. So do we consider to
> >>> add IOPF support for VFIO passthrough based on the IOPF part of SVA at
> >>> present?
> >>>
> >>> We have implemented a basic demo only for one stage of translation
> (GPA
> >>> -> HPA in virtualization, note that it can be configured at either stage),
> >>> and tested on Hisilicon Kunpeng920 board. The nested mode is more
> >> complicated
> >>> since VFIO only handles the second stage page faults (same as the non-
> >> nested
> >>> case), while the first stage page faults need to be further delivered to
> >>> the guest, which is being implemented in [4] on ARM. My thought on this
> >>> is to report the page faults to VFIO regardless of the occured stage (try
> >>> to carry the stage information), and handle respectively according to the
> >>> configured mode in VFIO. Or the IOMMU driver might evolve to support
> >> more...
> >>>
> >>> Might TODO:
> >>>  - Optimize the faulting path, and measure the performance (it might still
> >>>be a big issue).
> >>>  - Add support for PRI.
> >>>  - Add a MMU notifier to avoid pinning.
> >>>  - Add support for the nested mode.
> >>> ...
> >>>
> >>> Any comments and suggestions are very welcome. :-)
> >>
> >> I expect performance to be pretty bad here, the lookup involved per
> >> fault is excessive.  There are cases where a user is not going to be
> >> willing to have a slow ramp up of performance for their devices as they
> >> fault in pages, so we might need to considering making this
> >> configurable through the vfio interface.  Our page mapping also only
> >
> > There is another factor to be considered. The presence of IOMMU_
> > DEV_FEAT_IOPF just indicates the device capability of triggering I/O
> > page fault through the IOMMU, but not exactly means that the device
> > can tolerate I/O page fault for arbitrary DMA requests.
> 
> Yes, so I add a iopf_enabled field in VFIO to indicate the whole path faulting
> capability and set it to true after registering a VFIO page fault handler.
> 
> > In reality, many
> > devices allow I/O faulting only in selective contexts. However, there
> > is no standard way (e.g. PCISIG) for the device to report whether
> > arbitrary I/O fault is allowed. Then we may have to maintain device
> > specific knowledge in software, e.g. in an opt-in table to list devices
> > which allows arbitrary faults. For devices which only support selective
> > faulting, a mediator (either through vendor extensions on vfio-pci-core
> > or a mdev wrapper) might be necessary to help lock down non-faultable
> > mappings and then enable faulting on the rest mappings.
> 
> For devices which only support selective faulting, they could tell it to the
> IOMMU driver and let it filter out non-faultable faults? Do I get it wrong?

Not exactly to IOMMU driver. There is already a vfio_pin_pages() for
selectively page-pinning. The matter is that 'they' imply some device
specific logic to decide which pages must be pinned and such knowledge
is outside of VFIO.

From enabling p.o.v we could possibly do it in phased approach. First 
handles devices which tolerate arbitrary DMA faults, and then extends
to devices with selective-faulting. The former is simpler, but with one
main open whether we want to maintain such device IDs in a static
table in VFIO or rely on some hints from other components (e.g. PF
driver in VF assignment case). Let's see how Alex thinks about it.

> 
> >
> >> grows here, should mappings expire or do we need a least recently
> >> mapped tracker to avoid exceeding the user's locked memory limit?  How
> >> does a user know what to set for a locked memory limit?  The behavior
> >> here would lead to cases where an idle system might be ok, but as soon
> >> as load increases with more inflight DMA, we start seeing
> >> "unpredictable" I/O faults from the user perspective.  Seems like there
> >> are lots of outstanding considerations and I'd also like to hear from
> >> the SVA folks about how this meshes with their work.  Thanks,
> >>
> >
> > The main overlap between this feature and SVA is the IOPF reporting
> > framework, which currently still has gap to

[PATCH] media: atomisp: Remove unneeded return variable

This patch removes unneeded return variables, using only
'0' instead.
It fixes the following warning detected by coccinelle:
./drivers/staging/media/atomisp/pci/sh_css_mipi.c:39:5-8: Unneeded
variable: "err". Return "0" on line 44

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 drivers/staging/media/atomisp/pci/sh_css_mipi.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/sh_css_mipi.c 
b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
index d5ae7f0..de8ee45 100644
--- a/drivers/staging/media/atomisp/pci/sh_css_mipi.c
+++ b/drivers/staging/media/atomisp/pci/sh_css_mipi.c
@@ -36,12 +36,10 @@
 int
 ia_css_mipi_frame_specify(const unsigned int size_mem_words,
  const bool contiguous) {
-   int err = 0;
-
my_css.size_mem_words = size_mem_words;
(void)contiguous;
 
-   return err;
+   return 0;
 }
 
 /*
-- 
1.8.3.1

[PATCH] firewire: convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning:

./drivers/firewire/core-device.c:375:8-16: WARNING: use scnprintf or
sprintf.

Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong 
---
 drivers/firewire/core-device.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 80db43a..795f69e 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -372,8 +372,7 @@ static ssize_t rom_index_show(struct device *dev,
struct fw_device *device = fw_device(dev->parent);
struct fw_unit *unit = fw_unit(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n",
-   (int)(unit->directory - device->config_rom));
+   return sysfs_emit(buf, "%d\n", (int)(unit->directory - 
device->config_rom));
 }
 
 static struct device_attribute fw_unit_attributes[] = {
@@ -403,8 +402,7 @@ static ssize_t guid_show(struct device *dev,
int ret;
 
down_read(_device_rwsem);
-   ret = snprintf(buf, PAGE_SIZE, "0x%08x%08x\n",
-  device->config_rom[3], device->config_rom[4]);
+   ret = sysfs_emit(buf, "0x%08x%08x\n", device->config_rom[3], 
device->config_rom[4]);
up_read(_device_rwsem);
 
return ret;
-- 
1.8.3.1

Re: [PATCH] ARM: dts: am33xx: add aliases for mmc interfaces

2021-02-03 Thread Tony Lindgren

* Måns Rullgård  [210129 11:40]:
> Tony Lindgren  writes:
> 
> > * Mans Rullgard  [210128 18:09]:
> >> Without DT aliases, the numbering of mmc interfaces is unpredictable.
> >> Adding them makes it possible to refer to devices consistently.  The
> >> popular suggestion to use UUIDs obviously doesn't work with a blank
> >> device fresh from the factory.
> >> 
> >> See fa2d0aa96941 "mmc: core: Allow setting slot index via device tree
> >> alias" for more discussion.
> >
> > Sounds good to me, but will wait a few days before applying to make sure
> > this is still what we have agreed on :)
> 
> If it helps the decision, my existing systems fail to boot without
> something like this due to the eMMC moving from /dev/mmcblk1 to mmcblk0,
> at least sometimes.  I guess the kernel cares deeply about not breaking
> userspace, except when it doesn't give a damn.
> 
> I've been fighting this problem in various forms for the last 10 years
> or so, and I was hoping it would finally be over.

Yes this issue has been bugging folks for long time. Applying into fixes
thanks.

Tony

[PATCH v8 2/2] Kbuild: implement support for DWARF v5

DWARF v5 is the latest standard of the DWARF debug info format. GCC 11
will change the implicit default DWARF version, if left unspecified, to
DWARF v5.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363Mvmlinux.clang12.dwarf5.compressed
434Mvmlinux.clang12.dwarf4.compressed
439Mvmlinux.clang12.dwarf2.compressed
457Mvmlinux.clang12.dwarf5
536Mvmlinux.clang12.dwarf4
548Mvmlinux.clang12.dwarf2

515Mvmlinux.gcc10.2.dwarf5.compressed
599Mvmlinux.gcc10.2.dwarf4.compressed
624Mvmlinux.gcc10.2.dwarf2.compressed
630Mvmlinux.gcc10.2.dwarf5
765Mvmlinux.gcc10.2.dwarf4
809Mvmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
  One thing is GCC DWARF-5 support, that is whether the compiler will
  support -gdwarf-5 flag, and that support should be there from GCC 7
  onwards.

  All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
  option that enabled some small DWARF subset (initially only a few
  DW_LANG_* codes newly added to DWARF5 drafts).  Only GCC 7 (released
  after DWARF 5 has been finalized) started emitting DWARF5 section
  headers and got most of the DWARF5 changes in...

  Another separate thing is whether the assembler does support
  the -gdwarf-5 option (i.e. if you can compile assembler files
  with -Wa,-gdwarf-5) ... That option is about whether the assembler
  will emit DWARF5 or DWARF2 .debug_line.  It is fine to compile C sources
  with -gdwarf-5 and use DWARF2 .debug_line for assembler files if as
  doesn't support it.

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

Most issues with clang produced assembler were fixed in binutils 2.35.1,
but 2.35.2 fixed issues related to requiring the flag -Wa,-gdwarf-5
explicitly. The added shell script test checks for the latter, and is
only required when using clang without its integrated assembler, though
we use for clang regardless as we do not yet have a way to query the
assembler from Kconfig.

Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info.

This only modifies the DWARF version emitted by the compiler, not the
assembler.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump  | head -n 4 | grep version
or
$ readelf --debug-dump=info  2>/dev/null | grep Version

Parts of the tree don't reuse DEBUG_CFLAGS as they should; such cleanup
is left as a follow up.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707
Reported-by: Sedat Dilek 
Reported-by: Chris Murphy 
Suggested-by: Arvind Sankar 
Suggested-by: Caroline Tice 
Suggested-by: Fangrui Song 
Suggested-by: Jakub Jelinek 
Suggested-by: Masahiro Yamada 
Suggested-by: Nathan Chancellor 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Nick Desaulniers 
---
 Makefile  |  1 +
 include/asm-generic/vmlinux.lds.h |  7 ++-
 lib/Kconfig.debug | 18 ++
 scripts/test_dwarf5_support.sh|  8 
 4 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100755 scripts/test_dwarf5_support.sh

diff --git a/Makefile b/Makefile
index bed5cc150009..8b2deca568ee 100644
--- a/Makefile
+++ b/Makefile
@@ -831,6 +831,7 @@ KBUILD_AFLAGS   += -Wa,-gdwarf-2
 endif
 
 dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
 DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
 
 ifdef CONFIG_DEBUG_INFO_REDUCED
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 34b7e0d2346c..1e7cde4bd3f9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -842,8 +842,13 @@
/* DWARF 4 */   \
.debug_types0 : { *(.debug_types) } \
/* DWARF 5 */   \
+   .debug_addr 0 : { *(.debug_addr) }  \
+   .debug_line_str 0 : { *(.debug_line_str) }  \
+   .debug_loclists 0 : { *(.debug_loclists) }  \
.debug_macro0 : { *(.debug_macro) } \
-   .debug_addr 0 : { *(.debug_addr) }
+   .debug_names0 : { *(.debug_names) } \
+   .debug_rnglists 0 : { *(.debug_rnglists) }  \
+   .debug_str_offsets  0 : { *(.debug_str_offsets) }
 
 /* Stabs debugging sections. */
 #define STABS_DEBUG\
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 94c1a7ed6306..ad6f78989d4f 100644
--- a/lib/Kconfig.debug
+++

[PATCH v8 1/2] Kbuild: make DWARF version a choice

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is
the default. Does so in a way that's forward compatible with existing
configs, and makes adding future versions more straightforward.

GCC since ~4.8 has defaulted to this DWARF version implicitly.

Reviewed-by: Nathan Chancellor 
Suggested-by: Arvind Sankar 
Suggested-by: Fangrui Song 
Suggested-by: Nathan Chancellor 
Suggested-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
---
 Makefile  |  5 ++---
 lib/Kconfig.debug | 16 +++-
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index 407816375983..bed5cc150009 100644
--- a/Makefile
+++ b/Makefile
@@ -830,9 +830,8 @@ ifneq ($(LLVM_IAS),1)
 KBUILD_AFLAGS  += -Wa,-gdwarf-2
 endif
 
-ifdef CONFIG_DEBUG_INFO_DWARF4
-DEBUG_CFLAGS   += -gdwarf-4
-endif
+dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
+DEBUG_CFLAGS   += -gdwarf-$(dwarf-version-y)
 
 ifdef CONFIG_DEBUG_INFO_REDUCED
 DEBUG_CFLAGS   += $(call cc-option, -femit-struct-debug-baseonly) \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e906ea906cb7..94c1a7ed6306 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -256,13 +256,19 @@ config DEBUG_INFO_SPLIT
  to know about the .dwo files and include them.
  Incompatible with older versions of ccache.
 
+choice
+   prompt "DWARF version"
+   help
+ Which version of DWARF debug info to emit.
+
 config DEBUG_INFO_DWARF4
-   bool "Generate dwarf4 debuginfo"
+   bool "Generate DWARF Version 4 debuginfo"
help
- Generate dwarf4 debug info. This requires recent versions
- of gcc and gdb. It makes the debug information larger.
- But it significantly improves the success of resolving
- variables in gdb on optimized code.
+ Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
+ It makes the debug information larger, but it significantly
+ improves the success of resolving variables in gdb on optimized code.
+
+endchoice # "DWARF version"
 
 config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
-- 
2.30.0.365.g02bc693789-goog

[PATCH v8 0/2] Kbuild: DWARF v5 support

DWARF v5 is the latest standard of the DWARF debug info format.

DWARF5 wins significantly in terms of size and especially so when mixed
with compression (CONFIG_DEBUG_INFO_COMPRESSED).

Link: http://www.dwarfstd.org/doc/DWARF5.pdf

Patch 1 is a cleanup that lays the ground work and isn't DWARF
v5 specific.
Patch 2 implements Kconfig and Kbuild support for DWARFv5.

Changes from v7:
(Strictly commit message changes)
* Pick up Nathan's reviewed by tags for both patches.
* Add note about only modifying compiler dwarf info, not assembler dwarf
info, as per Nathan.
* Add link to Red Hat bug report and Chris' reported by on patch 2.
* Add more info from Jakub on patch 2 commit message.
* Reorder info about validating version, noting the tree is not "clean"
in the sense that parts mess up existing CFLAGS, or don't use
DEBUG_CFLAGS. I will not be adding such cleanups to this series. They
can be done AFTER.
* Update note about 2.35.2 (rather than include the full text Jakub
wrote on it in
https://patchwork.kernel.org/project/linux-kbuild/patch/20201022012106.1875129-1-ndesaulni...@google.com/#23727667).
* Add note that GCC 11 has changed the implicit default version.

Changes from v6:
* Reorder sections from linker script to match order from BFD's internal
linker script.
* Add .debug_names section, as per Fangrui.
* Drop CONFIG_DEBUG_INFO_DWARF2. Patch 0001 becomes a menu with 1
choice. GCC's implicit default version of DWARF has been DWARF v4
since ~4.8.
* Modify the test script to check for the presence of
https://sourceware.org/bugzilla/show_bug.cgi?id=27195.
* Drop the clang without integrated assembler block in
0002. Bumps the version requirement for GAS to 2.35.2, which isn't
released yet (but should be released soon). Folks looking to test
with clang but without the integrated assembler should fetch
binutils-gdb, build it from source, add a symlink to
binutils-gdb/gas/as-new to binutils-gdb/gas/as, then prefix
binutils-gdb/gas/as to their $PATH when building the kernel.

Changes from v5:
* Drop previous patch 1, it has been accepted into kbuild:

https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=kbuild=3f4d8ce271c7082be75bacbcbd2048aa78ce2b44
* Trying to set -Wa,-gdwarf-4 in the earlier patch was the source of
additional complexity. Drop it that part of the patch. We can revisit
clang without the integrated assembler setting -Wa,-gdwarf-4 later.
That is a separate problem from generally supporting DWARF v5.
* Rework the final patch for clang without the integrated assembler.
-Wa,-gdwarf-5 is required for DWARF5 in that case otherwise GAS will
not accept the assembler directives clang produces from C code when
generating asm.

Changes from v4:
* drop set -e from script as per Nathan.
* add dependency on !CONFIG_DEBUG_INFO_BTF for DWARF v5 as per Sedat.
* Move LLVM_IAS=1 complexity from patch 2 to patch 3 as per Arvind and
Masahiro. Sorry it took me a few tries to understand the point (I
might still not), but it looks much cleaner this way. Sorry Nathan, I
did not carry forward your previous reviews as a result, but I would
appreciate if you could look again.
* Add Nathan's reviewed by tag to patch 1.
* Reword commit message for patch 3 to mention LLVM_IAS=1 and -gdwarf-5
binutils addition later, and BTF issue.
* I still happen to see a pahole related error spew for the combination
of:
* LLVM=1
* LLVM_IAS=1
* CONFIG_DEBUG_INFO_DWARF4
* CONFIG_DEBUG_INFO_BTF
Though they're non-fatal to the build. I'm not sure yet why removing
any one of the above prevents the warning spew. Maybe we'll need a v6.

Changes from v3:

Changes as per Arvind:
* only add -Wa,-gdwarf-5 for (LLVM=1|CC=clang)+LLVM_IAS=0 builds.
* add -gdwarf-5 to Kconfig shell script.
* only run Kconfig shell script for Clang.

Apologies to Sedat and Nathan; I appreciate previous testing/review, but
I did no carry forward your Tested-by and Reviewed-by tags, as the
patches have changed too much IMO.

Changes from v2:
* Drop two of the earlier patches that have been accepted already.
* Add measurements with GCC 10.2 to commit message.
* Update help text as per Arvind with help from Caroline.
* Improve case/wording between DWARF Versions as per Masahiro.

Changes from the RFC:
* split patch in 3 patch series, include Fangrui's patch, too.
* prefer `DWARF vX` format, as per Fangrui.
* use spaces between assignment in Makefile as per Masahiro.
* simplify setting dwarf-version-y as per Masahiro.
* indent `prompt` in Kconfig change as per Masahiro.
* remove explicit default in Kconfig as per Masahiro.
* add comments to test_dwarf5_support.sh.
* change echo in test_dwarf5_support.sh as per Masahiro.
* remove -u from test_dwarf5_support.sh as per Masahiro.
* add a -gdwarf-5 cc-option check to Kconfig as per Jakub.

Nick Desaulniers (2):
Kbuild: make DWARF version a choice
Kbuild: implement support for DWARF v5

Makefile | 6

Re: [PATCH] ALSA: usb-audio: endpoint : remove redundant check before usb_free_coherent()

2021-02-03 Thread Takashi Iwai

On Thu, 04 Feb 2021 03:05:18 +0100,
Xu Wang wrote:
> 
> usb_free_coherent() is safe with NULL addr and this check is
> not required.

The check there isn't about NULL buffer or not; instead it checks
whether the buffer was allocated for each or it shares the single
buffer (for sync endpoints).  In the latter case, your patch will lead
to double-free.

thanks,

Takashi

[PATCH] drm/komeda: convert sysfs sprintf/snprintf family to sysfs_emit

Fix the following coccicheck warning:

./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING: use
scnprintf or sprintf.

./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING: use
scnprintf or sprintf.

./drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING: use
scnprintf or sprintf.

Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index ca891ae..cc7664c 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -62,7 +62,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
 {
struct komeda_dev *mdev = dev_to_mdev(dev);
 
-   return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id);
+   return sysfs_emit(buf, "0x%08x\n", mdev->chip.core_id);
 }
 static DEVICE_ATTR_RO(core_id);
 
@@ -85,7 +85,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER)
config_id.n_richs++;
}
-   return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value);
+   return sysfs_emit(buf, "0x%08x\n", config_id.value);
 }
 static DEVICE_ATTR_RO(config_id);
 
@@ -94,7 +94,7 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
 {
struct komeda_dev *mdev = dev_to_mdev(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%lu\n", clk_get_rate(mdev->aclk));
+   return sysfs_emit(buf, "%lu\n", clk_get_rate(mdev->aclk));
 }
 static DEVICE_ATTR_RO(aclk_hz);
 
-- 
1.8.3.1

Re: [PATCH v14 8/8] mm: hugetlb: optimize the code with the help of the compiler

2021-02-03 Thread Miaohe Lin

On 2021/2/4 11:50, Muchun Song wrote:
> We cannot optimize if a "struct page" crosses page boundaries. If
> it is true, we can optimize the code with the help of a compiler.
> When free_vmemmap_pages_per_hpage() returns zero, most functions are
> optimized by the compiler.
> 
> Signed-off-by: Muchun Song 

I like it. Thanks.
Reviewed-by: Miaohe Lin 

> ---
>  include/linux/hugetlb.h |  3 ++-
>  mm/hugetlb_vmemmap.c| 13 +
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 822ab2f5542a..7bfb06e16298 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -878,7 +878,8 @@ extern bool hugetlb_free_vmemmap_enabled;
>  
>  static inline bool is_hugetlb_free_vmemmap_enabled(void)
>  {
> - return hugetlb_free_vmemmap_enabled;
> + return hugetlb_free_vmemmap_enabled &&
> +is_power_of_2(sizeof(struct page));
>  }
>  #else
>  static inline bool is_hugetlb_free_vmemmap_enabled(void)
> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
> index 8efad9978821..068d0e0cebc8 100644
> --- a/mm/hugetlb_vmemmap.c
> +++ b/mm/hugetlb_vmemmap.c
> @@ -211,6 +211,12 @@ early_param("hugetlb_free_vmemmap", 
> early_hugetlb_free_vmemmap_param);
>   */
>  static inline unsigned int free_vmemmap_pages_per_hpage(struct hstate *h)
>  {
> + /*
> +  * This check aims to let the compiler help us optimize the code as
> +  * much as possible.
> +  */
> + if (!is_power_of_2(sizeof(struct page)))
> + return 0;
>   return h->nr_free_vmemmap_pages;
>  }
>  
> @@ -280,6 +286,13 @@ void __init hugetlb_vmemmap_init(struct hstate *h)
>   BUILD_BUG_ON(NR_USED_SUBPAGE >=
>RESERVE_VMEMMAP_SIZE / sizeof(struct page));
>  
> + /*
> +  * The compiler can help us to optimize this function to null
> +  * when the size of the struct page is not power of 2.
> +  */
> + if (!is_power_of_2(sizeof(struct page)))
> + return;
> +
>   if (!hugetlb_free_vmemmap_enabled)
>   return;
>  
>

[PATCH] ceph: minor coding style tweaks

2021-02-03 Thread Zhiyuan Dai

Fixed some coding style issues, improve code reading.

Signed-off-by: Zhiyuan Dai 
---
 fs/ceph/addr.c   |  3 +--
 fs/ceph/cache.c  | 14 +++---
 fs/ceph/caps.c   |  2 +-
 fs/ceph/dir.c|  6 +++---
 fs/ceph/export.c |  2 +-
 fs/ceph/inode.c  |  6 +++---
 fs/ceph/locks.c  |  2 +-
 fs/ceph/mds_client.c |  8 
 fs/ceph/mdsmap.c |  4 ++--
 fs/ceph/snap.c   |  6 +++---
 fs/ceph/xattr.c  |  4 ++--
 11 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 9505529..94ce73e 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -493,8 +493,7 @@ static int ceph_readpages(struct file *file, struct 
address_space *mapping,
return rc;
 }
 
-struct ceph_writeback_ctl
-{
+struct ceph_writeback_ctl {
loff_t i_size;
u64 truncate_size;
u32 truncate_seq;
diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
index 2f5cb6b..795523e 100644
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -50,7 +50,7 @@ void ceph_fscache_unregister(void)
fscache_unregister_netfs(_cache_netfs);
 }
 
-int ceph_fscache_register_fs(struct ceph_fs_client* fsc, struct fs_context *fc)
+int ceph_fscache_register_fs(struct ceph_fs_client *fsc, struct fs_context *fc)
 {
const struct ceph_fsid *fsid = >client->fsid;
const char *fscache_uniq = fsc->mount_options->fscache_uniq;
@@ -110,8 +110,8 @@ static enum fscache_checkaux ceph_fscache_inode_check_aux(
loff_t object_size)
 {
struct ceph_aux_inode aux;
-   struct ceph_inode_info* ci = cookie_netfs_data;
-   struct inode* inode = >vfs_inode;
+   struct ceph_inode_info *ci = cookie_netfs_data;
+   struct inode *inode = >vfs_inode;
 
if (dlen != sizeof(aux) ||
i_size_read(inode) != object_size)
@@ -164,9 +164,9 @@ void ceph_fscache_register_inode_cookie(struct inode *inode)
inode_unlock(inode);
 }
 
-void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info* ci)
+void ceph_fscache_unregister_inode_cookie(struct ceph_inode_info *ci)
 {
-   struct fscache_cookie* cookie;
+   struct fscache_cookie *cookie;
 
if ((cookie = ci->fscache) == NULL)
return;
@@ -296,7 +296,7 @@ void ceph_readpage_to_fscache(struct inode *inode, struct 
page *page)
 fscache_uncache_page(ci->fscache, page);
 }
 
-void ceph_invalidate_fscache_page(struct inode* inode, struct page *page)
+void ceph_invalidate_fscache_page(struct inode *inode, struct page *page)
 {
struct ceph_inode_info *ci = ceph_inode(inode);
 
@@ -307,7 +307,7 @@ void ceph_invalidate_fscache_page(struct inode* inode, 
struct page *page)
fscache_uncache_page(ci->fscache, page);
 }
 
-void ceph_fscache_unregister_fs(struct ceph_fs_client* fsc)
+void ceph_fscache_unregister_fs(struct ceph_fs_client *fsc)
 {
if (fscache_cookie_valid(fsc->fscache)) {
struct ceph_fscache_entry *ent;
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 255a512..39fe5d8 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -2270,7 +2270,7 @@ static int caps_are_flushed(struct inode *inode, u64 
flush_tid)
 
spin_lock(>i_ceph_lock);
if (!list_empty(>i_cap_flush_list)) {
-   struct ceph_cap_flush * cf =
+   struct ceph_cap_flush *cf =
list_first_entry(>i_cap_flush_list,
 struct ceph_cap_flush, i_list);
if (cf->tid <= flush_tid)
diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
index 858ee73..2b7edd00 100644
--- a/fs/ceph/dir.c
+++ b/fs/ceph/dir.c
@@ -1269,7 +1269,7 @@ void __ceph_dentry_lease_touch(struct ceph_dentry_info 
*di)
spin_unlock(>dentry_list_lock);
 }
 
-static void __dentry_dir_lease_touch(struct ceph_mds_client* mdsc,
+static void __dentry_dir_lease_touch(struct ceph_mds_client *mdsc,
 struct ceph_dentry_info *di)
 {
di->flags &= ~(CEPH_DENTRY_LEASE_LIST | CEPH_DENTRY_REFERENCED);
@@ -1351,7 +1351,7 @@ struct ceph_lease_walk_control {
 {
struct ceph_dentry_info *di, *tmp;
struct dentry *dentry, *last = NULL;
-   struct list_head* list;
+   struct list_head *list;
 LIST_HEAD(dispose);
unsigned long freed = 0;
int ret = 0;
@@ -1498,7 +1498,7 @@ int ceph_trim_dentries(struct ceph_mds_client *mdsc)
lwc.dir_lease = true;
lwc.expire_dir_lease = freed < count;
lwc.dir_lease_ttl = mdsc->fsc->mount_options->caps_wanted_delay_max * 
HZ;
-   freed +=__dentry_leases_walk(mdsc, , __dir_lease_check);
+   freed += __dentry_leases_walk(mdsc, , __dir_lease_check);
if (!lwc.nr_to_scan) /* more to check */
return -EAGAIN;
 
diff --git a/fs/ceph/export.c b/fs/ceph/export.c
index e088843..83ec43f 100644
--- a/fs/ceph/export.c
+++ b/fs/ceph/export.c
@@ -343,7 +343,7 @@ static struct dentry *ceph_get_parent(struct dentry *child)
struct

[PATCH 1/1] PCI/AER: Change to use helper pcie_aer_is_native() in some places

2021-02-03 Thread Xiaofei Tan

Use helper function pcie_aer_is_native() in some places to keep
the code tidy. No function changes.

Signed-off-by: Xiaofei Tan 
---
 drivers/pci/pcie/aer.c  | 4 ++--
 drivers/pci/pcie/err.c  | 2 +-
 drivers/pci/pcie/portdrv_core.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 77b0f2c..03212d0 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1397,7 +1397,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
 */
aer = root ? root->aer_cap : 0;
 
-   if ((host->native_aer || pcie_ports_native) && aer) {
+   if (pcie_aer_is_native(dev) && aer) {
/* Disable Root's interrupt in response to error messages */
pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
@@ -1417,7 +1417,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
pci_info(dev, "Root Port link has been reset (%d)\n", rc);
}
 
-   if ((host->native_aer || pcie_ports_native) && aer) {
+   if (pcie_aer_is_native(dev) && aer) {
/* Clear Root Error Status */
pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 510f31f..1d6cfb9 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -237,7 +237,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
 * this status.  In that case, the signaling device may not even be
 * visible to the OS.
 */
-   if (host->native_aer || pcie_ports_native) {
+   if (pcie_aer_is_native(dev)) {
pcie_clear_device_status(bridge);
pci_aer_clear_nonfatal_status(bridge);
}
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e1fed664..1e6a690 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -222,7 +222,7 @@ static int get_port_device_capability(struct pci_dev *dev)
 
 #ifdef CONFIG_PCIEAER
if (dev->aer_cap && pci_aer_available() &&
-   (pcie_ports_native || host->native_aer)) {
+   pcie_aer_is_native(dev)) {
services |= PCIE_PORT_SERVICE_AER;
 
/*
-- 
2.8.1

Re: [PATCH][next] usb: cdnsp: Fix spelling mistake "delagete" -> "delegate"

2021-02-03 Thread Greg Kroah-Hartman

On Thu, Feb 04, 2021 at 05:07:16AM +, Pawel Laszczak wrote:
> Hi Dan,
> 
> >> From: Colin Ian King 
> >>
> >> There is a spelling mistake in a literal string. Fix it.
> >>
> >> Signed-off-by: Colin Ian King 
> >> ---
> >>  drivers/usb/cdns3/cdnsp-ep0.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c
> >> index e2b1bcb3f80e..e30931ebc870 100644
> >> --- a/drivers/usb/cdns3/cdnsp-ep0.c
> >> +++ b/drivers/usb/cdns3/cdnsp-ep0.c
> >> @@ -45,7 +45,7 @@ static int cdnsp_ep0_delegate_req(struct cdnsp_device 
> >> *pdev,
> >>  {
> >>int ret;
> >>
> >> -  trace_cdnsp_ep0_request("delagete");
> >> +  trace_cdnsp_ep0_request("delegate");
> >>
> >
> >This printk is useless and should just be deleted.  Use ftrace instead.
> 
> Maybe this printk is redundant but it's more comfortable in use.
> To debug I can simply enable cdns-dev events (echo cdnsp-dev:* > set_event)
> and I will get the full  picture of what the driver is doing.
> 
> Otherwise, I must remember which function I need to add to set_ftrace_filter.
> Of course, by default I can simply add all cdnsp* functions (echo cdnsp* > 
> set_ftrace_filter) but it
> increases the trace log and makes it a little more difficult to analyze.
> 
> So maybe in some cases we shouldn't complain for such printk ?
> 
> It's my private opinion and not necessarily correct :)

Please don't have duplicate tracepoints for something like "this
function is now called", it's redundant.

thanks,

greg k-h

Re: [PATCH] x86: Add a prompt for HPET_EMULATE_RTC

2021-02-03 Thread Randy Dunlap

On 2/3/21 10:13 PM, Anand K. Mistry wrote:
>> Hi,
>>
>> When you run "make olddefconfig", should this "depends on"
>> line evaluate to true or false?
> 
> True. RTC_DRV_CMOS=y by default on x86 systems and HPET_TIMER also
> appears to default yes (on x86-64 if I'm reading this right).
> 
> Oddly, the RTC config option doesn't appear to exist. Probably a separate 
> issue.

Yes, just a separate simple patch.

>> I.e., what are the settings of these symbols in the old .config file?
>>
>>
>> depends on HPET_TIMER && (RTC=y || RTC=m || RTC_DRV_CMOS=m || 
>> RTC_DRV_CMOS=y)
> 
> Actually, none of these options are set in the old config.
> RTC_DRV_CMOS and HPET_TIMER appear to default to yes.
> 
>  % grep HPET .config
> CONFIG_HPET=y
> # CONFIG_HPET_EMULATE_RTC is not set
> # CONFIG_HPET_MMAP is not set
>  % grep RTC .config
> CONFIG_RTC_CLASS=y
> # CONFIG_HPET_EMULATE_RTC is not set
> CONFIG_PM_TRACE_RTC=y
> # CONFIG_RTC_HCTOSYS is not set
> 
>>
>> If not, is there some out-of-tree driver involved?
> 
> No out of tree drivers involved. I tried this on a vanilla 5.11-rc6.
> 
>> I'm having a little trouble seeing why this is needed.
> 
> So am I. But this is the magic that lets me keep
> CONFIG_HPET_EMULATE_RTC from the old config. I did manage to trace
> where the option is being overridden in the conf tool, but the
> reasoning why is beyond my knowledge.

Can you post the .config that you are feeding to 'make olddefconfig', please.
I'll take a look (or the x86 guys can do so).


thanks.
-- 
~Randy

[PATCH] btrfs: Remove unneeded return variable