Re: [PATCH 1/4] dt-bindings: arm: ti: Add bindings for J7200 SoC

[Lokesh Vutla]

Hi Nishanth,

On 27/08/20 5:53 am, Nishanth Menon wrote:
> On 14:16-20200723, Lokesh Vutla wrote:
>> The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
>> It is targeted for automotive gateway, vehicle compute systems,
>> Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
>> The SoC aims to meet the complex processing needs of modern embedded
>> products.
>>
>> Some highlights of this SoC are:
>> * Dual Cortex-A72s in a single cluster, two clusters of lockstep
>>   capable dual Cortex-R5F MCUs and a Centralized Device Management and
>>   Security Controller (DMSC).
>> * Configurable L3 Cache and IO-coherent architecture with high data
>>   throughput capable distributed DMA architecture under NAVSS.
>> * Integrated Ethernet switch supporting up to a total of 4 external ports
>>   in addition to legacy Ethernet switch of up to 2 ports.
>> * Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
>>   20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C and
>>   I2C, eCAP/eQEP, eHRPWM among other peripherals.
>> * One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
>>   management.
>>
>> See J7200 Technical Reference Manual (SPRUIU1, June 2020)
>> for further details: https://www.ti.com/lit/pdf/spruiu1
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>  Documentation/devicetree/bindings/arm/ti/k3.txt | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt 
>> b/Documentation/devicetree/bindings/arm/ti/k3.txt
>> index 333e7256126a..33419cce0afa 100644
>> --- a/Documentation/devicetree/bindings/arm/ti/k3.txt
>> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
>> @@ -16,6 +16,9 @@ architecture it uses, using one of the following 
>> compatible values:
>>  - J721E
>>compatible = "ti,j721e";
>>  
>> +- J7200
>> +  compatible = "ti,j7200";
>> +
>>  Boards
>>  --
> 
> Lets convert the k3.txt to k3.yaml before we do anything more here.
> Looking at the full series, I see that there are pending comments from

okay, I can switch Patch 1 and 2.

> Grygorii as well which needs to be looked at. I have'nt seen a follow up
> version since this version.

Grygorii replied to the same asking to ignore his mail[0]

[0] https://patchwork.kernel.org/cover/11680441/

Thanks and regards,
Lokesh

> 
> [1] 
> https://lore.kernel.org/linux-arm-kernel/20200723084628.19241-1-lokeshvu...@ti.com/
> 

Re: [PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Chanwoo Choi]

Hi,

You better to change the 'state' word to 'capability'.
Actually, this patch doesn't change the value of property.
It set the capability value of property.

"Set the VBUS and POLARITY property capability"

On 8/27/20 12:56 PM, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Set the VBUS and POLARITY property state.

ditto. Need to change the work from 'state' and 'capability'.

> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 8b930050a3f1..b5217a61615c 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   return ret;
>   }
>  
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> +EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> +EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> +EXTCON_PROP_USB_TYPEC_POLARITY);

Need to add blank line.

I understood that you set the property capability
because of get_flipped() function of your patch[1].

But, I think that you need to change the value of EXTCON_PROP_USB_TYPEC_POLARITY
when changing the state of EXTCON_USB_HOST. The polarity property value is 
always
zero regardless of EXTCON_USB_HOST state as following: The get_flipped()[1] 
returns
always the same *flipped value.

EXTCON_USB_HOST is 1, EXTCON_PROP_USB_TYPEC_POLARITY is 0
EXTCON_USB_HOST is 0, EXTCON_PROP_USB_TYPEC_POLARITY is 0

If EXTCON_PROP_USB_TYPEC_POLARITY value is not related to any behavior,
you don't need to get the property value from extcon consumer driver
like drivers/phy/phy-lgm-usb.c.

Actually, I don't understand why you don't handle the value
of EXTCON_PROP_USB_TYPEC_POLARITY. 

Or, are there any case of what drivers/phy/phy-lgm-usb.c
uses the different extcon device with EXTCON_PROP_USB_TYPEC_POLARITY property
in the future?

So, do you set the EXTCON_PROP_USB_TYPEC_POLARITY capability 
for the extensibility in order to use other extcon device on later?


[1] https://www.spinics.net/lists/devicetree/msg371828.html
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+   union extcon_property_value property;
+   int ret;
+
+   ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, &property);
+   if (ret) {
+   dev_err(ta->phy.dev, "no polarity property from extcon\n");
+   return ret;
+   }
+
+   *flipped = property.intval;
+
+   return ret;
+}


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


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] drm/ingenic: Fix driver not probing when IPU port is missing

[Sam Ravnborg]

Hi Paul.

On Wed, Aug 26, 2020 at 11:58:41PM +0200, Paul Cercueil wrote:
> Even if support for the IPU was compiled in, we may run on a device
> (e.g. the Qi LB60) where the IPU is not available, or simply with an old
> devicetree without the IPU node. In that case the ingenic-drm refused to
> probe.
> 
> Fix the driver so that it will probe even if the IPU node is not present
> in devicetree (but then IPU support is disabled of course).
> 
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index ada990a7f911..216b67f1672e 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -673,6 +673,18 @@ static void ingenic_drm_unbind_all(void *d)
>   component_unbind_all(priv->dev, &priv->drm);
>  }
>  
> +static inline struct device_node *ingenic_drm_get_ipu_node(struct device 
> *dev)
> +{
> + /* IPU is at port address 8 */
> + return of_graph_get_remote_node(dev->of_node, 8, 0);
> +}
kernel-doc for of_graph_get_remote_node() says:

* Return: Remote device node associated with remote endpoint node linked
*  to @node. Use of_node_put() on it when done.

In other words this code leaks a device node.
This was the case with the old code too.

Sam

> +
> +static inline bool ingenic_drm_has_ipu(struct device *dev)
> +{
> + return IS_ENABLED(CONFIG_DRM_INGENIC_IPU) &&
> + !!ingenic_drm_get_ipu_node(dev);
> +}
> +
>  static int ingenic_drm_bind(struct device *dev)
>  {
>   struct platform_device *pdev = to_platform_device(dev);
> @@ -808,7 +820,7 @@ static int ingenic_drm_bind(struct device *dev)
>   return ret;
>   }
>  
> - if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
> + if (ingenic_drm_has_ipu(dev)) {
>   ret = component_bind_all(dev, drm);
>   if (ret) {
>   if (ret != -EPROBE_DEFER)
> @@ -970,12 +982,9 @@ static int ingenic_drm_probe(struct platform_device 
> *pdev)
>   if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
>   return ingenic_drm_bind(dev);
>  
> - /* IPU is at port address 8 */
> - np = of_graph_get_remote_node(dev->of_node, 8, 0);
> - if (!np) {
> - dev_err(dev, "Unable to get IPU node\n");
> - return -EINVAL;
> - }
> + np = ingenic_drm_get_ipu_node(dev);
> + if (!np)
> + return ingenic_drm_bind(dev);
>  
>   drm_of_component_match_add(dev, &match, compare_of, np);
>  
> -- 
> 2.28.0

Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control

[Hoegeun Kwon]

Hi Stefan,

Thank you for your review.


On 8/26/20 7:04 PM, Stefan Wahren wrote:
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>> There is a problem that the output does not work at a resolution
>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>> resolution exceeding FHD.
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?

As far as I know, BCM2711 raspberry pi 4 supports 4k,

don't supported on pi 3 and pi 3+.

Since 4k is not supported in versions prior to Raspberry Pi 4,

I don't think we need to modify the bvb clock.


So I think it is better to update 'brcm,bcm2711-hdmi.yaml'

instead of 'brcm,bcm2835-hdmi.yaml'.

Please comment, what do you think?

>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.

Tested it several times with libdrm modetest.

I expect there will be no problem.


Best regards,

Hoegeun

>
> Best regards
> Stefan
>
>> Signed-off-by: Hoegeun Kwon 
>> ---
>>   drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>   drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 95ec5eedea39..eb3192d1fd86 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -80,6 +80,7 @@
>>   # define VC4_HD_M_ENABLE   BIT(0)
>>   
>>   #define CEC_CLOCK_FREQ 4
>> +#define VC4_HSM_MID_CLOCK 149985000
>>   
>>   static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>   {
>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct 
>> drm_encoder *encoder)
>>  HDMI_WRITE(HDMI_VID_CTL,
>> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>   
>> +clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>  clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>  clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>   
>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct 
>> drm_encoder *encoder)
>>  return;
>>  }
>>   
>> +ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>> +(hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>> +if (ret) {
>> +DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>> +ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>> +if (ret) {
>> +DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>> +clk_disable_unprepare(vc4_hdmi->hsm_clock);
>> +clk_disable_unprepare(vc4_hdmi->pixel_clock);
>> +return;
>> +}
>> +
>>  if (vc4_hdmi->variant->reset)
>>  vc4_hdmi->variant->reset(vc4_hdmi);
>>   
>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi 
>> *vc4_hdmi)
>>  return PTR_ERR(vc4_hdmi->audio_clock);
>>  }
>>   
>> +vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>> +if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>> +DRM_ERROR("Failed to get pixel bvb clock\n");
>> +return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>> +}
>> +
>>  vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>  if (IS_ERR(vc4_hdmi->reset)) {
>>  DRM_ERROR("Failed to get HDMI reset line\n");
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> index 0806c6d9f24e..63c6f8bddf1d 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>  struct clk *pixel_clock;
>>  struct clk *hsm_clock;
>>  struct clk *audio_clock;
>> +struct clk *pixel_bvb_clock;
>>   
>>  struct reset_control *reset;
>>   
>

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

[Lu Baolu]

Hi Kevin,

On 8/26/20 1:29 PM, Tian, Kevin wrote:

From: Lu Baolu
Sent: Wednesday, August 26, 2020 10:58 AM

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

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

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

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

diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index 9564d23d094f..19d7e18876fe 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -507,12 +507,16 @@ static void iommu_enable_irq_remapping(struct
intel_iommu *iommu)

/* Enable interrupt-remapping */
iommu->gcmd |= DMA_GCMD_IRE;
-   iommu->gcmd &= ~DMA_GCMD_CFI;  /* Block compatibility-format
MSIs */
writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
-
IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
  readl, (sts & DMA_GSTS_IRES), sts);

+   /* Block compatibility-format MSIs */
+   iommu->gcmd &= ~DMA_GCMD_CFI;
+   writel(iommu->gcmd, iommu->reg + DMAR_GCMD_REG);
+   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
+ readl, !(sts & DMA_GSTS_CFIS), sts);
+


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


Yes. Make sense. Will send a new version with this changed.

Best regards,
baolu




/*
 * With CFI clear in the Global Command register, we should be
 * protected from dangerous (i.e. compatibility) interrupts
--
2.17.1

___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

[Lu Baolu]

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

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

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

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

Change log:
v1->v2:
  - v1 posted here

https://lore.kernel.org/linux-iommu/20200826025825.2322-1-baolu...@linux.intel.com/;
  - Add status check before disabling CFI. (Kevin)

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

Re: [PATCH v2 1/2] drm/amdkfd: Move the ignore_crat check before the CRAT table get

[Felix Kuehling]

Am 2020-08-26 um 4:29 a.m. schrieb Hanjun Guo:
> If the ignore_crat is set to non-zero value, it's no point getting
> the CRAT table, so just move the ignore_crat check before we get the
> CRAT table.
>
> Signed-off-by: Hanjun Guo 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 6a250f8..ed77b109 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -764,6 +764,11 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
> *size)
>  
>   *crat_image = NULL;
>  
> + if (ignore_crat) {

A conflicting change in this area was just submitted on Monday to
amd-staging-drm-next. You'll need to rebase your patch. It should be
straight-forward. ignore_crat was replaced with a function call
kfd_ignore_crat().

Other than that, your patch series looks good to me. If I don't see an
update from you in a day or two, I'll fix it up myself and add my R-b.

Thanks,
  Felix


> + pr_info("CRAT table disabled by module option\n");
> + return -ENODATA;
> + }
> +
>   /* Fetch the CRAT table from ACPI */
>   status = acpi_get_table(CRAT_SIGNATURE, 0, &crat_table);
>   if (status == AE_NOT_FOUND) {
> @@ -776,11 +781,6 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
> *size)
>   return -EINVAL;
>   }
>  
> - if (ignore_crat) {
> - pr_info("CRAT table disabled by module option\n");
> - return -ENODATA;
> - }
> -
>   pcrat_image = kmemdup(crat_table, crat_table->length, GFP_KERNEL);
>   if (!pcrat_image)
>   return -ENOMEM;

[tip:x86/urgent] BUILD SUCCESS d4f07268d035721dd055ceb0de98ace6ac5f858b

[kernel test robot]

   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386 randconfig-a001-20200826
x86_64   randconfig-a015-20200826
x86_64   randconfig-a016-20200826
x86_64   randconfig-a012-20200826
x86_64   randconfig-a014-20200826
x86_64   randconfig-a011-20200826
x86_64   randconfig-a013-20200826
i386 randconfig-a013-20200826
i386 randconfig-a012-20200826
i386 randconfig-a011-20200826
i386 randconfig-a016-20200826
i386 randconfig-a015-20200826
i386 randconfig-a014-20200826
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

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

Re: [PATCH v2 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver

[Viresh Kumar]

On 26-08-20, 20:57, Hector Yuan wrote:
> On Mon, 2020-08-24 at 15:36 +0530, Viresh Kumar wrote:
> > On 13-08-20, 15:07, Hector Yuan wrote:
> > >  CONFIG_ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM=m
> > >  CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
> > > +CONFIG_ARM_MEDIATEK_CPUFREQ_HW=m
> > 
> > What about a 'default m' in Kconfig itself ?
> > OK, will update in V3.

Hector, you need to remove (or not add) the right bracket (>) before the
beginning of your lines. This makes it incredibly difficult to read.

> > > + for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> > > + data = readl_relaxed(base + (i * LUT_ROW_SIZE));
> > > + freq = FIELD_GET(LUT_FREQ, data) * 1000;
> > > + volt = FIELD_GET(LUT_VOLT, data);
> > > + if (freq != prev_freq) {
> > > + table[i].frequency = freq;
> > > + dev_pm_opp_add(cpu_dev, freq * 1000, volt);
> > 
> > Why are you adding OPPs here and rather why using OPP specific stuff
> > at all in the driver ?
> > yes, the opp information is read from CPU HW engine.Then add it to the CPU 
> > dev OPP one by one.  

I asked a different question, why are you adding OPPs ? You don't need the OPPs
at all in my opinion. You can just create the frequency table and that's it.

> > > + for_each_possible_cpu(cpu) {
> > > + cpu_np = of_cpu_device_node_get(cpu);
> > > + if (!cpu_np)
> > > + continue;
> > > +
> > > + ret = of_parse_phandle_with_args(cpu_np, "mtk,freq-domain",
> > 
> > Where are bindings of this node and how does this look ?
> > Can refer to the same patch series, I split it to another patch.Each cpu 
> > will be group into one frequency domain for the CPU DVFS. 

That binding only defines "mediatek,cpufreq-hw" and not "mtk,freq-domain".

-- 
viresh

[PATCH v2] drm/vkms: avoid warning in vkms_get_vblank_timestamp

[Sidong Yang]

This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't
enabled. When running igt test kms_cursor_crc just after vkms module, the
warning raised like below. Initial value of vblank time is zero and
hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module
isn't real hardware but just virtual hardware module. so vkms can't generate a
resonable timestamp when hrtimer is off. it's best to grab the current time.

[106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change
[106444.471475] WARNING: CPU: 0 PID: 10109 at
/home/realwakka/git/linux/drivers/gpu/drm/vkms//vkms_crtc.c:91
vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: GW  OE
5.9.0-rc1+ #6
[106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471528] Call Trace:
[106444.471551]  drm_get_last_vbltimestamp+0xb9/0xd0 [drm]
[106444.471566]  drm_reset_vblank_timestamp+0x63/0xe0 [drm]
[106444.471579]  drm_crtc_vblank_on+0x85/0x150 [drm]
[106444.471582]  vkms_crtc_atomic_enable+0xe/0x10 [vkms]
[106444.471592]  drm_atomic_helper_commit_modeset_enables+0x1db/0x230
[drm_kms_helper]
[106444.471594]  vkms_atomic_commit_tail+0x38/0xc0 [vkms]
[106444.471601]  commit_tail+0x97/0x130 [drm_kms_helper]
[106444.471608]  drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper]
[106444.471622]  drm_atomic_commit+0x4a/0x50 [drm]
[106444.471629]  drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper]
[106444.471642]  drm_mode_setcrtc+0x1d9/0x7b0 [drm]
[106444.471654]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471666]  drm_ioctl_kernel+0xb6/0x100 [drm]
[106444.471677]  drm_ioctl+0x3ad/0x470 [drm]
[106444.471688]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471692]  ? tomoyo_file_ioctl+0x19/0x20
[106444.471694]  __x64_sys_ioctl+0x96/0xd0
[106444.471697]  do_syscall_64+0x37/0x80
[106444.471699]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Sidong Yang 

---

v2:
 - modify commit message to make it a bit easier to understand. 

---
 drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..09c012d54d58 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
struct vkms_output *output = &vkmsdev->output;
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
 
+   if (!READ_ONCE(vblank->enabled)) {
+   *vblank_time = ktime_get();
+   return true;
+   }
+
*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
 
if (WARN_ON(*vblank_time == vblank->time))
-- 
2.17.1

[tip:x86/cache] BUILD SUCCESS 29b6bd41ee24f69a85666b9f68d500b382d408fd

[kernel test robot]

allyesconfig
xtensa   allyesconfig
h8300allyesconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386 randconfig-a001-20200826
x86_64   randconfig-a015-20200826
x86_64   randconfig-a016-20200826
x86_64   randconfig-a012-20200826
x86_64   randconfig-a014-20200826
x86_64   randconfig-a011-20200826
x86_64   randconfig-a013-20200826
i386 randconfig-a013-20200826
i386 randconfig-a012-20200826
i386 randconfig-a011-20200826
i386 randconfig-a016-20200826
i386 randconfig-a015-20200826
i386 randconfig-a014-20200826
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes

[kernel test robot]

Hi Ard,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   15bc20c6af4ceee97a1f90b43c0e386643c071b4
commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move existing 
library code into lib/crypto
date:   9 months ago
config: i386-randconfig-r015-20200827 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All warnings (new ones prefixed by >>):

   lib/crypto/chacha.c: In function 'chacha_permute':
>> lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger 
>> than 1024 bytes [-Wframe-larger-than=]
  65 | }
 | ^

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fb8ef25803ef33e2eb60b626435828b937bed75
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
vim +65 lib/crypto/chacha.c

e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  16  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  17  static void 
chacha_permute(u32 *x, int nrounds)
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  18  {
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  19  int i;
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  20  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  21  /* whitelist 
the allowed round counts */
aa7624093cb7fb lib/chacha.c   Eric Biggers  2018-11-16  22  
WARN_ON_ONCE(nrounds != 20 && nrounds != 12);
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  23  
1ca1b917940c24 lib/chacha.c   Eric Biggers  2018-11-16  24  for (i = 0; i < 
nrounds; i += 2) {
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  25  x[0]  
+= x[4];x[12] = rol32(x[12] ^ x[0],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  26  x[1]  
+= x[5];x[13] = rol32(x[13] ^ x[1],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  27  x[2]  
+= x[6];x[14] = rol32(x[14] ^ x[2],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  28  x[3]  
+= x[7];x[15] = rol32(x[15] ^ x[3],  16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  29  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  30  x[8]  
+= x[12];   x[4]  = rol32(x[4]  ^ x[8],  12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  31  x[9]  
+= x[13];   x[5]  = rol32(x[5]  ^ x[9],  12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  32  x[10] 
+= x[14];   x[6]  = rol32(x[6]  ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  33  x[11] 
+= x[15];   x[7]  = rol32(x[7]  ^ x[11], 12);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  34  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  35  x[0]  
+= x[4];x[12] = rol32(x[12] ^ x[0],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  36  x[1]  
+= x[5];x[13] = rol32(x[13] ^ x[1],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  37  x[2]  
+= x[6];x[14] = rol32(x[14] ^ x[2],   8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  38  x[3]  
+= x[7];x[15] = rol32(x[15] ^ x[3],   8);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  39  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  40  x[8]  
+= x[12];   x[4]  = rol32(x[4]  ^ x[8],   7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  41  x[9]  
+= x[13];   x[5]  = rol32(x[5]  ^ x[9],   7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  42  x[10] 
+= x[14];   x[6]  = rol32(x[6]  ^ x[10],  7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  43  x[11] 
+= x[15];   x[7]  = rol32(x[7]  ^ x[11],  7);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  44  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  45  x[0]  
+= x[5];x[15] = rol32(x[15] ^ x[0],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  46  x[1]  
+= x[6];x[12] = rol32(x[12] ^ x[1],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  47  x[2]  
+= x[7];x[13] = rol32(x[13] ^ x[2],  16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  48  x[3]  
+= x[4];x[14] = rol32(x[14] ^ x[3],  16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12  49  
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  50  x[10] 
+= x[15];   x[5]  = rol32(x[5]  ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers  2017-12-31  51

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

[Ashok Raj]

There is a race when taking a CPU offline. Current code looks like this:

native_cpu_disable()
{
...
apic_soft_disable();
/*
 * Any existing set bits for pending interrupt to
 * this CPU are preserved and will be sent via IPI
 * to another CPU by fixup_irqs().
 */
cpu_disable_common();
{

/*
 * Race window happens here. Once local APIC has been
 * disabled any new interrupts from the device to
 * the old CPU are lost
 */
fixup_irqs(); // Too late to capture anything in IRR.
...
}
}

The fix is to disable the APIC *after* cpu_disable_common().

Testing was done with a USB NIC that provided a source of frequent
interrupts. A script migrated interrupts to a specific CPU and
then took that CPU offline.

Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
Reported-by: Evan Green 
Tested-by: Mathias Nyman 
Tested-by: Evan Green 
Reviewed-by: Evan Green 
Signed-off-by: Ashok Raj 
---
v3:
Fix commit message and comments per Thomas.
https://lore.kernel.org/lkml/87mu2iw86q@nanos.tec.linutronix.de/

v2:
- Typos and fixes suggested by Randy Dunlap

To: linux-kernel@vger.kernel.org
To: Thomas Gleixner 
Cc: Sukumar Ghorai 
Cc: Srikanth Nandamuri 
Cc: Evan Green 
Cc: Mathias Nyman 
Cc: Bjorn Helgaas 
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
---
 arch/x86/kernel/smpboot.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 27aa04a95702..f5ef689dd62a 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1594,14 +1594,28 @@ int native_cpu_disable(void)
if (ret)
return ret;
 
-   /*
-* Disable the local APIC. Otherwise IPI broadcasts will reach
-* it. It still responds normally to INIT, NMI, SMI, and SIPI
-* messages.
-*/
-   apic_soft_disable();
cpu_disable_common();
 
+/*
+ * Disable the local APIC. Otherwise IPI broadcasts will reach
+ * it. It still responds normally to INIT, NMI, SMI, and SIPI
+ * messages.
+ *
+ * Disabling the APIC must happen after cpu_disable_common()
+ * which invokes fixup_irqs().
+ *
+ * Disabling the APIC preserves already set bits in IRR, but
+ * an interrupt arriving after disabling the local APIC does not
+ * set the corresponding IRR bit.
+ *
+ * fixup_irqs() scans IRR for set bits so it can raise a not
+ * yet handled interrupt on the new destination CPU via an IPI
+ * but obviously it can't do so for IRR bits which are not set.
+ * IOW, interrupts arriving after disabling the local APIC will
+ * be lost.
+ */
+   apic_soft_disable();
+
return 0;
 }
 
-- 
2.7.4

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

[Yue Hu]

On Wed, 26 Aug 2020 11:19:02 +0200
Daniel Lezcano  wrote:

> Hi Yue,
> 
> On 26/08/2020 04:13, Yue Hu wrote:
> > On Mon, 24 Aug 2020 12:40:35 +0200
> > Daniel Lezcano  wrote:
> >   
> >> On 18/08/2020 08:30, Yue Hu wrote:  
> >>> From: Yue Hu 
> >>>
> >>> We observed warning about kzalloc() when register thermal cooling device
> >>> in backlight_device_register(). backlight display can be a cooling device
> >>> since reducing screen brightness will can help reduce temperature.
> >>>
> >>> However, ->get_max_state of backlight will assign max brightness of 1024
> >>> to states. The memory size can be getting 1MB+ due to states * states.
> >>
> >> What are the benefits of a 1024 states cooling device ? Is the
> >> difference noticeable with a such small step ?  
> > 
> > Okay, this issue is happened under MSM/Android platform. QCOM spmi wled 
> > driver
> > will define the max brightness. We needs to fix the issue to get thermal 
> > statistics.  
> 
> Let me rephrase my questions:
> 
> Don't you think there is something wrong in creating a 1024 x 1024
> matrix to show transitions ?
> 
> What is the benefit of such stats ?
> 
> What is the benefit of having a 1024 states cooling device ?

Hi Daniel,

Now, i'm just focus on removing the kernel warning based on current code logic.
Commit 8ea229511e06 (thermal: Add cooling device's statistics in sysfs) added
the thermal statistics by viresh and viresh gived the patch an acknowledgement
in anther mail thread. 

Hi viresh,

Could you review the patch again about the question above?

Thank you.

> 
> 
> 
> 

Re: [PATCH] m68k: Correct some typos in comments

[Finn Thain]

On Wed, 26 Aug 2020, Geert Uytterhoeven wrote:

> > @@ -2654,7 +2654,7 @@ func_startmmu_get_page_table_entry,%d0/%a1
> > jne 2f
> >
> > /* If the page table entry doesn't exist, we allocate a complete new
> > -* page and use it as one continues big page table which can cover
> > +* page and use it as one continuous big page table which can cover
> 
> Usually I use "contiguous", but the dictionary seems to permit both.
> 

Two or more things may be said to be "contiguous". I think this sentence 
refers to only one thing.

> >  * 4MB of memory, nearly almost all mappings have that alignment.
> >  */
> > get_new_page
> 
> Reviewed-by: Geert Uytterhoeven 
> i.e. will queue in the m68k for-v5.10 branch.
> 

Thanks.

> Gr{oetje,eeting}s,
> 
> Geert
> 

Re: [bio] 37abbdc72e: WARNING:at_block/bio.c:#bio_release_pages

[John Hubbard]

On 8/26/20 8:25 PM, kernel test robot wrote:
...

kern  :warn  : [   59.757746] [ cut here ]
kern  :warn  : [   59.758325] WARNING: CPU: 3 PID: 2581 at block/bio.c:955 
bio_release_pages+0xd7/0xe0
kern  :warn  : [   59.758952] Modules linked in: dm_mod netconsole btrfs 
blake2b_generic xor zstd_compress raid6_pq libcrc32c intel_rapl_msr sd_mod 
intel_rapl_common t10_pi x86_pkg_temp_thermal sg intel_powerclamp coretemp i915 
intel_gtt drm_kms_helper kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel syscopyarea rapl intel_cstate sysfillrect 
intel_uncore sysimgblt fb_sys_fops drm mei_me ipmi_devintf ahci libahci 
ipmi_msghandler libata mei joydev ie31200_edac video ip_tables
kern  :warn  : [   59.761834] CPU: 3 PID: 2581 Comm: aiodio_sparse Not tainted 
5.8.0-10182-g37abbdc72ec00 #1
kern  :warn  : [   59.762559] Hardware name: Hewlett-Packard p6-1451cx/2ADA, 
BIOS 8.15 02/05/2013
kern  :warn  : [   59.763295] RIP: 0010:bio_release_pages+0xd7/0xe0
kern  :warn  : [   59.763983] Code: e1 89 d5 81 e2 ff 0f 00 00 c1 ed 0c 29 d1 48 c1 
e5 06 48 03 28 eb 9c 48 8b 45 08 a8 01 75 c0 48 89 ef e8 8c f0 d2 ff eb b6 c3 
<0f> 0b c3 66 0f 1f 44 00 00 0f 1f 44 00 00 41 54 31 c0 55 bd 00 10
kern  :warn  : [   59.765596] RSP: :c9124e68 EFLAGS: 00010246
kern  :warn  : [   59.766339] RAX: 0a00 RBX: 888212c3f2a0 RCX: 

kern  :warn  : [   59.767124] RDX: fff41387 RSI:  RDI: 
88821fae3000
kern  :warn  : [   59.767950] RBP: 88821fae3000 R08: 88821f1d1c00 R09: 

kern  :warn  : [   59.768726] R10: 88821f1d1a10 R11: 88821faab3b0 R12: 
4001
kern  :warn  : [   59.769513] R13: 0400 R14: 2c00 R15: 

kern  :warn  : [   59.770294] FS:  7fb0401ef740() 
GS:88821fb8() knlGS:
kern  :warn  : [   59.771112] CS:  0010 DS:  ES:  CR0: 80050033
kern  :warn  : [   59.771908] CR2: 7ffc3fc11000 CR3: 00012477e006 CR4: 
001706e0
kern  :warn  : [   59.772720] Call Trace:
kern  :warn  : [   59.773466]  
kern  :warn  : [   59.774200]  iomap_dio_bio_end_io+0x5f/0x100


ah, this is self-inflicted, because my new pin_user_page() (which is called
from iomap_dio_bio_end_io) doesn't set BIO_FOLL_PIN.

Obsolete, now that BIO_FOLL_PIN is not going to happen, but it's good to see
that the system isn't doing anything unexpected here.

thanks,
--
John Hubbard
NVIDIA


kern  :warn  : [   59.774973]  blk_update_request+0x219/0x3c0
kern  :warn  : [   59.775767]  scsi_end_request+0x29/0x140
kern  :warn  : [   59.776538]  scsi_io_completion+0x7a/0x520
kern  :warn  : [   59.777324]  blk_done_softirq+0x95/0xc0
kern  :warn  : [   59.778098]  __do_softirq+0xe8/0x313
kern  :warn  : [   59.778887]  asm_call_on_stack+0x12/0x20
kern  :warn  : [   59.779662]  
kern  :warn  : [   59.780435]  do_softirq_own_stack+0x39/0x60
kern  :warn  : [   59.781217]  irq_exit_rcu+0xd2/0xe0
kern  :warn  : [   59.782020]  common_interrupt+0x74/0x140
kern  :warn  : [   59.782797]  ? asm_common_interrupt+0x8/0x40
kern  :warn  : [   59.783594]  asm_common_interrupt+0x1e/0x40
kern  :warn  : [   59.784359] RIP: 0033:0x5572c6b47f20
kern  :warn  : [   59.785119] Code: 10 00 00 49 01 c4 44 39 fd 0f 8c a2 00 00 00 ba 
00 10 00 00 4c 89 ee 44 89 f7 e8 ab f5 ff ff 85 c0 7e d7 89 c2 4c 89 eb eb 09 
<48> 83 c3 01 83 ea 01 74 c7 44 0f be 03 45 84 c0 74 ee 83 fa 03 7e
kern  :warn  : [   59.786952] RSP: 002b:7ffc3fc0fed0 EFLAGS: 0246
kern  :warn  : [   59.787836] RAX: 1000 RBX: 7ffc3fc11de1 RCX: 
7fb0403c950e
kern  :warn  : [   59.788750] RDX: 00bf RSI: 7ffc3fc10ea0 RDI: 
0007
kern  :warn  : [   59.789647] RBP: 001b5c00 R08:  R09: 
7ffc3fc0d6b7
kern  :warn  : [   59.790550] R10:  R11: 0246 R12: 
0003e000
kern  :warn  : [   59.791447] R13: 7ffc3fc10ea0 R14: 0007 R15: 
0003e000
kern  :warn  : [   59.792356] ---[ end trace 1c52c540ed6c08e4 ]---

...

[PATCH v2 2/2] extcon: ptn5150: Set the VBUS and POLARITY property state

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Set the VBUS and POLARITY property state.

Signed-off-by: Ramuthevar Vadivel Murugan 

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

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8b930050a3f1..b5217a61615c 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -279,6 +279,12 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
return ret;
}
 
+   extcon_set_property_capability(info->edev, EXTCON_USB,
+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_VBUS);
+   extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+  EXTCON_PROP_USB_TYPEC_POLARITY);
/* Initialize PTN5150 device and print vendor id and version id */
ret = ptn5150_init_dev_type(info);
if (ret)
-- 
2.11.0

[PATCH v2 0/2] extcon: ptn5150: Add usb-typec support for Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

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

Original driver is not supporting usb detection on Intel LGM SoC based boards
then we debugged and fixed the issue, but before sending our patches Mr.Krzyszto
has sent the same kind of patches, so I have rebased over his latest patches
which is present in maintainer tree.

Built and tested it's working fine, overthat created the new patch.

Thanks for Krzyszto and Chanwoo Choi
---
v2:
  - Krzyszto review comments update
  - squash my previous patches 1 to 5 as single patch
  - add extcon_set_property_capability for EXTCON_USB and 
EXTCON_PROP_USB_TYPEC_POLARITY 

Reference to mail discussion:
 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2281723.html

Ramuthevar Vadivel Murugan (2):
  extcon: ptn5150: Switch to GENMASK() and BIT() macros
  extcon: ptn5150: Set the VBUS and POLARITY property state

 drivers/extcon/extcon-ptn5150.c | 49 ++---
 1 file changed, 17 insertions(+), 32 deletions(-)

-- 
2.11.0

[PATCH v2 1/2] extcon: ptn5150: Switch to GENMASK() and BIT() macros

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Switch to GENMASK() and BIT() macros.

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Krzysztof Kozlowski 
---
 drivers/extcon/extcon-ptn5150.c | 43 +++--
 1 file changed, 11 insertions(+), 32 deletions(-)

diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 8ba706fad887..8b930050a3f1 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -7,6 +7,7 @@
 // Author: Vijai Kumar K 
 // Copyright (c) 2020 Krzysztof Kozlowski 
 
+#include 
 #include 
 #include 
 #include 
@@ -35,29 +36,13 @@ enum ptn5150_reg {
 #define PTN5150_UFP_ATTACHED   0x2
 
 /* Define PTN5150 MASK/SHIFT constant */
-#define PTN5150_REG_DEVICE_ID_VENDOR_SHIFT 0
-#define PTN5150_REG_DEVICE_ID_VENDOR_MASK  \
-   (0x3 << PTN5150_REG_DEVICE_ID_VENDOR_SHIFT)
+#define PTN5150_REG_DEVICE_ID_VERSION  GENMASK(7, 3)
+#define PTN5150_REG_DEVICE_ID_VENDOR   GENMASK(2, 0)
 
-#define PTN5150_REG_DEVICE_ID_VERSION_SHIFT3
-#define PTN5150_REG_DEVICE_ID_VERSION_MASK \
-   (0x1f << PTN5150_REG_DEVICE_ID_VERSION_SHIFT)
-
-#define PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT   2
-#define PTN5150_REG_CC_PORT_ATTACHMENT_MASK\
-   (0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
-
-#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT7
-#define PTN5150_REG_CC_VBUS_DETECTION_MASK \
-   (0x1 << PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
-
-#define PTN5150_REG_INT_CABLE_ATTACH_SHIFT 0
-#define PTN5150_REG_INT_CABLE_ATTACH_MASK  \
-   (0x1 << PTN5150_REG_INT_CABLE_ATTACH_SHIFT)
-
-#define PTN5150_REG_INT_CABLE_DETACH_SHIFT 1
-#define PTN5150_REG_INT_CABLE_DETACH_MASK  \
-   (0x1 << PTN5150_REG_CC_CABLE_DETACH_SHIFT)
+#define PTN5150_REG_CC_PORT_ATTACHMENT GENMASK(4, 2)
+#define PTN5150_REG_CC_VBUS_DETECTION  BIT(7)
+#define PTN5150_REG_INT_CABLE_ATTACH_MASK  BIT(0)
+#define PTN5150_REG_INT_CABLE_DETACH_MASK  BIT(1)
 
 struct ptn5150_info {
struct device *dev;
@@ -95,9 +80,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
return;
}
 
-   port_status = ((reg_data &
-   PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
-   PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
+   port_status = FIELD_GET(PTN5150_REG_CC_PORT_ATTACHMENT, reg_data);
 
switch (port_status) {
case PTN5150_DFP_ATTACHED:
@@ -107,8 +90,7 @@ static void ptn5150_check_state(struct ptn5150_info *info)
break;
case PTN5150_UFP_ATTACHED:
extcon_set_state_sync(info->edev, EXTCON_USB, false);
-   vbus = ((reg_data & PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
-   PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
+   vbus = FIELD_GET(PTN5150_REG_CC_VBUS_DETECTION, reg_data);
if (vbus)
gpiod_set_value_cansleep(info->vbus_gpiod, 0);
else
@@ -191,11 +173,8 @@ static int ptn5150_init_dev_type(struct ptn5150_info *info)
return -EINVAL;
}
 
-   vendor_id = ((reg_data & PTN5150_REG_DEVICE_ID_VENDOR_MASK) >>
-   PTN5150_REG_DEVICE_ID_VENDOR_SHIFT);
-   version_id = ((reg_data & PTN5150_REG_DEVICE_ID_VERSION_MASK) >>
-   PTN5150_REG_DEVICE_ID_VERSION_SHIFT);
-
+   vendor_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VENDOR, reg_data);
+   version_id = FIELD_GET(PTN5150_REG_DEVICE_ID_VERSION, reg_data);
dev_dbg(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
version_id, vendor_id);
 
-- 
2.11.0

Re: [PATCH] libnvdimm/e820: Fix build error without MEMORY_HOTPLUG

[Yuehaibing]

Pls ignore this

It has be fixed in commit dbb8733abb1c 
("mm-memory_hotplug-introduce-default-phys_to_target_node-implementation-fix")

On 2020/8/26 20:18, YueHaibing wrote:
> If MEMORY_HOTPLUG is n, build fails:
> 
> drivers/nvdimm/e820.c: In function ‘e820_register_one’:
> drivers/nvdimm/e820.c:24:12: error: implicit declaration of function 
> ‘phys_to_target_node’; did you mean ‘set_page_node’? 
> [-Werror=implicit-function-declaration]
>   int nid = phys_to_target_node(res->start);
> ^~~
> set_page_node
> 
> Fixes: 7b27a8622f80 ("libnvdimm/e820: Retrieve and populate correct 
> 'target_node' info")
> Signed-off-by: YueHaibing 
> ---
>  drivers/nvdimm/e820.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/nvdimm/e820.c b/drivers/nvdimm/e820.c
> index 4cd18be9d0e9..c741f029f215 100644
> --- a/drivers/nvdimm/e820.c
> +++ b/drivers/nvdimm/e820.c
> @@ -17,6 +17,13 @@ static int e820_pmem_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +#ifndef CONFIG_MEMORY_HOTPLUG
> +static inline int phys_to_target_node(u64 start)
> +{
> + return 0;
> +}
> +#endif
> +
>  static int e820_register_one(struct resource *res, void *data)
>  {
>   struct nd_region_desc ndr_desc;
> 

[PATCH v6 0/7] Fix timeout clock used by hardware data timeout

[Sowjanya Komatineni]

Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.

Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.

This series includes patches to fix this for Tegra210/Tegra186/Tegra194.

These patches need to be manually backported for 4.9, 4.14 and 4.19.

Will send patches to backport separately once these patches are ack'd.

Delta between patch versions:
[v6]:   v5 is sent out mistakenly with incorrect patches.
v6 includes proper patches addressing v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v5]:   Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v4]:   Include additional dt-binding patch

[v3]:   Same as v2 with fixes tag

[v2]:   Includes minor fix
- Patch-0006: parentheses around operand of '!'

Sowjanya Komatineni (7):
  sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
  sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
  dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
  arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
  arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
  arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
  sdhci: tegra: Add missing TMCLK for data timeout

 .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 +++-
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 20 +++--
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 15 ++--
 arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 20 +++--
 drivers/mmc/host/sdhci-tegra.c | 92 +++---
 5 files changed, 144 insertions(+), 35 deletions(-)

-- 
2.7.4

[PATCH v6 1/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210

[Sowjanya Komatineni]

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.

Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra210.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 0a3f9d0..2be3511 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1418,7 +1418,6 @@ static const struct sdhci_ops tegra210_sdhci_ops = {
 
 static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
-- 
2.7.4

[PATCH v6 5/7] arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes

[Sowjanya Komatineni]

commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")

Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.

So, this clock should be kept enabled by the SDMMC driver.

Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 34d249d..8eb61dd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -337,8 +337,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0340 0x0 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA186_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA186_CLK_SDMMC1>,
+<&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = <&bpmp TEGRA186_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = <&mc TEGRA186_MEMORY_CLIENT_SDMMCRA &emc>,
@@ -366,8 +367,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0342 0x0 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA186_CLK_SDMMC2>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA186_CLK_SDMMC2>,
+<&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = <&bpmp TEGRA186_RESET_SDMMC2>;
reset-names = "sdhci";
interconnects = <&mc TEGRA186_MEMORY_CLIENT_SDMMCRAA &emc>,
@@ -390,8 +392,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0344 0x0 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA186_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA186_CLK_SDMMC3>,
+<&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = <&bpmp TEGRA186_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = <&mc TEGRA186_MEMORY_CLIENT_SDMMCR &emc>,
@@ -416,8 +419,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0346 0x0 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA186_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA186_CLK_SDMMC4>,
+<&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
assigned-clocks = <&bpmp TEGRA186_CLK_SDMMC4>,
  <&bpmp TEGRA186_CLK_PLLC4_VCO>;
assigned-clock-parents = <&bpmp TEGRA186_CLK_PLLC4_VCO>;
-- 
2.7.4

[PATCH v6 7/7] sdhci: tegra: Add missing TMCLK for data timeout

[Sowjanya Komatineni]

commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")

Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.

USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
SDHCI_TEGRA_VENDOR_SYS_SW_CTRL can be used to choose either TMCLK or
SDCLK for data timeout.

Default USE_TMCLK_FOR_DATA_TIMEOUT bit is set to 1 and TMCLK is used
for data timeout by Tegra SDMMC hardware and having TMCLK not enabled
is not recommended.

So, this patch adds quirk NVQUIRK_HAS_TMCLK for SoC having separate
timeout clock and keeps TMCLK enabled all the time.

Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 90 ++
 1 file changed, 82 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 31ed321..f69ca8d 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -110,6 +111,12 @@
 #define NVQUIRK_DIS_CARD_CLK_CONFIG_TAPBIT(8)
 #define NVQUIRK_CQHCI_DCMD_R1B_CMD_TIMING  BIT(9)
 
+/*
+ * NVQUIRK_HAS_TMCLK is for SoC's having separate timeout clock for Tegra
+ * SDMMC hardware data timeout.
+ */
+#define NVQUIRK_HAS_TMCLK  BIT(10)
+
 /* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
 #define SDHCI_TEGRA_CQE_BASE_ADDR  0xF000
 
@@ -140,6 +147,7 @@ struct sdhci_tegra_autocal_offsets {
 struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
struct gpio_desc *power_gpio;
+   struct clk *tmclk;
bool ddr_signaling;
bool pad_calib_required;
bool pad_control_available;
@@ -1433,7 +1441,8 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra210 = {
NVQUIRK_HAS_PADCALIB |
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
-   NVQUIRK_ENABLE_SDR104,
+   NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK,
.min_tap_delay = 106,
.max_tap_delay = 185,
 };
@@ -1471,6 +1480,7 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra186 = {
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK |
NVQUIRK_CQHCI_DCMD_R1B_CMD_TIMING,
.min_tap_delay = 84,
.max_tap_delay = 136,
@@ -1483,7 +1493,8 @@ static const struct sdhci_tegra_soc_data 
soc_data_tegra194 = {
NVQUIRK_HAS_PADCALIB |
NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
NVQUIRK_ENABLE_SDR50 |
-   NVQUIRK_ENABLE_SDR104,
+   NVQUIRK_ENABLE_SDR104 |
+   NVQUIRK_HAS_TMCLK,
.min_tap_delay = 96,
.max_tap_delay = 139,
 };
@@ -1611,15 +1622,76 @@ static int sdhci_tegra_probe(struct platform_device 
*pdev)
goto err_power_req;
}
 
-   clk = devm_clk_get(mmc_dev(host->mmc), NULL);
-   if (IS_ERR(clk)) {
-   rc = PTR_ERR(clk);
+   /*
+* Tegra210 and later has separate SDMMC_LEGACY_TM clock used for
+* hardware data timeout clock and SW can choose TMCLK or SDCLK for
+* hardware data timeout through the bit USE_TMCLK_FOR_DATA_TIMEOUT
+* of the register SDHCI_TEGRA_VENDOR_SYS_SW_CTRL.
+*
+* USE_TMCLK_FOR_DATA_TIMEOUT bit default is set to 1 and SDMMC uses
+* 12Mhz TMCLK which is advertised in host capability register.
+* With TMCLK of 12Mhz provides maximum data timeout period that can
+* be achieved is 11s better than using SDCLK for data timeout.
+*
+* So, TMCLK is set to 12Mhz and kept enabled all the time on SoC's
+* supporting separate TMCLK.
+*
+* Old device tree has single sdhci clock. So with addition of TMCLK,
+* retrieving sdhci clock by "sdhci" clock name based on number of
+* clocks in sdhci device node.
+*/
+
+   if (of_clk_get_parent_count(pdev->dev.of_node) == 1) {
+   if (soc_data->nvquirks & NVQUIRK_HAS_TMCLK)
+   dev_warn(&pdev->dev,
+"missing tmclk in the device tree\n");
+
+   clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(clk)) {
+   rc = PTR_ERR(clk);
 
-   if (rc != -EPROBE_DEFER)
-   dev_err(&pdev->dev, "failed to get clock: %d\n", rc);
+   if (rc != -EPROBE_DEFER)
+ 

[PATCH v6 2/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186

[Sowjanya Komatineni]

commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")

SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.

Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.

So, this patch remove this quirk for Tegra186.

Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Acked-by: Adrian Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 drivers/mmc/host/sdhci-tegra.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 2be3511..31ed321 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -1455,7 +1455,6 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
 
 static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_SINGLE_POWER_WRITE |
  SDHCI_QUIRK_NO_HISPD_BIT |
  SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
-- 
2.7.4

[PATCH v6 3/7] dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later

[Sowjanya Komatineni]

Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
timeout.

So, this patch adds "tmclk" to Tegra sdhci clock property in the
device tree binding.

Signed-off-by: Sowjanya Komatineni 
---
 .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 --
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt 
b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
index 2cf3aff..96c0b14 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
@@ -15,8 +15,15 @@ Required properties:
   - "nvidia,tegra210-sdhci": for Tegra210
   - "nvidia,tegra186-sdhci": for Tegra186
   - "nvidia,tegra194-sdhci": for Tegra194
-- clocks : Must contain one entry, for the module clock.
-  See ../clocks/clock-bindings.txt for details.
+- clocks: For Tegra210, Tegra186 and Tegra194 must contain two entries.
+ One for the module clock and one for the timeout clock.
+ For all other Tegra devices, must contain a single entry for
+ the module clock. See ../clocks/clock-bindings.txt for details.
+- clock-names: For Tegra210, Tegra186 and Tegra194 must contain the
+  strings 'sdhci' and 'tmclk' to represent the module and
+  the timeout clocks, respectively.
+  For all other Tegra devices must contain the string 'sdhci'
+  to represent the module clock.
 - resets : Must contain an entry for each entry in reset-names.
   See ../reset/reset.txt for details.
 - reset-names : Must include the following entries:
@@ -99,7 +106,7 @@ Optional properties for Tegra210, Tegra186 and Tegra194:
 
 Example:
 sdhci@700b {
-   compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+   compatible = "nvidia,tegra124-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
clocks = <&tegra_car TEGRA210_CLK_SDMMC1>;
@@ -115,3 +122,22 @@ sdhci@700b {
nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
status = "disabled";
 };
+
+sdhci@700b {
+   compatible = "nvidia,tegra210-sdhci";
+   reg = <0x0 0x700b 0x0 0x200>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA210_CLK_SDMMC1>,
+<&tegra_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
+   resets = <&tegra_car 14>;
+   reset-names = "sdhci";
+   pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
+   pinctrl-0 = <&sdmmc1_3v3>;
+   pinctrl-1 = <&sdmmc1_1v8>;
+   nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>;
+   nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>;
+   nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>;
+   nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
+   status = "disabled";
+};
-- 
2.7.4

[PATCH v6 4/7] arm64: tegra: Add missing timeout clock to Tegra210 SDMMC

[Sowjanya Komatineni]

commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")

Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 829f786..8cca216 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1194,8 +1194,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
-   clocks = <&tegra_car TEGRA210_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = <&tegra_car TEGRA210_CLK_SDMMC1>,
+<&tegra_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <&tegra_car 14>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1222,8 +1223,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0200 0x0 0x200>;
interrupts = ;
-   clocks = <&tegra_car TEGRA210_CLK_SDMMC2>;
-   clock-names = "sdhci";
+   clocks = <&tegra_car TEGRA210_CLK_SDMMC2>,
+<&tegra_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <&tegra_car 9>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-1v8-drv";
@@ -1239,8 +1241,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0400 0x0 0x200>;
interrupts = ;
-   clocks = <&tegra_car TEGRA210_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = <&tegra_car TEGRA210_CLK_SDMMC3>,
+<&tegra_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <&tegra_car 69>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8",
@@ -1262,8 +1265,9 @@
compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0600 0x0 0x200>;
interrupts = ;
-   clocks = <&tegra_car TEGRA210_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = <&tegra_car TEGRA210_CLK_SDMMC4>,
+<&tegra_car TEGRA210_CLK_SDMMC_LEGACY>;
+   clock-names = "sdhci", "tmclk";
resets = <&tegra_car 15>;
reset-names = "sdhci";
pinctrl-names = "sdmmc-3v3-drv", "sdmmc-1v8-drv";
-- 
2.7.4

[PATCH v6 6/7] arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes

[Sowjanya Komatineni]

commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")

Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.

Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.

So, this clock should be kept enabled by SDMMC driver.

Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Cc: stable  # 5.4
Tested-by: Jon Hunter 
Reviewed-by: Jon Hunter 
Signed-off-by: Sowjanya Komatineni 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 48160f4..ca5cb6a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -460,8 +460,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0340 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA194_CLK_SDMMC1>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA194_CLK_SDMMC1>,
+<&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = <&bpmp TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
interconnects = <&mc TEGRA194_MEMORY_CLIENT_SDMMCRA 
&emc>,
@@ -485,8 +486,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0344 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA194_CLK_SDMMC3>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA194_CLK_SDMMC3>,
+<&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
resets = <&bpmp TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
interconnects = <&mc TEGRA194_MEMORY_CLIENT_SDMMCR 
&emc>,
@@ -511,8 +513,9 @@
compatible = "nvidia,tegra194-sdhci";
reg = <0x0346 0x1>;
interrupts = ;
-   clocks = <&bpmp TEGRA194_CLK_SDMMC4>;
-   clock-names = "sdhci";
+   clocks = <&bpmp TEGRA194_CLK_SDMMC4>,
+<&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>;
+   clock-names = "sdhci", "tmclk";
assigned-clocks = <&bpmp TEGRA194_CLK_SDMMC4>,
  <&bpmp TEGRA194_CLK_PLLC4>;
assigned-clock-parents =
-- 
2.7.4

Re: [kthread] 2e7d8748eb: last_state.is_incomplete_run

[qianli zhao]

I did not see any exceptions related to my changes,the corresponding
macro CONFIG_DEBUG_OBJECTS_KTHREAD is not enabled,so i think the issue
has nothing to do with my changes

Thanks

On Thu, 20 Aug 2020 at 14:26, kernel test robot  wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 2e7d8748eba7e32150cbd4f57129ea77d1255892 ("[RFC V2] kthread: add 
> object debug support")
> url: 
> https://github.com/0day-ci/linux/commits/Qianli-Zhao/kthread-add-object-debug-support/20200812-131719
> base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git 
> fb893de323e2d39f7a1f6df425703a2edbdf56ea
>
> in testcase: boot
>
> on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G 
> memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
>
>
>
> kernel boot failed by kexec:
>
> user  :notice:  [32m[  +0.371313]  [0m [33mLKP [0m: kexec loading...
> user  :notice:  [32m[  +0.007118]  [0mkexec --noefi -l 
> /opt/rootfs/tmp/pkg/linux/x86_64-rhel-8.3/gcc-9/2e7d8748eba7e32150cbd4f57129ea77d1255892/vmlinuz-5.8.0-12610-g2e7d8748eba7e
>  --initrd=/opt/rootfs/tmp/initrd-concatenated
>
>
>
>
> Thanks,
> Rong Chen
>

Re: [PATCH v2 3/3] usb typec: mt6360: Prevent the race condition during module remove

[Guenter Roeck]

On 8/26/20 8:25 PM, cy_huang wrote:
> From: ChiYuan Huang 
> 
> Prevent the race condition from interrupt and tcpci port unregister
> during module remove.
> 
> Signed-off-by: ChiYuan Huang 

Please squash with the first patch of the series.

Thanks,
Guenter

> ---
>  drivers/usb/typec/tcpm/tcpci_mt6360.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
> b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> index 6a28193..a381b5d 100644
> --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> @@ -164,6 +164,7 @@ static int mt6360_tcpc_remove(struct platform_device 
> *pdev)
>  {
>   struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
>  
> + disable_irq(mti->irq);
>   tcpci_unregister_port(mti->tcpci);
>   return 0;
>  }
> 

Re: [PATCH] deprecated.rst: Remove now removed uninitialized_var

[Nick Desaulniers]

On Wed, Aug 26, 2020 at 8:12 PM Joe Perches  wrote:
>
> It's now gone from the kernel so remove it from the deprecated API text.
>
> Signed-off-by: Joe Perches 

Thanks Joe.
Reviewed-by: Nick Desaulniers 

> ---
>  Documentation/process/deprecated.rst | 18 --
>  1 file changed, 18 deletions(-)
>
> diff --git a/Documentation/process/deprecated.rst 
> b/Documentation/process/deprecated.rst
> index 918e32d76fc4..70720f00b9aa 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -51,24 +51,6 @@ to make sure their systems do not continue running in the 
> face of
>  "unreachable" conditions. (For example, see commits like `this one
>  `_.)
>
> -uninitialized_var()
> 
> -For any compiler warnings about uninitialized variables, just add
> -an initializer. Using the uninitialized_var() macro (or similar
> -warning-silencing tricks) is dangerous as it papers over `real bugs
> -`_
> -(or can in the future), and suppresses unrelated compiler warnings
> -(e.g. "unused variable"). If the compiler thinks it is uninitialized,
> -either simply initialize the variable or make compiler changes. Keep in
> -mind that in most cases, if an initialization is obviously redundant,
> -the compiler's dead-store elimination pass will make sure there are no
> -needless variable writes.
> -
> -As Linus has said, this macro
> -`must 
> `_
> -`be 
> `_
> -`removed 
> `_.
> -
>  open-coded arithmetic in allocator arguments
>  
>  Dynamic size calculations (especially multiplication) should not be
>
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v2] extcon: ptn5150: Deduplicate parts of dev_err_probe()

[Chanwoo Choi]

Hi Andy,

On 8/27/20 12:23 AM, Andy Shevchenko wrote:
> dev_err_probe() is designed to be used like
> 
>   return dev_err_probe(dev, ret, "Error message\n");
> 
> Hence no need to have a separate return statement. Besides that
> dev_err_probe() prints already returned error code, no need to repeat
> that either.
> 
> Cc: Vijai Kumar K 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Krzysztof Kozlowski 
> ---
> v2: dropped Fixed tag (Krzysztof)
>  drivers/extcon/extcon-ptn5150.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 8ba706fad887..051bf374b43f 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -242,8 +242,7 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   dev_info(dev, "No VBUS GPIO, ignoring VBUS control\n");
>   info->vbus_gpiod = NULL;
>   } else {
> - dev_err_probe(dev, ret, "failed to get VBUS GPIO\n");
> - return ret;
> + return dev_err_probe(dev, ret, "failed to get VBUS 
> GPIO\n");
>   }
>   }
>  
> @@ -253,10 +252,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>  
>   info->regmap = devm_regmap_init_i2c(i2c, &ptn5150_regmap_config);
>   if (IS_ERR(info->regmap)) {
> - ret = PTR_ERR(info->regmap);
> - dev_err_probe(info->dev, ret, "failed to allocate register map: 
> %d\n",
> -   ret);
> - return ret;
> + return dev_err_probe(info->dev, PTR_ERR(info->regmap),
> +  "failed to allocate register map\n");
>   }
>  
>   if (i2c->irq > 0) {
> @@ -264,9 +261,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c)
>   } else {
>   info->int_gpiod = devm_gpiod_get(&i2c->dev, "int", GPIOD_IN);
>   if (IS_ERR(info->int_gpiod)) {
> - ret = PTR_ERR(info->int_gpiod);
> - dev_err_probe(dev, ret, "failed to get INT GPIO\n");
> - return ret;
> + return dev_err_probe(dev, PTR_ERR(info->int_gpiod),
> +  "failed to get INT GPIO\n");
>   }
>  
>   info->irq = gpiod_to_irq(info->int_gpiod);
> 

Applied it. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[PATCH v2 3/3] usb typec: mt6360: Prevent the race condition during module remove

[cy_huang]

From: ChiYuan Huang 

Prevent the race condition from interrupt and tcpci port unregister
during module remove.

Signed-off-by: ChiYuan Huang 
---
 drivers/usb/typec/tcpm/tcpci_mt6360.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
b/drivers/usb/typec/tcpm/tcpci_mt6360.c
index 6a28193..a381b5d 100644
--- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
+++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
@@ -164,6 +164,7 @@ static int mt6360_tcpc_remove(struct platform_device *pdev)
 {
struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
 
+   disable_irq(mti->irq);
tcpci_unregister_port(mti->tcpci);
return 0;
 }
-- 
2.7.4

[PATCH v2 1/3] usb typec: mt6360: Add support for mt6360 Type-C driver

[cy_huang]

From: ChiYuan Huang 

Mediatek MT6360 is a multi-functional IC that includes USB Type-C.
It works with Type-C Port Controller Manager to provide USB PD
and USB Type-C functionalities.

Signed-off-by: ChiYuan Huang 
---
 drivers/usb/typec/tcpm/Kconfig|   8 ++
 drivers/usb/typec/tcpm/Makefile   |   1 +
 drivers/usb/typec/tcpm/tcpci_mt6360.c | 212 ++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6360.c

diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index fa3f393..58a64e1 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -27,6 +27,14 @@ config TYPEC_RT1711H
  Type-C Port Controller Manager to provide USB PD and USB
  Type-C functionalities.
 
+config TYPEC_MT6360
+   tristate "Mediatek MT6360 Type-C driver"
+   depends on MFD_MT6360
+   help
+ Mediatek MT6360 is a multi-functional IC that includes
+ USB Type-C. It works with Type-C Port Controller Manager
+ to provide USB PD and USB Type-C functionalities.
+
 endif # TYPEC_TCPCI
 
 config TYPEC_FUSB302
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index a5ff6c8..7592ccb 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_WCOVE)   += typec_wcove.o
 typec_wcove-y  := wcove.o
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
 obj-$(CONFIG_TYPEC_RT1711H)+= tcpci_rt1711h.o
+obj-$(CONFIG_TYPEC_MT6360) += tcpci_mt6360.o
diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
b/drivers/usb/typec/tcpm/tcpci_mt6360.c
new file mode 100644
index ..6a28193
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (C) 2020 MediaTek Inc.
+//
+// Author: ChiYuan Huang 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tcpci.h"
+
+#define MT6360_REG_VCONNCTRL1  0x8C
+#define MT6360_REG_MODECTRL2   0x8F
+#define MT6360_REG_SWRESET 0xA0
+#define MT6360_REG_DEBCTRL10xA1
+#define MT6360_REG_DRPCTRL10xA2
+#define MT6360_REG_DRPCTRL20xA3
+#define MT6360_REG_I2CTORST0xBF
+#define MT6360_REG_RXCTRL2 0xCF
+#define MT6360_REG_CTDCTRL20xEC
+
+/* MT6360_REG_VCONNCTRL1 */
+#define MT6360_VCONNCL_ENABLE  BIT(0)
+/* MT6360_REG_RXCTRL2 */
+#define MT6360_OPEN40M_ENABLE  BIT(7)
+/* MT6360_REG_CTDCTRL2 */
+#define MT6360_RPONESHOT_ENABLEBIT(6)
+
+struct mt6360_tcpc_info {
+   struct tcpci_data tdata;
+   struct tcpci *tcpci;
+   struct device *dev;
+   int irq;
+};
+
+static inline int mt6360_tcpc_read16(struct regmap *regmap,
+unsigned int reg, u16 *val)
+{
+   return regmap_raw_read(regmap, reg, val, sizeof(u16));
+}
+
+static inline int mt6360_tcpc_write16(struct regmap *regmap,
+ unsigned int reg, u16 val)
+{
+   return regmap_raw_write(regmap, reg, &val, sizeof(u16));
+}
+
+static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+   struct regmap *regmap = tdata->regmap;
+   int ret;
+
+   ret = regmap_write(regmap, MT6360_REG_SWRESET, 0x01);
+   if (ret)
+   return ret;
+
+   /* after reset command, wait 1~2ms to wait IC action */
+   usleep_range(1000, 2000);
+
+   /* write all alert to masked */
+   ret = mt6360_tcpc_write16(regmap, TCPC_ALERT_MASK, 0);
+   if (ret)
+   return ret;
+
+   /* config I2C timeout reset enable , and timeout to 200ms */
+   ret = regmap_write(regmap, MT6360_REG_I2CTORST, 0x8F);
+   if (ret)
+   return ret;
+
+   /* config CC Detect Debounce : 26.7*val us */
+   ret = regmap_write(regmap, MT6360_REG_DEBCTRL1, 0x10);
+   if (ret)
+   return ret;
+
+   /* DRP Toggle Cycle : 51.2 + 6.4*val ms */
+   ret = regmap_write(regmap, MT6360_REG_DRPCTRL1, 4);
+   if (ret)
+   return ret;
+
+   /* DRP Duyt Ctrl : dcSRC: /1024 */
+   ret = mt6360_tcpc_write16(regmap, MT6360_REG_DRPCTRL2, 330);
+   if (ret)
+   return ret;
+
+   /* Enable VCONN Current Limit function */
+   ret = regmap_update_bits(regmap, MT6360_REG_VCONNCTRL1, 
MT6360_VCONNCL_ENABLE,
+MT6360_VCONNCL_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable cc open 40ms when pmic send vsysuv signal */
+   ret = regmap_update_bits(regmap, MT6360_REG_RXCTRL2, 
MT6360_OPEN40M_ENABLE,
+MT6360_OPEN40M_ENABLE);
+   if (ret)
+   return ret;
+
+   /* Enable Rpdet oneshot detection */
+   ret = regmap_update_bits(regmap, MT6360_REG_CTDCTRL2, 
MT6360_RPONESHOT_ENABLE,
+MT6360_RPONESHOT_ENABLE);
+   if (ret)
+   ret

[PATCH v2 2/3] usb typec: mt6360: Add MT6360 Type-C DT binding documentation

[cy_huang]

From: ChiYuan Huang 

Add a devicetree binding documentation for the MT6360 Type-C driver.

Signed-off-by: ChiYuan Huang 
---
 .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml 
b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
new file mode 100644
index ..9e8ab0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT 
bindings
+
+maintainers:
+  - ChiYuan Huang 
+
+description: |
+  Mediatek MT6360 is a multi-functional device. It integrates charger, ADC, 
flash, RGB indicators,
+  regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery 
controller.
+  This document only describes MT6360 Type-C Port Switch and Power Delivery 
controller.
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6360-tcpc
+
+  interrupts-extended:
+maxItems: 1
+
+  interrupt-names:
+items:
+  - const: PD_IRQB
+
+patternProperties:
+  "connector":
+type: object
+$ref: ../connector/usb-connector.yaml#
+description:
+  Properties for usb c connector.
+
+additionalProperties: false
+
+required:
+  - compatible
+  - interrupts-extended
+  - interrupt-names
+
+examples:
+  - |
+#include 
+#include 
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mt6360@34 {
+compatible = "mediatek,mt6360";
+reg = <0x34>;
+
+tcpc {
+compatible = "mediatek,mt6360-tcpc";
+interrupts-extended = <&gpio26 3 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "PD_IRQB";
+
+connector {
+compatible = "usb-c-connector";
+label = "USB-C";
+data-role = "dual";
+power-role = "dual";
+try-power-role = "sink";
+source-pdos = ;
+sink-pdos = ;
+op-sink-microwatt = <1000>;
+};
+};
+};
+};
+...
-- 
2.7.4

RE: [PATCH v4 1/5] exfat: integrates dir-entry getting and validation

[Namjae Jeon]

> + i = ES_INDEX_NAME;
> + while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
Please find the way to access name entries like ep_file, ep_stream
without calling exfat_get_validated_dentry().
>   exfat_extract_uni_name(ep, uniname);
>   uniname += EXFAT_FILE_NAME_LEN;
>   }
> @@ -372,7 +369,7 @@ unsigned int exfat_get_entry_type(struct exfat_dentry *ep)
>   if (ep->type == EXFAT_STREAM)
>   return TYPE_STREAM;
>   if (ep->type == EXFAT_NAME)
> - return TYPE_EXTEND;
> + return TYPE_NAME;
>   if (ep->type == EXFAT_ACL)
>   return TYPE_ACL;
>   return TYPE_CRITICAL_SEC;
> @@ -388,7 +385,7 @@ static void exfat_set_entry_type(struct exfat_dentry *ep, 
> unsigned int type)
>   ep->type &= EXFAT_DELETE;
>   } else if (type == TYPE_STREAM) {
>   ep->type = EXFAT_STREAM;
> - } else if (type == TYPE_EXTEND) {
> + } else if (type == TYPE_NAME) {
>   ep->type = EXFAT_NAME;
>   } else if (type == TYPE_BITMAP) {
>   ep->type = EXFAT_BITMAP;
> @@ -421,7 +418,7 @@ static void exfat_init_name_entry(struct exfat_dentry 
> *ep,  {
>   int i;
> 
> - exfat_set_entry_type(ep, TYPE_EXTEND);
> + exfat_set_entry_type(ep, TYPE_NAME);
>   ep->dentry.name.flags = 0x0;
> 
>   for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) { @@ -550,7 +547,7 @@ int 
> exfat_init_ext_entry(struct
> inode *inode, struct exfat_chain *p_dir,
>   exfat_update_bh(bh, sync);
>   brelse(bh);
> 
> - for (i = EXFAT_FIRST_CLUSTER; i < num_entries; i++) {
> + for (i = ES_INDEX_NAME; i < num_entries; i++) {
>   ep = exfat_get_dentry(sb, p_dir, entry + i, &bh, §or);
>   if (!ep)
>   return -EIO;
> @@ -590,17 +587,16 @@ int exfat_remove_entries(struct inode *inode, struct 
> exfat_chain *p_dir,  void
> exfat_update_dir_chksum_with_entry_set(struct exfat_entry_set_cache *es)  {
>   int chksum_type = CS_DIR_ENTRY, i;
> - unsigned short chksum = 0;
> + u16 chksum = 0;
>   struct exfat_dentry *ep;
> 
>   for (i = 0; i < es->num_entries; i++) {
> - ep = exfat_get_dentry_cached(es, i);
> + ep = exfat_get_validated_dentry(es, i, TYPE_ALL);
Ditto, You do not need to repeatedly call exfat_get_validated_dentry() for the 
entries
which got from exfat_get_dentry_set().
>   chksum = exfat_calc_chksum16(ep, DENTRY_SIZE, chksum,
>chksum_type);
>   chksum_type = CS_DEFAULT;
>   }
> - ep = exfat_get_dentry_cached(es, 0);
> - ep->dentry.file.checksum = cpu_to_le16(chksum);
> + ES_FILE(es).checksum = cpu_to_le16(chksum);
>   es->modified = true;
>  }
> 
>  struct exfat_entry_set_cache *exfat_get_dentry_set(struct super_block *sb,
> - struct exfat_chain *p_dir, int entry, unsigned int type)
> + struct exfat_chain *p_dir, int entry, int max_entries)
>  {
>   int ret, i, num_bh;
> - unsigned int off, byte_offset, clu = 0;
> + unsigned int byte_offset, clu = 0;
>   sector_t sec;
>   struct exfat_sb_info *sbi = EXFAT_SB(sb);
>   struct exfat_entry_set_cache *es;
> - struct exfat_dentry *ep;
> - int num_entries;
> - enum exfat_validate_dentry_mode mode = ES_MODE_STARTED;
>   struct buffer_head *bh;
> 
>   if (p_dir->dir == DIR_DELETED) {
> @@ -844,13 +811,13 @@ struct exfat_entry_set_cache 
> *exfat_get_dentry_set(struct super_block *sb,
>   return NULL;
>   es->sb = sb;
>   es->modified = false;
> + es->num_entries = 1;
> 
>   /* byte offset in cluster */
>   byte_offset = EXFAT_CLU_OFFSET(byte_offset, sbi);
> 
>   /* byte offset in sector */
> - off = EXFAT_BLK_OFFSET(byte_offset, sb);
> - es->start_off = off;
> + es->start_off = EXFAT_BLK_OFFSET(byte_offset, sb);
> 
>   /* sector offset in cluster */
>   sec = EXFAT_B_TO_BLK(byte_offset, sb); @@ -861,15 +828,12 @@ struct 
> exfat_entry_set_cache
> *exfat_get_dentry_set(struct super_block *sb,
>   goto free_es;
>   es->bh[es->num_bh++] = bh;
> 
> - ep = exfat_get_dentry_cached(es, 0);
> - if (!exfat_validate_entry(exfat_get_entry_type(ep), &mode))
> + es->ep_file = exfat_get_validated_dentry(es, ES_INDEX_FILE, TYPE_FILE);
> + if (!es->ep_file)
>   goto free_es;
> + es->num_entries = min(ES_FILE(es).num_ext + 1, max_entries);
> 
> - num_entries = type == ES_ALL_ENTRIES ?
> - ep->dentry.file.num_ext + 1 : type;
> - es->num_entries = num_entries;
> -
> - num_bh = EXFAT_B_TO_BLK_ROUND_UP(off + num_entries * DENTRY_SIZE, sb);
> + num_bh = EXFAT_B_TO_BLK_ROUND_UP(es->start_off  + es->num_entries *
> +DENTRY_SIZE, sb);
>   for (i = 1; i < num_bh; i++) {
>   /* get the next sector */
>

RE: [PATCH] exfat: fix pointer error checking

[Namjae Jeon]

> Fix missing result check of exfat_build_inode().
> And use PTR_ERR_OR_ZERO instead of PTR_ERR.
> 
> Signed-off-by: Tetsuhiro Kohada 
Pushed it to exfat #dev.
Thanks for your patch!

Re: [PATCH] MIPS: Loongson: Fix complie errors without CONFIG_SMP

[Matthew Wilcox]

On Thu, Aug 27, 2020 at 10:31:33AM +0800, hejinyang wrote:
> 
> 
> On 08/26/2020 09:01 PM, Matthew Wilcox wrote:
> > On Wed, Aug 26, 2020 at 08:53:27PM +0800, Jinyang He wrote:
> > > +++ b/arch/mips/include/asm/mach-loongson64/topology.h
> > > @@ -4,7 +4,11 @@
> > >   #ifdef CONFIG_NUMA
> > > +#ifdef CONFIG_SMP
> > >   #define cpu_to_node(cpu)(cpu_logical_map(cpu) >> 2)
> > > +#else
> > > +#define cpu_to_node(cpu) 0
> > > +#endif
> > Are you saying you've enabled NUMA without enabling SMP?  Does that make
> > sense?
> 
> NUMA option normally work with more than two nodes, though Loongson64 use it
> default after patch 6fbde6b492dfc761ad60a68fb2cb32b1eb05b786. Loongson64(3A)'s
> each node consists of 4 cpus while it only has 4 cpus. In other words, it has
> only one node while open NUMA. I'm confused it if NUMA deponds on SMP.
> 
> I'll try fix it with unabling NUMA and SMP later.

mips:
config NUMA
bool "NUMA Support"
depends on SYS_SUPPORTS_NUMA

x86:
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
depends on SMP

If you had a good reason for enabling NUMA without enabling SMP (CPU-less
memory nodes?), that'd be an interesting discussion to have.  Since your
hardware seems to have SMP by default, I'd suggest just adding the missing
'depends'.

[PATCH] deprecated.rst: Remove now removed uninitialized_var

[Joe Perches]

It's now gone from the kernel so remove it from the deprecated API text.

Signed-off-by: Joe Perches 
---
 Documentation/process/deprecated.rst | 18 --
 1 file changed, 18 deletions(-)

diff --git a/Documentation/process/deprecated.rst 
b/Documentation/process/deprecated.rst
index 918e32d76fc4..70720f00b9aa 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -51,24 +51,6 @@ to make sure their systems do not continue running in the 
face of
 "unreachable" conditions. (For example, see commits like `this one
 `_.)
 
-uninitialized_var()

-For any compiler warnings about uninitialized variables, just add
-an initializer. Using the uninitialized_var() macro (or similar
-warning-silencing tricks) is dangerous as it papers over `real bugs
-`_
-(or can in the future), and suppresses unrelated compiler warnings
-(e.g. "unused variable"). If the compiler thinks it is uninitialized,
-either simply initialize the variable or make compiler changes. Keep in
-mind that in most cases, if an initialization is obviously redundant,
-the compiler's dead-store elimination pass will make sure there are no
-needless variable writes.
-
-As Linus has said, this macro
-`must 
`_
-`be 
`_
-`removed 
`_.
-
 open-coded arithmetic in allocator arguments
 
 Dynamic size calculations (especially multiplication) should not be

[PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver

[Neal Liu]

MediaTek bus fabric provides TrustZone security support and data
protection to prevent slaves from being accessed by unexpected
masters.
The security violation is logged and sent to the processor for
further analysis or countermeasures.

Any occurrence of security violation would raise an interrupt, and
it will be handled by mtk-devapc driver. The violation
information is printed in order to find the murderer.

Signed-off-by: Neal Liu 
---
 drivers/soc/mediatek/Kconfig  |9 ++
 drivers/soc/mediatek/Makefile |1 +
 drivers/soc/mediatek/mtk-devapc.c |  305 +
 3 files changed, 315 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..1177c98 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -17,6 +17,15 @@ config MTK_CMDQ
  time limitation, such as updating display configuration during the
  vblank.
 
+config MTK_DEVAPC
+   tristate "Mediatek Device APC Support"
+   help
+ Say yes here to enable support for Mediatek Device APC driver.
+ This driver is mainly used to handle the violation which catches
+ unexpected transaction.
+ The violation information is logged for further analysis or
+ countermeasures.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..abfd4ba 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
+obj-$(CONFIG_MTK_DEVAPC) += mtk-devapc.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-devapc.c 
b/drivers/soc/mediatek/mtk-devapc.c
new file mode 100644
index 000..0ba61d7
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-devapc.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VIO_MOD_TO_REG_IND(m)  ((m) / 32)
+#define VIO_MOD_TO_REG_OFF(m)  ((m) % 32)
+
+struct mtk_devapc_vio_dbgs {
+   union {
+   u32 vio_dbg0;
+   struct {
+   u32 mstid:16;
+   u32 dmnid:6;
+   u32 vio_w:1;
+   u32 vio_r:1;
+   u32 addr_h:4;
+   u32 resv:4;
+   } dbg0_bits;
+   };
+
+   u32 vio_dbg1;
+};
+
+struct mtk_devapc_data {
+   u32 vio_idx_num;
+   u32 vio_mask_offset;
+   u32 vio_sta_offset;
+   u32 vio_dbg0_offset;
+   u32 vio_dbg1_offset;
+   u32 apc_con_offset;
+   u32 vio_shift_sta_offset;
+   u32 vio_shift_sel_offset;
+   u32 vio_shift_con_offset;
+};
+
+struct mtk_devapc_context {
+   struct device *dev;
+   void __iomem *infra_base;
+   struct clk *infra_clk;
+   const struct mtk_devapc_data *data;
+};
+
+static void clear_vio_status(struct mtk_devapc_context *ctx)
+{
+   void __iomem *reg;
+   int i;
+
+   reg = ctx->infra_base + ctx->data->vio_sta_offset;
+
+   for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++)
+   writel(GENMASK(31, 0), reg + 4 * i);
+
+   writel(GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1), 0),
+  reg + 4 * i);
+}
+
+static void mask_module_irq(struct mtk_devapc_context *ctx, bool mask)
+{
+   void __iomem *reg;
+   u32 val;
+   int i;
+
+   reg = ctx->infra_base + ctx->data->vio_mask_offset;
+
+   if (mask)
+   val = GENMASK(31, 0);
+   else
+   val = 0;
+
+   for (i = 0; i < VIO_MOD_TO_REG_IND(ctx->data->vio_idx_num - 1); i++)
+   writel(val, reg + 4 * i);
+
+   val = readl(reg + 4 * i);
+   if (mask)
+   val |= GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1),
+  0);
+   else
+   val &= ~GENMASK(VIO_MOD_TO_REG_OFF(ctx->data->vio_idx_num - 1),
+   0);
+
+   writel(val, reg + 4 * i);
+}
+
+#define PHY_DEVAPC_TIMEOUT 0x1
+
+/*
+ * devapc_sync_vio_dbg - do "shift" mechansim" to get full violation 
information.
+ *   shift mechanism is depends on devapc hardware design.
+ *   Mediatek devapc set multiple slaves as a group.
+ *   When violation is triggered, violation info is kept
+ *   inside devapc hardware.
+ *   Driver should do shift mechansim to sync full 
violation
+ *   info to VIO_DBGs registers.
+ *
+ */
+static int devapc_sync_vio_dbg(struct

[PATCH v7] Add MediaTek MT6779 devapc driver

[Neal Liu]

These patch series introduce a MediaTek MT6779 devapc driver.

MediaTek bus fabric provides TrustZone security support and data protection to 
prevent slaves from being accessed by unexpected masters.
The security violation is logged and sent to the processor for further analysis 
or countermeasures.

Any occurrence of security violation would raise an interrupt, and it will be 
handled by mtk-devapc driver.
The violation information is printed in order to find the murderer.

changes since v6:
- remove unnecessary mask/unmask module irq during ISR.

changes since v5:
- remove redundant write reg operation.
- use static variable of vio_dbgs instead.
- add stop_devapc() if driver is removed.

changes since v4:
- refactor data structure.
- merge two simple functions into one.
- refactor register setting to prevent too many function call overhead.

changes since v3:
- revise violation handling flow to make it more easily to understand
  hardware behavior.
- add more comments to understand how hardware works.

changes since v2:
- pass platform info through DT data.
- remove unnecessary function.
- remove slave_type because it always equals to 1 in current support SoC.
- use vio_idx_num instread of list all devices' index.
- add more comments to describe hardware behavior.

changes since v1:
- move SoC specific part to DT data.
- remove unnecessary boundary check.
- remove unnecessary data type declaration.
- use read_poll_timeout() instread of for loop polling.
- revise coding style elegantly.


*** BLURB HERE ***

Neal Liu (2):
  dt-bindings: devapc: add bindings for mtk-devapc
  soc: mediatek: add mt6779 devapc driver

 .../bindings/soc/mediatek/devapc.yaml |  58 
 drivers/soc/mediatek/Kconfig  |   9 +
 drivers/soc/mediatek/Makefile |   1 +
 drivers/soc/mediatek/mtk-devapc.c | 305 ++
 4 files changed, 373 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
 create mode 100644 drivers/soc/mediatek/mtk-devapc.c

-- 
2.18.0

[PATCH v7 1/2] dt-bindings: devapc: add bindings for mtk-devapc

[Neal Liu]

Add bindings for mtk-devapc.

Signed-off-by: Neal Liu 
---
 .../devicetree/bindings/soc/mediatek/devapc.yaml   |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml

diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml 
b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
new file mode 100644
index 000..6c763f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/mediatek/devapc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: MediaTek Device Access Permission Control driver
+
+description: |
+  MediaTek bus fabric provides TrustZone security support and data
+  protection to prevent slaves from being accessed by unexpected masters.
+  The security violation is logged and sent to the processor for further
+  analysis and countermeasures.
+
+maintainers:
+  - Neal Liu 
+
+properties:
+  compatible:
+enum:
+  - mediatek,mt6779-devapc
+
+  reg:
+description: The base address of devapc register bank
+maxItems: 1
+
+  interrupts:
+description: A single interrupt specifier
+maxItems: 1
+
+  clocks:
+description: Contains module clock source and clock names
+maxItems: 1
+
+  clock-names:
+description: Names of the clocks list in clocks property
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+examples:
+  - |
+#include 
+#include 
+
+devapc: devapc@10207000 {
+  compatible = "mediatek,mt6779-devapc";
+  reg = <0x10207000 0x1000>;
+  interrupts = ;
+  clocks = <&infracfg_ao CLK_INFRA_DEVICE_APC>;
+  clock-names = "devapc-infra-clock";
+};
-- 
1.7.9.5

Re: [PATCH v5 0/7] Fix timeout clock used by hardware data timeout

[Sowjanya Komatineni]

Sorry please ignore this series.

Wrong patches from my system went out.

Will send as v6.

Thanks

Sowjanya

On 8/26/20 1:05 PM, Sowjanya Komatineni wrote:

Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.

Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.

This series includes patches to fix this for Tegra210/Tegra186/Tegra194.

These patches need to be manually backported for 4.9, 4.14 and 4.19.

Will send patches to backport separately once these patches are ack'd.

Delta between patch versions:
[v5]:   Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
  based on no. of clocks in sdhci device node as old device trees
  do not use sdhci clock name and this allows proper clock retrival
  irrespective of sdhci and tmclk clocks order in device tree.  
- Added separate quirk for identifying SoC's supporting separate
  timeout clock to be more clear.

[v4]:   Include additional dt-binding patch

[v3]:   Same as v2 with fixes tag

[v2]:   Includes minor fix
- Patch-0006: parentheses around operand of '!'

Sowjanya Komatineni (7):
   sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
   sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
   dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
   arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
   arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
   arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
   sdhci: tegra: Add missing TMCLK for data timeout

  .../bindings/mmc/nvidia,tegra20-sdhci.txt  | 32 +++-
  arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 20 +++--
  arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 15 ++--
  arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 20 +++--
  drivers/mmc/host/sdhci-tegra.c | 91 +++---
  5 files changed, 143 insertions(+), 35 deletions(-)

kernel BUG at fs/ext4/inode.c:LINE!

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:c3d8f220 Merge tag 'kbuild-fixes-v5.9' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f83cb690
kernel config:  https://syzkaller.appspot.com/x/.config?x=bb68b9e8a8cc842f
dashboard link: https://syzkaller.appspot.com/bug?extid=3622cea378100f45d59f
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1287ac9690
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11c7ac4690

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3622cea378100f45d...@syzkaller.appspotmail.com

[ cut here ]
kernel BUG at fs/ext4/inode.c:2598!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 1 PID: 27612 Comm: syz-executor879 Not tainted 5.9.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:mpage_prepare_extent_to_map+0xd34/0xd40 fs/ext4/inode.c:2598
Code: 89 e8 a0 74 9f ff 0f 0b e8 59 81 70 ff 4c 89 e7 48 c7 c6 da a3 07 89 e8 
8a 74 9f ff 0f 0b e8 43 81 70 ff 0f 0b e8 3c 81 70 ff <0f> 0b e8 c5 b3 25 06 0f 
1f 44 00 00 55 41 57 41 56 41 55 41 54 53
RSP: 0018:c9000a0974d8 EFLAGS: 00010293
RAX: 820476e4 RBX: 00fffe00a01f RCX: 88808ea5c340
RDX:  RSI: a01f RDI: 
RBP: ea00020d4f80 R08: 820471e4 R09: f9400041a9f1
R10: f9400041a9f1 R11:  R12: ea00020d4f80
R13: c9000a0977b0 R14: 1d400041a9f1 R15: dc00
FS:  7f5055f25700() GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004ae4b0 CR3: a2d7f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 ext4_writepages+0xa98/0x3750 fs/ext4/inode.c:2735
 do_writepages+0xda/0x1f0 mm/page-writeback.c:2352
 __filemap_fdatawrite_range+0x2a5/0x350 mm/filemap.c:422
 filemap_write_and_wait_range+0xca/0x160 mm/filemap.c:655
 iomap_dio_rw+0x5a7/0xeb0 fs/iomap/direct-io.c:478
 ext4_dio_read_iter fs/ext4/file.c:77 [inline]
 ext4_file_read_iter+0x544/0x6d0 fs/ext4/file.c:129
 call_read_iter include/linux/fs.h:1876 [inline]
 generic_file_splice_read+0x3c5/0x640 fs/splice.c:312
 do_splice_to fs/splice.c:870 [inline]
 splice_direct_to_actor+0x3bd/0xb60 fs/splice.c:950
 do_splice_direct+0x201/0x340 fs/splice.c:1059
 do_sendfile+0x86d/0x1210 fs/read_write.c:1540
 __do_sys_sendfile64 fs/read_write.c:1601 [inline]
 __se_sys_sendfile64 fs/read_write.c:1587 [inline]
 __x64_sys_sendfile64+0x164/0x1a0 fs/read_write.c:1587
 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x448bc9
Code: e8 1c e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
0b 06 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f5055f24ce8 EFLAGS: 0246 ORIG_RAX: 0028
RAX: ffda RBX: 006e4a28 RCX: 00448bc9
RDX:  RSI: 0006 RDI: 0004
RBP: 006e4a20 R08:  R09: 
R10: 8400fffb R11: 0246 R12: 006e4a2c
R13: 7ffdc73a76df R14: 7f5055f259c0 R15: 20c49ba5e353f7cf
Modules linked in:
---[ end trace aba5fca59eda2183 ]---
RIP: 0010:mpage_prepare_extent_to_map+0xd34/0xd40 fs/ext4/inode.c:2598
Code: 89 e8 a0 74 9f ff 0f 0b e8 59 81 70 ff 4c 89 e7 48 c7 c6 da a3 07 89 e8 
8a 74 9f ff 0f 0b e8 43 81 70 ff 0f 0b e8 3c 81 70 ff <0f> 0b e8 c5 b3 25 06 0f 
1f 44 00 00 55 41 57 41 56 41 55 41 54 53
RSP: 0018:c9000a0974d8 EFLAGS: 00010293
RAX: 820476e4 RBX: 00fffe00a01f RCX: 88808ea5c340
RDX:  RSI: a01f RDI: 
RBP: ea00020d4f80 R08: 820471e4 R09: f9400041a9f1
R10: f9400041a9f1 R11:  R12: ea00020d4f80
R13: c9000a0977b0 R14: 1d400041a9f1 R15: dc00
FS:  7f5055f25700() GS:8880ae90() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004ae4b0 CR3: a2d7f000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patche

Re: [PATCH v5 7/7] sdhci: tegra: Add missing TMCLK for data timeout

[kernel test robot]

Hi Sowjanya,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Sowjanya-Komatineni/Fix-timeout-clock-used-by-hardware-data-timeout/20200827-040814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

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

All errors (new ones prefixed by >>):

>> drivers/mmc/host/sdhci-tegra.c:1496:24: error: expected '}' before ';' token
1496 |   NVQUIRK_HAS_TMCLK;
 |^
   drivers/mmc/host/sdhci-tegra.c:1488:62: note: to match this '{'
1488 | static const struct sdhci_tegra_soc_data soc_data_tegra194 = {
 |  ^
   drivers/mmc/host/sdhci-tegra.c: In function 'sdhci_tegra_probe':
>> drivers/mmc/host/sdhci-tegra.c:1643:6: error: implicit declaration of 
>> function 'of_clk_get_parent_count' [-Werror=implicit-function-declaration]
1643 |  if (of_clk_get_parent_count(&pdev->dev) == 1) {
 |  ^~~
>> drivers/mmc/host/sdhci-tegra.c:1648:22: error: 'dev' undeclared (first use 
>> in this function); did you mean 'pdev'?
1648 |   clk = devm_clk_get(dev, NULL)
 |  ^~~
 |  pdev
   drivers/mmc/host/sdhci-tegra.c:1648:22: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/mmc/host/sdhci-tegra.c:1648:32: error: expected ';' before 'if'
1648 |   clk = devm_clk_get(dev, NULL)
 |^
 |;
1649 |   if (IS_ERR(clk)) {
 |   ~~
   drivers/mmc/host/sdhci-tegra.c:1682:35: error: expected ';' before 'if'
1682 |   clk = devm_clk_get(dev, "sdhci")
 |   ^
 |   ;
1683 |   if (IS_ERR(clk)) {
 |   ~~   
   drivers/mmc/host/sdhci-tegra.c:1727:1: warning: label 'err_clk_get' defined 
but not used [-Wunused-label]
1727 | err_clk_get:
 | ^~~
   cc1: some warnings being treated as errors

# 
https://github.com/0day-ci/linux/commit/51ed0e529a10cbce9dba08a11817207acb1b5bcf
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sowjanya-Komatineni/Fix-timeout-clock-used-by-hardware-data-timeout/20200827-040814
git checkout 51ed0e529a10cbce9dba08a11817207acb1b5bcf
vim +1496 drivers/mmc/host/sdhci-tegra.c

  1487  
  1488  static const struct sdhci_tegra_soc_data soc_data_tegra194 = {
  1489  .pdata = &sdhci_tegra186_pdata,
  1490  .dma_mask = DMA_BIT_MASK(39),
  1491  .nvquirks = NVQUIRK_NEEDS_PAD_CONTROL |
  1492  NVQUIRK_HAS_PADCALIB |
  1493  NVQUIRK_DIS_CARD_CLK_CONFIG_TAP |
  1494  NVQUIRK_ENABLE_SDR50 |
  1495  NVQUIRK_ENABLE_SDR104 |
> 1496  NVQUIRK_HAS_TMCLK;
  1497  .min_tap_delay = 96,
  1498  .max_tap_delay = 139,
  1499  };
  1500  
  1501  static const struct of_device_id sdhci_tegra_dt_match[] = {
  1502  { .compatible = "nvidia,tegra194-sdhci", .data = 
&soc_data_tegra194 },
  1503  { .compatible = "nvidia,tegra186-sdhci", .data = 
&soc_data_tegra186 },
  1504  { .compatible = "nvidia,tegra210-sdhci", .data = 
&soc_data_tegra210 },
  1505  { .compatible = "nvidia,tegra124-sdhci", .data = 
&soc_data_tegra124 },
  1506  { .compatible = "nvidia,tegra114-sdhci", .data = 
&soc_data_tegra114 },
  1507  { .compatible = "nvidia,tegra30-sdhci", .data = 
&soc_data_tegra30 },
  1508  { .compatible = "nvidia,tegra20-sdhci", .data = 
&soc_data_tegra20 },
  1509  {}
  1510  };
  1511  MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
  1512  
  

Re: [PATCH v3] lib/string.c: implement stpcpy

[Joe Perches]

On Wed, 2020-08-26 at 19:33 -0700, Kees Cook wrote:
> On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
> > On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
> > > On Thu, Aug 27, 2020 at 07:59:45AM +0900, Masahiro Yamada wrote:
> > []
> > > > OK, then stpcpy(), strcpy() and sprintf()
> > > > have the same level of unsafety.
> > > 
> > > Yes. And even snprintf() is dangerous because its return value is how
> > > much it WOULD have written, which when (commonly) used as an offset for
> > > further pointer writes, causes OOB writes too. :(
> > > https://github.com/KSPP/linux/issues/105
> > > 
> > > > strcpy() is used everywhere.
> > > 
> > > Yes. It's very frustrating, but it's not an excuse to continue
> > > using it nor introducing more bad APIs.
> > > 
> > > $ git grep '\bstrcpy\b' | wc -l
> > > 2212
> > > $ git grep '\bstrncpy\b' | wc -l
> > > 751
> > > $ git grep '\bstrlcpy\b' | wc -l
> > > 1712
> > > 
> > > $ git grep '\bstrscpy\b' | wc -l
> > > 1066
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> > > https://github.com/KSPP/linux/issues/88
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> > > https://github.com/KSPP/linux/issues/89
> > > 
> > > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> > > https://github.com/KSPP/linux/issues/90
> > > 
> > > We have no way right now to block the addition of deprecated API usage,
> > > which makes ever catching up on this replacement very challenging.
> > 
> > These could be added to checkpatch's deprecated_api test.
> > ---
> >  scripts/checkpatch.pl | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 149518d2a6a7..f9ccb2a63a95 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -605,6 +605,9 @@ foreach my $entry (@mode_permission_funcs) {
> >  $mode_perms_search = "(?:${mode_perms_search})";
> >  
> >  our %deprecated_apis = (
> > +   "strcpy"=> "strscpy",
> > +   "strncpy"   => "strscpy",
> > +   "strlcpy"   => "strscpy",
> > "synchronize_rcu_bh"=> "synchronize_rcu",
> > "synchronize_rcu_bh_expedited"  => "synchronize_rcu_expedited",
> > "call_rcu_bh"   => "call_rcu",
> > 
> > 
> 
> Good idea, yeah. We, unfortunately, need to leave strncpy() off this
> list for now because it's not *strictly* deprecated (see the notes in
> bug report[1]), but the others can be.

OK, but it is in Documentation/process/deprecated.rst

strncpy() on NUL-terminated strings
---
Use of strncpy() does not guarantee that the destination buffer
will be NUL terminated. This can lead to various linear read overflows
and other misbehavior due to the missing termination. It also NUL-pads the
destination buffer if the source contents are shorter than the destination
buffer size, which may be a needless performance penalty for callers using
only NUL-terminated strings. The safe replacement is strscpy().
(Users of strscpy() still needing NUL-padding should instead
use strscpy_pad().)

If a caller is using non-NUL-terminated strings, strncpy() can
still be used, but destinations should be marked with the `__nonstring
`_
attribute to avoid future compiler warnings.

[PATCH] ice: Fix memleak in ice_set_ringparam

[Dinghao Liu]

When kcalloc() on rx_rings fails, we should free tx_rings
and xdp_rings to prevent memleak. Similarly, when
ice_alloc_rx_bufs() fails, we should free xdp_rings.

Signed-off-by: Dinghao Liu 
---
 drivers/net/ethernet/intel/ice/ice_ethtool.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 9e8e9531cd87..caf64eb5e96d 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -2863,7 +2863,7 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
rx_rings = kcalloc(vsi->num_rxq, sizeof(*rx_rings), GFP_KERNEL);
if (!rx_rings) {
err = -ENOMEM;
-   goto done;
+   goto free_xdp;
}
 
ice_for_each_rxq(vsi, i) {
@@ -2892,7 +2892,7 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
}
kfree(rx_rings);
err = -ENOMEM;
-   goto free_tx;
+   goto free_xdp;
}
}
 
@@ -2943,6 +2943,15 @@ ice_set_ringparam(struct net_device *netdev, struct 
ethtool_ringparam *ring)
}
goto done;
 
+free_xdp:
+   if (xdp_rings) {
+   for (i = 0; i < vsi->num_xdp_txq; i++) {
+   ice_free_tx_ring(vsi->xdp_rings[i]);
+   *vsi->xdp_rings[i] = xdp_rings[i];
+   }
+   kfree(xdp_rings);
+   }
+
 free_tx:
/* error cleanup if the Rx allocations failed after getting Tx */
if (tx_rings) {
-- 
2.17.1

Re: [PATCH v3] lib/string.c: implement stpcpy

[Kees Cook]

On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
> On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2020 at 07:59:45AM +0900, Masahiro Yamada wrote:
> []
> > > OK, then stpcpy(), strcpy() and sprintf()
> > > have the same level of unsafety.
> > 
> > Yes. And even snprintf() is dangerous because its return value is how
> > much it WOULD have written, which when (commonly) used as an offset for
> > further pointer writes, causes OOB writes too. :(
> > https://github.com/KSPP/linux/issues/105
> > 
> > > strcpy() is used everywhere.
> > 
> > Yes. It's very frustrating, but it's not an excuse to continue
> > using it nor introducing more bad APIs.
> > 
> > $ git grep '\bstrcpy\b' | wc -l
> > 2212
> > $ git grep '\bstrncpy\b' | wc -l
> > 751
> > $ git grep '\bstrlcpy\b' | wc -l
> > 1712
> > 
> > $ git grep '\bstrscpy\b' | wc -l
> > 1066
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> > https://github.com/KSPP/linux/issues/88
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> > https://github.com/KSPP/linux/issues/89
> > 
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
> > https://github.com/KSPP/linux/issues/90
> > 
> > We have no way right now to block the addition of deprecated API usage,
> > which makes ever catching up on this replacement very challenging.
> 
> These could be added to checkpatch's deprecated_api test.
> ---
>  scripts/checkpatch.pl | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 149518d2a6a7..f9ccb2a63a95 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -605,6 +605,9 @@ foreach my $entry (@mode_permission_funcs) {
>  $mode_perms_search = "(?:${mode_perms_search})";
>  
>  our %deprecated_apis = (
> + "strcpy"=> "strscpy",
> + "strncpy"   => "strscpy",
> + "strlcpy"   => "strscpy",
>   "synchronize_rcu_bh"=> "synchronize_rcu",
>   "synchronize_rcu_bh_expedited"  => "synchronize_rcu_expedited",
>   "call_rcu_bh"   => "call_rcu",
> 
> 

Good idea, yeah. We, unfortunately, need to leave strncpy() off this
list for now because it's not *strictly* deprecated (see the notes in
bug report[1]), but the others can be.

[1] https://github.com/KSPP/linux/issues/89

-- 
Kees Cook

[PATCH v3] mm: memcg: Fix memcg reclaim soft lockup

[Xunlei Pang]

We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
the target memcg doesn't have any reclaimable memory.

It can be easily reproduced as below:
 watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204]
 CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12
 Call Trace:
  shrink_lruvec+0x49f/0x640
  shrink_node+0x2a6/0x6f0
  do_try_to_free_pages+0xe9/0x3e0
  try_to_free_mem_cgroup_pages+0xef/0x1f0
  try_charge+0x2c1/0x750
  mem_cgroup_charge+0xd7/0x240
  __add_to_page_cache_locked+0x2fd/0x370
  add_to_page_cache_lru+0x4a/0xc0
  pagecache_get_page+0x10b/0x2f0
  filemap_fault+0x661/0xad0
  ext4_filemap_fault+0x2c/0x40
  __do_fault+0x4d/0xf9
  handle_mm_fault+0x1080/0x1790

It only happens on our 1-vcpu instances, because there's no chance
for oom reaper to run to reclaim the to-be-killed process.

Add a cond_resched() at the upper shrink_node_memcgs() to solve this
issue, this will mean that we will get a scheduling point for each
memcg in the reclaimed hierarchy without any dependency on the
reclaimable memory in that memcg thus making it more predictable.

Acked-by: Chris Down 
Acked-by: Michal Hocko 
Suggested-by: Michal Hocko 
Signed-off-by: Xunlei Pang 
---
 mm/vmscan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 99e1796..9727dd8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2615,6 +2615,14 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct 
scan_control *sc)
unsigned long reclaimed;
unsigned long scanned;
 
+   /*
+* This loop can become CPU-bound when target memcgs
+* aren't eligible for reclaim - either because they
+* don't have any reclaimable pages, or because their
+* memory is explicitly protected. Avoid soft lockups.
+*/
+   cond_resched();
+
mem_cgroup_calculate_protection(target_memcg, memcg);
 
if (mem_cgroup_below_min(memcg)) {
-- 
1.8.3.1

Re: [PATCH] MIPS: Loongson: Fix complie errors without CONFIG_SMP

[hejinyang]

On 08/26/2020 09:01 PM, Matthew Wilcox wrote:

On Wed, Aug 26, 2020 at 08:53:27PM +0800, Jinyang He wrote:

+++ b/arch/mips/include/asm/mach-loongson64/topology.h
@@ -4,7 +4,11 @@
  
  #ifdef CONFIG_NUMA
  
+#ifdef CONFIG_SMP

  #define cpu_to_node(cpu)  (cpu_logical_map(cpu) >> 2)
+#else
+#define cpu_to_node(cpu)   0
+#endif

Are you saying you've enabled NUMA without enabling SMP?  Does that make
sense?


NUMA option normally work with more than two nodes, though Loongson64 use it
default after patch 6fbde6b492dfc761ad60a68fb2cb32b1eb05b786. Loongson64(3A)'s
each node consists of 4 cpus while it only has 4 cpus. In other words, it has
only one node while open NUMA. I'm confused it if NUMA deponds on SMP.

I'll try fix it with unabling NUMA and SMP later.

Thanks.:-)

Re: [PATCH] linux/kernel.h: add container_from()

[Kees Cook]

On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote:
> Introduce container_from() as a generic helper instead of
> sub-systems defining a private from_* API
> (Eg: from_tasklets recently introduced in
> 12cc923f1ccc: Tasklet: Introduce new initialization API)
> 
> The helper is similar to container_of() in argument order
> with the difference of naming the containing structure instead
> of having to specify its type.
> 
> Suggested-by: James E.J. Bottomley 
> Suggested-by: Greg Kroah-Hartman 
> Suggested-by: Jens Axboe 
> Signed-off-by: Allen Pais 

Acked-by: Kees Cook 

Who can carry this so it can get used by multiple trees? Should I keep a
git branch folks should merge when taking Allen's conversion patches?

(In the future we can do a treewide replacement of the
subsystem-specific from*() macros into container_from())

Thanks!

-- 
Kees Cook

Re: [PATCH v2 00/13] extcon: ptn5150: Improvements and fixes

[Chanwoo Choi]

Hi Suman,

On 8/27/20 6:56 AM, Suman Anna wrote:
> Hi Chanwoo,
> 
> On 8/24/20 6:28 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 8/24/20 7:36 PM, Ramuthevar, Vadivel MuruganX wrote:
>>> Hi,
>>>
>>>  Thank you for the patches and optimized the code as well.
>>>  I have applied your patches and tested, it's working fine
>>>  with few minor changes as per Intel's LGM board.
>>
>> Thanks for the test.
>>
>>>
>>>  can I send the patches along with patches or we need to wait until
>>>  your patch get merge?
>>>
>>>  Please suggest to me go further, Thanks!
>>
>> I applied these patches. You better to send your patches
>> based on extcon-next. Thanks.
> 
> I am not sure what happened, but the $id and $schema got morphed in the patch
> on linux-next, 000ce2ad3c96 ("dt-bindings: extcon: ptn5150: Convert binding to
> DT schema"), when compared to Krzysztof's original patch.

It is my fault because of the company's firewall.
I updated and pushed it. Thanks.

> 
> This is causing dtbs_check to fail in general on linux-next,
>   UPD include/config/kernel.release
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> Traceback (most recent call last):
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 774, in resolve_from_url
> document = self.store[url]
>   File "/home/suman/.local/lib/python3.6/site-packages/jsonschema/_utils.py",
> line 22, in __getitem__
> return self.store[self.normalize(uri)]
> KeyError:
> 'https://protect2.fireeye.com/url?k=59835ffc-05905d01-59822c67-0cc47a336902-306bd2691e458c36&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 777, in resolve_from_url
> document = self.resolve_remote(url)
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 860, in resolve_remote
> result = requests.get(uri).json()
>   File "/usr/lib/python3/dist-packages/requests/models.py", line 892, in json
> return complexjson.loads(self.text, **kwargs)
>   File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in 
> loads
> return _default_decoder.decode(s)
>   File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in 
> decode
> obj, end = self.raw_decode(s)
>   File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in
> raw_decode
> return self.scan_once(s, idx=_w(s, idx).end())
> simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/home/suman/.local/bin/dt-doc-validate", line 67, in 
> ret = check_doc(f)
>   File "/home/suman/.local/bin/dt-doc-validate", line 33, in check_doc
> for error in sorted(dtschema.DTValidator.iter_schema_errors(testtree),
> key=lambda e: e.linecol):
>   File "/home/suman/.local/lib/python3.6/site-packages/dtschema/lib.py", line
> 663, in iter_schema_errors
> meta_schema = cls.resolver.resolve_from_url(schema['$schema'])
>   File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", 
> line
> 779, in resolve_from_url
> raise exceptions.RefResolutionError(exc)
> jsonschema.exceptions.RefResolutionError: Expecting value: line 1 column 1 
> (char 0)
> Documentation/devicetree/bindings/Makefile:52: recipe for target
> 'Documentation/devicetree/bindings/processed-schema-examples.json' failed
> make[1]: *** 
> [Documentation/devicetree/bindings/processed-schema-examples.json]
> Error 123
> Makefile:1366: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
> 
> regards
> Suman
> 
>>
>>>
>>> On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
 Hi,

 Changes since v1:
 1. Mutex unlock fix in patch 8/13.

 Best regards,
 Krzysztof

>>>
>>>
>>
>>
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[Guenter Roeck]

On 8/26/20 6:11 PM, 啟原黃 wrote:
> Guenter Roeck  於 2020年8月27日 週四 上午9:02寫道：
>>
>> On 8/26/20 5:59 PM, 啟原黃 wrote:
>> [ ... ]
> +static int mt6360_tcpc_remove(struct platform_device *pdev)
> +{
> + struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
> +
> + tcpci_unregister_port(mti->tcpci);

 That leaves interrupts enabled, which might be racy
 because interrupts are still enabled here.
>>> M..., yes, it will cause the race condition during module remove.
>>> I'll add disable_irq before tcpci unregister to prevent it.
>>
>> Or just set TCPC_ALERT_MASK to 0, as in tcpci.c.
> Both are right, Thx. I'll choose one.
> 
> BTW, it seems enum typec_cc_status is used by tcpci.h.
> If I don't include tcpm.h, it will raise a warning during the compile time.

Ok, thanks for the note (that means tcpci.h should include
linux/usb/tcpm.h, really).

Guenter

Re: [PATCH] perf stat: update POWER9 metrics to utilize other metrics

[Paul A. Clarke]

On Wed, Aug 26, 2020 at 09:26:40AM -0700, Ian Rogers wrote:
> On Fri, Aug 14, 2020 at 5:43 AM Arnaldo Carvalho de Melo
>  wrote:
> > Em Fri, Aug 14, 2020 at 11:20:42AM +0530, kajoljain escreveu:
> > > On 8/14/20 9:13 AM, Ian Rogers wrote:
> > > > On Thu, Aug 13, 2020 at 3:21 PM Paul A. Clarke  wrote:
> > > >> These changes take advantage of the new capability added in
> > > >> merge commit 00e4db51259a5f936fec1424b884f029479d3981
> > > >> "Allow using computed metrics in calculating other metrics".
> > > >>
> > > >> The net is a simplification of the expressions for a handful
> > > >> of metrics, but no functional change.
> > > >>
> > > >> Signed-off-by: Paul A. Clarke 
> > >
> > >   The patch looks good to me.
> > >
> > > Reviewed-by: Kajol Jain
> >
> > Thanks, applied. Added Ian's Acked-by as well.
> 
> I've synced perf and testing on a remote machine (not easy for me to
> log into) I see failures in perf test "10.3: Parsing of PMU event
> table metrics" like:
> ...
> parsing metric: dfu_stall_cpi - dflong_stall_cpi
> Parse event failed metric 'dfu_other_stall_cpi' id 'dflong_stall_cpi'
> expr 'dfu_stall_cpi - dflong_stall_cpi'
> Error string 'parser error' help '(null)'
> Parse event failed metric 'dfu_other_stall_cpi' id 'dfu_stall_cpi'
> expr 'dfu_stall_cpi - dflong_stall_cpi'
> Error string 'parser error' help '(null)'
> ...
> 
> This may be that the test doesn't handle the metric in terms of metric
> addition and so I'll look for a fix. I thought I'd send a heads up in
> case you had already seen/addressed this. Is perf test on PowerPC
> clean for you at the moment?

I see these errors as well (on 5.9-rc2).  Each error seems to be for the
newer metrics that take advantage of the newer functionality, including
the metrics I changed recently, and Kajol's 24x7 and nest metrics.

Thanks for the heads up!  I confess I had not seen the errors only because
I wasn't looking.  :-/

PC

Re: [PATCH 5/6] pwm: sprd: Simplify with dev_err_probe()

[Chunyan Zhang]

On Wed, 26 Aug 2020 at 22:48, Krzysztof Kozlowski  wrote:
>
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe().  Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Chunyan Zhang 

Thanks!

> ---
>  drivers/pwm/pwm-sprd.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sprd.c b/drivers/pwm/pwm-sprd.c
> index be2394227423..5123d948efd6 100644
> --- a/drivers/pwm/pwm-sprd.c
> +++ b/drivers/pwm/pwm-sprd.c
> @@ -228,11 +228,8 @@ static int sprd_pwm_clk_init(struct sprd_pwm_chip *spc)
> if (ret == -ENOENT)
> break;
>
> -   if (ret != -EPROBE_DEFER)
> -   dev_err(spc->dev,
> -   "failed to get channel clocks\n");
> -
> -   return ret;
> +   return dev_err_probe(spc->dev, ret,
> +"failed to get channel 
> clocks\n");
> }
>
> clk_pwm = chn->clks[SPRD_PWM_CHN_OUTPUT_CLK].clk;
> --
> 2.17.1
>

Re: [PATCH v8 1/2] Add a "nosymfollow" mount option.

[Al Viro]

On Wed, Aug 26, 2020 at 02:48:19PM -0600, Ross Zwisler wrote:

> Al, now that the changes to fs/namei.c have landed and we're past the merge
> window for v5.9, what are your thoughts on this patch and the associated test?

Humm...  should that be nd->path.mnt->mnt_flags or link->mnt->mnt_flags?
Usually it's the same thing, but they might differ.  IOW, is that about the
directory we'd found it in, or is it about the link itself?

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

[Bjorn Andersson]

On Wed 26 Aug 16:32 CDT 2020, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2020-08-25 21:36:16)
> > On Tue 25 Aug 21:47 CDT 2020, Stephen Boyd wrote:
> > 
> > > The dp_com resource is always at index 1 according to the dts files in
> > > the kernel. Get this resource by index so that we don't need to make
> > > future additions to the DT binding use 'reg-names'.
> > > 
> > 
> > Afaict the DT binding for the USB/DP phy defines that there should be a
> > reg name of "dp_com" and the current dts files all specifies this. Am I
> > missing something?
> 
> Yes the binding enforces this but this patch is removing that
> enforcement and instead mandating that dp_com is always at index 1 (i.e.
> the second one) so that we can add the DP serdes region directly after
> and avoid adding yet another reg-names property. I changed the binding
> for this usb3-dp phy compatible to make reg-names optional as well. I
> don't see any gain from using reg-names.
> 

Thanks for the explanation, I don't have any objections to this.

> > 
> > PS. Why isn't this a devm_platform_ioremap_resource{,_byname}()?
> 
> Sure. I'll roll that into this patch.

Thanks,
Bjorn

Re: [PATCH v2 2/2] soc: qcom: rpmh: Allow RPMH driver to be loaded as a module

[Bjorn Andersson]

On Tue 25 Aug 06:21 CDT 2020, Maulik Shah wrote:

> From: John Stultz 
> 
> This patch allow the rpmh driver to be loaded as a permenent
> module. Meaning it can be loaded from a module, but then cannot
> be unloaded.
> 
> Ideally, it would include a remove hook and related logic, but
> the rpmh driver is fairly core to the system, so once its loaded
> with almost anything else to get the system to go, the dependencies
> are not likely to ever also be removed.
> 
> So making it a permanent module at least improves things slightly
> over requiring it to be a built in driver.
> 
> Cc: Todd Kjos 
> Cc: Saravana Kannan 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Rajendra Nayak 
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: John Stultz 
> Signed-off-by: Bjorn Andersson 
> [mkshah: Fix typos in commit message, send after removing _rcuidle trace]
> Signed-off-by: Maulik Shah 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/soc/qcom/Kconfig| 2 +-
>  drivers/soc/qcom/rpmh-rsc.c | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 3dc3e3d..892bdc7 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -92,7 +92,7 @@ config QCOM_RMTFS_MEM
> Say y here if you intend to boot the modem remoteproc.
>  
>  config QCOM_RPMH
> - bool "Qualcomm RPM-Hardened (RPMH) Communication"
> + tristate "Qualcomm RPM-Hardened (RPMH) Communication"
>   depends on ARCH_QCOM || COMPILE_TEST
>   help
> Support for communication with the hardened-RPM blocks in
> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index fabe390d..5fce87c 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1025,6 +1026,7 @@ static const struct of_device_id rpmh_drv_match[] = {
>   { .compatible = "qcom,rpmh-rsc", },
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, rpmh_drv_match);
>  
>  static struct platform_driver rpmh_driver = {
>   .probe = rpmh_rsc_probe,
> @@ -1040,3 +1042,6 @@ static int __init rpmh_driver_init(void)
>   return platform_driver_register(&rpmh_driver);
>  }
>  arch_initcall(rpmh_driver_init);
> +
> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. RPMh Driver");
> +MODULE_LICENSE("GPL v2");
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

[PATCH v9 0/5] Provide basic driver to control Arm R5 co-processor found on Xilinx ZynqMP

[Ben Levinsky]

The driver was tested on Xilinx ZynqMP

For sake of ease of review, only support ZynqMP. Once accepted, then
add support for Versal platform and R5 loading onto OCM.

v2:
- remove domain struct as per review from Mathieu
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4:
- add default values for enums
- fix formatting as per checkpatch.pl --strict. Note that 1 warning and
  1 check are still raised as each is due to fixing the warning
  results in that particular line going over 80 characters.
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
- parse_fw change from use of rproc_of_resm_mem_entry_init to
  rproc_mem_entry_init and use of alloc/release
- var's of type zynqmp_r5_pdata all have same local variable name
- use dev_dbg instead of dev_info
v6:
- adding memory carveouts is handled much more similarly.
  All mem carveouts are now described in reserved memory as needed.
  That is, TCM nodes are not coupled to remoteproc anymore.
  This is reflected in the remoteproc R5 driver and the device tree
  binding.
- remove mailbox from device tree binding as it is not necessary for elf
  loading 
v7:
- remove unused headers
- zynqmp_r5_remoteproc_probe:lockstep_mode from u32* to u32
- device-tree binding "lockstep-mode"  to "xlnx,cluster-mode"
- remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
  probe()
- remove is_r5_mode_set from  zynqmp rpu remote processor private data
- do not error out if no mailbox is provided since mailboxes are optional
- remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as pdata
  is handled in zynqmp_r5_remoteproc_remove
v8:
- remove old acks, reviewed-by's in commit message
v9:
- if zynqmp_r5_remoteproc.c pdata->tx_mc_skbs not initialized, then do not
  call skb_queue_empty
- update arguments and documentation for zynqmp_pm_set_rpu_mode
- in fn zynqmp_pm_force_powerdown, change arg 'target' to 'node'
- zynqmp_pm_request_wakeup update code style
- edit 3/5 patch commit message
- document zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode
  documentation to include expected return val
- remove unused fn zynqmp_pm_get_node_status
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode uses second arg
- zynqmp_r5_remoteproc.c use of zynqmp_pm_set_tcm_config now does not
  have output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change lockstep_mode from u32* to u32
- update zynqmp_pm_set_rpu_mode and zynqmp_pm_set_rpu_mode documentation
  and remove unused args
v10:
- add include types.h to xlnx-zynqmp.h for compilation

Ben Levinsky (5):
  firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU
configuration.
  firmware: xilinx: Add shutdown/wakeup APIs
  firmware: xilinx: Add RPU configuration APIs
  dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc
bindings
  remoteproc: Add initial zynqmp R5 re

[PATCH v10 2/5] firmware: xilinx: Add shutdown/wakeup APIs

[Ben Levinsky]

Add shutdown/wakeup a resource eemi operations to shutdown
or bringup a resource.

Note alignment of args matches convention of other fn's in this file.
The reason being that the long fn name results in aligned args that
otherwise go over 80 chars so shift right to avoid this

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- fix formatting
v4:
- add default values for enumv3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
- fix formatting
v4:
- add default values for enum
v9:
- zynqmp_pm_force_powerdown update arg 'target' to 'node'
- zynqmp_pm_request_wakeup fix code style
v10:
- add types.h to includes for compilation
---
 drivers/firmware/xilinx/zynqmp.c | 35 
 include/linux/firmware/xlnx-zynqmp.h | 23 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 8d1ff2454e2e..a966ee956573 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,41 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
+ * be powered down forcefully
+ * @node:  Node ID of the targeted PU or subsystem
+ * @ack:   Flag to specify whether acknowledge is requested
+ *
+ * Return: status, either success or error+reason
+ */
+int zynqmp_pm_force_pwrdwn(const u32 node,
+  const enum zynqmp_pm_request_ack ack)
+{
+   return zynqmp_pm_invoke_fn(PM_FORCE_POWERDOWN, node, ack, 0, 0, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_force_pwrdwn);
+
+/**
+ * zynqmp_pm_request_wake - PM call to wake up selected master or subsystem
+ * @node:  Node ID of the master or subsystem
+ * @set_addr:  Specifies whether the address argument is relevant
+ * @address:   Address from which to resume when woken up
+ * @ack:   Flag to specify whether acknowledge requested
+ *
+ * Return: status, either success or error+reason
+ */
+int zynqmp_pm_request_wake(const u32 node,
+  const bool set_addr,
+  const u64 address,
+  const enum zynqmp_pm_request_ack ack)
+{
+   /* set_addr flag is encoded into 1st bit of address */
+   return zynqmp_pm_invoke_fn(PM_REQUEST_WAKEUP, node, address | set_addr,
+  address >> 32, ack, NULL);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
+
 /**
  * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
  * @node:  Node ID of the slave
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index bb347dfe4ba4..6241c5ac51b3 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -12,6 +12,7 @@
 
 #ifndef __FIRMWARE_ZYNQMP_H__
 #define __FIRMWARE_ZYNQMP_H__
+#include 
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
@@ -64,6 +65,8 @@
 
 enum pm_api_id {
PM_GET_API_VERSION = 1,
+   PM_FORCE_POWERDOWN = 8,
+   PM_REQUEST_WAKEUP = 10,
PM_SYSTEM_SHUTDOWN = 12,
PM_REQUEST_NODE = 13,
PM_RELEASE_NODE,
@@ -376,6 +379,12 @@ int zynqmp_pm_write_pggs(u32 index, u32 value);
 int zynqmp_pm_read_pggs(u32 index, u32 *value);
 int zynqmp_pm_system_shutdown(const u32 type, const u32 subtype);
 int zynqmp_pm_set_boot_health_status(u32 value);
+int zynqmp_pm_force_pwrdwn(const u32 target,
+  const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_request_wake(const u32 node,
+  const bool set_addr,
+  const u64 address,
+  const enum zynqmp_pm_request_ack ack);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -526,6 +535,20 @@ static inline int zynqmp_pm_set_boot_health_status(u32 
value)
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_force_pwrdwn(const u32 target,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_request_wake(const u32 node,
+const bool set_addr,
+const u64 address,
+const enum zynqmp_pm_request_ack ack)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1

[PATCH v10 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver

[Ben Levinsky]

R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different 2
configurations: split or lock-step.

The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
Platform Management Unit that handles the R5 configuration, memory access
and R5 lifecycle management. The interface to this manager is done in this
driver via zynqmp_pm_* function calls.

Signed-off-by: Ben Levinsky 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
Signed-off-by: Ed Mooring 
Signed-off-by: Jason Wu 
---
v2:
 - remove domain struct as per review from Mathieu
 v3:
 - add xilinx-related platform mgmt fn's instead of wrapping around
   function pointer in xilinx eemi ops struct
 v4:
 - add default values for enums
 - fix formatting as per checkpatch.pl --strict. Note that 1 warning and 1 check
   are still raised as each is due to fixing the warning results in that
 particular line going over 80 characters.
 v5:
 - parse_fw change from use of rproc_of_resm_mem_entry_init to
 rproc_mem_entry_init and use of alloc/release
 - var's of type zynqmp_r5_pdata all have same local variable name
 - use dev_dbg instead of dev_info
 v6:
 - adding memory carveouts is handled much more similarly. All mem
 carveouts are
   now described in reserved memory as needed. That is, TCM nodes are not
   coupled to remoteproc anymore. This is reflected in the remoteproc R5
 driver
   and the device tree binding.
 - remove mailbox from device tree binding as it is not necessary for elf
   loading
 - use lockstep-mode property for configuring RPU
 v7:
 - remove unused headers
 - change  u32 *lockstep_mode ->  u32 lockstep_mode;
 - change device-tree binding "lockstep-mode"  to xlnx,cluster-mode
 - remove zynqmp_r5_mem_probe and loop to Probe R5 memory devices at
   remoteproc-probe time
 - remove is_r5_mode_set from  zynqmp rpu remote processor private data
 - do not error out if no mailbox is provided
 - remove zynqmp_r5_remoteproc_probe call of platform_set_drvdata as
 pdata is
   handled in zynqmp_r5_remoteproc_remove
v8:
 - remove old acks, reviewed-by's in commit message
v9:
- as mboxes are now optional, if pdata->tx_mc_skbs not initialized then
  do not call skb_queue_empty
- update usage for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config and
  zynqmp_pm_get_rpu_mode
- update 5/5 patch commit message to document supported configurations
  and how they are booted by the driver.
- remove copyrights other than SPDX from zynqmp_r5_remoteproc.c
- compilation warnings no longer raised
- remove unused includes from zynqmp_r5_remoteproc.c
- remove unused  var autoboot from zynqmp_r5_remoteproc.c
- reorder zynqmp_r5_pdata fpr small mem savings due to alignment
- use of zynqmp_pm_set_tcm_config now does not have
  output arg
- in tcm handling, unconditionally use &= 0x000f mask since all nodes
  in this fn are for tcm
- update comments for translating dma field in tcm handling to device
  address
- update calls to rproc_mem_entry_init in parse_mem_regions so that there
  are only 2 cases for types of carveouts instead of 3
- in parse_mem_regions, check if device tree node is null before using it
- add example device tree nodes used in parse_mem_regions and tcm parsing
- add comment for vring id node length
- add check for string length so that vring id is at least min length
- move tcm nodes from reserved mem to instead own device tree nodes
   and only use them if enabled in device tree
- add comment for explaining handling of rproc_elf_load_rsc_table
- remove obsolete check for "if (vqid < 0)" in zynqmp_r5_rproc_kick
- remove unused field mems in struct zynqmp_r5_pdata
- remove call to zynqmp_r5_mem_probe and the fn itself as tcm handling
  is done by zyqmp_r5_pm_request_tcm
- remove obsolete setting of dma_ops and parent device dma_mask
- remove obsolete use of of_dma_configure
- add comment for call to r5_set_mode fn
- make mbox usage optional and gracefully inform user via dev_dbg if not
  present
- change var lockstep_mode from u32* to u32
---
 drivers/remoteproc/Kconfig|  10 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/zynqmp_r5_remoteproc.c | 898 ++
 3 files changed, 909 insertions(+)
 create mode 100644 drivers/remoteproc/zynqmp_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c4d1731295eb..dd9ed45654e0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -249,6 +249,16 @@ config STM32_RPROC
 
  This can be either built-in or a loadable module.
 
+config ZYNQMP_R5_REMOTEPROC
+   tristate "ZynqMP_R5 remoteproc support"
+   depends on ARM64 && PM && ARCH_ZYNQMP
+   select RPMSG_VIRTIO
+   select MAILBOX
+   select ZYNQMP_IPI_MBOX
+   help
+ Say y or m here to support ZynqMP R5 remote processors via the remote
+ processor framework.
+
 endif # REMOTEPROC
 
 endmenu
diff --git a/drivers/remoteproc

[PATCH v10 3/5] firmware: xilinx: Add RPU configuration APIs

[Ben Levinsky]

This patch adds APIs to access to configure RPU and its
processor-specific memory.

That is query the run-time mode of RPU as either split or lockstep as well
as API to set this mode. In addition add APIs to access configuration of
the RPUs' tightly coupled memory (TCM).

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
v9:
- update commit message
- for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
  expected output, arguments as well removing unused args
- remove unused fn zynqmp_pm_get_node_status
---
 drivers/firmware/xilinx/zynqmp.c | 51 
 include/linux/firmware/xlnx-zynqmp.h | 22 
 2 files changed, 73 insertions(+)

diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index a966ee956573..6907abcaa981 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -846,6 +846,57 @@ int zynqmp_pm_release_node(const u32 node)
 }
 EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
 
+/**
+ * zynqmp_pm_get_rpu_mode() - Get RPU mode
+ * @node_id:   Node ID of the device
+ * @out:   Returned output value
+ *
+ * Return: RPU mode. This is enum rpu_oper_mode
+ */
+int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_GET_RPU_OPER_MODE, 0, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
+
+/**
+ * zynqmp_pm_set_rpu_mode() - Set RPU mode
+ * @node_id:   Node ID of the device
+ * @arg1:  Argument 1 to requested IOCTL call. This is expeted to
+ *  to be value from enum rpu_oper_mode
+ * @out:   Returned output value
+ *
+ * This function is used to set RPU mode to split or lockstep
+ *
+ * Return: Returns status, either success or error+reason
+ */
+int zynqmp_pm_set_rpu_mode(u32 node_id,
+  u32 arg1, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_SET_RPU_OPER_MODE, arg1, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
+
+/**
+ * zynqmp_pm_set_tcm_config - configure TCM
+ * @arg1:  Argument 1 to requested IOCTL call
+ *  either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
+ * @out:   Returned output value
+ *
+ * This function is used to set RPU mode to split or combined
+ *
+ * Return: status: 0 for success, else failure
+ */
+int zynqmp_pm_set_tcm_config(u32 node_id,
+u32 arg1, u32 *out)
+{
+   return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
+  IOCTL_TCM_COMB_CONFIG, arg1, 0, out);
+}
+EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
+
 /**
  * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
  * be powered down forcefully
diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 6241c5ac51b3..c9977d890095 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -385,6 +385,11 @@ int zynqmp_pm_request_wake(const u32 node,
   const bool set_addr,
   const u64 address,
   const enum zynqmp_pm_request_ack ack);
+int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out);
+int zynqmp_pm_set_rpu_mode(u32 node_id,
+  u32 arg1, u32 *out);
+int zynqmp_pm_set_tcm_config(u32 node_id,
+u32 arg1, u32 *out);
 #else
 static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
 {
@@ -549,6 +554,23 @@ static inline int zynqmp_pm_request_wake(const u32 node,
 {
return -ENODEV;
 }
+
+static inline int zynqmp_pm_get_rpu_mode(u32 node_id, u32 *out)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_rpu_mode(u32 node_id,
+u32 arg1, u32 *out)
+{
+   return -ENODEV;
+}
+
+static inline int zynqmp_pm_set_tcm_config(u32 node_id,
+  u32 arg1, u32 *out)
+{
+   return -ENODEV;
+}
 #endif
 
 #endif /* __FIRMWARE_ZYNQMP_H__ */
-- 
2.17.1

[PATCH v10 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration.

[Ben Levinsky]

Add ZynqMP firmware ioctl enums for RPU configuration.

Signed-off-by: Ben Levinsky 
---
v3:
- add xilinx-related platform mgmt fn's instead of wrapping around
  function pointer in xilinx eemi ops struct
v4:
- add default values for enums
---

 include/linux/firmware/xlnx-zynqmp.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/firmware/xlnx-zynqmp.h 
b/include/linux/firmware/xlnx-zynqmp.h
index 5968df82b991..bb347dfe4ba4 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -104,6 +104,10 @@ enum pm_ret_status {
 };
 
 enum pm_ioctl_id {
+   IOCTL_GET_RPU_OPER_MODE = 0,
+   IOCTL_SET_RPU_OPER_MODE = 1,
+   IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+   IOCTL_TCM_COMB_CONFIG = 3,
IOCTL_SD_DLL_RESET = 6,
IOCTL_SET_SD_TAPDELAY,
IOCTL_SET_PLL_FRAC_MODE,
@@ -129,6 +133,21 @@ enum pm_query_id {
PM_QID_CLOCK_GET_MAX_DIVISOR,
 };
 
+enum rpu_oper_mode {
+   PM_RPU_MODE_LOCKSTEP = 0,
+   PM_RPU_MODE_SPLIT = 1,
+};
+
+enum rpu_boot_mem {
+   PM_RPU_BOOTMEM_LOVEC = 0,
+   PM_RPU_BOOTMEM_HIVEC = 1,
+};
+
+enum rpu_tcm_comb {
+   PM_RPU_TCM_SPLIT = 0,
+   PM_RPU_TCM_COMB = 1,
+};
+
 enum zynqmp_pm_reset_action {
PM_RESET_ACTION_RELEASE,
PM_RESET_ACTION_ASSERT,
-- 
2.17.1

[PATCH v10 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

[Ben Levinsky]

Add binding for ZynqMP R5 OpenAMP.

Represent the RPU domain resources in one device node. Each RPU
processor is a subnode of the top RPU domain node.

Signed-off-by: Ben Levinsky 
Signed-off-by: Jason Wu 
Signed-off-by: Wendy Liang 
Signed-off-by: Michal Simek 
---
v3:
- update zynqmp_r5 yaml parsing to not raise warnings for extra
  information in children of R5 node. The warning "node has a unit
  name, but no reg or ranges property" will still be raised though 
  as this particular node is needed to describe the
  '#address-cells' and '#size-cells' information.
v4::
- remove warning '/example-0/rpu@ff9a/r5@0: 
  node has a unit name, but no reg or ranges property'
  by adding reg to r5 node.
v5:
- update device tree sample and yaml parsing to not raise any warnings
- description for memory-region in yaml parsing
- compatible string in yaml parsing for TCM
v6:
- remove coupling TCM nodes with remoteproc 
- remove mailbox as it is optional not needed
v7:
- change lockstep-mode to xlnx,cluster-mode
v9:
- show example IPC nodes and tcm bank nodes
---
 .../xilinx,zynqmp-r5-remoteproc.yaml  | 113 ++
 1 file changed, 113 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
new file mode 100644
index ..f4a28831af6c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Xilinx R5 remote processor controller bindings
+
+description:
+  This document defines the binding for the remoteproc component that loads and
+  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
+
+  Note that the Linux has global addressing view of the R5-related memory (TCM)
+  so the absolute address ranges are provided in TCM reg's.
+maintainers:
+  - Ed Mooring 
+  - Ben Levinsky 
+
+properties:
+  compatible:
+const: "xlnx,zynqmp-r5-remoteproc-1.0"
+
+  lockstep-mode:
+description:
+  R5 core configuration (split is 0 or lock-step and 1)
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt mapping for remoteproc IPI. It is required if the
+  user uses the remoteproc driver with the RPMsg kernel driver.
+maxItems: 6
+
+  memory-region:
+description:
+  collection of memory carveouts used for elf-loading and inter-processor
+  communication.
+maxItems: 4
+minItems: 4
+  pnode-id:
+maxItems: 1
+  mboxes:
+maxItems: 2
+  mbox-names:
+maxItems: 2
+
+examples:
+  - |
+ reserved-memory {
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  elf_load: rproc@3ed00 {
+   no-map;
+   reg = <0x3ed0 0x4>;
+  };
+ };
+ rpu {
+  compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
+  #address-cells = <1>;
+  #size-cells = <1>;
+  ranges;
+  lockstep-mode = <0>;
+  r5_0 {
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   memory-region = <&elf_load>;
+   pnode-id = <0x7>;
+  };
+ };
+
+ /*
+  * Below nodes are required if using TCM to load R5 firmware
+  * if not, then either do not provide nodes are label as disabled in
+  * status property
+  */
+ tcm_0a@0 {
+ reg = <0x0 0xffe0 0x0 0x1>;
+ pnode-id = <0xf>;
+ no-map;
+ status = "okay";
+ };
+ tcm_1a@0 {
+ reg = <0x0 0xffe2 0x0 0x1>;
+ pnode-id = <0x10>;
+ no-map;
+ status = "okay";
+ };
+
+ /*
+  * Below nodes are required for IPC, as Xilinx Kernel
+  * can potentially have other applications that use CMA
+  * and conflict from hardware design. With that in mind,
+  * explicitly state the address spaces for the IPC remoteproc
+  * mechanisms.
+  *
+  * If IPC not required and only elf-loading then these are not needed.
+  */
+ rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
+ no-map;
+ reg = <0x0 0x3ed4 0x0 0x4000>;
+ };
+ rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
+ no-map;
+ reg = <0x0 0x3ed44000 0x0 0x4000>;
+ };
+ rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
+ no-map;
+ reg = <0x0 0x3ed48000 0x0 0x10>;
+ };
+
+...
-- 
2.17.1

Re: [PATCH] ext4: flag as supporting buffered async reads

[Jens Axboe]

On 8/25/20 8:18 AM, Jens Axboe wrote:
> On 8/24/20 4:56 AM, Jens Axboe wrote:
>> On 8/22/20 9:48 AM, Jens Axboe wrote:
>>> On 8/22/20 8:33 AM, Theodore Y. Ts'o wrote:
 On Fri, Aug 21, 2020 at 03:26:35PM -0600, Jens Axboe wrote:
 Resending this one, as I've been carrying it privately since May. The
 necessary bits are now upstream (and XFS/btrfs equiv changes as well),
 please consider this one for 5.9. Thanks!
>>>
>>> The necessary commit only hit upstream as of 5.9-rc1, unless I'm
>>> missing something?  It's on my queue to send to Linus once I get my
>>> (late) ext4 primary pull request for 5.9.
>>
>> Right, it went in at the start of the merge window for 5.9. Thanks Ted!
>
> Didn't see it in the queue that just sent in, is it still queued up?

 It wasn't in the queue which I queued up because that was based on
 5.8-rc4.  Linus was a bit grumpy (fairly so) because it was late, and
 that's totally on me.

 He has said that he's going to start ignoring pull requests that
 aren't fixes only if this becomes a pattern, so while I can send him
 another pull request which will just have that one change, there are
 no guarantees he's going to take it at this late date.

 Sorry, when you sent me the commit saying that the changes that were
 needed were already upstream on August 3rd, I thought that meant that
 they were aready in Linus's tree.  I should have checked and noticed
 that that in fact "ext4: flag as supporting buffered async reads"
 wasn't compiling against Linus's upstream tree, so I didn't realize
 this needed to be handled as a special case during the merge window.
>>>
>>> Well to be honest, this kind of sucks. I've been posting it since May,
>>> and the ideal approach would have been to just ack it and I could have
>>> carried it in my tree. That's what we did for btrfs and XFS, both of
>>> which have it.
>>>
>>> The required patches *were* upstreamed on August 3rd, which is why I
>>> mentioned that. But yes, not in 5.8 or earlier, of course.
>>>
>>> So I suggest that you either include it for the next pull request for
>>> Linus, or that I put it in with your ack. Either is fine with me. I'd
>>> consider this a "dropping the ball" kind of thing, it's not like the
>>> patch hasn't been in linux-next or hasn't been ready for months. This
>>> isn't some "oh I wrote this feature after the merge window" event. It'd
>>> be a real shame to ship 5.9 and ext4 not have support for the more
>>> efficient async buffered reads, imho, especially since the two other
>>> major local file systems already have it.
>>>
>>> Let me know what you think.
>>
>> Ted, can you make a call on this, please? It's now post -rc2. Let's
>> get this settled and included, one way or another.
> 
> Daily ping on this one...

And again. Ted, not sure how to make any progress with this, to be
honest, it's like pounding sand.

-- 
Jens Axboe

Re: [PATCH v2 1/2] Revert "drivers: qcom: rpmh-rsc: Use rcuidle tracepoints for rpmh"

[Bjorn Andersson]

On Tue 25 Aug 06:21 CDT 2020, Maulik Shah wrote:

> Commit efde2659b0fe ("drivers: qcom: rpmh-rsc: Use rcuidle tracepoints
> for rpmh") was written to fix a bug seen in an unmerged series that
> implemented a struct generic_pm_domain::power_off() callback calling
> rpmh_flush(). See stack trace below.
> 
>  Call trace:
>   dump_backtrace+0x0/0x174
>   show_stack+0x20/0x2c
>   dump_stack+0xc8/0x124
>   lockdep_rcu_suspicious+0xe4/0x104
>   __tcs_buffer_write+0x230/0x2d0
>   rpmh_rsc_write_ctrl_data+0x210/0x270
>   rpmh_flush+0x84/0x24c
>   rpmh_domain_power_off+0x78/0x98
>   _genpd_power_off+0x40/0xc0
>   genpd_power_off+0x168/0x208
> 
> Later the final merged solution is to use CPU PM notification to invoke
> rpmh_flush() and power_off() callback of genpd is not implemented in the
> driver.
> 
> CPU PM notifiers are run with RCU enabled/watching (see cpu_pm_notify()
> and how it calls rcu_irq_enter_irqson() before calling the notifiers).
> 
> Remove this change since RCU will not be idle during CPU PM notifications
> hence not required to use _rcuidle tracepoint. Using _rcuidle tracepoint
> prevented rpmh driver to be loadable module as these are not exported
> symbols.
> 
> This reverts commit efde2659b0fe835732047357b2902cca14f054d9.
> 
> Cc: Sai Prakash Ranjan 
> Cc: John Stultz 
> Cc: Stephen Rothwell 
> Reviewed-by: Stephen Boyd 
> Reviewed-by: Sai Prakash Ranjan 
> Reviewed-by: Ulf Hansson 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Maulik Shah 
> ---
>  drivers/soc/qcom/rpmh-rsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c
> index ae66757..fabe390d 100644
> --- a/drivers/soc/qcom/rpmh-rsc.c
> +++ b/drivers/soc/qcom/rpmh-rsc.c
> @@ -495,7 +495,7 @@ static void __tcs_buffer_write(struct rsc_drv *drv, int 
> tcs_id, int cmd_id,
>   write_tcs_cmd(drv, RSC_DRV_CMD_MSGID, tcs_id, j, msgid);
>   write_tcs_cmd(drv, RSC_DRV_CMD_ADDR, tcs_id, j, cmd->addr);
>   write_tcs_cmd(drv, RSC_DRV_CMD_DATA, tcs_id, j, cmd->data);
> - trace_rpmh_send_msg_rcuidle(drv, tcs_id, j, msgid, cmd);
> + trace_rpmh_send_msg(drv, tcs_id, j, msgid, cmd);
>   }
>  
>   write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, tcs_id, cmd_complete);
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH v2] HID: google: add google vivaldi HID driver

[Sean O'Brien]

> I actually believe we should follow the standard convention here, and have
> just one hid- driver for all google products. Currently we have
> hid-google-hammer, and this would add hid-google-vivaldi. Would you (or
> Wei-Ning, CCing here) object on merging these two together?

I'm a bit reluctant to merge them.  Partly because I'm not familiar with
the hid-google-hammer driver, but mostly because this driver is intended
to handle non-google products which will use a google-defined usage code.
Perhaps I should drop "google" from the driver name?

Thanks,
Sean O'Brien

[PATCH v2] arm64: dts: mt8173-elm: Set GPU power regulator to always on

[Anand K Mistry]

Keep the da9212 BUCKB always-on. This works around an issue on Elm/Hana
devices where sometimes, the regulator is disabled before scpsys is
suspended, causing the suspension of scpsys to fail.

Usually, the GPU and scpsys are suspended by the runtime PM before the
system is suspended, due to the GPU being idle. In this case, scpsys is
suspended inline with the GPU suspend, which then disables the
regulator. However, if the GPU is still active when system is suspended,
GPU suspend occurs but defers suspending scpsys to the PM's noirq phase.
Since GPU suspend disables the regulator, scpsys isn't powered and
suspending it fails with the following error:
[  523.773227] mtk-scpsys 10006000.scpsys: Failed to power off domain mfg_2d

On resume, scpsys is resumed in the noirq phase. Since scpsys requires
power from the regulator, which is still disabled at this point,
attempting to turn it on will hang the CPU. A HW watchdog eventually
reboots the system.

The obvious solution would be to add a link to the regulator from scpsys
in the devicetree. This would prevent the regulator from being disabled
until scpsys is suspended. However, in the case where suspending scpsys
is deferred to the noirq phase, disabling the regulator will fail since
it is connected over I2C which requires IRQs to be enabled. Even in the
usual case where scpsys is suspended inline with the GPU, PM will always
attempt to resume scpsys in noirq. This will attempt to enable the
regulator, which will also fail due to being unable to communicate over
I2C.

Since I2C can't be using with IRQs disabled, a workaround is to never
turn off the regulator.

Measuring power on the GPU rail on an Elm DVT device shows that the
change in power usage is negligible. The two relavent cases are S0 with
an idle GPU, and S3 (system suspended). Measurements taken using a debug
board every 100ms for 1 minute.

In S0 with an idle GPU, current behaviour with the regulator off:
@@   NAME  COUNT  AVERAGE  STDDEV  MAXMIN
@@ gpu_mw600 1.741.31 6.75   0.00
... and with the regulator on, but no load:
@@   NAME  COUNT  AVERAGE  STDDEV MAXMIN
@@ gpu_mw600 1.681.257.13   0.00
The difference being well within the margin of error.

In S3, current behaviour with the regulator off:
@@   NAME  COUNT  AVERAGE  STDDEV MAXMIN
@@ gpu_mw600 0.940.743.25   0.00
... and with the regulator on:
@@   NAME  COUNT  AVERAGE  STDDEV MAX MIN
@@ gpu_mw600 0.830.663.250.00

Signed-off-by: Anand K Mistry 

---

Changes in v2:
- Remove CHROMIUM from subject line
- Correct device in subject line (8183 -> 8173)
- Grammar/clarity changes in description

 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a5a12b2599a4..1294f27b21c1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -304,6 +304,7 @@ da9211_vgpu_reg: BUCKB {
regulator-min-microamp  = <200>;
regulator-max-microamp  = <300>;
regulator-ramp-delay = <1>;
+   regulator-always-on;
};
};
};
-- 
2.28.0.297.g1956fa8f8d-goog

[PATCH v2] Input: elants_i2c - Report resolution of ABS_MT_TOUCH_MAJOR by FW information.

[Johnny Chuang]

This patch adds a new behavior to report touch major resolution
based on information provided by firmware.

In initial process, driver acquires touch information from touch ic.
This information contains of one flag about reporting resolution of
ABS_MT_TOUCH_MAJOR is needed, or not.
Touch driver will report touch major resolution after geting this flag.

Signed-off-by: Johnny Chuang 
---
Changes in v2:
  - register real resolution instead of true/false.
---
 drivers/input/touchscreen/elants_i2c.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index b0bd5bb..dc7f4a5 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -151,6 +151,7 @@ struct elants_data {
 
bool wake_irq_enabled;
bool keep_power_in_suspend;
+   u8 report_major_resolution;
 
/* Must be last to be used for DMA operations */
u8 buf[MAX_PACKET_SIZE] cacheline_aligned;
@@ -459,6 +460,9 @@ static int elants_i2c_query_ts_info(struct elants_data *ts)
rows = resp[2] + resp[6] + resp[10];
cols = resp[3] + resp[7] + resp[11];
 
+   /* Decide if report resolution of ABS_MT_TOUCH_MAJOR */
+   ts->report_major_resolution = resp[16];
+
/* Process mm_to_pixel information */
error = elants_i2c_execute_command(client,
   get_osr_cmd, sizeof(get_osr_cmd),
@@ -1325,6 +1329,8 @@ static int elants_i2c_probe(struct i2c_client *client,
 0, MT_TOOL_PALM, 0, 0);
input_abs_set_res(ts->input, ABS_MT_POSITION_X, ts->x_res);
input_abs_set_res(ts->input, ABS_MT_POSITION_Y, ts->y_res);
+   if (ts->report_major_resolution > 0)
+   input_abs_set_res(ts->input, ABS_MT_TOUCH_MAJOR, 
ts->report_major_resolution);
 
touchscreen_parse_properties(ts->input, true, &ts->prop);
 
-- 
2.7.4

Re: [PATCH] ASoC: fsl_spdif: Fix unnecessary check infsl_spdif_probe()

[Tang Bin]

Hi Mark

在 2020/8/27 0:53, Mark Brown 写道:

On Wed, Aug 26, 2020 at 11:09:18PM +0800, Tang Bin wrote:

The function fsl_spdif_probe() is only called with an openfirmware
platform device. Therefore there is no need to check that the passed
in device is NULL.

Why is this an issue - the check will make things more robust if someone
manages to load the driver on a non-DT system and otherwise costs us a
couple of instructions?

Thanks for your reply.

In this function,  function fsl_spdif_probe() can be triggered only if 
the platform_device and platform_driver matches,


so I think the judgement at the beginning is redundant.

Thanks

Tang Bin

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

[Shakeel Butt]

On Fri, Aug 21, 2020 at 8:18 AM Roman Gushchin  wrote:
>
> Include map metadata and the node size (struct bpf_dtab_netdev) on
> element update into the accounting.
>
> Signed-off-by: Roman Gushchin 
> Acked-by: Song Liu 

Reviewed-by: Shakeel Butt 

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

[Allen]

On Wed, Aug 26, 2020 at 8:43 PM Kees Cook  wrote:
>
> On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
> > On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
> > > On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
> > >  wrote:
> > > >
> > > > On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
> > > > > > [...]
> > > > > > > > Since both threads seem to have petered out, let me suggest in
> > > > > > > > kernel.h:
> > > > > > > >
> > > > > > > > #define cast_out(ptr, container, member) \
> > > > > > > > container_of(ptr, typeof(*container), member)
> > > > > > > >
> > > > > > > > It does what you want, the argument order is the same as
> > > > > > > > container_of with the only difference being you name the
> > > > > > > > containing structure instead of having to specify its type.
> > > > > > >
> > > > > > > Not to incessantly bike shed on the naming, but I don't like
> > > > > > > cast_out, it's not very descriptive. And it has connotations of
> > > > > > > getting rid of something, which isn't really true.
> > > > > >
> > > > > > Um, I thought it was exactly descriptive: you're casting to the
> > > > > > outer container.  I thought about following the C++ dynamic casting
> > > > > > style, so out_cast(), but that seemed a bit pejorative.  What about
> > > > > > outer_cast()?
> > > > > >
> > > > > > > FWIW, I like the from_ part of the original naming, as it has
> > > > > > > some clues as to what is being done here. Why not just
> > > > > > > from_container()? That should immediately tell people what it
> > > > > > > does without having to look up the implementation, even before
> > > > > > > this becomes a part of the accepted coding norm.
> > > > > >
> > > > > > I'm not opposed to container_from() but it seems a little less
> > > > > > descriptive than outer_cast() but I don't really care.  I always
> > > > > > have to look up container_of() when I'm using it so this would just
> > > > > > be another macro of that type ...
> > > > > >
> > > > >
> > > > >  So far we have a few which have been suggested as replacement
> > > > > for from_tasklet()
> > > > >
> > > > > - out_cast() or outer_cast()
> > > > > - from_member().
> > > > > - container_from() or from_container()
> > > > >
> > > > > from_container() sounds fine, would trimming it a bit work? like
> > > > > from_cont().
> > > >
> > > > I'm fine with container_from().  It's the same form as container_of()
> > > > and I think we need urgent agreement to not stall everything else so
> > > > the most innocuous name is likely to get the widest acceptance.
> > >
> > > Kees,
> > >
> > >   Will you be  sending the newly proposed API to Linus? I have V2
> > > which uses container_from()
> > > ready to be sent out.
> >
> > I liked that James swapped the first two arguments so that it matches
> > container_of().  Plus it's nice that when you have:
> >
> >   struct whatever *foo = container_from(ptr, foo, member);
> >
> > Then it means that "ptr == &foo->member".
>
> I'm a bit stalled right now -- the merge window was keeping me busy, and
> this week is the Linux Plumbers Conference. This is on my list, but I
> haven't gotten back around to it. If you want, feel free to send the
> container_from() patch; you might be able to unblock this faster than me
> right now. :)
>

Sure, Thanks.



-- 
   - Allen

Re: Is: virtio_gpu_object_shmem_init issues? Was:Re: upstream boot error: general protection fault in swiotlb_map

[Thomas Tai]

Hello,
I had a similiar panic when booting an ARM VM with kernel v5.9-rc1. git 
bisect identified following bad commit. After reverting the bad commit, 
the VM boot ok. Maybe we should look into the following commit.


d323bb44e4d23802eb25d13de1f93f2335bd60d0 is the first bad commit
commit d323bb44e4d23802eb25d13de1f93f2335bd60d0
Author: Daniel Vetter 
Date:   Mon May 11 11:35:49 2020 +0200

drm/virtio: Call the right shmem helpers

drm_gem_shmem_get_sg_table is meant to implement
obj->funcs->get_sg_table, for prime exporting. The one we want is
drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
just native objects.

v2: Rebase, this stuff moved around in

commit 2f2aa13724d56829d910b2fa8e80c502d388f106
Author: Gerd Hoffmann 
Date:   Fri Feb 7 08:46:38 2020 +0100

drm/virtio: move virtio_gpu_mem_entry initialization to new 
function


Acked-by: Thomas Zimmermann 
Signed-off-by: Daniel Vetter 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
Link: 
https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-5-daniel.vet...@ffwll.ch


Thank you,
Thomas


On 2020-08-24 11:06 a.m., Konrad Rzeszutek Wilk wrote:

On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
kernel config:  https://syzkaller.appspot.com/x/.config?x=7c06047f622c5724
dashboard link: https://syzkaller.appspot.com/bug?extid=3f86afd0b1e4bf1cb64c
compiler:   gcc (GCC) 10.1.0-syz 20200507

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f86afd0b1e4bf1cb...@syzkaller.appspotmail.com

ceph: loaded (mds proto 32)
NET: Registered protocol family 38
async_tx: api initialized (async)
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Asymmetric key parser 'pkcs8' registered
Key type pkcs7_test registered
Asymmetric key parser 'tpm_parser' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)
io scheduler mq-deadline registered
io scheduler kyber registered
io scheduler bfq registered
hgafb: HGA card not detected.
hgafb: probe of hgafb.0 failed with error -22
usbcore: registered new interface driver udlfb
uvesafb: failed to execute /sbin/v86d
uvesafb: make sure that the v86d helper is installed and executable
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22
vga16fb: mapped to 0x8aac772d
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
ioatdma: Intel(R) QuickData Technology Driver 5.00
PCI Interrupt Link [GSIF] enabled at IRQ 21
PCI Interrupt Link [GSIG] enabled at IRQ 22
PCI Interrupt Link [GSIH] enabled at IRQ 23
N_HDLC line discipline registered with maxframe=4096
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
Cyclades driver 2.6
Initializing Nozomi driver 2.1d
RocketPort device driver module, version 2.09, 12-June-2003
No rocketport ports found; unloading driver
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
[drm] Initialized vgem 1.0.0 20120112 for vgem on minor 0
[drm] Initialized vkms 1.0.0 20180514 for vkms on minor 1
usbcore: registered new interface driver udl
[drm] pci: virtio-vga detected at :00:01.0
fb0: switching to virtiodrmfb from VGA16 VGA
Console: switching to colour VGA+ 80x25
virtio-pci :00:01.0: vgaarb: deactivate vga console
Console: switching to colour dummy device 80x25
[drm] features: -virgl +edid
[drm] number of scanouts: 1
[drm] number of cap sets: 0
[drm] Initialized virtio_gpu 0.1.0 0 for virtio0 on minor 2
general protection fault, probably for non-canonical address 
0xdc00:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:swiotlb_map+0x5ac/0x700 kernel/dma/swiotlb.c:683
Code: 28 04 00 00 48 c1 ea 03 80 3c 02 00 0f 85 4d 01 00 00 4c 8b a5 18 04 00 00 48 
b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 1e 01 00 00 
48 8d 7d 50 4d 8b 24 24 48 b8 00 00
RSP: :c934f3e0 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 8162cc1d
RDX:  RSI: 8162cc98 RDI: 88802971a470
RBP: 88802971a048 R08: 0001 R09: 8c5dba77
R10:  R11:  R12: 
R13: 7ac0 R14: d

[PATCH] linux/kernel.h: add container_from()

[Allen Pais]

Introduce container_from() as a generic helper instead of
sub-systems defining a private from_* API
(Eg: from_tasklets recently introduced in
12cc923f1ccc: Tasklet: Introduce new initialization API)

The helper is similar to container_of() in argument order
with the difference of naming the containing structure instead
of having to specify its type.

Suggested-by: James E.J. Bottomley 
Suggested-by: Greg Kroah-Hartman 
Suggested-by: Jens Axboe 
Signed-off-by: Allen Pais 
---
 include/linux/kernel.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 500def620d8f..9d446324a8be 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -1019,6 +1019,15 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
oops_dump_mode) { }
 "pointer type mismatch in container_of()");\
IS_ERR_OR_NULL(__mptr) ? ERR_CAST(__mptr) : \
((type *)(__mptr - offsetof(type, member))); })
+/**
+ * container_from - cast a member of a structure out to the containing 
structure
+ * @ptr:   the pointer to the member.
+ * @container: the type of the container struct.
+ * @member:the name of the member within the struct.
+ *
+ */
+#define container_from(ptr, container, member) \
+   container_of(ptr, typeof(*container), member)
 
 /* Rebuild everything on CONFIG_FTRACE_MCOUNT_RECORD */
 #ifdef CONFIG_FTRACE_MCOUNT_RECORD
-- 
2.25.1

Re: [PATCH] drm/vkms: fix warning in vkms_get_vblank_timestamp

[Sidong Yang]

On Wed, Aug 26, 2020 at 05:49:54PM -0300, Melissa Wen wrote:

Hi Melissa!
Thanks for review.

> Hi Sidong,
> 
> Thanks for this patch.
> 
> The code looks good to me; however, I see some issues in the patch
> format and commit message. Please, see inline comments.
> 
> On 08/25, Sidong Yang wrote:
> > From: Sidong Yang , Haneen Mohammed 
> > 
> 
> You need to fix the Author name.

Oops. 

> > 
> > When vkms_get_vblank_timestamp() is called very first time without
> > enabling vblank before, vblank time has just intial value and it makes
> > warning message. this patch prevents warning message by setting vblank
> > time to current time.
> 
> I consider *fix* a somewhat strong term to this change. In my opinion,
> it would be better to choose another term in the commit message like
> *avoid* timestamp warning when vblanks aren't enabled.

It's good to me. Next patch need to be more explicit.

> 
> In the body of the commit message, I think interesting to include the
> exactly warning message that this patch addresses. You could also
> describe the initial values that triggers this warning and why this
> approach is reasonable, as VKMS has fake clocks.

Yeah, It will be more comprehensive patch if there is description in detail.
I'll work for next patch!

Thanks.
-Sidong

> 
> > 
> > Cc: Daniel Vetter 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Cc: Melissa Wen 
> > 
> > Signed-off-by: Sidong Yang 
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..09c012d54d58 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc 
> > *crtc,
> > struct vkms_output *output = &vkmsdev->output;
> > struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> >  
> > +   if (!READ_ONCE(vblank->enabled)) {
> > +   *vblank_time = ktime_get();
> > +   return true;
> > +   }
> > +
> 
> Apart from issues in commit message and format, I checked the code and it
> works fine.
> 
> Reviewed-by: Melissa Wen 
> 
> > *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
> >  
> > if (WARN_ON(*vblank_time == vblank->time))
> > -- 
> > 2.17.1
> > 

Re: [PATCH v2 1/2] IB/qib: remove superfluous fallthrough statements

[Gustavo A. R. Silva]

On Wed, Aug 26, 2020 at 09:11:49PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 26, 2020 at 02:18:59PM -0500, Gustavo A. R. Silva wrote:
> > Hi,
> > 
> > On Tue, Aug 25, 2020 at 02:33:27PM -0500, Gustavo A. R. Silva wrote:
> > > On Tue, Aug 25, 2020 at 06:12:42PM +0100, Alex Dewar wrote:
> > > > Commit 36a8f01cd24b ("IB/qib: Add congestion control agent 
> > > > implementation")
> > > > erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
> > > > were later converted to fallthrough statements by commit df561f6688fe
> > > > ("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
> > > > warning about unreachable code.
> > > >
> > > 
> > > It's worth mentioning that this warning is triggered only by compilers
> > > that don't support __attribute__((__fallthrough__)), which has been
> > > supported since GCC 7.1.
> > > 
> > > > Remove the fallthrough statements.
> > > > 
> > > > Addresses-Coverity: ("Unreachable code")
> > > > Fixes: 36a8f01cd24b ("IB/qib: Add congestion control agent 
> > > > implementation")
> > > > Signed-off-by: Alex Dewar 
> > > 
> > > Reviewed-by: Gustavo A. R. Silva 
> > > 
> > 
> > I can take this in my tree for 5.9-rc3.
> 
> That would make conflicts for the 2nd patch, lets just send them all
> through the rdma tree please.

OK.

> Is there a reason this is -rc material?

It's just that this warning is currently in mainline.

Thanks
--
Gustavo

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

[Shakeel Butt]

On Fri, Aug 21, 2020 at 8:17 AM Roman Gushchin  wrote:
>
> Account memory used by cgroup storage maps including the percpu memory
> for the percpu flavor of cgroup storage and map metadata.
>
> Signed-off-by: Roman Gushchin 
> Acked-by: Song Liu 

Reviewed-by: Shakeel Butt 

Re: [PATCH v2 03/11] sched,idle,rcu: Push rcu_idle deeper into the idle path

[Joel Fernandes]

On Wed, Aug 26, 2020 at 09:18:26PM -0400, Joel Fernandes wrote:
> On Fri, Aug 21, 2020 at 10:47:41AM +0200, Peter Zijlstra wrote:
> > Lots of things take locks, due to a wee bug, rcu_lockdep didn't notice
> > that the locking tracepoints were using RCU.
> > 
> > Push rcu_idle_{enter,exit}() as deep as possible into the idle paths,
> > this also resolves a lot of _rcuidle()/RCU_NONIDLE() usage.
> > 
> > Specifically, sched_clock_idle_wakeup_event() will use ktime which
> > will use seqlocks which will tickle lockdep, and
> > stop_critical_timings() uses lock.
> 
> I was wondering if those tracepoints should just use _rcuidle variant of the
> trace call. But that's a terrible idea considering that would add unwanted
> overhead I think.
> 
> Reviewed-by: Joel Fernandes (Google) 

BTW, if tracepoint is converted to use RCU-trace flavor, then these kinds of
issues go away, no? That RCU flavor is always watching.

thanks,

 - Joel

> 
> thanks,
> 
>  - Joel
> 
> > 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > Reviewed-by: Steven Rostedt (VMware) 
> > Tested-by: Marco Elver 
> > ---
> >  drivers/cpuidle/cpuidle.c |   12 
> >  kernel/sched/idle.c   |   22 --
> >  2 files changed, 16 insertions(+), 18 deletions(-)
> > 
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -145,13 +145,14 @@ static void enter_s2idle_proper(struct c
> >  * executing it contains RCU usage regarded as invalid in the idle
> >  * context, so tell RCU about that.
> >  */
> > -   RCU_NONIDLE(tick_freeze());
> > +   tick_freeze();
> > /*
> >  * The state used here cannot be a "coupled" one, because the "coupled"
> >  * cpuidle mechanism enables interrupts and doing that with timekeeping
> >  * suspended is generally unsafe.
> >  */
> > stop_critical_timings();
> > +   rcu_idle_enter();
> > drv->states[index].enter_s2idle(dev, drv, index);
> > if (WARN_ON_ONCE(!irqs_disabled()))
> > local_irq_disable();
> > @@ -160,7 +161,8 @@ static void enter_s2idle_proper(struct c
> >  * first CPU executing it calls functions containing RCU read-side
> >  * critical sections, so tell RCU about that.
> >  */
> > -   RCU_NONIDLE(tick_unfreeze());
> > +   rcu_idle_exit();
> > +   tick_unfreeze();
> > start_critical_timings();
> >  
> > time_end = ns_to_ktime(local_clock());
> > @@ -229,16 +231,18 @@ int cpuidle_enter_state(struct cpuidle_d
> > /* Take note of the planned idle state. */
> > sched_idle_set_state(target_state);
> >  
> > -   trace_cpu_idle_rcuidle(index, dev->cpu);
> > +   trace_cpu_idle(index, dev->cpu);
> > time_start = ns_to_ktime(local_clock());
> >  
> > stop_critical_timings();
> > +   rcu_idle_enter();
> > entered_state = target_state->enter(dev, drv, index);
> > +   rcu_idle_exit();
> > start_critical_timings();
> >  
> > sched_clock_idle_wakeup_event();
> > time_end = ns_to_ktime(local_clock());
> > -   trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
> > +   trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
> >  
> > /* The cpu is no longer idle or about to enter idle. */
> > sched_idle_set_state(NULL);
> > --- a/kernel/sched/idle.c
> > +++ b/kernel/sched/idle.c
> > @@ -54,17 +54,18 @@ __setup("hlt", cpu_idle_nopoll_setup);
> >  
> >  static noinline int __cpuidle cpu_idle_poll(void)
> >  {
> > +   trace_cpu_idle(0, smp_processor_id());
> > +   stop_critical_timings();
> > rcu_idle_enter();
> > -   trace_cpu_idle_rcuidle(0, smp_processor_id());
> > local_irq_enable();
> > -   stop_critical_timings();
> >  
> > while (!tif_need_resched() &&
> > -   (cpu_idle_force_poll || tick_check_broadcast_expired()))
> > +  (cpu_idle_force_poll || tick_check_broadcast_expired()))
> > cpu_relax();
> > -   start_critical_timings();
> > -   trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
> > +
> > rcu_idle_exit();
> > +   start_critical_timings();
> > +   trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> >  
> > return 1;
> >  }
> > @@ -91,7 +92,9 @@ void __cpuidle default_idle_call(void)
> > local_irq_enable();
> > } else {
> > stop_critical_timings();
> > +   rcu_idle_enter();
> > arch_cpu_idle();
> > +   rcu_idle_exit();
> > start_critical_timings();
> > }
> >  }
> > @@ -158,7 +161,6 @@ static void cpuidle_idle_call(void)
> >  
> > if (cpuidle_not_available(drv, dev)) {
> > tick_nohz_idle_stop_tick();
> > -   rcu_idle_enter();
> >  
> > default_idle_call();
> > goto exit_idle;
> > @@ -178,21 +180,17 @@ static void cpuidle_idle_call(void)
> > u64 max_latency_ns;
> >  
> > if (idle_should_enter_s2idle()) {
> > -   rcu_idle_enter();
> >  
> > entered_state = call_cpuidle_s2idle(drv, dev);
> > if (entered_state > 0)
> > 

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

[Shakeel Butt]

On Fri, Aug 21, 2020 at 8:11 AM Roman Gushchin  wrote:
>
> Include metadata and percpu data into the memcg-based memory accounting.
>
> Signed-off-by: Roman Gushchin 
> Acked-by: Song Liu 

Reviewed-by: Shakeel Butt 

Re: [RFC PATCH 00/16] Core scheduling v6

[Vineeth Pillai]

Hi Alex,

>
> As discussed during Linux Plumbers, here is a small repo with test
> scripts and applications that I've used to look at core scheduling
> unfairness:
>
>https://github.com/agraf/schedgaps
>
Thanks for sharing :).

> Please let me know if it's unclear how to use it or if you see issues in
> your environment.
>
Will give it a try soon and let you know. Went through the
README quickly and documentation is very clear.

This is really helpful and would be really useful in future
testing as well.

Thanks,
Vineeth

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

[Shakeel Butt]

On Fri, Aug 21, 2020 at 8:11 AM Roman Gushchin  wrote:
>
> Include percpu arrays and auxiliary data into the memcg-based memory
> accounting.
>
> Signed-off-by: Roman Gushchin 
> Acked-by: Song Liu 
> ---
>  kernel/bpf/arraymap.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 8ff419b632a6..9597fecff8da 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -28,12 +28,12 @@ static void bpf_array_free_percpu(struct bpf_array *array)
>
>  static int bpf_array_alloc_percpu(struct bpf_array *array)
>  {
> +   const gfp_t gfp = GFP_USER | __GFP_NOWARN | __GFP_ACCOUNT;
> void __percpu *ptr;
> int i;
>
> for (i = 0; i < array->map.max_entries; i++) {
> -   ptr = __alloc_percpu_gfp(array->elem_size, 8,
> -GFP_USER | __GFP_NOWARN);
> +   ptr = __alloc_percpu_gfp(array->elem_size, 8, gfp);
> if (!ptr) {
> bpf_array_free_percpu(array);
> return -ENOMEM;
> @@ -969,7 +969,7 @@ static struct bpf_map *prog_array_map_alloc(union 
> bpf_attr *attr)
> struct bpf_array_aux *aux;
> struct bpf_map *map;
>
> -   aux = kzalloc(sizeof(*aux), GFP_KERNEL);
> +   aux = kzalloc(sizeof(*aux), GFP_KERNEL_ACCOUNT);
> if (!aux)
> return ERR_PTR(-ENOMEM);
>

There are a couple other allocations in the file. Can you please
comment why those are fine without __GFP_ACCOUNT flag. One seems to be
iterator allocation which should be temporary and fine without
__GFP_ACCOUNT but what about the ones in prog_array_map_poke_track()
and bpf_event_entry_gen()?

Re: [PATCH v2 03/11] sched,idle,rcu: Push rcu_idle deeper into the idle path

[Joel Fernandes]

On Fri, Aug 21, 2020 at 10:47:41AM +0200, Peter Zijlstra wrote:
> Lots of things take locks, due to a wee bug, rcu_lockdep didn't notice
> that the locking tracepoints were using RCU.
> 
> Push rcu_idle_{enter,exit}() as deep as possible into the idle paths,
> this also resolves a lot of _rcuidle()/RCU_NONIDLE() usage.
> 
> Specifically, sched_clock_idle_wakeup_event() will use ktime which
> will use seqlocks which will tickle lockdep, and
> stop_critical_timings() uses lock.

I was wondering if those tracepoints should just use _rcuidle variant of the
trace call. But that's a terrible idea considering that would add unwanted
overhead I think.

Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel

> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Reviewed-by: Steven Rostedt (VMware) 
> Tested-by: Marco Elver 
> ---
>  drivers/cpuidle/cpuidle.c |   12 
>  kernel/sched/idle.c   |   22 --
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -145,13 +145,14 @@ static void enter_s2idle_proper(struct c
>* executing it contains RCU usage regarded as invalid in the idle
>* context, so tell RCU about that.
>*/
> - RCU_NONIDLE(tick_freeze());
> + tick_freeze();
>   /*
>* The state used here cannot be a "coupled" one, because the "coupled"
>* cpuidle mechanism enables interrupts and doing that with timekeeping
>* suspended is generally unsafe.
>*/
>   stop_critical_timings();
> + rcu_idle_enter();
>   drv->states[index].enter_s2idle(dev, drv, index);
>   if (WARN_ON_ONCE(!irqs_disabled()))
>   local_irq_disable();
> @@ -160,7 +161,8 @@ static void enter_s2idle_proper(struct c
>* first CPU executing it calls functions containing RCU read-side
>* critical sections, so tell RCU about that.
>*/
> - RCU_NONIDLE(tick_unfreeze());
> + rcu_idle_exit();
> + tick_unfreeze();
>   start_critical_timings();
>  
>   time_end = ns_to_ktime(local_clock());
> @@ -229,16 +231,18 @@ int cpuidle_enter_state(struct cpuidle_d
>   /* Take note of the planned idle state. */
>   sched_idle_set_state(target_state);
>  
> - trace_cpu_idle_rcuidle(index, dev->cpu);
> + trace_cpu_idle(index, dev->cpu);
>   time_start = ns_to_ktime(local_clock());
>  
>   stop_critical_timings();
> + rcu_idle_enter();
>   entered_state = target_state->enter(dev, drv, index);
> + rcu_idle_exit();
>   start_critical_timings();
>  
>   sched_clock_idle_wakeup_event();
>   time_end = ns_to_ktime(local_clock());
> - trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
> + trace_cpu_idle(PWR_EVENT_EXIT, dev->cpu);
>  
>   /* The cpu is no longer idle or about to enter idle. */
>   sched_idle_set_state(NULL);
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -54,17 +54,18 @@ __setup("hlt", cpu_idle_nopoll_setup);
>  
>  static noinline int __cpuidle cpu_idle_poll(void)
>  {
> + trace_cpu_idle(0, smp_processor_id());
> + stop_critical_timings();
>   rcu_idle_enter();
> - trace_cpu_idle_rcuidle(0, smp_processor_id());
>   local_irq_enable();
> - stop_critical_timings();
>  
>   while (!tif_need_resched() &&
> - (cpu_idle_force_poll || tick_check_broadcast_expired()))
> +(cpu_idle_force_poll || tick_check_broadcast_expired()))
>   cpu_relax();
> - start_critical_timings();
> - trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
> +
>   rcu_idle_exit();
> + start_critical_timings();
> + trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
>  
>   return 1;
>  }
> @@ -91,7 +92,9 @@ void __cpuidle default_idle_call(void)
>   local_irq_enable();
>   } else {
>   stop_critical_timings();
> + rcu_idle_enter();
>   arch_cpu_idle();
> + rcu_idle_exit();
>   start_critical_timings();
>   }
>  }
> @@ -158,7 +161,6 @@ static void cpuidle_idle_call(void)
>  
>   if (cpuidle_not_available(drv, dev)) {
>   tick_nohz_idle_stop_tick();
> - rcu_idle_enter();
>  
>   default_idle_call();
>   goto exit_idle;
> @@ -178,21 +180,17 @@ static void cpuidle_idle_call(void)
>   u64 max_latency_ns;
>  
>   if (idle_should_enter_s2idle()) {
> - rcu_idle_enter();
>  
>   entered_state = call_cpuidle_s2idle(drv, dev);
>   if (entered_state > 0)
>   goto exit_idle;
>  
> - rcu_idle_exit();
> -
>   max_latency_ns = U64_MAX;
>   } else {
>   max_latency_ns = dev->forced_idle_latency_limit_ns;
>   }
>  
>   tick_nohz_idle_stop_tick();
> - rcu_idle_en

Re: [PATCH 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[啟原黃]

Guenter Roeck  於 2020年8月27日 週四 上午9:02寫道：
>
> On 8/26/20 5:59 PM, 啟原黃 wrote:
> [ ... ]
> >>> +static int mt6360_tcpc_remove(struct platform_device *pdev)
> >>> +{
> >>> + struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
> >>> +
> >>> + tcpci_unregister_port(mti->tcpci);
> >>
> >> That leaves interrupts enabled, which might be racy
> >> because interrupts are still enabled here.
> > M..., yes, it will cause the race condition during module remove.
> > I'll add disable_irq before tcpci unregister to prevent it.
>
> Or just set TCPC_ALERT_MASK to 0, as in tcpci.c.
Both are right, Thx. I'll choose one.

BTW, it seems enum typec_cc_status is used by tcpci.h.
If I don't include tcpm.h, it will raise a warning during the compile time.
>
> Guenter

Re: KASAN: use-after-free Write in afs_manage_cell

[syzbot]

syzbot has bisected this issue to:

commit c99c2171fc61476afac0dfb59fb2c447a01fb1e0
Author: David Howells 
Date:   Thu Nov 1 23:07:27 2018 +

afs: Use fs_context to pass parameters over automount

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=10679fa990
start commit:   abb3438d Merge tag 'm68knommu-for-v5.9-rc3' of git://git.k..
git tree:   upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=12679fa990
console output: https://syzkaller.appspot.com/x/log.txt?x=14679fa990
kernel config:  https://syzkaller.appspot.com/x/.config?x=891ca5711a9f1650
dashboard link: https://syzkaller.appspot.com/bug?extid=f59c67285cb61166a0cf
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10d97d4690
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14eb9fa990

Reported-by: syzbot+f59c67285cb61166a...@syzkaller.appspotmail.com
Fixes: c99c2171fc61 ("afs: Use fs_context to pass parameters over automount")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [PATCH v2 02/11] cpuidle: Fixup IRQ state

[Joel Fernandes]

On Fri, Aug 21, 2020 at 07:36:43PM +0200, Rafael J. Wysocki wrote:
> On Friday, August 21, 2020 10:47:40 AM CEST Peter Zijlstra wrote:
> > Match the pattern elsewhere in this file.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > Reviewed-by: Steven Rostedt (VMware) 
> > Tested-by: Marco Elver 
> 
> For all patches in the series:
> 
> Acked-by: Rafael J. Wysocki 

Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel

> 
> > ---
> >  drivers/cpuidle/cpuidle.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -153,7 +153,8 @@ static void enter_s2idle_proper(struct c
> >  */
> > stop_critical_timings();
> > drv->states[index].enter_s2idle(dev, drv, index);
> > -   WARN_ON(!irqs_disabled());
> > +   if (WARN_ON_ONCE(!irqs_disabled()))
> > +   local_irq_disable();
> > /*
> >  * timekeeping_resume() that will be called by tick_unfreeze() for the
> >  * first CPU executing it calls functions containing RCU read-side
> > 
> > 
> > 
> 
> 
> 
> 

Re: [PATCH v2 01/11] lockdep: Use raw_cpu_*() for per-cpu variables

[Joel Fernandes]

On Fri, Aug 21, 2020 at 10:47:39AM +0200, Peter Zijlstra wrote:
> Sven reported that commit a21ee6055c30 ("lockdep: Change
> hardirq{s_enabled,_context} to per-cpu variables") caused trouble on
> s390 because their this_cpu_*() primitives disable preemption which
> then lands back tracing.
> 
> On the one hand, per-cpu ops should use preempt_*able_notrace() and
> raw_local_irq_*(), on the other hand, we can trivialy use raw_cpu_*()
> ops for this.
> 
> Fixes: a21ee6055c30 ("lockdep: Change hardirq{s_enabled,_context} to per-cpu 
> variables")
> Reported-by: Sven Schnelle 
> Reviewed-by: Steven Rostedt (VMware) 
> Tested-by: Marco Elver 

Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel

> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  include/linux/irqflags.h |6 +++---
>  include/linux/lockdep.h  |   18 +-
>  kernel/locking/lockdep.c |4 ++--
>  3 files changed, 18 insertions(+), 10 deletions(-)
> 
> --- a/include/linux/irqflags.h
> +++ b/include/linux/irqflags.h
> @@ -53,13 +53,13 @@ DECLARE_PER_CPU(int, hardirq_context);
>extern void trace_hardirqs_off_finish(void);
>extern void trace_hardirqs_on(void);
>extern void trace_hardirqs_off(void);
> -# define lockdep_hardirq_context()   (this_cpu_read(hardirq_context))
> +# define lockdep_hardirq_context()   (raw_cpu_read(hardirq_context))
>  # define lockdep_softirq_context(p)  ((p)->softirq_context)
>  # define lockdep_hardirqs_enabled()  (this_cpu_read(hardirqs_enabled))
>  # define lockdep_softirqs_enabled(p) ((p)->softirqs_enabled)
>  # define lockdep_hardirq_enter() \
>  do { \
> - if (this_cpu_inc_return(hardirq_context) == 1)  \
> + if (__this_cpu_inc_return(hardirq_context) == 1)\
>   current->hardirq_threaded = 0;  \
>  } while (0)
>  # define lockdep_hardirq_threaded()  \
> @@ -68,7 +68,7 @@ do {\
>  } while (0)
>  # define lockdep_hardirq_exit()  \
>  do { \
> - this_cpu_dec(hardirq_context);  \
> + __this_cpu_dec(hardirq_context);\
>  } while (0)
>  # define lockdep_softirq_enter() \
>  do { \
> --- a/include/linux/lockdep.h
> +++ b/include/linux/lockdep.h
> @@ -535,19 +535,27 @@ do {
> \
>  DECLARE_PER_CPU(int, hardirqs_enabled);
>  DECLARE_PER_CPU(int, hardirq_context);
>  
> +/*
> + * The below lockdep_assert_*() macros use raw_cpu_read() to access the above
> + * per-cpu variables. This is required because this_cpu_read() will 
> potentially
> + * call into preempt/irq-disable and that obviously isn't right. This is also
> + * correct because when IRQs are enabled, it doesn't matter if we 
> accidentally
> + * read the value from our previous CPU.
> + */
> +
>  #define lockdep_assert_irqs_enabled()
> \
>  do { \
> - WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirqs_enabled));  \
> + WARN_ON_ONCE(debug_locks && !raw_cpu_read(hardirqs_enabled));   \
>  } while (0)
>  
>  #define lockdep_assert_irqs_disabled()   
> \
>  do { \
> - WARN_ON_ONCE(debug_locks && this_cpu_read(hardirqs_enabled));   \
> + WARN_ON_ONCE(debug_locks && raw_cpu_read(hardirqs_enabled));\
>  } while (0)
>  
>  #define lockdep_assert_in_irq()  
> \
>  do { \
> - WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirq_context));   \
> + WARN_ON_ONCE(debug_locks && !raw_cpu_read(hardirq_context));\
>  } while (0)
>  
>  #define lockdep_assert_preemption_enabled()  \
> @@ -555,7 +563,7 @@ do {  
> \
>   WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
>debug_locks&&  \
>(preempt_count() != 0  ||  \
> -   !this_cpu_read(hardirqs_enabled)));   \
> +   !raw_cpu_read(hardirqs_enabled)));\
>  } while (0)
>  
>  #define lockdep_assert_preemption_disabled() \
> @@ -563,7 +571,7 @@ do {  
> \
>   WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
>debug_locks&&  \
>(preempt_count() == 0  &&  \
> -   this_cpu_read(hardirqs_enabled)));\
> + 

Re: [PATCH 1/2] veth: Initialize dev->perm_addr

[Mira Ressel]

On Wed, Aug 26, 2020 at 09:33:29AM -0700, David Miller wrote:
> From: Mira Ressel 
> Date: Wed, 26 Aug 2020 16:29:01 +
> 
> > On Wed, Aug 26, 2020 at 08:28:57AM -0700, David Miller wrote:
> >> From: Mira Ressel 
> >> Date: Wed, 26 Aug 2020 15:20:00 +
> >> 
> >> > I'm setting the peer->perm_addr, which would otherwise be zero, to its
> >> > dev_addr, which has been either generated randomly by the kernel or
> >> > provided by userland in a netlink attribute.
> >> 
> >> Which by definition makes it not necessarily a "permanent address" and
> >> therefore is subject to being different across boots, which is exactly
> >> what you don't want to happen for automatic address generation.
> > 
> > That's true, but since veth devices aren't backed by any hardware, I
> > unfortunately don't have a good source for a permanent address. The only
> > inherently permanent thing about them is their name.
> > 
> > People who use the default eui64-based address generation don't get
> > persistent link-local addresses for their veth devices out of the box
> > either -- the EUI64 is derived from the device's dev_addr, which is
> > randomized by default.
> > 
> > If that presents a problem for anyone, they can configure their userland
> > to set the dev_addr to a static value, which handily fixes this problem
> > for both address generation algorithms.
> > 
> > I'm admittedly glancing over one problem here -- I'm only setting the
> > perm_addr during device creation, whereas userland can change the
> > dev_addr at any time. I'm not sure if it'd make sense here to update the
> > perm_addr if the dev_addr is changed later on?
> 
> We are talking about which parent device address to inherit from, you
> have choosen to use dev_addr and I am saying you should use perm_addr.
> 
> Can you explain why this isn't clear?

Which parent device? This is the veth patch, not the vlan patch. I'm
setting the perm_addrs of both sides of the veth pair to their
respective dev_addrs that they were assigned by userland or through
random generation. If I were to give both of them the same perm_addr,
we'd again have the problem that they'd get conflicting link-local
addresses and trigger DAD.

My apologies if I'm misunderstanding something here!

Regards,
Mira

Re: [PATCH 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[Guenter Roeck]

On 8/26/20 5:59 PM, 啟原黃 wrote:
[ ... ]
>>> +static int mt6360_tcpc_remove(struct platform_device *pdev)
>>> +{
>>> + struct mt6360_tcpc_info *mti = platform_get_drvdata(pdev);
>>> +
>>> + tcpci_unregister_port(mti->tcpci);
>>
>> That leaves interrupts enabled, which might be racy
>> because interrupts are still enabled here.
> M..., yes, it will cause the race condition during module remove.
> I'll add disable_irq before tcpci unregister to prevent it.

Or just set TCPC_ALERT_MASK to 0, as in tcpci.c.

Guenter

Re: [PATCH 1/2] usb typec: mt6360: Add support for mt6360 Type-C driver

[啟原黃]

Guenter Roeck  於 2020年8月27日 週四 上午4:44寫道：
>
> On 8/26/20 4:16 AM, cy_huang wrote:
> > From: ChiYuan Huang 
> >
> > Mediatek MT6360 is a multi-functional IC that includes USB Type-C.
> > It works with Type-C Port Controller Manager to provide USB PD
> > and USB Type-C functionalities.
> >
> > Signed-off-by: ChiYuan Huang 
> > ---
> >  drivers/usb/typec/tcpm/Kconfig|   8 ++
> >  drivers/usb/typec/tcpm/Makefile   |   1 +
> >  drivers/usb/typec/tcpm/tcpci_mt6360.c | 212 
> > ++
> >  3 files changed, 221 insertions(+)
> >  create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6360.c
> >
> > diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
> > index fa3f393..58a64e1 100644
> > --- a/drivers/usb/typec/tcpm/Kconfig
> > +++ b/drivers/usb/typec/tcpm/Kconfig
> > @@ -27,6 +27,14 @@ config TYPEC_RT1711H
> > Type-C Port Controller Manager to provide USB PD and USB
> > Type-C functionalities.
> >
> > +config TYPEC_MT6360
> > + tristate "Mediatek MT6360 Type-C driver"
> > + depends on MFD_MT6360
> > + help
> > +   Mediatek MT6360 is a multi-functional IC that includes
> > +   USB Type-C. It works with Type-C Port Controller Manager
> > +   to provide USB PD and USB Type-C functionalities.
> > +
> >  endif # TYPEC_TCPCI
> >
> >  config TYPEC_FUSB302
> > diff --git a/drivers/usb/typec/tcpm/Makefile 
> > b/drivers/usb/typec/tcpm/Makefile
> > index a5ff6c8..7592ccb 100644
> > --- a/drivers/usb/typec/tcpm/Makefile
> > +++ b/drivers/usb/typec/tcpm/Makefile
> > @@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
> >  typec_wcove-y:= wcove.o
> >  obj-$(CONFIG_TYPEC_TCPCI)+= tcpci.o
> >  obj-$(CONFIG_TYPEC_RT1711H)  += tcpci_rt1711h.o
> > +obj-$(CONFIG_TYPEC_MT6360)   += tcpci_mt6360.o
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c 
> > b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > new file mode 100644
> > index ..6a28193
> > --- /dev/null
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -0,0 +1,212 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +//
> > +// Copyright (C) 2020 MediaTek Inc.
> > +//
> > +// Author: ChiYuan Huang 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Is that needed ?
Ah, sorry, for some testing, I forget to remove it.
>
> > +
> > +#include "tcpci.h"
> > +
> > +#define MT6360_REG_VCONNCTRL10x8C
> > +#define MT6360_REG_MODECTRL2 0x8F
> > +#define MT6360_REG_SWRESET   0xA0
> > +#define MT6360_REG_DEBCTRL1  0xA1
> > +#define MT6360_REG_DRPCTRL1  0xA2
> > +#define MT6360_REG_DRPCTRL2  0xA3
> > +#define MT6360_REG_I2CTORST  0xBF
> > +#define MT6360_REG_RXCTRL2   0xCF
> > +#define MT6360_REG_CTDCTRL2  0xEC
> > +
> > +/* MT6360_REG_VCONNCTRL1 */
> > +#define MT6360_VCONNCL_ENABLEBIT(0)
> > +/* MT6360_REG_RXCTRL2 */
> > +#define MT6360_OPEN40M_ENABLEBIT(7)
> > +/* MT6360_REG_CTDCTRL2 */
> > +#define MT6360_RPONESHOT_ENABLE  BIT(6)
> > +
> > +struct mt6360_tcpc_info {
> > + struct tcpci_data tdata;
> > + struct tcpci *tcpci;
> > + struct device *dev;
> > + int irq;
> > +};
> > +
> > +static inline int mt6360_tcpc_read16(struct regmap *regmap,
> > +  unsigned int reg, u16 *val)
> > +{
> > + return regmap_raw_read(regmap, reg, val, sizeof(u16));
> > +}
> > +
> > +static inline int mt6360_tcpc_write16(struct regmap *regmap,
> > +   unsigned int reg, u16 val)
> > +{
> > + return regmap_raw_write(regmap, reg, &val, sizeof(u16));
> > +}
> > +
> > +static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
> > +{
> > + struct regmap *regmap = tdata->regmap;
> > + int ret;
> > +
> > + ret = regmap_write(regmap, MT6360_REG_SWRESET, 0x01);
> > + if (ret)
> > + return ret;
> > +
> > + /* after reset command, wait 1~2ms to wait IC action */
> > + usleep_range(1000, 2000);
> > +
> > + /* write all alert to masked */
> > + ret = mt6360_tcpc_write16(regmap, TCPC_ALERT_MASK, 0);
> > + if (ret)
> > + return ret;
> > +
> > + /* config I2C timeout reset enable , and timeout to 200ms */
> > + ret = regmap_write(regmap, MT6360_REG_I2CTORST, 0x8F);
> > + if (ret)
> > + return ret;
> > +
> > + /* config CC Detect Debounce : 26.7*val us */
> > + ret = regmap_write(regmap, MT6360_REG_DEBCTRL1, 0x10);
> > + if (ret)
> > + return ret;
> > +
> > + /* DRP Toggle Cycle : 51.2 + 6.4*val ms */
> > + ret = regmap_write(regmap, MT6360_REG_DRPCTRL1, 4);
> > + if (ret)
> > + return ret;
> > +
> > + /* DRP Duyt Ctrl : dcSRC: /1024 */
> > + ret = mt6360_tcpc_write16(regmap, MT6360_REG_DRPCTRL2, 330);
> > + if (ret)
> > + return ret;
> > +
> > + /* Enable VCONN Current Limit function */
> > + ret = regmap_update_bits(regmap, MT63

Re: [PATCH v2] staging: qlge: fix build breakage with dumping enabled

[Benjamin Poirier]

On 2020-08-27 07:27 +0800, Coiby Xu wrote:
> This fixes commit 0107635e15ac
> ("staging: qlge: replace pr_err with netdev_err") which introduced an
> build breakage of missing `struct ql_adapter *qdev` for some functions
> and a warning of type mismatch with dumping enabled, i.e.,
> 
> $ make CFLAGS_MODULE="QL_ALL_DUMP=1 QL_OB_DUMP=1 QL_CB_DUMP=1 \
>   QL_IB_DUMP=1 QL_REG_DUMP=1 QL_DEV_DUMP=1" M=drivers/staging/qlge
> 
> qlge_dbg.c: In function ‘ql_dump_ob_mac_rsp’:
> qlge_dbg.c:2051:13: error: ‘qdev’ undeclared (first use in this function); 
> did you mean ‘cdev’?
>  2051 |  netdev_err(qdev->ndev, "%s\n", __func__);
>   | ^~~~
> qlge_dbg.c: In function ‘ql_dump_routing_entries’:
> qlge_dbg.c:1435:10: warning: format ‘%s’ expects argument of type ‘char *’, 
> but argument 3 has type ‘int’ [-Wformat=]
>  1435 |"%s: Routing Mask %d = 0x%.08x\n",
>   | ~^
>   |  |
>   |  char *
>   | %d
>  1436 |i, value);
>   |~
>   ||
>   |int
> qlge_dbg.c:1435:37: warning: format ‘%x’ expects a matching ‘unsigned int’ 
> argument [-Wformat=]
>  1435 |"%s: Routing Mask %d = 0x%.08x\n",
>   | ^
>   | |
>   | unsigned int
> 
> Fixes: 0107635e15ac ("staging: qlge: replace pr_err with netdev_err")
> Reported-by: Benjamin Poirier 
> Suggested-by: Benjamin Poirier 
> Signed-off-by: Coiby Xu 
> ---
>  drivers/staging/qlge/qlge.h  | 20 ++--
>  drivers/staging/qlge/qlge_dbg.c  | 24 ++--
>  drivers/staging/qlge/qlge_main.c |  8 
>  3 files changed, 32 insertions(+), 20 deletions(-)
> 
[...]
> @@ -1632,6 +1635,8 @@ void ql_dump_wqicb(struct wqicb *wqicb)
> 
>  void ql_dump_tx_ring(struct tx_ring *tx_ring)
>  {
> + struct ql_adapter *qdev = tx_ring->qdev;
> +
>   if (!tx_ring)
>   return;

Given the null check for tx_ring, it seems unwise to dereference tx_ring
before the check.

Looking at ql_dump_all(), I'm not sure that the check is needed at all
though. Maybe it should be removed.

Same problem in ql_dump_rx_ring().

>   netdev_err(qdev->ndev, "= Dumping tx_ring %d 
> ===\n",
> @@ -1657,6 +1662,8 @@ void ql_dump_tx_ring(struct tx_ring *tx_ring)
>  void ql_dump_ricb(struct ricb *ricb)
>  {
>   int i;
> + struct ql_adapter *qdev =
> + container_of(ricb, struct ql_adapter, ricb);

Here, davem would point out that the variables are not declared in
"reverse xmas tree" order.

[PATCH 1/3] sched: Allow hrticks to work with core scheduling

[Alexander Graf]

The core scheduling logic bypasses the scheduling class's
pick_next_task() which starts the hrtick logic usually. Instead,
it explicitly calls set_next_task() or leaves the current task
running without any callback into the CFS scheduler.

To ensure that we still configure the hrtick timer properly when we
know which task we want to run, let's add an explicit callback to
the scheduler class which can then be triggered from the core's
pick_next_task().

With this patch, core scheduling with HRTICK enabled does see
improved responsiveness on scheduling decisions.

Signed-off-by: Alexander Graf 
---
 kernel/sched/core.c  | 13 +
 kernel/sched/fair.c  |  9 +
 kernel/sched/sched.h |  4 
 3 files changed, 26 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 0362102fa3d2..72bf837422bf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4486,6 +4486,12 @@ pick_next_task(struct rq *rq, struct task_struct *prev, 
struct rq_flags *rf)
set_next_task(rq, next);
}
 
+#ifdef CONFIG_SCHED_HRTICK
+   /* Trigger next hrtick after task selection */
+   if (next->sched_class->hrtick_update)
+   next->sched_class->hrtick_update(rq);
+#endif
+
trace_printk("pick pre selected (%u %u %u): %s/%d %lx\n",
 rq->core->core_task_seq,
 rq->core->core_pick_seq,
@@ -4667,6 +4673,13 @@ next_class:;
 
 done:
set_next_task(rq, next);
+
+#ifdef CONFIG_SCHED_HRTICK
+   /* Trigger next hrtick after task selection */
+   if (next->sched_class->hrtick_update)
+   next->sched_class->hrtick_update(rq);
+#endif
+
return next;
 }
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 435b460d3c3f..0d4ff3ab2572 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5512,6 +5512,11 @@ static inline void hrtick_update(struct rq *rq)
 }
 #endif
 
+static void hrtick_update_fair(struct rq *rq)
+{
+   hrtick_update(rq);
+}
+
 #ifdef CONFIG_SMP
 static inline unsigned long cpu_util(int cpu);
 
@@ -11391,6 +11396,10 @@ const struct sched_class fair_sched_class = {
 #ifdef CONFIG_UCLAMP_TASK
.uclamp_enabled = 1,
 #endif
+
+#ifdef CONFIG_SCHED_HRTICK
+   .hrtick_update  = hrtick_update_fair,
+#endif
 };
 
 #ifdef CONFIG_SCHED_DEBUG
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 6445943d3215..b382e0ee0c87 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1942,6 +1942,10 @@ struct sched_class {
 #ifdef CONFIG_FAIR_GROUP_SCHED
void (*task_change_group)(struct task_struct *p, int type);
 #endif
+
+#ifdef CONFIG_SCHED_HRTICK
+   void (*hrtick_update)(struct rq *rq);
+#endif
 };
 
 static inline void put_prev_task(struct rq *rq, struct task_struct *prev)
-- 
2.26.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

[PATCH 2/3] sched: Trigger new hrtick if timer expires too fast

[Alexander Graf]

When an hrtick timer event occurs too quickly, we just bail out and don't
attempt to set a new hrtick timeout. That means that the time slice for
that particular task grows until the next HZ tick occurs. That again may
create significant jitter for the respective task, as it will not get
scheduled for as long as it executed before, to bring the overall queue's
vruntime into balance again.

With this patch, even a too early hrtick timer event will just reconfigure
the hrtick to when we expected it to fire, removing overall jitter from
the system.

Signed-off-by: Alexander Graf 
---
 kernel/sched/fair.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0d4ff3ab2572..66e7aae8b15e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -99,6 +99,8 @@ static int __init setup_sched_thermal_decay_shift(char *str)
 }
 __setup("sched_thermal_decay_shift=", setup_sched_thermal_decay_shift);
 
+static void hrtick_update(struct rq *rq);
+
 #ifdef CONFIG_SMP
 /*
  * For asym packing, by default the lower numbered CPU has higher priority.
@@ -4458,8 +4460,10 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct 
sched_entity *curr)
 * narrow margin doesn't have to wait for a full slice.
 * This also mitigates buddy induced latencies under load.
 */
-   if (delta_exec < sysctl_sched_min_granularity)
+   if (delta_exec < sysctl_sched_min_granularity) {
+   hrtick_update(rq_of(cfs_rq));
return;
+   }
 
se = __pick_first_entity(cfs_rq);
delta = curr->vruntime - se->vruntime;
-- 
2.26.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

[PATCH 3/3] sched: Use hrticks even with >sched_nr_latency tasks

[Alexander Graf]

When hrticks are enabled, we configure an hrtimer fire at the exact point
in time when we would like to have a rescheduling event occur.

However, the current code disables that logic when the number of currently
running tasks exceeds sched_nr_latency. sched_nr_latency describes the point
at which CFS resorts to giving each task sched_min_granularity slices.

However, these slices may well be smaller than the HZ tick and we thus may
still want to use hrticks to ensure that we can actually slice the CPU time
at sched_min_granularity.

This patch changes the logic to still enable hrticks if sched_min_granularity
is smaller than the HZ tick would allow us to account with. That way systems
with HZ=1000 will usually resort to the HZ tick while systems at lower HZ values
will keep using hrticks.

Signed-off-by: Alexander Graf 
---
 kernel/sched/fair.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 66e7aae8b15e..0092bba52edf 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5502,7 +5502,8 @@ static void hrtick_update(struct rq *rq)
if (!hrtick_enabled(rq) || curr->sched_class != &fair_sched_class)
return;
 
-   if (cfs_rq_of(&curr->se)->nr_running < sched_nr_latency)
+   if ((cfs_rq_of(&curr->se)->nr_running < sched_nr_latency) ||
+   (sysctl_sched_min_granularity < (HZ * 100)))
hrtick_start_fair(rq, curr);
 }
 #else /* !CONFIG_SCHED_HRTICK */
-- 
2.26.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

[PATCH 0/3] Add HRTICK support to Core Scheduling

[Alexander Graf]

CFS supports a feature called "HRTICK" which allows scheduling
decisions to be made independent of the HZ tick. That means that
we can achieve much more fine grained time slices and thus be
more fair in distributing time to different workloads.

Unfortunately, HRTICK currently does not work with the Core
Scheduling patch set. This patch set adds support for it.
Feel free to squash bits in where it makes sense.


Alex

Alexander Graf (3):
  sched: Allow hrticks to work with core scheduling
  sched: Trigger new hrtick if timer expires too fast
  sched: Use hrticks even with >sched_nr_latency tasks

 kernel/sched/core.c  | 13 +
 kernel/sched/fair.c  | 18 --
 kernel/sched/sched.h |  4 
 3 files changed, 33 insertions(+), 2 deletions(-)

-- 
2.26.2




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

Hi all,

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

  drivers/net/ethernet/ibm/ibmvnic.c

between commit:

  9f1345737790 ("ibmvnic fix NULL tx_pools and rx_tools issue at do_reset")

from the net tree and commit:

  507ebe6444a4 ("ibmvnic: Fix use-after-free of VNIC login response buffer")

from the net-next tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/ibm/ibmvnic.c
index d3a774331afc,86a83e53dce5..
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@@ -475,17 -467,12 +467,15 @@@ static int init_stats_token(struct ibmv
  static int reset_rx_pools(struct ibmvnic_adapter *adapter)
  {
struct ibmvnic_rx_pool *rx_pool;
+   u64 buff_size;
int rx_scrqs;
int i, j, rc;
-   u64 *size_array;
  
 +  if (!adapter->rx_pool)
 +  return -1;
 +
-   size_array = (u64 *)((u8 *)(adapter->login_rsp_buf) +
-   be32_to_cpu(adapter->login_rsp_buf->off_rxadd_buff_size));
- 
-   rx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_rxadd_subcrqs);
+   buff_size = adapter->cur_rx_buf_sz;
+   rx_scrqs = adapter->num_active_rx_pools;
for (i = 0; i < rx_scrqs; i++) {
rx_pool = &adapter->rx_pool[i];
  
@@@ -652,10 -637,7 +640,10 @@@ static int reset_tx_pools(struct ibmvni
int tx_scrqs;
int i, rc;
  
 +  if (!adapter->tx_pool)
 +  return -1;
 +
-   tx_scrqs = be32_to_cpu(adapter->login_rsp_buf->num_txsubm_subcrqs);
+   tx_scrqs = adapter->num_active_tx_pools;
for (i = 0; i < tx_scrqs; i++) {
rc = reset_one_tx_pool(adapter, &adapter->tso_pool[i]);
if (rc)


pgpOn07Hll0jN.pgp
Description: OpenPGP digital signature

Re: [RFC PATCH 00/16] Core scheduling v6

[Alexander Graf]

Hi Vineeth,

On 30.06.20 23:32, Vineeth Remanan Pillai wrote:

Sixth iteration of the Core-Scheduling feature.

Core scheduling is a feature that allows only trusted tasks to run
concurrently on cpus sharing compute resources (eg: hyperthreads on a
core). The goal is to mitigate the core-level side-channel attacks
without requiring to disable SMT (which has a significant impact on
performance in some situations). Core scheduling (as of v6) mitigates
user-space to user-space attacks and user to kernel attack when one of
the siblings enters the kernel via interrupts. It is still possible to
have a task attack the sibling thread when it enters the kernel via
syscalls.

By default, the feature doesn't change any of the current scheduler
behavior. The user decides which tasks can run simultaneously on the
same core (for now by having them in the same tagged cgroup). When a
tag is enabled in a cgroup and a task from that cgroup is running on a
hardware thread, the scheduler ensures that only idle or trusted tasks
run on the other sibling(s). Besides security concerns, this feature
can also be beneficial for RT and performance applications where we
want to control how tasks make use of SMT dynamically.

This iteration is mostly a cleanup of v5 except for a major feature of
pausing sibling when a cpu enters kernel via nmi/irq/softirq. Also
introducing documentation and includes minor crash fixes.

One major cleanup was removing the hotplug support and related code.
The hotplug related crashes were not documented and the fixes piled up
over time leading to complex code. We were not able to reproduce the
crashes in the limited testing done. But if they are reroducable, we
don't want to hide them. We should document them and design better
fixes if any.

In terms of performance, the results in this release are similar to
v5. On a x86 system with N hardware threads:
- if only N/2 hardware threads are busy, the performance is similar
   between baseline, corescheduling and nosmt
- if N hardware threads are busy with N different corescheduling
   groups, the impact of corescheduling is similar to nosmt
- if N hardware threads are busy and multiple active threads share the
   same corescheduling cookie, they gain a performance improvement over
   nosmt.
   The specific performance impact depends on the workload, but for a
   really busy database 12-vcpu VM (1 coresched tag) running on a 36
   hardware threads NUMA node with 96 mostly idle neighbor VMs (each in
   their own coresched tag), the performance drops by 54% with
   corescheduling and drops by 90% with nosmt.

v6 is rebased on 5.7.6(a06eb423367e)
https://github.com/digitalocean/linux-coresched/tree/coresched/v6-v5.7.y


As discussed during Linux Plumbers, here is a small repo with test 
scripts and applications that I've used to look at core scheduling 
unfairness:


  https://github.com/agraf/schedgaps

Please let me know if it's unclear how to use it or if you see issues in 
your environment.


Please also make sure to only run this on idle server class hardware. 
Notebooks will most definitely have too many uncontrollable sources of 
timing entropy to give sensible results.



Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [PATCH v2 05/23] arm64: use asm-generic/mmu_context.h for no-op implementations

[kernel test robot]

Hi Nicholas,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Nicholas-Piggin/Use-asm-generic-for-mmu_context-no-op-functions/20200826-225632
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
2ac69819ba9e3d8d550bb5d2d2df74848e556812
config: arm64-randconfig-r036-20200826 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
7cfcecece0e0430937cf529ce74d3a071a4dedc6)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All errors (new ones prefixed by >>):

   In file included from arch/arm64/mm/mmu.c:35:
>> arch/arm64/include/asm/mmu_context.h:226:31: error: too few arguments to 
>> function call, expected 2, have 1
   check_and_switch_context(next);
    ^
   arch/arm64/include/asm/mmu_context.h:177:6: note: 'check_and_switch_context' 
declared here
   void check_and_switch_context(struct mm_struct *mm, unsigned int cpu);
^
   1 error generated.
--
   In file included from arch/arm64/mm/context.c:16:
>> arch/arm64/include/asm/mmu_context.h:226:31: error: too few arguments to 
>> function call, expected 2, have 1
   check_and_switch_context(next);
    ^
   arch/arm64/include/asm/mmu_context.h:177:6: note: 'check_and_switch_context' 
declared here
   void check_and_switch_context(struct mm_struct *mm, unsigned int cpu);
^
>> arch/arm64/mm/context.c:201:6: error: conflicting types for 
>> 'check_and_switch_context'
   void check_and_switch_context(struct mm_struct *mm)
^
   arch/arm64/include/asm/mmu_context.h:177:6: note: previous declaration is 
here
   void check_and_switch_context(struct mm_struct *mm, unsigned int cpu);
^
   2 errors generated.
--
   In file included from arch/arm64/kernel/process.c:54:
>> arch/arm64/include/asm/mmu_context.h:226:31: error: too few arguments to 
>> function call, expected 2, have 1
   check_and_switch_context(next);
    ^
   arch/arm64/include/asm/mmu_context.h:177:6: note: 'check_and_switch_context' 
declared here
   void check_and_switch_context(struct mm_struct *mm, unsigned int cpu);
^
   arch/arm64/kernel/process.c:260:6: warning: no previous prototype for 
function '__show_regs' [-Wmissing-prototypes]
   void __show_regs(struct pt_regs *regs)
^
   arch/arm64/kernel/process.c:260:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   void __show_regs(struct pt_regs *regs)
   ^
   static 
   arch/arm64/kernel/process.c:352:5: warning: no previous prototype for 
function 'arch_dup_task_struct' [-Wmissing-prototypes]
   int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
   ^
   arch/arm64/kernel/process.c:352:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
   int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
   ^
   static 
   arch/arm64/kernel/process.c:554:41: warning: no previous prototype for 
function '__switch_to' [-Wmissing-prototypes]
   __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
   ^
   arch/arm64/kernel/process.c:554:21: note: declare 'static' if the function 
is not intended to be used outside of this translation unit
   __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
   ^
   static 
   arch/arm64/kernel/process.c:692:25: warning: no previous prototype for 
function 'arm64_preempt_schedule_irq' [-Wmissing-prototypes]
   asmlinkage void __sched arm64_preempt_schedule_irq(void)
   ^
   arch/arm64/kernel/process.c:692:12: note: declare 'static' if the function 
is not intended to be used outside of this translation unit
   asmlinkage void __sched arm64_preempt

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

[Peter Chen]

On 20-08-26 15:49:57, Roger Quadros wrote:
> Peter,
> 
> On 26/08/2020 11:07, Peter Chen wrote:
> > > 
> > > 
> > > > 
> > > > On 20-08-26 04:04:01, Pawel Laszczak wrote:
> > > > > > On 20-08-25 15:00:59, Roger Quadros wrote:
> > > > > > > From: Pawel Laszczak 
> > > > > > > 
> > > > > > > USB2.0 PHY hangs in Rx Compliance test when the incoming packet
> > > > > > > amplitude is varied below and above the Squelch Level of Receiver
> > > > > > > during the active packet multiple times.
> > > > > > > 
> > > > > > > Version 1 of the controller allows PHY to be reset when RX fail
> > > > > > > condition is detected to work around the above issue. This feature
> > > > > > > is disabled by default and needs to be enabled using a bit from
> > > > > > > the newly added PHYRST_CFG register. This patch enables the 
> > > > > > > workaround.
> > > > > > > 
> > > > > > > As there is no way to distinguish between the controller version
> > > > > > > before the device controller is started we need to rely on a DT
> > > > > > > property to decide when to apply the workaround.
> > > > > > 
> > > > > > Pawel, it could know the controller version at cdns3_gadget_start,
> > > > > > but the controller starts when it tries to bind gadget driver, at
> > > > > > that time, it has already known the controller version.
> > > > > > 
> > > > > > For me, the device controller starts is using USB_CONF.DEVEN (Device
> > > > > > Enable) through usb_gadget_connect, I am not sure if it is the same
> > > > > > with yours.
> > > > > > 
> > > > > 
> > > > > Yes in device mode driver knows controller version but this
> > > > > workaround Must be enabled also in host mode. In host mode the
> > > > > controller doesn't have access to device registers. The controller
> > > > > version is placed in device register.
> > > > > 
> > > > 
> > > > You may suggest your design team adding CHIP_VER register at global
> > > > register region, it will easy the software engineer life.
> > > > 
> > > >From what I read, this register is only enabling USB2 PHY reset
> > > > software control, it needs for all chips with rev 0x0002450D, and the
> > > > place you current change is only for 0x0002450D, right?
> > > 
> > > Even I could say that this workaround should be enabled only for Specific 
> > > USB2
> > > PHY  (only 0x0002450D)
> > > 
> > > This bit should not have any impact for Cadence PHY but it can has Impact 
> > > for third
> > > party PHYs.
> > > 
> > 
> > So, it is related to specific PHY, but enable this specific PHY reset bit 
> > is at controller region, why don't
> > put this enable bit at PHY region?
> 
> I think this is related to Controller + PHY combination.
> The fix for the issue is via a bit in the controller, so it needs to be 
> managed by the
> controller driver.
> 
> > 
> > So, you use controller's device property to know this specific PHY, can 
> > controller know this specific
> > PHY dynamically?
> 
> Still the PHY will have to tell the controller the enable that bit. How to do 
> that?
> 
> Adding a dt-property that vendors can used was the simplest option.
> 

Ok, does all controllers with ver 0x0002450D need this fix? I just think
if we introduce a flag stands for ver 0x0002450D in case this ver has
other issues in future or just using phy reset enable property?

Pawel & Roger, what's your opinion?

-- 

Thanks,
Peter Chen

Re: [PATCH 1/4] dt-bindings: arm: ti: Add bindings for J7200 SoC

[Nishanth Menon]

On 14:16-20200723, Lokesh Vutla wrote:
> The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
> It is targeted for automotive gateway, vehicle compute systems,
> Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
> The SoC aims to meet the complex processing needs of modern embedded
> products.
> 
> Some highlights of this SoC are:
> * Dual Cortex-A72s in a single cluster, two clusters of lockstep
>   capable dual Cortex-R5F MCUs and a Centralized Device Management and
>   Security Controller (DMSC).
> * Configurable L3 Cache and IO-coherent architecture with high data
>   throughput capable distributed DMA architecture under NAVSS.
> * Integrated Ethernet switch supporting up to a total of 4 external ports
>   in addition to legacy Ethernet switch of up to 2 ports.
> * Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
>   20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C and
>   I2C, eCAP/eQEP, eHRPWM among other peripherals.
> * One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
>   management.
> 
> See J7200 Technical Reference Manual (SPRUIU1, June 2020)
> for further details: https://www.ti.com/lit/pdf/spruiu1
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  Documentation/devicetree/bindings/arm/ti/k3.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt 
> b/Documentation/devicetree/bindings/arm/ti/k3.txt
> index 333e7256126a..33419cce0afa 100644
> --- a/Documentation/devicetree/bindings/arm/ti/k3.txt
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
> @@ -16,6 +16,9 @@ architecture it uses, using one of the following compatible 
> values:
>  - J721E
>compatible = "ti,j721e";
>  
> +- J7200
> +  compatible = "ti,j7200";
> +
>  Boards
>  --

Lets convert the k3.txt to k3.yaml before we do anything more here.
Looking at the full series, I see that there are pending comments from
Grygorii as well which needs to be looked at. I have'nt seen a follow up
version since this version.

[1] 
https://lore.kernel.org/linux-arm-kernel/20200723084628.19241-1-lokeshvu...@ti.com/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:183:18: sparse: sparse: incorrect type in assignment (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   15bc20c6af4ceee97a1f90b43c0e386643c071b4
commit: 7fdf9b05c73b79c4d9a85b5a9905efa10ee482a6 dmaengine: fsl-dpaa2-qdma: Add 
NXP dpaa2 qDMA controller driver for Layerscape SoCs
date:   11 months ago
config: arm64-randconfig-s031-20200826 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 7fdf9b05c73b79c4d9a85b5a9905efa10ee482a6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:183:18: sparse: sparse: incorrect 
>> type in assignment (different base types) @@ expected unsigned int 
>> [usertype] cmd @@ got restricted __le32 [usertype] @@
>> drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:183:18: sparse: expected 
>> unsigned int [usertype] cmd
>> drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:183:18: sparse: got restricted 
>> __le32 [usertype]
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:188:26: sparse: sparse: incorrect 
type in assignment (different base types) @@ expected unsigned int 
[usertype] cmd @@ got restricted __le32 [usertype] @@
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:188:26: sparse: expected 
unsigned int [usertype] cmd
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:188:26: sparse: got restricted 
__le32 [usertype]
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:190:26: sparse: sparse: incorrect 
type in assignment (different base types) @@ expected unsigned int 
[usertype] cmd @@ got restricted __le32 [usertype] @@
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:190:26: sparse: expected 
unsigned int [usertype] cmd
   drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:190:26: sparse: got restricted 
__le32 [usertype]
--
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:81:24: sparse: sparse: incorrect type in 
>> assignment (different base types) @@ expected restricted __le64 
>> [usertype] @@ got restricted __le32 [usertype] @@
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:81:24: sparse: expected restricted 
>> __le64 [usertype]
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:81:24: sparse: got restricted __le32 
>> [usertype]
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse: sparse: invalid 
>> assignment: |=
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse:left side has type 
>> restricted __le64
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse:right side has type 
>> unsigned long long
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse: sparse: invalid 
>> assignment: |=
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse:left side has type 
>> restricted __le64
>> drivers/dma/fsl-dpaa2-qdma/dpdmai.c:148:9: sparse:right side has type 
>> unsigned long long

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fdf9b05c73b79c4d9a85b5a9905efa10ee482a6
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7fdf9b05c73b79c4d9a85b5a9905efa10ee482a6
vim +183 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c

   170  
   171  /* first frame list for descriptor buffer */
   172  static void
   173  dpaa2_qdma_populate_first_framel(struct dpaa2_fl_entry *f_list,
   174   struct dpaa2_qdma_comp *dpaa2_comp,
   175   bool wrt_changed)
   176  {
   177  struct dpaa2_qdma_sd_d *sdd;
   178  
   179  sdd = dpaa2_comp->desc_virt_addr;
   180  memset(sdd, 0, 2 * (sizeof(*sdd)));
   181  
   182  /* source descriptor CMD */
 > 183  sdd->cmd = cpu_to_le32(QDMA_SD_CMD_RDTTYPE_COHERENT);
   184  sdd++;
   185  
   186  /* dest descriptor CMD */
   187  if (wrt_changed)
   188  sdd->cmd = 
cpu_to_le32(LX2160_QDMA_DD_CMD_WRTTYPE_COHERENT);
   189  else
   190  sdd->cmd = cpu_to_le32(QDMA_DD_CMD_WRTTYPE_COHERENT);
   191  
   192  memset(f_list, 0, sizeof(struct dpaa2_fl_entry));
   193  
   194  /* first frame list to source descriptor */
   195  dpaa2_fl_set_addr(f_list, dpaa2_comp->desc_bus_addr);
   196  dpaa2_fl_set_len(f_list, 0x20);
   197  dpaa2_fl_set_format(f_list, QDMA_FL_FMT_SBF | QDMA_FL_SL_LONG);
   198