Re: [PATCH v6 7/7] tpm: pass an array of tpm_bank_list structures to tpm_pcr_extend()

[Roberto Sassu]

On 12/12/2018 7:27 PM, Jarkko Sakkinen wrote:

On Thu, Dec 06, 2018 at 07:38:30PM +0100, Roberto Sassu wrote:

On 12/5/2018 1:14 AM, Jarkko Sakkinen wrote:

On Tue, Dec 04, 2018 at 09:21:38AM +0100, Roberto Sassu wrote:

The new tpm_bank_list structure has been preferred to the tpm_digest
structure, to let the caller specify the size of the digest (which may be
unknown to the TPM driver).


Why is that? Didn't previous commit query these?


Since the TPM driver pads/truncates the first digest passed by the
caller to extend PCRs for which no digest was provided, it must know
which amount of data it can use. It is possible that the algorithm of
the first digest is unknown for the TPM driver, if the caller of
tpm_pcr_extend() didn't check chip->allocated_banks.

By requiring that the caller passes also the digest size, this problem
does not arise. It seems reasonable to me to pass this information, as
the caller calculated the digest and it should know the digest size.


OK. I noticed something other things that look to alarming:

1. The function does not fail if alg_id is not found. This will go
silent.


It is intentional. If alg_id is not found, the PCR is extended with the
first digest passed by the caller of tpm_pcr_extend(). If no digest was
provided, the PCR is extended with 0s. This is done to prevent that
PCRs in unused banks are extended later with fake measurements.



2. The function does not fail if there is a mismatch with the digest
sizes.


The data passed by the caller of tpm_pcr_extend() is copied to
dummy_hash, which has the maximum length. Then, tpm2_pcr_extend() takes
from dummy_hash as many bytes as needed, depending on the current
algorithm.

Roberto



/Jarkko



--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI

Re: [PATCH v3] mm: thp: fix flags for pmd migration when split

[Konstantin Khlebnikov]

On Thu, Dec 13, 2018 at 8:15 AM Peter Xu  wrote:
>
> When splitting a huge migrating PMD, we'll transfer all the existing
> PMD bits and apply them again onto the small PTEs.  However we are
> fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
> or pmd_yound() while actually they don't make sense at all when it's
> a migration entry.  Fix them up.  Since at it, drop the ifdef together
> as not needed.
>
> Note that if my understanding is correct about the problem then if
> without the patch there is chance to lose some of the dirty bits in
> the migrating pmd pages (on x86_64 we're fetching bit 11 which is part
> of swap offset instead of bit 2) and it could potentially corrupt the
> memory of an userspace program which depends on the dirty bit.
>

Looks good to me

Reviewed-by: Konstantin Khlebnikov 

> CC: Andrea Arcangeli 
> CC: Andrew Morton 
> CC: "Kirill A. Shutemov" 
> CC: Matthew Wilcox 
> CC: Michal Hocko 
> CC: Dave Jiang 
> CC: "Aneesh Kumar K.V" 
> CC: Souptick Joarder 
> CC: Konstantin Khlebnikov 
> CC: Zi Yan 
> CC: linux...@kvack.org
> CC: linux-kernel@vger.kernel.org
> Signed-off-by: Peter Xu 
> ---
> v2:
> - fix it up for young/write/dirty bits too [Konstantin]
> v3:
> - fetch write correctly for migration entry; drop macro [Konstantin]
> ---
>  mm/huge_memory.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index f2d19e4fe854..aebade83cec9 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2145,23 +2145,25 @@ static void __split_huge_pmd_locked(struct 
> vm_area_struct *vma, pmd_t *pmd,
>  */
> old_pmd = pmdp_invalidate(vma, haddr, pmd);
>
> -#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
> pmd_migration = is_pmd_migration_entry(old_pmd);
> -   if (pmd_migration) {
> +   if (unlikely(pmd_migration)) {
> swp_entry_t entry;
>
> entry = pmd_to_swp_entry(old_pmd);
> page = pfn_to_page(swp_offset(entry));
> -   } else
> -#endif
> +   write = is_write_migration_entry(entry);
> +   young = false;
> +   soft_dirty = pmd_swp_soft_dirty(old_pmd);
> +   } else {
> page = pmd_page(old_pmd);
> +   if (pmd_dirty(old_pmd))
> +   SetPageDirty(page);
> +   write = pmd_write(old_pmd);
> +   young = pmd_young(old_pmd);
> +   soft_dirty = pmd_soft_dirty(old_pmd);
> +   }
> VM_BUG_ON_PAGE(!page_count(page), page);
> page_ref_add(page, HPAGE_PMD_NR - 1);
> -   if (pmd_dirty(old_pmd))
> -   SetPageDirty(page);
> -   write = pmd_write(old_pmd);
> -   young = pmd_young(old_pmd);
> -   soft_dirty = pmd_soft_dirty(old_pmd);
>
> /*
>  * Withdraw the table only after we mark the pmd entry invalid.
> --
> 2.17.1
>

Re: [PATCH] xen: xen-pciback: Reset MSI-X state when exposing a device

[Jan Beulich]

>>> On 13.12.18 at 04:46,  wrote:
> On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
> On 12.12.18 at 16:18,  wrote:
>>> On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
>>> On 12.12.18 at 08:06,  wrote:
> On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
 I find some pass-thru devices don't work any more across guest reboot.
 Assigning it to another guest also meets the same issue. And the only
 way to make it work again is un-binding and binding it to pciback.
 Someone reported this issue one year ago [1]. More detail also can be
 found in [2].

 The root-cause is Xen's internal MSI-X state isn't reset properly
 during reboot or re-assignment. In the above case, Xen set maskall bit
 to mask all MSI interrupts after it detected a potential security
 issue. Even after device reset, Xen didn't reset its internal maskall
 bit. As a result, maskall bit would be set again in next write to
 MSI-X message control register.

 Given that PHYSDEVOPS_prepare_msix() also triggers Xen resetting MSI-X
 internal state of a device, we employ it to fix this issue rather than
 introducing another dedicated sub-hypercall.

 Note that PHYSDEVOPS_release_msix() will fail if the mapping between
 the device's msix and pirq has been created. This limitation prevents
 us calling this function when detaching a device from a guest during
 guest shutdown. Thus it is called right before calling
 PHYSDEVOPS_prepare_msix().
>>> s/PHYSDEVOPS/PHYSDEVOP/ (no final S). And then I would also drop the
>>> () at the end of the hypercall name since it's not a function.
>>>
>>> I'm also wondering why the release can't be done when the device is
>>> detached from the guest (or the guest has been shut down). This makes
>>> me worry about the raciness of the attach/detach procedure: if there's
>>> a state where pciback assumes the device has been detached from the
>>> guest, but there are still pirqs bound, an attempt to attach to
>>> another guest in such state will fail.
>>
>>I wonder whether this additional reset functionality could be done out
>>of xen_pcibk_xenbus_remove(). We first do a (best effort) device reset
>>and then do the extra things that are not properly done there.
> 
> No. It cannot be done in xen_pcibk_xenbus_remove() without modifying
> the handler of PHYSDEVOP_release_msix. To do a successful Xen internal
> MSI-X state reset, PHYSDEVOP_{release, prepare}_msix should be finished
> without error. But ATM, xen expects that no msi is bound to pirq when
> doing PHYSDEVOP_release_msix. Otherwise it fails with error code -EBUSY.
> However, the expectation isn't guaranteed in xen_pcibk_xenbus_remove().
> In some cases, if qemu fails to unmap MSIs, MSIs are unmapped by Xen
> at last minute, which happens after device reset in 
> xen_pcibk_xenbus_remove().

But that may need taking care of: I don't think it is a good idea to have
anything left from the prior owning domain when the device gets reset.
I.e. left over IRQ bindings should perhaps be forcibly cleared before
invoking the reset;
>>> 
>>> Agree. How about pciback to track the established IRQ bindings? Then
>>> pciback can clear irq binding before invoking the reset.
>>
>>How would pciback even know of those mappings, when it's qemu
>>who establishes (and manages) them?
> 
> I meant to expose some interfaces from pciback. And pciback serves
> as the proxy of IRQ (un)binding APIs.

If at all possible we should avoid having to change more parties (qemu,
libxc, kernel, hypervisor) than really necessary. Remember that such
a bug fix may want backporting, and making sure affected people have
all relevant components updated is increasingly difficult with their
number growing.

in fact I'd expect this to happen in the course of
domain destruction, and I'd expect the device reset to come after the
domain was cleaned up. Perhaps simply an ordering issue in the tool
stack?
>>> 
>>> I don't think reversing the sequences of device reset and domain
>>> destruction would be simple. Furthermore, during device hot-unplug,
>>> device reset is done when the owner is alive. So if we use domain
>>> destruction to enforce all irq binding cleared, in theory, it won't be
>>> applicable to hot-unplug case (if qemu's hot-unplug logic is
>>> compromised).
>>
>>Even in the hot-unplug case the tool stack could issue unbind
>>requests, behind the back of the possibly compromised qemu,
>>once neither the guest nor qemu have access to the device
>>anymore.
> 
> But currently, tool stack doesn't know the remaining IRQ bindings.
> If tool stack can 

[PATCH v12 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

[Taniya Das]

Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.

Signed-off-by: Taniya Das 
---
 .../bindings/cpufreq/cpufreq-qcom-hw.txt   | 172 +
 1 file changed, 172 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
new file mode 100644
index 000..2b82965
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
@@ -0,0 +1,172 @@
+Qualcomm Technologies, Inc. CPUFREQ Bindings
+
+CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
+SoCs to manage frequency in hardware. It is capable of controlling frequency
+for multiple clusters.
+
+Properties:
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,cpufreq-hw".
+
+- clocks
+   Usage:  required
+   Value type:  From common clock binding.
+   Definition: clock handle for XO clock and GPLL0 clock.
+
+- clock-names
+   Usage:  required
+   Value type:  From common clock binding.
+   Definition: must be "xo", "alternate".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of the HW bases in
+   each frequency domain.
+- reg-names
+   Usage:  Optional
+   Value type: 
+   Definition: Frequency domain name i.e.
+   "freq-domain0", "freq-domain1".
+
+- freq-domain-cells:
+   Usage:  required.
+   Definition: Number of cells in a freqency domain specifier.
+
+* Property qcom,freq-domain
+Devices supporting freq-domain must set their "qcom,freq-domain" property with
+phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
+
+
+Example:
+
+Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
+DCVS state together.
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <_0>;
+   qcom,freq-domain = <_hw 0>;
+   L2_0: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   L3_0: l3-cache {
+ compatible = "cache";
+   };
+   };
+   };
+
+   CPU1: cpu@100 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x100>;
+   enable-method = "psci";
+   next-level-cache = <_100>;
+   qcom,freq-domain = <_hw 0>;
+   L2_100: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU2: cpu@200 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x200>;
+   enable-method = "psci";
+   next-level-cache = <_200>;
+   qcom,freq-domain = <_hw 0>;
+   L2_200: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU3: cpu@300 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x300>;
+   enable-method = "psci";
+   next-level-cache = <_300>;
+   qcom,freq-domain = <_hw 0>;
+   L2_300: l2-cache {
+   compatible = "cache";
+   next-level-cache = <_0>;
+   };
+   };
+
+   CPU4: cpu@400 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x400>;
+   enable-method = "psci";
+   next-level-cache = <_400>;
+   qcom,freq-domain = <_hw 1>;
+   L2_400: l2-cache {
+   compatible = "cache";
+   next-level-cache = 

[PATCH v12 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Taniya Das]

The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.

Signed-off-by: Saravana Kannan 
Signed-off-by: Stephen Boyd 
Signed-off-by: Taniya Das 
---
 drivers/cpufreq/Kconfig.arm   |  11 ++
 drivers/cpufreq/Makefile  |   1 +
 drivers/cpufreq/qcom-cpufreq-hw.c | 305 ++
 3 files changed, 317 insertions(+)
 create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 4e1131e..688f102 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -114,6 +114,17 @@ config ARM_QCOM_CPUFREQ_KRYO

  If in doubt, say N.

+config ARM_QCOM_CPUFREQ_HW
+   tristate "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   help
+ Support for the CPUFreq HW driver.
+ Some QCOM chipsets have a HW engine to offload the steps
+ necessary for changing the frequency of the CPUs. Firmware loaded
+ in this engine exposes a programming interface to the OS.
+ The driver implements the cpufreq interface for this HW engine.
+ Say Y if you want to support CPUFreq HW.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index d5ee456..08c071b 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_MVEBU_V7)   += mvebu-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o
 obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO)+= qcom-cpufreq-kryo.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
 obj-$(CONFIG_ARM_S3C2412_CPUFREQ)  += s3c2412-cpufreq.o
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..a65d0ae
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LUT_MAX_ENTRIES40U
+#define LUT_SRCGENMASK(31, 30)
+#define LUT_L_VAL  GENMASK(7, 0)
+#define LUT_CORE_COUNT GENMASK(18, 16)
+#define LUT_ROW_SIZE   32
+#define CLK_HW_DIV 2
+
+/* Register offsets */
+#define REG_ENABLE 0x0
+#define REG_LUT_TABLE  0x110
+#define REG_PERF_STATE 0x920
+
+static unsigned long cpu_hw_rate, xo_rate;
+static struct platform_device *global_pdev;
+
+static int qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+   unsigned int index)
+{
+   void __iomem *perf_state_reg = policy->driver_data;
+
+   writel_relaxed(index, perf_state_reg);
+
+   return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+   void __iomem *perf_state_reg;
+   struct cpufreq_policy *policy;
+   unsigned int index;
+
+   policy = cpufreq_cpu_get_raw(cpu);
+   if (!policy)
+   return 0;
+
+   perf_state_reg = policy->driver_data;
+
+   index = readl_relaxed(perf_state_reg);
+   index = min(index, LUT_MAX_ENTRIES - 1);
+
+   return policy->freq_table[index].frequency;
+}
+
+static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   void __iomem *perf_state_reg = policy->driver_data;
+   int index;
+
+   index = policy->cached_resolved_idx;
+   if (index < 0)
+   return 0;
+
+   writel_relaxed(index, perf_state_reg);
+
+   return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_read_lut(struct device *dev,
+   struct cpufreq_policy *policy,
+   void __iomem *base)
+{
+   u32 data, src, lval, i, core_count, prev_cc = 0, prev_freq = 0, freq;
+   unsigned int max_cores = cpumask_weight(policy->cpus);
+   struct cpufreq_frequency_table  *table;
+
+   table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
+   if (!table)
+   return -ENOMEM;
+
+   for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+   data = readl_relaxed(base + REG_LUT_TABLE + i * LUT_ROW_SIZE);
+   src = FIELD_GET(LUT_SRC, data);
+   lval = FIELD_GET(LUT_L_VAL, data);
+   core_count = FIELD_GET(LUT_CORE_COUNT, data);
+
+   if (src)
+   freq = 

[PATCH v12 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW

[Taniya Das]

 [v12]
   * Remove per-cpu domain global structure.

 [v11]
   * Updated the code logic as per Stephen.
   * Default boost enabled is removed.
   * Update the clock name to use "alternate" for GPLL0 source in code and
 Documentation binding.
   * Module description updated.
   * perf_base updated to perf_state_reg.

 [v10]
  * Update Documentation binding for cpufreq node.
  * Make the driver 'tristate' instead of 'bool' and update code.
  * Update the clock name to reflect the hardware name.
  * Remove support for varying offset.

 [v9]
  * Update the Documentation binding for freq-domain-cells & cpufreq node.
  * Address comments in Kconfig.arm & Makefile.
  * Remove include file & MODULE_DESCRIPTION not required.
  * Fix the code for 'of_node_put(cpu_np)'.

 [v8]
   * Address comments to update code to take cpufreq_hw phandle and index from
 the CPU nodes.
   * Updated the Documentation for the above change in DT.
   * Updated logic for assigning 'qcom_freq_domain_map' for related CPUs.
   * Clock input to the HW block is taken from DT which has been updated in
 code and Device tree documentation.

 [v7]
   * Updated the logic to check for related CPUs.

 [v6]
   * Renamed match table 'qcom_cpufreq_hw_match'.
   * Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'.
   * Updated the logic to check for related CPUs at the beginning of the
 'qcom_cpu_resources_init'.
   * Use devm_ioremap_resource instead of devm_ioremap.
   * Update the use of of_node_put to handle error conditions.
   * Use policy->cached_resolved_idx in fast switch callback.
   * Keep precalculated offsets 'reg_bases'.
   * XO clock is taken from Device tree.
   * Update documentation binding for clocks/clock-names.
   * Minor comments in Kconfig.arm.
   * Comments to move dev_info to dev_dbg.

 [v5]
   * Remove mapping different register regions of perf/lut/enable,
 instead map the entire HW region.
   * Add reg_offset/cpufreq_qcom_std_offsets to be supplied as device data.
   * Check of src == 0 during lut read.
   * Add of_node_put(cpu_np) in qcom_get_related_cpus
   * Update the qcom_cpu_resources_init for register offset data,
 and cleanup the related cpus to keep a single copy of CPUfreq.
   * Replace FW with HW, update Kconfig, rename filename qcom-cpufreq-hw.c
   * Update the documentation binding to reflect the changes of mapping the
   * entire HW region.

 [v4]
   * Fixed console messages as per comments.
   * Return error from qcom_resources_init()
 in the cases where failed to get frequency domain.
   * Rename cpu_dev to cpu_np in qcom_resources_init,
 qcom_get_related_cpus(). Also use temp variable freq_np in
 qcom_get_related_cpus().
   * Update qcom_cpufreq_fw_get() to use the policy data to incoporate
 the hotplug use case.
   * Update code to use of fast_switching.
   * Check for !c->max_cores instead of cpumask_empty in
 qcom_get_related_cpus().
   * Update the logic of assigning 'c' to qcom_freq_domain_map[cpu].

 [v3]
   * Remove index check from 'qcom_cpufreq_fw_target_index'.
   * Update the Documentation binding to add the platform specific properties in
 the CPU nodes, node name "qcom,freq-domain".
   * Update return value to '0' from -ENODEV from 'qcom_cpufreq_fw_get'.
   * Update the logic for boost frequency to use local variables instead of
 cpufreq driver data in 'qcom_read_lut'.
   * Update the logic in 'qcom_get_related_cpus' to find the related cpus.
   * Update the reg-names to remove "_base" and also update the binding with the
 description of these registers.
   * Update the logic in 'qcom_resources_init' to address the new device tree
 notation of handling the frequency domain phandles.

 [v2]
   * Fixed the alignment issues in "qcom_cpufreq_fw_target_index" for dev_err 
and
 also for "qcom_cpu_resources_init".
   * Removed ret = 0 from qcom_get_related_cpus and added to check for
 cpu_mask_empty to return -ENOENT.
   * Fixes qcom_cpu_resources_init function
   * Remove initialization of 'index'
   * Check for valid 'c'
   * Removed initialization of 'prev_cc' from 'qcom_read_lut'.

Taniya Das (2):
  dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
  cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

 .../bindings/cpufreq/cpufreq-qcom-hw.txt   | 172 
 drivers/cpufreq/Kconfig.arm|  11 +
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/qcom-cpufreq-hw.c  | 305 +
 4 files changed, 489 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
 create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c

--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.

Re: [PATCH v11 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Taniya Das]

Hello Viresh,

On 12/12/2018 10:17 AM, Viresh Kumar wrote:

On 11-12-18, 19:05, Taniya Das wrote:

The design here assumes that there would not be any per-cpu/per-cluster
based SW requirement for the HW during frequency transitions, which again
makes me think that we would require to re-introduce these structures again
in case we have such requirements in near future.


Firstly, even in such cases we can go ahead with the design we proposed. And I
am not at all concerned about some hardware which we don't have right now. We
will see what to do when such hardware comes, maybe reintroduce the structures,
but that doesn't matter right now.


Also I think leaving the structures also helps us debug any boot up issues
looking at the ram contents of the per-(cpu/cluster) structures with the
contents from the firmware.


I don't see how debugging would be hard without those structures in place.


Hope these above helps us to go ahead with the current SW design.


Sorry, but I don't see any satisfactory reason on why you shouldn't make the
suggested changes. We are trying to make your (and any other developer who will
work on that driver) life simple by simplifying the code. Nothing beyond that :)



Sure, Thanks, will submit the next patch series for your ACK :).

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [Resend PATCH V5 7/10] KVM: Make kvm_set_spte_hva() return int

[Tianyu Lan]

Hi Paul:
 Thanks for your review.
On Wed, Dec 12, 2018 at 1:03 PM Paul Mackerras  wrote:
>
> On Thu, Dec 06, 2018 at 09:21:10PM +0800, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu 
> >
> > The patch is to make kvm_set_spte_hva() return int and caller can
> > check return value to determine flush tlb or not.
>
> It would be helpful if the patch description told the reader which
> return value(s) mean that the caller should flush the tlb.  I would
> guess that non-zero means to do the flush, but you should make that
> explicit.

OK. Thanks for suggestion and will update in the next version.

>
> > Signed-off-by: Lan Tianyu 
>
> For the powerpc bits:
>
> Acked-by: Paul Mackerras 



-- 
Best regards
Tianyu Lan

Re: [PATCH v2] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.

[Tomasz Figa]

Hi Helen,

On Sat, Nov 24, 2018 at 6:54 AM Helen Koike  wrote:
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and update for the same plane is
> not queued.

First of all, thanks for the patch. Please see my comments below.

If the description above applies (and AFAICT that's what the existing
code does indeed), then this doesn't sound like "amend" to me. It
sounds exactly as the kernel code calls it - "async update" or perhaps
"instantaneous commit" could better describe it?

>
> It uses the already in place infrastructure for async updates.
>
> It is useful for cursor updates and async PageFlips over the atomic
> ioctl, otherwise in some cases updates may be delayed to the point the
> user will notice it. Note that for now it's only enabled for cursor
> planes.
>
> DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this
> feature.
>
> Signed-off-by: Gustavo Padovan 
> Signed-off-by: Enric Balletbo i Serra 
> [updated for upstream]
> Signed-off-by: Helen Koike 
> ---
> Hi,
>
> This is the second attempt to introduce the new ATOMIC_AMEND flag for atomic
> operations, see the commit message for a more detailed description.
>
> This was tested using a small program that exercises the uAPI for easy
> sanity testing. The program was created by Alexandros and modified by
> Enric to test the capability flag [2].
>
> To test, just build the program and use the --atomic flag to use the cursor
> plane with the ATOMIC_AMEND flag. E.g.
>
>   drm_cursor --atomic
>
> The test worked on a rockchip Ficus v1.1 board on top of mainline plus
> the patch to update cursors asynchronously through atomic for the
> drm/rockchip driver plus the DRM_CAP_ASYNC_UPDATE patch.
>
> Alexandros also did a proof-of-concept to use this flag and draw cursors
> using atomic if possible on ozone [1].
>
> Thanks
> Helen
>
> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711
> [2] https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability
>
>
> Changes in v2:
> - rebase tree
> - do not fall back to a non-async update if if there isn't any
> pending commit to amend
>
> Changes in v1:
> - https://patchwork.freedesktop.org/patch/243088/
> - Only enable it if userspace requests it.
> - Only allow async update for cursor type planes.
> - Rename ASYNC_UPDATE for ATOMIC_AMEND.
>
>  drivers/gpu/drm/drm_atomic_helper.c | 6 +-
>  drivers/gpu/drm/drm_atomic_uapi.c   | 6 ++
>  include/uapi/drm/drm_mode.h | 4 +++-
>  3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 269f1a74de38..333190c6a0a4 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -934,7 +934,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> -   if (state->legacy_cursor_update)
> +   if (state->async_update || state->legacy_cursor_update)
> state->async_update = !drm_atomic_helper_async_check(dev, 
> state);
>
> return ret;
> @@ -1602,6 +1602,10 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
> if (new_plane_state->fence)
> return -EINVAL;
>
> +   /* Only allow async update for cursor type planes. */
> +   if (plane->type != DRM_PLANE_TYPE_CURSOR)
> +   return -EINVAL;
> +

So the existing upstream code already allowed this for any planes and
we're restricting this to cursor planes only. Is this expected? No
potential users that already started using this for other plane types?

Best regards,
Tomasz

Re: [PATCH] rtlwifi: Fix non-working BSS STA mode

[Pkshih]

On Thu, 2018-12-13 at 13:36 +0800, Kai Heng Feng wrote:
> > On Dec 13, 2018, at 08:35, Pkshih  wrote:
> > 
> > On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
> >> Once BSS STA mode gets started, it can be scanned by other clients but
> >> cannot entablish a connection.
> >  ^^^ typo: establish
> >> 
> >> Turns out the set_bcn_reg() and its *_set_beacon_related_registers()
> >> callbacks never get called so it has problem beaconing.
> >> 
> >> Enable the function in rtl_op_bss_info_changed() can make BSS STA mode
> >> start to work.
> >> 
> >> Signed-off-by: Kai-Heng Feng 
> >> ---
> >>  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> >> b/drivers/net/wireless/realtek/rtlwifi/core.c
> >> index 4bf7967590ca..11d27a5cc576 100644
> >> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> >> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> >> @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct
> ieee80211_hw
> >> *hw,
> >>     "BSS_CHANGED_BEACON_ENABLED\n");
> >>  
> >>    /*start hw beacon interrupt. */
> >> -  /*rtlpriv->cfg->ops->set_bcn_reg(hw); */
> >> +  rtlpriv->cfg->ops->set_bcn_reg(hw);
> >>    mac->beacon_enabled = 1;
> >>    rtlpriv->cfg->ops-
> >update_interrupt_mask(hw,
> >>    rtlpriv->cfg->maps
> > 
> > Which wifi chip do you use? And, please share your test scenario.
> 
> It’s Realtek 8723DE, which is currently not supported in mainline so I use
> rtl8723de in rtlwifi_new [1] to test it out.
> 
> The test scenario is simply enable hotspot through network manager, which uses
> wpa_supplicant to do the work.
> 
> [1] https://github.com/lwfinger/rtlwifi_new
> 

Since rtl8723de isn't supported yet, this patch would be pending.
I'll take time to check whether it works on existing chips.

Thanks
PK

Re: [PATCH 4.19 014/110] usb: xhci: Prevent bus suspend if a port connect change or polling state is detected

[Greg Kroah-Hartman]

On Wed, Dec 12, 2018 at 11:53:34PM +0100, Thomas Zeitlhofer wrote:
> Hello,
> 
> On Thu, Nov 29, 2018 at 03:11:45PM +0100, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch.  If anyone has any objections, please let me
> > know.
> > 
> > --
> > 
> > From: Mathias Nyman 
> > 
> > commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.
> [...]
> 
> on a current Thinkpad X1 Yoga, this breaks resume from hibernate such
> that opening the lid has (in the regular use case, see below) no effect
> any more: 
> 
> The system is configured to hibernate when the lid is closed. So, the
> expected behavior, which is restored by reverting this patch, is:
> 
>   close lid => system hibernates
>   open lid => system resumes
> 
> With this patch, the following two cases are observed:
> 
>   1)
>   close lid => system hibernates
>   open lid => system stays off
>   press power button => system boots and resumes
> 
>   2)
>   # systemctl hibernate => system hibernates
>   close lid 
>   open lid => system resumes
> 

So this is a problem in Linus's tree?  If so, let's work to get this
fixed there first.

If not, then we have other issues :)

thanks,

greg k-h

Re: [PATCH 1/2] scripts/spdxcheck.py: Always open files in binary mode

[Uwe Kleine-König]

On Wed, Dec 12, 2018 at 01:14:10PM -0500, Jeremy Cline wrote:
> Hi,
> 
> On Wed, Dec 12, 2018 at 02:12:09PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The spdxcheck script currently falls over when confronted with a binary
> > file (such as Documentation/logo.gif). To avoid that, always open files
> > in binary mode and decode line-by-line, ignoring encoding errors.

I suggest pointing out that the breakage only happens with python3 and
results in a UnicodeDecodeError.

> > One tricky case is when piping data into the script and reading it from
> > standard input. By default, standard input will be opened in text mode,
> > so we need to reopen it in binary mode.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> >  scripts/spdxcheck.py | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/scripts/spdxcheck.py b/scripts/spdxcheck.py
> > index 5056fb3b897d..e559c6294c39 100755
> > --- a/scripts/spdxcheck.py
> > +++ b/scripts/spdxcheck.py
> > @@ -168,6 +168,7 @@ class id_parser(object):
> >  self.curline = 0
> >  try:
> >  for line in fd:
> > +line = line.decode(locale.getpreferredencoding(False), 
> > errors='ignore')
> >  self.curline += 1
> >  if self.curline > maxlines:
> >  break
> > @@ -249,12 +250,13 @@ if __name__ == '__main__':
> >  
> >  try:
> >  if len(args.path) and args.path[0] == '-':
> > -parser.parse_lines(sys.stdin, args.maxlines, '-')
> > +stdin = os.fdopen(sys.stdin.fileno(), 'rb')
> > +parser.parse_lines(stdin, args.maxlines, '-')
> >  else:
> >  if args.path:
> >  for p in args.path:
> >  if os.path.isfile(p):
> > -parser.parse_lines(open(p), args.maxlines, p)
> > +parser.parse_lines(open(p, 'rb'), args.maxlines, p)
> >  elif os.path.isdir(p):
> >  scan_git_subtree(repo.head.reference.commit.tree, 
> > p)
> >  else:
> > -- 
> > 2.19.1
> > 
> 
> It might be worth noting this fixes commit 6f4d29df66ac
> ("scripts/spdxcheck.py: make python3 compliant") and also Cc this for
> stable since 6f4d29df66ac got backported to v4.19. While that commit
> did indeed make the script work with Python 3 for piping data, it broke
> Python 2 and made its way to stable.

It didn't break for me. Can you provide details about how and when it
broke for you?

Best regards
Uwe

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

[PATCH v2] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK

[Christophe Leroy]

[2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837 
dma_nommu_map_page+0x44/0xd4
[2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW 
4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[2.384740] NIP:  c000c540 LR: c000c584 CTR: 
[2.389743] REGS: c95abab0 TRAP: 0700   Tainted: GW  
(4.20.0-rc5-00560-g6bfb52e23a00-dirty)
[2.400042] MSR:  00029032   CR: 24042204  XER: 
[2.406669]
[2.406669] GPR00: c02f2244 c95abb60 c6262990 c95abd80 256a 0001 
0001 0001
[2.406669] GPR08:  2000 0010 0010 24042202  
0100 c95abd88
[2.406669] GPR16:  c05569d4 0001 0010 c95abc88 c0615664 
0004 
[2.406669] GPR24: 0010 c95abc88 c95abc88  c61ae210 c7ff6d40 
c61ae210 3d68
[2.441559] NIP [c000c540] dma_nommu_map_page+0x44/0xd4
[2.446720] LR [c000c584] dma_nommu_map_page+0x88/0xd4
[2.451762] Call Trace:
[2.454195] [c95abb60] [82000808] 0x82000808 (unreliable)
[2.459572] [c95abb80] [c02f2244] talitos_edesc_alloc+0xbc/0x3c8
[2.465493] [c95abbb0] [c02f2600] ablkcipher_edesc_alloc+0x4c/0x5c
[2.471606] [c95abbd0] [c02f4ed0] ablkcipher_encrypt+0x20/0x64
[2.477389] [c95abbe0] [c02023b0] __test_skcipher+0x4bc/0xa08
[2.483049] [c95abe00] [c0204b60] test_skcipher+0x2c/0xcc
[2.488385] [c95abe20] [c0204c48] alg_test_skcipher+0x48/0xbc
[2.494064] [c95abe40] [c0205cec] alg_test+0x164/0x2e8
[2.499142] [c95abf00] [c0200dec] cryptomgr_test+0x48/0x50
[2.504558] [c95abf10] [c0039ff4] kthread+0xe4/0x110
[2.509471] [c95abf40] [c000e1d0] ret_from_kernel_thread+0x14/0x1c
[2.515532] Instruction dump:
[2.518468] 7c7e1b78 7c9d2378 7cbf2b78 41820054 3d20c076 8089c200 3d20c076 
7c84e850
[2.526127] 8129c204 7c842e70 7f844840 419c0008 <0fe0> 2f9e 54847022 
7c84fa14
[2.533960] ---[ end trace bf78d94af73fe3b8 ]---
[2.539123] talitos ff02.crypto: master data transfer error
[2.544775] talitos ff02.crypto: TEA error: ISR 0x2000_0040
[2.551625] alg: skcipher: encryption failed on test 1 for ecb-aes-talitos: 
ret=22

IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.

This patch copies the IV from areq->info into the request context.

Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 
---
 v2: Using per-request context.

 drivers/crypto/talitos.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6988012deca4..df289758755c 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1664,12 +1664,16 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
 static struct talitos_edesc *ablkcipher_edesc_alloc(struct ablkcipher_request *
areq, bool encrypt)
 {
+   void *req_ctx = ablkcipher_request_ctx(areq);
struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(areq);
struct talitos_ctx *ctx = crypto_ablkcipher_ctx(cipher);
unsigned int ivsize = crypto_ablkcipher_ivsize(cipher);
 
+   if (ivsize)
+   memcpy(req_ctx, areq->info, ivsize);
+
return talitos_edesc_alloc(ctx->dev, areq->src, areq->dst,
-  areq->info, 0, areq->nbytes, 0, ivsize, 0,
+  req_ctx, 0, areq->nbytes, 0, ivsize, 0,
   areq->base.flags, encrypt);
 }
 
@@ -3066,6 +3070,13 @@ static int talitos_cra_init_ahash(struct crypto_tfm *tfm)
return 0;
 }
 
+static int talitos_cra_init_ablkcipher(struct crypto_tfm *tfm)
+{
+   tfm->crt_ablkcipher.reqsize = TALITOS_MAX_IV_LENGTH;
+
+   return talitos_cra_init(tfm);
+}
+
 static void talitos_cra_exit(struct crypto_tfm *tfm)
 {
struct talitos_ctx *ctx = crypto_tfm_ctx(tfm);
@@ -3149,7 +3160,7 @@ static struct talitos_crypto_alg 
*talitos_alg_alloc(struct device *dev,
switch (t_alg->algt.type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
alg = _alg->algt.alg.crypto;
-   alg->cra_init = talitos_cra_init;
+   alg->cra_init = talitos_cra_init_ablkcipher;
alg->cra_exit = talitos_cra_exit;
alg->cra_type = _ablkcipher_type;
alg->cra_ablkcipher.setkey = ablkcipher_setkey;
-- 
2.13.3

Re: [GIT PULL] tee subsys for v4.21

[Jens Wiklander]

Hi Olof,

On Wed, Dec 12, 2018 at 11:16 PM Olof Johansson  wrote:
>
> On Wed, Dec 12, 2018 at 01:31:21PM +0100, Jens Wiklander wrote:
> > Hello arm-soc maintainers,
> >
> > Please pull this small OP-TEE driver enhancement. A friendly log message
> > is added to inform that dynamic shared memory is used when initiazing
> > the OP-TEE driver.
>
> Hi Jens,
>
> We generally try to keep our branches based on quite early -rc releases (rc
> 1/2/3), to avoid having to merge-back into our tree from upstream too much.

Sorry, I'll keep that in mind from now on.

>
> Your branch is unfortunately based on -rc6. Would you prefer to respin it with
> an older base, or should I cherry-pick over the patch from it? Either is OK
> with me.

If you don't mind cherry-pick over please do so.

Thanks,
Jens

Re: [GIT PULL] tee driver fix for v4.21

[Jens Wiklander]

On Wed, Dec 12, 2018 at 11:16 PM Olof Johansson  wrote:
>
> On Wed, Dec 12, 2018 at 01:28:00PM +0100, Jens Wiklander wrote:
> > Hello arm-soc maintainers,
> >
> > Please pull this tee driver fix for a possible double list_del() in the
> > OP-TEE driver while uninitializing.
> >
> > Thanks,
> > Jens
> >
> > The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d:
> >
> >   Linux 4.20-rc6 (2018-12-09 15:31:00 -0800)
> >
> > are available in the Git repository at:
> >
> >   https://git.linaro.org/people/jens.wiklander/linux-tee.git 
> > tags/tee-subsys-fix-for-4.21
> >
> > for you to fetch changes up to b2d102bd0146d9eb1fa630ca0cd19a15ef2f74c8:
> >
> >   tee: optee: avoid possible double list_del() (2018-12-11 14:38:21 +0100)
> >
> > 
> > Avoid possible double list_del in supplicant comms
> >
> > A fix for the OP-TEE driver to avoid possible double list_del during
> > tee-supplicant communication while the system is shutting down.
>
> Do you want this for 4.20 or 4.21? Seems like .20 material to me but the tag
> name is 4.21.

It's just that we're so late in the 4.20 cycle. If you're OK with
taking it now I'm happy with that.

Thanks,
Jens

Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

[kbuild test robot]

Hi Rafael,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc6 next-20181212]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rafael-David-Tinoco/mm-zsmalloc-c-Fix-zsmalloc-32-bit-PAE-support/20181211-020704
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

>> mm/zsmalloc.c:112:3: error: #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be 
>> defined by arch using zsmalloc";
 #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using 
zsmalloc";
  ^

vim +112 mm/zsmalloc.c

   103  
   104  /*
   105   * MAX_POSSIBLE_PHYSMEM_BITS should be defined by all archs using 
zsmalloc:
   106   * Trying to guess it from MAX_PHYSMEM_BITS, or considering it 
BITS_PER_LONG,
   107   * proved to be wrong by not considering PAE capabilities, or using 
SPARSEMEM
   108   * only headers, leading to bad object encoding due to object index 
overflow.
   109   */
   110  #ifndef MAX_POSSIBLE_PHYSMEM_BITS
   111   #define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
 > 112   #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using 
 > zsmalloc";
   113  #else
   114   #ifndef CONFIG_64BIT
   115#if (MAX_POSSIBLE_PHYSMEM_BITS >= (BITS_PER_LONG + PAGE_SHIFT - 
OBJ_TAG_BITS))
   116 #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
   117#endif
   118   #endif
   119  #endif
   120  

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


.config.gz
Description: application/gzip

RE: [PATCH] PCI: imx: make msi work without pcieportbus

[Richard Zhu]

> -Original Message-
> From: Baruch Siach [mailto:bar...@tkos.co.il]
> Sent: 2018年12月13日 14:37
> To: Richard Zhu 
> Cc: bhelg...@google.com; lorenzo.pieral...@arm.com;
> l.st...@pengutronix.de; andrew.smir...@gmail.com;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] PCI: imx: make msi work without pcieportbus
> 
> Hi Richard,
> 
> Thanks for debugging this issue. One question below.
> 
> Richard Zhu writes:
> > MSI_EN of iMX PCIe RC would be asserted when PCIEPORTBUS driver is
> > selected.
> > Thus, the MSI works fine on iMX PCIe before.
> > Make a double check on this bit, and assert it when it is not set and
> > MSI is supported.
> > Otherwise, the MSI wouldn't be triggered although the EP is present
> > and the MSIs are assigned.
> >
> > Signed-off-by: Richard Zhu 
> > ---
> >  drivers/pci/controller/dwc/pci-imx6.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 26087b3..6c3e56b 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -74,6 +74,7 @@ struct imx6_pcie {
> >  #define PHY_PLL_LOCK_WAIT_USLEEP_MAX   200
> >
> >  /* PCIe Root Complex registers (memory-mapped) */
> > +#define PCI_MSI_CAP0x50
> >  #define PCIE_RC_LCR0x7c
> >  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1   0x1
> >  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2   0x2
> > @@ -926,6 +927,7 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> > struct resource *dbi_base;
> > struct device_node *node = dev->of_node;
> > int ret;
> > +   u16 val;
> >
> > imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
> > if (!imx6_pcie)
> > @@ -1070,6 +1072,14 @@ static int imx6_pcie_probe(struct
> platform_device *pdev)
> > ret = imx6_add_pcie_port(imx6_pcie, pdev);
> > if (ret < 0)
> > return ret;
> > +   if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > +   val = dw_pcie_readw_dbi(pci, PCI_MSI_CAP + PCI_MSI_FLAGS);
> > +   if ((val & PCI_MSI_FLAGS_ENABLE) == 0) {
> > +   val |= PCI_MSI_FLAGS_ENABLE;
> 
> Why not assert the PCI_MSI_FLAGS_ENABLE flag unconditionally here?
[Richard Zhu] Thanks for your kindly review.
It's more efficient to set it unconditionally.
I would change it in next version.

> 
> > +   dw_pcie_writew_dbi(pci, PCI_MSI_CAP +
> > +   PCI_MSI_FLAGS, val);
> > +   }
> > +   }
> >
> > return 0;
> >  }
> 
> baruch
> 
> --
> 
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbaru
> ch.siach.name%2Fblog%2Fdata=02%7C01%7Chongxing.zhu%40nxp.co
> m%7Ce9d8a943e90f4055f41708d660c55801%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C636802798043957806sdata=hh4ichdPcGA0
> N1om4AdZIOaEX3HE2rpW6jYl8m1F%2FWE%3Dreserved=0
> ~. .~   Tk Open Systems
> =}ooO--U--Ooo{=
>- bar...@tkos.co.il - tel: +972.52.368.4656,
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> .tkos.co.ildata=02%7C01%7Chongxing.zhu%40nxp.com%7Ce9d8a943e
> 90f4055f41708d660c55801%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C636802798043957806sdata=awQAaFvN9%2B63IxOonaox7O
> JxZoTtSHJGFNKSXEKPKso%3Dreserved=0 -

[PATCH v2 4/4] perf record: implement --affinity=node|cpu option

[Alexey Budankov]

Implement --affinity=node|cpu option for the record mode defaulting
to system affinity mask bouncing.

Signed-off-by: Alexey Budankov 
---
 tools/perf/Documentation/perf-record.txt |  5 +
 tools/perf/builtin-record.c  | 18 ++
 2 files changed, 23 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index d232b13ea713..efb839784f32 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -440,6 +440,11 @@ Use  control blocks in asynchronous (Posix AIO) trace 
writing mode (default:
 Asynchronous mode is supported only when linking Perf tool with libc library
 providing implementation for Posix AIO API.
 
+--affinity=mode::
+Set affinity mask of trace reading thread according to the policy defined by 
'mode' value:
+  node - thread affinity mask is set to NUMA node cpu mask of the processed 
mmap buffer
+  cpu  - thread affinity mask is set to cpu of the processed mmap buffer
+
 --all-kernel::
 Configure all used events to run in kernel space.
 
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index eea96794ee45..57dc3a45d16f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1653,6 +1653,21 @@ static int parse_clockid(const struct option *opt, const 
char *str, int unset)
ui__warning("unknown clockid %s, check man page\n", ostr);
return -1;
 }
+static int record__parse_affinity(const struct option *opt, const char *str, 
int unset)
+{
+   struct record_opts *opts = (struct record_opts *)opt->value;
+
+   if (!unset) {
+   if (str) {
+   if (!strcasecmp(str, "node"))
+   opts->affinity = PERF_AFFINITY_NODE;
+   else if (!strcasecmp(str, "cpu"))
+   opts->affinity = PERF_AFFINITY_CPU;
+   }
+   }
+
+   return 0;
+}
 
 static int record__parse_mmap_pages(const struct option *opt,
const char *str,
@@ -1961,6 +1976,9 @@ static struct option __record_options[] = {
 _cblocks_default, "n", "Use  control blocks in 
asynchronous trace writing mode (default: 1, max: 4)",
 record__aio_parse),
 #endif
+   OPT_CALLBACK(0, "affinity", , "node|cpu",
+"Set affinity mask of trace reading thread to NUMA node 
cpu mask or cpu of processed mmap buffer",
+record__parse_affinity),
OPT_END()
 };

[PATCH v2 2/4] perf record: bind the AIO user space buffers to nodes

[Alexey Budankov]

Allocate and bind AIO user space buffers to the memory nodes
that mmap kernel buffers are bound to.

Signed-off-by: Alexey Budankov 
---
Changes in v2:
- implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind 
  and put HAVE_LIBNUMA_SUPPORT #ifdefs in there
---
 tools/perf/util/mmap.c | 49 --
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index e68ba754a8e2..742fa9a8e498 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -10,6 +10,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_LIBNUMA_SUPPORT
+#include 
+#endif
 #include "debug.h"
 #include "event.h"
 #include "mmap.h"
@@ -154,6 +157,46 @@ void __weak auxtrace_mmap_params__set_idx(struct 
auxtrace_mmap_params *mp __mayb
 }
 
 #ifdef HAVE_AIO_SUPPORT
+
+#ifdef HAVE_LIBNUMA_SUPPORT
+static void perf_mmap__aio_alloc(void **data, size_t len)
+{
+   *data = mmap(NULL, len, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
+}
+
+static void perf_mmap__aio_free(void **data, size_t len)
+{
+   munmap(*data, len);
+   *data = NULL;
+}
+
+static void perf_mmap__aio_bind(void *data, size_t len, int cpu, int affinity)
+{
+   if (affinity != PERF_AFFINITY_SYS && cpu__max_node() > 1) {
+   unsigned long node_mask = 1UL << cpu__get_node(cpu);
+   if (mbind(data, len, MPOL_BIND, _mask, 1, 0)) {
+ pr_debug2("failed to bind [%p-%p] to node %d\n",
+   data, data + len, cpu__get_node(cpu));
+   }
+   }
+}
+#else
+static void perf_mmap__aio_alloc(void **data, size_t len)
+{
+   *data = malloc(len);
+}
+
+static void perf_mmap__aio_free(void **data, size_t len __maybe_unused)
+{
+   zfree(data);
+}
+
+static void perf_mmap__aio_bind(void *data __maybe_unused, size_t len 
__maybe_unused,
+int cpu __maybe_unused, int affinity 
__maybe_unused)
+{
+}
+#endif
+
 static int perf_mmap__aio_mmap(struct perf_mmap *map, struct mmap_params *mp)
 {
int delta_max, i, prio;
@@ -177,11 +220,13 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map, 
struct mmap_params *mp)
}
delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
for (i = 0; i < map->aio.nr_cblocks; ++i) {
-   map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
+   size_t mmap_len = perf_mmap__mmap_len(map);
+   perf_mmap__aio_alloc(&(map->aio.data[i]), mmap_len);
if (!map->aio.data[i]) {
pr_debug2("failed to allocate data buffer area, 
error %m");
return -1;
}
+   perf_mmap__aio_bind(map->aio.data[i], mmap_len, 
map->cpu, mp->affinity);
/*
 * Use cblock.aio_fildes value different from -1
 * to denote started aio write operation on the
@@ -210,7 +255,7 @@ static void perf_mmap__aio_munmap(struct perf_mmap *map)
int i;
 
for (i = 0; i < map->aio.nr_cblocks; ++i)
-   zfree(>aio.data[i]);
+   perf_mmap__aio_free(&(map->aio.data[i]), 
perf_mmap__mmap_len(map));
if (map->aio.data)
zfree(>aio.data);
zfree(>aio.cblocks);

[PATCH v2 3/4] perf record: apply affinity masks when reading mmap, buffers

[Alexey Budankov]

Build node cpu masks for mmap data buffers. Apply node cpu
masks to tool thread every time it references data buffers
cross node or cross cpu.

Signed-off-by: Alexey Budankov 
---
Changes in v2:
- separated AIO buffers binding to patch 2/4
---
 tools/perf/builtin-record.c |  9 +
 tools/perf/util/evlist.c|  6 +-
 tools/perf/util/mmap.c  | 12 
 tools/perf/util/mmap.h  |  1 +
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index b26febb54d01..eea96794ee45 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -536,6 +536,9 @@ static int record__mmap_evlist(struct record *rec,
struct record_opts *opts = >opts;
char msg[512];
 
+   if (opts->affinity != PERF_AFFINITY_SYS)
+   cpu__setup_cpunode_map();
+
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
 opts->auxtrace_mmap_pages,
 opts->auxtrace_snapshot_mode,
@@ -755,6 +758,12 @@ static int record__mmap_read_evlist(struct record *rec, 
struct perf_evlist *evli
struct perf_mmap *map = [i];
 
if (map->base) {
+   if (rec->opts.affinity != PERF_AFFINITY_SYS &&
+   !CPU_EQUAL(>affinity_mask, 
>affinity_mask)) {
+   CPU_ZERO(>affinity_mask);
+   CPU_OR(>affinity_mask, 
>affinity_mask, >affinity_mask);
+   sched_setaffinity(0, 
sizeof(rec->affinity_mask), >affinity_mask);
+   }
if (!record__aio_enabled(rec)) {
if (perf_mmap__push(map, rec, record__pushfn) 
!= 0) {
rc = -1;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 60e825be944a..5ca5bb5ea0db 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1028,7 +1028,11 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist, 
unsigned int pages,
 * Its value is decided by evsel's write_backward.
 * So  should not be passed through const pointer.
 */
-   struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity = 
affinity };
+   struct mmap_params mp = {
+   .nr_cblocks = nr_cblocks,
+   .affinity   = affinity,
+   .cpu_map= cpus
+   };
 
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index 742fa9a8e498..a2095e4eda4b 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -361,6 +361,7 @@ void perf_mmap__munmap(struct perf_mmap *map)
 
 int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int 
cpu)
 {
+   int c, nr_cpus, node;
/*
 * The last one will be done at perf_mmap__consume(), so that we
 * make sure we don't prevent tools from consuming every last event in
@@ -389,6 +390,17 @@ int perf_mmap__mmap(struct perf_mmap *map, struct 
mmap_params *mp, int fd, int c
map->cpu = cpu;
 
CPU_ZERO(>affinity_mask);
+   if (mp->affinity == PERF_AFFINITY_NODE && cpu__max_node() > 1) {
+   nr_cpus = cpu_map__nr(mp->cpu_map);
+   node = cpu__get_node(map->cpu);
+   for (c = 0; c < nr_cpus; c++) {
+   if (cpu__get_node(c) == node) {
+   CPU_SET(c, >affinity_mask);
+   }
+   }
+   } else if (mp->affinity == PERF_AFFINITY_CPU) {
+   CPU_SET(map->cpu, >affinity_mask);
+   }
 
if (auxtrace_mmap__mmap(>auxtrace_mmap,
>auxtrace_mp, map->base, fd))
diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
index e566c19b242b..b3f724fad22e 100644
--- a/tools/perf/util/mmap.h
+++ b/tools/perf/util/mmap.h
@@ -72,6 +72,7 @@ enum bkw_mmap_state {
 struct mmap_params {
int prot, mask, nr_cblocks, affinity;
struct auxtrace_mmap_params auxtrace_mp;
+   const struct cpu_map*cpu_map;
 };
 
 int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int 
cpu);

[PATCH v2 1/4] perf record: allocate affinity masks

[Alexey Budankov]

Allocate affinity option and masks for mmap data buffers and
record thread as well as initialize allocated objects.

Signed-off-by: Alexey Budankov 
---
Changes in v2:
- made debug affinity mode message user friendly
- converted affinity mode defines to enum values
---
 tools/perf/builtin-record.c | 13 -
 tools/perf/perf.h   |  8 
 tools/perf/util/evlist.c|  6 +++---
 tools/perf/util/evlist.h|  2 +-
 tools/perf/util/mmap.c  |  2 ++
 tools/perf/util/mmap.h  |  3 ++-
 6 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 882285fb9f64..b26febb54d01 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -81,12 +81,17 @@ struct record {
booltimestamp_boundary;
struct switch_outputswitch_output;
unsigned long long  samples;
+   cpu_set_t   affinity_mask;
 };
 
 static volatile int auxtrace_record__snapshot_started;
 static DEFINE_TRIGGER(auxtrace_snapshot_trigger);
 static DEFINE_TRIGGER(switch_output_trigger);
 
+static const char* affinity_tags[PERF_AFFINITY_EOF] = {
+   "SYS", "NODE", "CPU"
+};
+
 static bool switch_output_signal(struct record *rec)
 {
return rec->switch_output.signal &&
@@ -533,7 +538,8 @@ static int record__mmap_evlist(struct record *rec,
 
if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
 opts->auxtrace_mmap_pages,
-opts->auxtrace_snapshot_mode, 
opts->nr_cblocks) < 0) {
+opts->auxtrace_snapshot_mode,
+opts->nr_cblocks, opts->affinity) < 0) {
if (errno == EPERM) {
pr_err("Permission error mapping pages.\n"
   "Consider increasing "
@@ -1980,6 +1986,9 @@ int cmd_record(int argc, const char **argv)
 # undef REASON
 #endif
 
+   CPU_ZERO(>affinity_mask);
+   rec->opts.affinity = PERF_AFFINITY_SYS;
+
rec->evlist = perf_evlist__new();
if (rec->evlist == NULL)
return -ENOMEM;
@@ -2143,6 +2152,8 @@ int cmd_record(int argc, const char **argv)
if (verbose > 0)
pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
 
+   pr_debug("affinity: %s\n", affinity_tags[rec->opts.affinity]);
+
err = __cmd_record(, argc, argv);
 out:
perf_evlist__delete(rec->evlist);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 388c6dd128b8..69f54529d81f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -83,6 +83,14 @@ struct record_opts {
clockid_tclockid;
u64  clockid_res_ns;
int  nr_cblocks;
+   int  affinity;
+};
+
+enum perf_affinity {
+   PERF_AFFINITY_SYS = 0,
+   PERF_AFFINITY_NODE,
+   PERF_AFFINITY_CPU,
+   PERF_AFFINITY_EOF
 };
 
 struct option;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e90575192209..60e825be944a 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1018,7 +1018,7 @@ int perf_evlist__parse_mmap_pages(const struct option 
*opt, const char *str,
  */
 int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
 unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks)
+bool auxtrace_overwrite, int nr_cblocks, int affinity)
 {
struct perf_evsel *evsel;
const struct cpu_map *cpus = evlist->cpus;
@@ -1028,7 +1028,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist, 
unsigned int pages,
 * Its value is decided by evsel's write_backward.
 * So  should not be passed through const pointer.
 */
-   struct mmap_params mp = { .nr_cblocks = nr_cblocks };
+   struct mmap_params mp = { .nr_cblocks = nr_cblocks, .affinity = 
affinity };
 
if (!evlist->mmap)
evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
@@ -1060,7 +1060,7 @@ int perf_evlist__mmap_ex(struct perf_evlist *evlist, 
unsigned int pages,
 
 int perf_evlist__mmap(struct perf_evlist *evlist, unsigned int pages)
 {
-   return perf_evlist__mmap_ex(evlist, pages, 0, false, 0);
+   return perf_evlist__mmap_ex(evlist, pages, 0, false, 0, 
PERF_AFFINITY_SYS);
 }
 
 int perf_evlist__create_maps(struct perf_evlist *evlist, struct target *target)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 868294491194..72728d7f4432 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -162,7 +162,7 @@ unsigned long perf_event_mlock_kb_in_pages(void);
 
 int perf_evlist__mmap_ex(struct perf_evlist *evlist, unsigned int pages,
 unsigned int auxtrace_pages,
-bool auxtrace_overwrite, int nr_cblocks);
+bool auxtrace_overwrite, int nr_cblocks, int 

[PATCH 2/2] can: flexcan: add support for PE clock source select

[Joakim Zhang]

From: Dong Aisheng 

Add support to select the clock source for CAN Protocol Engine (PE).
It's Soc Implementation dependent. Refer to RM for detailed definition
of each Soc. We select clock source 1 (peripheral clock) by default in
driver now, this patch add support to prase clock source in DTS file.

Signed-off-by: Dong Aisheng 
Signed-off-by: Joakim Zhang 
---
 drivers/net/can/flexcan.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 0f36eafe3ac1..2bca867bcfaa 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -273,6 +273,8 @@ struct flexcan_priv {
u8 tx_mb_idx;
u8 mb_count;
u8 mb_size;
+   /* Select clock source to CAN Protocol Engine */
+   u8 clk_src;
u32 reg_ctrl_default;
u32 reg_imask1_default;
u32 reg_imask2_default;
@@ -1361,9 +1363,12 @@ static int register_flexcandev(struct net_device *dev)
err = flexcan_chip_disable(priv);
if (err)
goto out_disable_per;
-   reg = priv->read(>ctrl);
-   reg |= FLEXCAN_CTRL_CLK_SRC;
-   priv->write(reg, >ctrl);
+
+   if (priv->clk_src) {
+   reg = priv->read(>ctrl);
+   reg |= FLEXCAN_CTRL_CLK_SRC;
+   priv->write(reg, >ctrl);
+   }
 
err = flexcan_chip_enable(priv);
if (err)
@@ -1488,6 +1493,7 @@ static int flexcan_probe(struct platform_device *pdev)
struct clk *clk_ipg = NULL, *clk_per = NULL;
struct flexcan_regs __iomem *regs;
int err, irq;
+   u8 clk_src = 1;
u32 clock_freq = 0;
 
reg_xceiver = devm_regulator_get(>dev, "xceiver");
@@ -1496,9 +1502,12 @@ static int flexcan_probe(struct platform_device *pdev)
else if (IS_ERR(reg_xceiver))
reg_xceiver = NULL;
 
-   if (pdev->dev.of_node)
+   if (pdev->dev.of_node) {
of_property_read_u32(pdev->dev.of_node,
 "clock-frequency", _freq);
+   of_property_read_u8(pdev->dev.of_node,
+   "fsl,clk-source", _src);
+   }
 
if (!clock_freq) {
clk_ipg = devm_clk_get(>dev, "ipg");
@@ -1556,6 +1565,7 @@ static int flexcan_probe(struct platform_device *pdev)
priv->write = flexcan_write_le;
}
 
+   priv->clk_src = clk_src;
priv->can.clock.freq = clock_freq;
priv->can.bittiming_const = _bittiming_const;
priv->can.do_set_mode = flexcan_set_mode;
-- 
2.17.1

[PATCH 0/2] can: flexcan: add PE clock source select support

[Joakim Zhang]

The patch set intends to add support for PE clock source select. The
FlexCAN controller can parse "fsl,clk-source" property from device tree
to select clock source.

Dong Aisheng (2):
  Documentation: can: flexcan: add PE clock source property to device
tree
  can: flexcan: add support for PE clock source select

 .../bindings/net/can/fsl-flexcan.txt   |  8 
 drivers/net/can/flexcan.c  | 18 ++
 2 files changed, 22 insertions(+), 4 deletions(-)

-- 
2.17.1

[PATCH 1/2] Documentation: can: flexcan: add PE clock source property to device tree

[Joakim Zhang]

From: Dong Aisheng 

The FlexCAN controller can parse clock source property from DTS file to
select PE clock source.

Signed-off-by: Dong Aisheng 
Signed-off-by: Joakim Zhang 
---
 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt 
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index bc77477c6878..a04168605998 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -32,6 +32,13 @@ Optional properties:
 ack_gpr is the gpr register offset of CAN stop acknowledge.
 ack_bit is the bit offset of CAN stop acknowledge.
 
+- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE).
+ It's SoC Implementation dependent. Refer to RM for detailed
+ definition. If this property is not set in device tree node
+ then driver selects clock source 1 by default.
+ 0: clock source 0 (oscillator clock)
+ 1: clock source 1 (peripheral clock)
+
 Example:
 
can@1c000 {
@@ -40,4 +47,5 @@ Example:
interrupts = <48 0x2>;
interrupt-parent = <>;
clock-frequency = <2>; // filled in by bootloader
+   fsl,clk-source = <0>; // select clock source 0 for PE
};
-- 
2.17.1

[PATCH v2 0/4] Reduce NUMA related overhead in perf record profiling on large server systems

[Alexey Budankov]

It has been observed that trace reading thread runs on the same hw thread
most of the time during perf record sampling collection. This scheduling
layout leads up to 30% profiling overhead in case when some cpu intensive
workload fully utilizes a large server system with NUMA. Overhead usually
arises from remote (cross node) HW and memory references that have much
longer latencies than local ones [1].

This patch set implements --affinity option that lowers 30% overhead
completely for serial trace streaming (--affinity=cpu) and from 30% to
10% for AIO1 (--aio=1) trace streaming (--affinity=node|cpu).
See OVERHEAD section below for more details.

Implemented extension provides users with capability to instruct Perf 
tool to bounce trace reading thread's affinity mask between NUMA nodes 
(--affinity=node) or assign the thread to the exact cpu (--affinity=cpu) 
that trace buffer being processed belongs to.

The extension brings improvement in case of full system utilization when 
Perf tool process contends with workload process on cpu cores. In case a 
system has free cores to execute Perf tool process during profiling the 
default system scheduling layout induces the lowest overhead.

The patch set has been validated on BT benchmark from NAS Parallel 
Benchmarks [2] running on dual socket, 44 cores, 88 hw threads Broadwell 
system with kernels v4.4-21-generic (Ubuntu 16.04) and v4.20.0-rc5 
(tip perf/core). 

OVERHEAD:
   BENCH REPORT BASED   ELAPSED TIME BASED
  v4.20.0-rc5 
  (tip perf/core):

(current) SERIAL-SYS  / BASE : 1.27x (14.37/11.31), 1.29x (15.19/11.69)
  SERIAL-NODE / BASE : 1.15x (13.04/11.31), 1.17x (13.79/11.69)
  SERIAL-CPU  / BASE : 1.00x (11.32/11.31), 1.01x (11.89/11.69)

  AIO1-SYS/ BASE : 1.29x (14.58/11.31), 1.29x (15.26/11.69)
  AIO1-NODE   / BASE : 1.08x (12.23/11.31), 1,11x (13.01/11.69)
  AIO1-CPU/ BASE : 1.07x (12.14/11.31), 1.08x (12.83/11.69)

  v4.4.0-21-generic
  (Ubuntu 16.04 LTS):

(current) SERIAL-SYS  / BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32)
  SERIAL-NODE / BASE : 1.19x (13.02/10.87), 1.23x (14.03/11.32)
  SERIAL-CPU  / BASE : 1.03x (11.21/10.87), 1.07x (12.18/11.32)

  AIO1-SYS/ BASE : 1.26x (13.73/10.87), 1.29x (14.69/11.32)
  AIO1-NODE   / BASE : 1.10x (12.04/10.87), 1.15x (13.03/11.32)
  AIO1-CPU/ BASE : 1.12x (12.20/10.87), 1.15x (13.09/11.32)

The patch set is generated for acme perf/core repository.

---
Alexey Budankov (4):
  perf record: allocate affinity masks
  perf record: bind the AIO user space buffers to nodes
  perf record: apply affinity masks when reading mmap buffers
  perf record: implement --affinity=node|cpu option

 tools/perf/Documentation/perf-record.txt |  5 ++
 tools/perf/builtin-record.c  | 40 ++-
 tools/perf/perf.h|  8 +++
 tools/perf/util/evlist.c | 10 ++--
 tools/perf/util/evlist.h |  2 +-
 tools/perf/util/mmap.c   | 63 +++-
 tools/perf/util/mmap.h   |  4 +-
 7 files changed, 124 insertions(+), 8 deletions(-)

---
Changes in v2:
- made debug affinity mode message user friendly
- converted affinity mode defines to enum values
- implemented perf_mmap__aio_alloc, perf_mmap__aio_free, perf_mmap__aio_bind 
  and put HAVE_LIBNUMA_SUPPORT #ifdefs in there
- separated AIO buffers binding to patch 2/4

---
[1] https://en.wikipedia.org/wiki/Non-uniform_memory_access
[2] https://www.nas.nasa.gov/publications/npb.html
[3] http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html
[4] http://man7.org/linux/man-pages/man2/mbind.2.html

---
ENVIRONMENT AND MEASUREMENTS:

  MACHINE:

broadwell, dual socket, 44 core, 88 threads

/proc/cpuinfo

processor   : 87
vendor_id   : GenuineIntel
cpu family  : 6
model   : 79
model name  : Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
stepping: 1
microcode   : 0xb19
cpu MHz : 1200.117
cache size  : 56320 KB
physical id : 1
siblings: 44
core id : 28
cpu cores   : 22
apicid  : 121
initial apicid  : 121
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 

Re: [PATCH v1 2/3] perf record: apply affinity masks when reading mmap buffers

[Alexey Budankov]

Hi,
On 12.12.2018 15:15, Jiri Olsa wrote:
> On Wed, Dec 12, 2018 at 10:40:22AM +0300, Alexey Budankov wrote:
>>
>> Build node cpu masks for mmap data buffers. Bind AIO data buffers
>> to nodes according to kernel data buffers location. Apply node cpu
>> masks to trace reading thread every time it references memory cross
>> node or cross cpu.
>>
>> Signed-off-by: Alexey Budankov 
>> ---
>>  tools/perf/builtin-record.c |  9 +
>>  tools/perf/util/evlist.c|  6 +-
>>  tools/perf/util/mmap.c  | 38 -
>>  tools/perf/util/mmap.h  |  1 +
>>  4 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 4979719e54ae..1a1438c73f96 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -532,6 +532,9 @@ static int record__mmap_evlist(struct record *rec,
>>  struct record_opts *opts = >opts;
>>  char msg[512];
>>  
>> +if (opts->affinity != PERF_AFFINITY_SYS)
>> +cpu__setup_cpunode_map();
>> +
>>  if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
>>   opts->auxtrace_mmap_pages,
>>   opts->auxtrace_snapshot_mode,
>> @@ -751,6 +754,12 @@ static int record__mmap_read_evlist(struct record *rec, 
>> struct perf_evlist *evli
>>  struct perf_mmap *map = [i];
>>  
>>  if (map->base) {
>> +if (rec->opts.affinity != PERF_AFFINITY_SYS &&
>> +!CPU_EQUAL(>affinity_mask, 
>> >affinity_mask)) {
>> +CPU_ZERO(>affinity_mask);
>> +CPU_OR(>affinity_mask, 
>> >affinity_mask, >affinity_mask);
>> +sched_setaffinity(0, 
>> sizeof(rec->affinity_mask), >affinity_mask);
>> +}
> 
> hum, so you change affinity every time you read different map?

That is what exactly happens when --affinity=cpu. With --affinity=node
thread affinity changes only when the thread gets mmap buffer allocated
at the remote node. For dual socket machine it is twice at max for one
loop execution.

> I'm surprised this is actualy faster..

Imagine that some app's thread running on cpu 0 of node 1 generates samples
into a kernel buffer which is also allocated at node 1. The tool thread 
running on cpu 0 of node 0 takes the buffer and puts some part of it into 
write syscall what can cause cross node memory move and induce collection 
overhead (from the kernel buffer into fs cache buffers executing some portion
of write syscall code on cpu 0 of node 0).

> 
> anyway this patch is doing 2 things.. binding the memory allocation
> to nodes and setting the process affinity, please seprate those and
> explain the logic behind

Separated in v2. Binding is implemented for AIO user space buffers only
to map them to the same nodes kernel buffers are mapped to. Tool thread 
affinity mask bouncing is implemented and applicable as for serial as
for AIO streaming. AIO streaming without binding can result in cross node 
memory moves from kernel buffers to AIO ones.

Thanks,
Alexey

> 
> thanks,
> jirka
> 

Re: [PATCH] proc/sysctl: don't return ENOMEM on lookup when a table is unregistering

[Al Viro]

On Wed, Dec 12, 2018 at 05:57:43PM -0800, Ivan Delalande wrote:
> proc_sys_lookup can fail with ENOMEM instead of ENOENT when the
> corresponding sysctl table is being unregistered. In our case we see
> this upon opening /proc/sys/net/*/conf files while network interfaces
> are being removed, which confuses our configuration daemon.
> 
> The problem was successfully reproduced and this fix tested on v4.9.122
> and v4.20-rc6.
> 
> Fixes: ace0c791e6c3 ("proc/sysctl: Don't grab i_lock under sysctl_lock.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ivan Delalande 
> ---
>  fs/proc/proc_sysctl.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index 89921a0d2ebb..834be5bc3d07 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -474,7 +474,7 @@ static struct inode *proc_sys_make_inode(struct 
> super_block *sb,
>   if (unlikely(head->unregistering)) {
>   spin_unlock(_lock);
>   iput(inode);
> - inode = NULL;
> + inode = ERR_PTR(-ENOENT);
>   goto out;
>   }
>   ei->sysctl = head;
> @@ -549,10 +549,11 @@ static struct dentry *proc_sys_lookup(struct inode 
> *dir, struct dentry *dentry,
>   goto out;
>   }
>  
> - err = ERR_PTR(-ENOMEM);
>   inode = proc_sys_make_inode(dir->i_sb, h ? h : head, p);
> - if (!inode)
> + if (IS_ERR_OR_NULL(inode)) {
> + err = inode ? ERR_CAST(inode) : ERR_PTR(-ENOMEM);

*gags*

If you want to return specific errors, do just that and for pity sake,
do *NOT* invent such hybrids.  "Pointer to object on success,
ERR_PTR(-E...) on failure, NULL means ERR_PTR(-ENOMEM)" is a bitch to
reason about and prone to breakage.

"Return NULL on error" and "return ERR_PTR() on error" do not mix.
Just make proc_sys_make_inode() return ERR_PTR(-ENOMEM) on allocation
failures and update the callers (as you have to, anyway).

IS_ERR_OR_NULL() is usually a sign of bad calling conventions and it
certainly is just that in this case.

Just do
inode = new_inode(sb);
if (!inode)
return ERR_PTR(-ENOMEM);
in there, in addition to your return of ERR_PTR(-ENOENT), and lose those
IS_ERR_OR_NULL() things.  Make those IS_ERR() and turn the assignment
to err into straight ERR_CAST().  All there is to it...

Re: [PATCH 0/2] Graph fixes for using multiple endpoints per port

[Peter Ujfalusi]

On 12/12/2018 16.50, Tony Lindgren wrote:
> * Peter Ujfalusi  [181212 13:03]:
>> On 12/12/2018 2.19, Tony Lindgren wrote:
>>> In my McBSP case there is only a single physical I2S port
>>> that can be TDM split into timeslots.
>>
>> So what is missing from the McBSP driver is to configure the TDM. We
>> never had a hardware which would require it so it is _not_ implemented.
> 
> Curiously.. Nothing needs to be done in the McBSP driver for the droid
> 4 TDM configuration AFAIK.

So you always have 4 timeslot and that's it?

> The CPCAP PMIC is the clock master, and only the PMIC registers need to
> be configured in this case for the timeslot to switch between codecs
> connected to McBSP3.

The McBSP TDM configuration is not master only.
You basically tell McBSP on which timeslot to transmit/receive.
Let's say you have two codecs connected to a single McBSP.
codec1 is configured to listen for timeslot 0/1
codec2 is configured to listen for timeslot 2/3

If you open a stereo stream to codec1 then you tell McBSP to
send/receive the data under timeslot 0/1 and ignore any other timeslots.

If you open a stereo stream to codec2 then you tell McBSP to
send/receive the data under timeslot 2/3 and ignore any other timeslots.

For codec1 you don't really need anything regarding to TDM configuration
as McBSP will send/receive right after the start condition on the FS,
but for codec2 you need to configure the TDM mode of McBSP to ignore
timeslot 0/1

>> imho the 'only' thing is to implement the set_tdm_slot callback for the
>> McBSP DAI. In DT you would have single card with two dai_link section
>> and each section would set different tdm slots to use for the codecs
>> listening on different slots.
>>
>> There is one issue for sure with this setup: the two PCM can not be used
>> at the same time. But we have one DMA channel so if you would open both
>> the PCM stream need to be set up in a way to match with the HW or create
>> a asound.conf file to do some mapping.
> 
> Yes in the droid 4 TDM case only one device can be used at a time
> and all that configuration is done in the PMIC codec .set_tdm_slot
> function.

Hrm, do you have two DAIs on the PMIC side or different timeslots from
the TDM stream is routed to different outputs, similarly to twl6040
where timeslot 0/1 is Headset, timeslot 2/3 is Handsfree and timeslot 5
is to drive a vibra?

> I think it's possible to do more complex configurations where McBSP
> is the master and would implement a .set_tdm_slot function. But I
> don't know anything about that and I'm not aware of any such use
> cases in the mainline kernel.

No, the set_tdm_slot is applicable for both master and slave mode of McBSP.

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 4/9] arm64: defconfig: Drop USB_ULPI_BUS and USB_CHIPIDEA_ULPI

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:02:18AM +0100, Marc Gonzalez wrote:
> Commit a930d8bd94d8 ("usb: chipidea: Always build ULPI code") made
> USB_CHIPIDEA select USB_ULPI_BUS, and removed USB_CHIPIDEA_ULPI.
> 
> Reviewed-by: Fabio Estevam 
> Signed-off-by: Marc Gonzalez 

This one is the same as some of the others; it had already dropped off with the
refresh.


-Olof

Re: [PATCH v3 3/9] arm64: defconfig: Drop NF_CONNTRACK_IPV{4,6}

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:01:13AM +0100, Marc Gonzalez wrote:
> Commit a0ae2562c6c4 ("netfilter: conntrack: remove l3proto abstraction")
> folded NF_CONNTRACK_IPV4 and NF_CONNTRACK_IPV6 into NF_CONNTRACK.
> 
> Signed-off-by: Marc Gonzalez 

Same here, this one is no longer needed either.

-Olof

Re: [PATCH v3 6/9] arm64: defconfig: Drop redundant SND_SOC_ROCKCHIP_I2S

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:03:55AM +0100, Marc Gonzalez wrote:
> SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_ROCKCHIP_I2S
> 
> Signed-off-by: Marc Gonzalez 
> ---
>  arch/arm64/configs/defconfig | 1 -
>  1 file changed, 1 deletion(-)

This one got covered by patch 1 too.


-Olof

Re: [PATCH v3 8/9] arm64: defconfig: Change SCSI_UFS_HISI=m

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:08:07AM +0100, Marc Gonzalez wrote:
> SCSI_UFS_HISI depends on SCSI_UFSHCD_PLATFORM=m
> 
> Signed-off-by: Marc Gonzalez 
> ---
>  arch/arm64/configs/defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Another one that got covered by patch 1.


-Olof

Re: [PATCH v3 5/9] arm64: defconfig: Replace PINCTRL_MT7622 with PINCTRL_MTK_MOORE

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:03:20AM +0100, Marc Gonzalez wrote:
> Commit e78d57b2f87c ("pinctrl: mediatek: add pinctrl-moore that
> implements the generic pinctrl dt-bindings") made PINCTRL_MT7622
> depend on PINCTRL_MTK_MOORE.
> 
> Signed-off-by: Marc Gonzalez 

Applied, needed touchups.


-Olof

Re: [PATCH v3 7/9] arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO

[Olof Johansson]

On Fri, Nov 09, 2018 at 06:05:24AM +, Horia Geanta wrote:
> On 11/9/2018 3:11 AM, Marc Gonzalez wrote:
> > Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
> > enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
> > which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
> > CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
> > 
> > Signed-off-by: Marc Gonzalez 
> Reviewed-by: Horia Geantă 

I had to redo this one, and when I did I noticed that there's also an ethernet
driver. Should that be enabled as well?


-Olof

Re: [PATCH v3 9/9] arm64: defconfig: Drop redundant sound codec options

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:08:41AM +0100, Marc Gonzalez wrote:
> SND_SOC_RK3399_GRU_SOUND selects SND_SOC_DA7219, SND_SOC_MAX98357A,
> SND_SOC_RT5514, SND_SOC_RT5514_SPI.
> 
> SND_SOC_ROCKCHIP_RT5645 selects SND_SOC_RT5645.
> 
> SND_SOC_RL6231 is pulled in for SND_SOC_RT5514 and SND_SOC_RT5645.
> 
> Signed-off-by: Marc Gonzalez 
> ---
>  arch/arm64/configs/defconfig | 6 --
>  1 file changed, 6 deletions(-)

Also covered by patch 1.


-Olof

Re: [PATCH v3 0/9] Regenerate arm64 defconfig for current kernel

[Olof Johansson]

On Tue, Dec 11, 2018 at 07:41:59AM -0800, Olof Johansson wrote:
> On Wed, Dec 05, 2018 at 04:33:37PM +0100, Marc Gonzalez wrote:
> > On 09/11/2018 01:54, Marc Gonzalez wrote:
> > 
> > > Hello ARM maintainers,
> > > 
> > > v3: Keep CRYPTO_DEV_FSL_DPAA2_CAAM in patch 7/9
> > > 
> > > v2: Improve commit message for a few patches
> > > 
> > > The set of Kconfig options slowly changes with every kernel version.
> > > This patch series regenerates the arm64 defconfig for v4.20
> > > No functional change intended, except adding PINCTRL_MTK_MOORE to
> > > keep PINCTRL_MT7622, and adding FSL_MC_BUS and FSL_MC_DPIO to
> > > keep CRYPTO_DEV_FSL_DPAA2_CAAM.
> > > 
> > > Marc Gonzalez (9):
> > >   arm64: defconfig: Regenerate for v4.20
> > >   arm64: defconfig: Drop ARM_BIG_LITTLE_CPUFREQ
> > >   arm64: defconfig: Drop NF_CONNTRACK_IPV{4,6}
> > >   arm64: defconfig: Drop USB_ULPI_BUS and USB_CHIPIDEA_ULPI
> > >   arm64: defconfig: Replace PINCTRL_MT7622 with PINCTRL_MTK_MOORE
> > >   arm64: defconfig: Drop redundant SND_SOC_ROCKCHIP_I2S
> > >   arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO
> > >   arm64: defconfig: Change SCSI_UFS_HISI=m
> > >   arm64: defconfig: Drop redundant sound codec options
> > > 
> > >  arch/arm64/configs/defconfig | 108 
> > > ---
> > >  1 file changed, 49 insertions(+), 59 deletions(-)
> > 
> > Arnd, Olof,
> > 
> > Would you take this series for 4.21-rc1?
> 
> Hi,
> 
> Yeah, I'm happy to look at applying it but will do it towards the end of the
> staging of new contents so we don't get too much conflicts with pull requests
> that come in.

I've applied the patches from the series that were still needed. When
re-running savedefconfig as part of patch 1, several of them were no longer
applicable.


-Olof

Re: [PATCH v3 2/9] arm64: defconfig: Drop ARM_BIG_LITTLE_CPUFREQ

[Olof Johansson]

On Fri, Nov 09, 2018 at 02:00:28AM +0100, Marc Gonzalez wrote:
> Commit a7314405d83c ("drop ARM_BIG_LITTLE_CPUFREQ support for ARM64")
> dropped ARM_BIG_LITTLE_CPUFREQ support for ARM64, so remove it from
> the defconfig.
> 
> Acked-by: Viresh Kumar 
> Acked-by: Sudeep Holla 
> Acked-by: Mark Rutland 
> Signed-off-by: Marc Gonzalez 

No longer needed since patch 1 dropped it.


-Olof

Re: [PATCH v3 1/9] arm64: defconfig: Regenerate for v4.20

[Olof Johansson]

On Fri, Nov 09, 2018 at 01:56:44AM +0100, Marc Gonzalez wrote:
> Run the platform defconfig through kbuild, and handle the trivial case
> where options merely move around.
> 
> Signed-off-by: Marc Gonzalez 

Applied, which in reality meant that I had to redo what you did and commit
that, but that's fine. :)


-Olof

linux-next: Tree for Dec 13

[Stephen Rothwell]

Hi all,

Changes since 20181212:

The rdma tree still had its build failure so I used a supplied patch.

The akpm-current tree gained a conflict aaginst the arm64 tree.

Non-merge commits (relative to Linus' tree): 8282
 8923 files changed, 382977 insertions(+), 220160 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 288 trees (counting Linus' and 68 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f5d582777bcb Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid)
Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs)
Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2)
Merging arc-current/for-curr (4c567a448b30 ARC: perf: remove useless ifdefs)
Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential 
uninitialized return)
Merging arm64-fixes/for-next/fixes (b4aecf78083d arm64: hibernate: Avoid 
sending cross-calling with interrupts disabled)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (a225f1567405 powerpc/ptrace: replace 
ptrace_report_syscall() with a tracehook call)
Merging sparc/master (cf76c364a1e1 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (ee28b30cbbe0 r8169: fix crash if CONFIG_DEBUG_SHIRQ is 
enabled)
Merging bpf/master (fdadd04931c2 bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 
64K)
Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on 
acquire)
Merging netfilter/master (530aad77010b netfilter: seqadj: re-load tcp header 
pointer after possible head reallocation)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4)
Merging mac80211/master (312ca38ddda6 cfg80211: Fix busy loop regression in 
ieee80211_ie_split_ric())
Merging rdma-fixes/for-rc (47f07f03b5ee IB/mlx5: Block DEVX umem from the non 
applicable cases)
Merging sound-current/for-linus (0bea4cc83835 ALSA: hda/realtek: Enable audio 
jacks of ASUS UX433FN/UX333FA with ALC294)
Merging sound-asoc-fixes/for-linus (043eb516967a Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3)
Merging regulator-fixes/for-linus (4fa0d5751846 Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (47080fe1623c Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (b07b864ee423 Revert "PCI/ASPM: Do not initialize 
link state when aspm_disabled is set")
Merging driver-core.current/driver-core-linus (2595646791c3 Linux 4.20-rc5)
Merging tty.current/tty-linus (40e020c129cf Linux 4.20-rc6)
Merging usb.current/usb-linus (40e020c129cf Linux 4.20-rc6)
Merging usb-gadget-fixes/fixes (069caf5950df USB: omap_udc: fix rejection of 
out transfers when DMA is used)
Merging usb-serial-fixes/usb-linus (cc6730df08a2 USB: serial: option: add 
Simcom SIM7500/SIM7600 (MBIM mode))
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (c88520db18ba phy: qcom-qusb2: Fix HSTX_TRIM tu

Re: [PATCH] opp: Add API for getting voltage from supplies

[Viresh Kumar]

On 10-12-18, 20:36, Nick Fan wrote:
> For the users who only use one supply, they can use
> dev_pm_opp_get_voltage to get the voltage data from an opp.
> But if the users who use more than one supply, they will need this API
> to get their voltage data from OPP.
> The users should know about the supply count while creating opp table by
> using dev_pm_opp_set_regulators function.
> By using this API, the users can get the voltages by using index to
> specify which supplies they want.
> 
> The following is a simple example to get multiple regulators by this
> API.
> for (i = 0; i < regulator_num; i++)
>   target_volt[i] = dev_pm_opp_get_voltage_supply(opp, i);

Fair enough. I couldn't find anything wrong with the patch. Will it be
possible to send this patch as part of a series which uses the new API
? So that we are sure of somebody using it eventually.

-- 
viresh

Re: [PATCH] PCI: imx: make msi work without pcieportbus

[Baruch Siach]

Hi Richard,

Thanks for debugging this issue. One question below.

Richard Zhu writes:
> MSI_EN of iMX PCIe RC would be asserted when
> PCIEPORTBUS driver is selected.
> Thus, the MSI works fine on iMX PCIe before.
> Make a double check on this bit, and assert it
> when it is not set and MSI is supported.
> Otherwise, the MSI wouldn't be triggered although
> the EP is present and the MSIs are assigned.
>
> Signed-off-by: Richard Zhu 
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 26087b3..6c3e56b 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -74,6 +74,7 @@ struct imx6_pcie {
>  #define PHY_PLL_LOCK_WAIT_USLEEP_MAX 200
>  
>  /* PCIe Root Complex registers (memory-mapped) */
> +#define PCI_MSI_CAP  0x50
>  #define PCIE_RC_LCR  0x7c
>  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1 0x1
>  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2 0x2
> @@ -926,6 +927,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>   struct resource *dbi_base;
>   struct device_node *node = dev->of_node;
>   int ret;
> + u16 val;
>  
>   imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
>   if (!imx6_pcie)
> @@ -1070,6 +1072,14 @@ static int imx6_pcie_probe(struct platform_device 
> *pdev)
>   ret = imx6_add_pcie_port(imx6_pcie, pdev);
>   if (ret < 0)
>   return ret;
> + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> + val = dw_pcie_readw_dbi(pci, PCI_MSI_CAP + PCI_MSI_FLAGS);
> + if ((val & PCI_MSI_FLAGS_ENABLE) == 0) {
> + val |= PCI_MSI_FLAGS_ENABLE;

Why not assert the PCI_MSI_FLAGS_ENABLE flag unconditionally here?

> + dw_pcie_writew_dbi(pci, PCI_MSI_CAP +
> + PCI_MSI_FLAGS, val);
> + }
> + }
>  
>   return 0;
>  }

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH] Export mm_update_next_owner function for vhost-net

[Jason Wang]

On 2018/12/13 下午12:47, gchen.guo...@gmail.com wrote:

From: guomin chen 

  Under normal circumstances,When do_exit exits, mm->owner will
  be updated on exit_mm(). but when the kernel process calls
  unuse_mm() and then exits,mm->owner cannot be updated. And it
  will point to a task that has been released.

  Below is my issue on vhost_net:
 A, B are two kernel processes(such as vhost_worker),
 C is a user space process(such as qemu), and all
 three use the mm of the user process C.
 Now, because user process C exits abnormally, the owner of this
 mm becomes A. When A calls unuse_mm and exits, this mm->ower
 still points to the A that has been released.
 When B accesses this mm->owner again, A has been released.



Could you describe how you reproduce this issue? I believe vhost process 
should exit before process C?





  Process A Process B
  vhost_worker()vhost_worker()
   - -
   use_mm()  use_mm()
...
   unuse_mm()
  tsk->mm=NULL
do_exit()page fault
 exit_mm()   access mm->owner
can't update owner   kernel Oops

 unuse_mm()

Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: "Eric W. Biederman" 
Cc: Andrew Morton 
Cc: Sudip Mukherjee 
Cc: "Luis R. Rodriguez" 
Cc: Dominik Brodowski 
Signed-off-by: guomin chen 
---
  drivers/vhost/vhost.c | 1 +
  kernel/exit.c | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 6b98d8e..7c09087 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -368,6 +368,7 @@ static int vhost_worker(void *data)
}
}
unuse_mm(dev->mm);
+   mm_update_next_owner(dev->mm);



If you analysis is correct, this is still racy isn't it? (E.g page fault 
happen between unuse_mm() and mm_update_next_owner()).


Thanks



set_fs(oldfs);
return 0;
  }
diff --git a/kernel/exit.c b/kernel/exit.c
index 0e21e6d..9e046dd 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -486,6 +486,7 @@ void mm_update_next_owner(struct mm_struct *mm)
task_unlock(c);
put_task_struct(c);
  }
+EXPORT_SYMBOL(mm_update_next_owner);
  #endif /* CONFIG_MEMCG */
  
  /*

Re: [f2fs-dev] [PATCH] f2fs: add an ioctl() to explicitly trigger fsck later

[Chao Yu]

On 2018/12/13 11:56, Jaegeuk Kim wrote:
> On 12/07, Chao Yu wrote:
>> On 2018/12/1 4:36, Jaegeuk Kim wrote:
>>> On 11/30, Chao Yu wrote:
 On 2018/11/29 9:52, Jaegeuk Kim wrote:
> This adds an option in ioctl(F2FS_IOC_SHUTDOWN) in order to trigger fsck 
> by
> setting a NEED_FSCK flag.
>
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h | 1 +
>  fs/f2fs/file.c | 7 +++
>  2 files changed, 8 insertions(+)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index aa500239baf2..7cec897146a3 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -417,6 +417,7 @@ static inline bool __has_cursum_space(struct 
> f2fs_journal *journal,
>  #define F2FS_GOING_DOWN_METASYNC 0x1 /* going down with metadata */
>  #define F2FS_GOING_DOWN_NOSYNC   0x2 /* going down */
>  #define F2FS_GOING_DOWN_METAFLUSH0x3 /* going down with meta 
> flush */
> +#define F2FS_GOING_DOWN_NEED_FSCK0x4 /* going down to 
> trigger fsck */

 Why not add a new ioctl interface for this? F2FS_GOING_DOWN_ prefix implies
 filesystem will shutdown, IMO, we'd better to keep all sub-interfaces being
 consistent in f2fs_ioc_shutdown().
>>>
>>> I'm thinking to use this for QA as device shutdown tests.
>>>

>  
>  #if defined(__KERNEL__) && defined(CONFIG_COMPAT)
>  /*
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index ff82350a2c55..ca9bdbb8651b 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1966,6 +1966,13 @@ static int f2fs_ioc_shutdown(struct file *filp, 
> unsigned long arg)
>   f2fs_stop_checkpoint(sbi, false);
>   set_sbi_flag(sbi, SBI_IS_SHUTDOWN);
>   break;
> + case F2FS_GOING_DOWN_NEED_FSCK:
> + set_sbi_flag(sbi, SBI_NEED_FSCK);
> + /* do checkpoint only */
> + ret = f2fs_sync_fs(sb, 1);
> + if (ret)
> + goto out;

 In large-sized image, it may take long time to trigger full scan during
 boot, so I'd like to ask how often we set this flag?
>>>
>>> Based on the use of shutdown ioctl, I'll use this for testing purpose, so it
>>> won't be used for regular cases.
>>
>> How about adding some commit messages or comments on
>> F2FS_GOING_DOWN_NEED_FSCK marco definition to give a bit hint for f2fs
>> developers to know the usage of the interface?
> 
> Done. :P
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev

Looks good to me now. ;)

Reviewed-by: Chao Yu 

Thanks,

> 
>>
>> Thanks,
>>
>>>

 Thanks,

> + break;
>   default:
>   ret = -EINVAL;
>   goto out;
>
>>>
>>> .
>>>
> 
> .
> 

Re: [PATCH v1 2/3] perf record: apply affinity masks when reading mmap buffers

[Alexey Budankov]

Hi,
On 12.12.2018 15:15, Jiri Olsa wrote:
> On Wed, Dec 12, 2018 at 10:40:22AM +0300, Alexey Budankov wrote:
> 
> SNIP
> 
>>  int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, 
>> int cpu)
>>  {
>> +int c, nr_cpus, node;
>>  /*
>>   * The last one will be done at perf_mmap__consume(), so that we
>>   * make sure we don't prevent tools from consuming every last event in
>> @@ -344,6 +369,17 @@ int perf_mmap__mmap(struct perf_mmap *map, struct 
>> mmap_params *mp, int fd, int c
>>  map->cpu = cpu;
>>  
>>  CPU_ZERO(>affinity_mask);
>> +if (mp->affinity == PERF_AFFINITY_NODE && cpu__max_node() > 1) {
>> +nr_cpus = cpu_map__nr(mp->cpu_map);
>> +node = cpu__get_node(map->cpu);
>> +for (c = 0; c < nr_cpus; c++) {
>> +if (cpu__get_node(c) == node) {
>> +CPU_SET(c, >affinity_mask);
>> +}
>> +}
>> +} else if (mp->affinity == PERF_AFFINITY_CPU) {
>> +CPU_SET(map->cpu, >affinity_mask);
>> +}
> 
> won't both of this end up in same mask?

For tested dual socket 44 core broadwell:

node 0  node 1
cpu mask0-21,44-65  22-43,66-87

For affinity=node map->affinity_mask is either [0-21,44-65] or [22-43,66-87].
For affinity=cpu  map->affinity_mask is [0] or [1] or [2] and so on.

Without affinity option set map->affinity_mask and record->affinity_mask are [].

Thanks,
Alexey

> 
> jirka
> 

Re: [PATCH v1 1/3] perf record: allocate affinity masks

[Alexey Budankov]

Hi,
On 12.12.2018 15:15, Jiri Olsa wrote:
> On Wed, Dec 12, 2018 at 10:38:23AM +0300, Alexey Budankov wrote:
>>
>> Allocate affinity option and masks for mmap data buffers and
>> record thread as well as initialize allocated objects.
>>
>> Signed-off-by: Alexey Budankov 
>> ---
>>  tools/perf/builtin-record.c | 11 ++-
>>  tools/perf/perf.h   |  5 +
>>  tools/perf/util/evlist.c|  6 +++---
>>  tools/perf/util/evlist.h|  2 +-
>>  tools/perf/util/mmap.c  |  2 ++
>>  tools/perf/util/mmap.h  |  3 ++-
>>  6 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 882285fb9f64..4979719e54ae 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -81,6 +81,7 @@ struct record {
>>  booltimestamp_boundary;
>>  struct switch_outputswitch_output;
>>  unsigned long long  samples;
>> +cpu_set_t   affinity_mask;
>>  };
>>  
>>  static volatile int auxtrace_record__snapshot_started;
>> @@ -533,7 +534,8 @@ static int record__mmap_evlist(struct record *rec,
>>  
>>  if (perf_evlist__mmap_ex(evlist, opts->mmap_pages,
>>   opts->auxtrace_mmap_pages,
>> - opts->auxtrace_snapshot_mode, 
>> opts->nr_cblocks) < 0) {
>> + opts->auxtrace_snapshot_mode,
>> + opts->nr_cblocks, opts->affinity) < 0) {
>>  if (errno == EPERM) {
>>  pr_err("Permission error mapping pages.\n"
>> "Consider increasing "
>> @@ -1980,6 +1982,9 @@ int cmd_record(int argc, const char **argv)
>>  # undef REASON
>>  #endif
>>  
>> +CPU_ZERO(>affinity_mask);
>> +rec->opts.affinity = PERF_AFFINITY_SYS;
>> +
>>  rec->evlist = perf_evlist__new();
>>  if (rec->evlist == NULL)
>>  return -ENOMEM;
>> @@ -2143,6 +2148,10 @@ int cmd_record(int argc, const char **argv)
>>  if (verbose > 0)
>>  pr_info("nr_cblocks: %d\n", rec->opts.nr_cblocks);
>>  
>> +pr_debug("affinity (UNSET:%d, NODE:%d, CPU:%d) = %d\n",
>> + PERF_AFFINITY_SYS, PERF_AFFINITY_NODE,
>> + PERF_AFFINITY_CPU, rec->opts.affinity);
> 
> please make this user friendly and display the actual string like 
> "UNSET/NODE/CPU"

Implemented in v2.

> 
>> +
>>  err = __cmd_record(, argc, argv);
>>  out:
>>  perf_evlist__delete(rec->evlist);
>> diff --git a/tools/perf/perf.h b/tools/perf/perf.h
>> index 388c6dd128b8..08e75815de2f 100644
>> --- a/tools/perf/perf.h
>> +++ b/tools/perf/perf.h
>> @@ -83,8 +83,13 @@ struct record_opts {
>>  clockid_tclockid;
>>  u64  clockid_res_ns;
>>  int  nr_cblocks;
>> +int  affinity;
>>  };
>>  
>> +#define PERF_AFFINITY_SYS  0
>> +#define PERF_AFFINITY_NODE 1
>> +#define PERF_AFFINITY_CPU  2
> 
> please put those to enum

Implemented in v2.

Thanks,
Alexey

> 
> thanks,
> jirka
> 

Re: [PATCH v1 2/3] perf record: apply affinity masks when reading mmap buffers

[Alexey Budankov]

Hi,
On 12.12.2018 15:14, Jiri Olsa wrote:
> On Wed, Dec 12, 2018 at 10:40:22AM +0300, Alexey Budankov wrote:
> 
> SNIP
> 
>> diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
>> index e68ba754a8e2..0d017ea85dcb 100644
>> --- a/tools/perf/util/mmap.c
>> +++ b/tools/perf/util/mmap.c
>> @@ -10,6 +10,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#ifdef HAVE_LIBNUMA_SUPPORT
>> +#include 
>> +#endif
>>  #include "debug.h"
>>  #include "event.h"
>>  #include "mmap.h"
>> @@ -177,11 +180,27 @@ static int perf_mmap__aio_mmap(struct perf_mmap *map, 
>> struct mmap_params *mp)
>>  }
>>  delta_max = sysconf(_SC_AIO_PRIO_DELTA_MAX);
>>  for (i = 0; i < map->aio.nr_cblocks; ++i) {
>> +#ifndef HAVE_LIBNUMA_SUPPORT
>>  map->aio.data[i] = malloc(perf_mmap__mmap_len(map));
>> +#else
>> +size_t mmap_len = perf_mmap__mmap_len(map);
>> +map->aio.data[i] = mmap(NULL, mmap_len,
>> +PROT_READ|PROT_WRITE, 
>> MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
>> +#endif
>>  if (!map->aio.data[i]) {
>>  pr_debug2("failed to allocate data buffer area, 
>> error %m");
>>  return -1;
>>  }
>> +#ifdef HAVE_LIBNUMA_SUPPORT
>> +if (mp->affinity != PERF_AFFINITY_SYS && 
>> cpu__max_node() > 1) {
>> +unsigned long node_mask = 1UL << 
>> cpu__get_node(map->cpu);
>> +if (mbind(map->aio.data[i], mmap_len, 
>> MPOL_BIND, _mask, 1, 0)) {
>> +pr_debug2("failed to bind [%p-%p] to 
>> node %d\n",
>> +  map->aio.data[i], 
>> map->aio.data[i] + mmap_len,
>> +  cpu__get_node(map->cpu));
>> +}
>> +}
>> +#endif
> 
> could you please do the same thing as we did for aio functions
> (like record__aio_mmap_read_sync) and provide functions for both
> #fidef cases?

Implemented perf_mmap__aio_alloc(),
perf_mmap__aio_free(),
perf_mmap__aio_bind() in v2.

Thanks,
Alexey

> 
> thanks,
> jirka
> 

[PATCH] tty: serial: don't do termios for BTIF

[Ryder Lee]

The MediaTek BTIF controller doesn't need to set termios so add
a new capability 'UART_CAP_NMOD' for the unsupported case.


Signed-off-by: Sean Wang 
Signed-off-by: Ryder Lee 
---
 drivers/tty/serial/8250/8250.h  | 1 +
 drivers/tty/serial/8250/8250_port.c | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index ebfb0bd..2b9ba39 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -80,6 +80,7 @@ struct serial8250_config {
 #define UART_CAP_MINI  (1 << 17)   /* Mini UART on BCM283X family lacks:
 * STOP PARITY EPAR SPAR WLEN5 WLEN6
 */
+#define UART_CAP_NMOD  (1 << 18)   /* UART doesn't do termios */
 
 #define UART_BUG_QUOT  (1 << 0)/* UART has buggy quot LSB */
 #define UART_BUG_TXEN  (1 << 1)/* UART has buggy TX IIR status */
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index c39482b..e4a69a0 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -297,7 +297,7 @@
.tx_loadsz  = 16,
.fcr= UART_FCR_ENABLE_FIFO |
  UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT,
-   .flags  = UART_CAP_FIFO,
+   .flags  = UART_CAP_FIFO | UART_CAP_NMOD,
},
[PORT_NPCM] = {
.name   = "Nuvoton 16550",
@@ -2663,6 +2663,11 @@ static unsigned int serial8250_get_baud_rate(struct 
uart_port *port,
unsigned long flags;
unsigned int baud, quot, frac = 0;
 
+   if (up->capabilities & UART_CAP_NMOD) {
+   termios->c_cflag = 0;
+   return;
+   }
+
if (up->capabilities & UART_CAP_MINI) {
termios->c_cflag &= ~(CSTOPB | PARENB | PARODD | CMSPAR);
if ((termios->c_cflag & CSIZE) == CS5 ||
-- 
1.9.1

[PATCH] PCI: imx: make msi work without pcieportbus

[Richard Zhu]

MSI_EN of iMX PCIe RC would be asserted when
PCIEPORTBUS driver is selected.
Thus, the MSI works fine on iMX PCIe before.
Make a double check on this bit, and assert it
when it is not set and MSI is supported.
Otherwise, the MSI wouldn't be triggered although
the EP is present and the MSIs are assigned.

Signed-off-by: Richard Zhu 
---
 drivers/pci/controller/dwc/pci-imx6.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 26087b3..6c3e56b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -74,6 +74,7 @@ struct imx6_pcie {
 #define PHY_PLL_LOCK_WAIT_USLEEP_MAX   200
 
 /* PCIe Root Complex registers (memory-mapped) */
+#define PCI_MSI_CAP0x50
 #define PCIE_RC_LCR0x7c
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1   0x1
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2   0x2
@@ -926,6 +927,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
struct resource *dbi_base;
struct device_node *node = dev->of_node;
int ret;
+   u16 val;
 
imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
if (!imx6_pcie)
@@ -1070,6 +1072,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
ret = imx6_add_pcie_port(imx6_pcie, pdev);
if (ret < 0)
return ret;
+   if (IS_ENABLED(CONFIG_PCI_MSI)) {
+   val = dw_pcie_readw_dbi(pci, PCI_MSI_CAP + PCI_MSI_FLAGS);
+   if ((val & PCI_MSI_FLAGS_ENABLE) == 0) {
+   val |= PCI_MSI_FLAGS_ENABLE;
+   dw_pcie_writew_dbi(pci, PCI_MSI_CAP +
+   PCI_MSI_FLAGS, val);
+   }
+   }
 
return 0;
 }
-- 
2.7.4

Re: [PATCH net] net: ipv4: do not handle duplicate fragments as overlapping

[Eric Dumazet]

On 12/12/2018 06:28 PM, Michal Kubecek wrote:
> Since commit 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping
> segments.") IPv4 reassembly code drops the whole queue whenever an
> overlapping fragment is received. However, the test is written in a way
> which detects duplicate fragments as overlapping so that in environments
> with many duplicate packets, fragmented packets may be undeliverable.
> 
> Add an extra test and for (potentially) duplicate fragment, only drop the
> new fragment rather than the whole queue. Only starting offset and length
> are checked, not the contents of the fragments as that would be too
> expensive.  Check for duplicity with last (tail) fragment first as in real
> life scenarios this should be the most frequent case and we would have to
> iterate through the whole "run" otherwise.
> 
> Fixes: 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping segments.")
> Signed-off-by: Michal Kubecek 
> ---
>  net/ipv4/ip_fragment.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> index aa0b22697998..f09e3683b209 100644
> --- a/net/ipv4/ip_fragment.c
> +++ b/net/ipv4/ip_fragment.c
> @@ -436,6 +436,10 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff 
> *skb)
>   ip4_frag_append_to_last_run(>q, skb);
>   else
>   ip4_frag_create_run(>q, skb);
> + } else if (offset == prev_tail->ip_defrag_offset &&
> +skb->len == prev_tail->len) {
> + /* potential duplicate of last fragment */
> + goto err;

What value is in @err variable at this point ?

Are you sure callers expect to receive -EINVAL ?



>   } else {
>   /* Binary search. Note that skb can become the first fragment,
>* but not the last (covered above).
> @@ -449,8 +453,16 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff 
> *skb)
>   else if (offset >= skb1->ip_defrag_offset +
>   FRAG_CB(skb1)->frag_run_len)
>   rbn = >rb_right;
> - else /* Found an overlap with skb1. */
> + else {
> + /* check for potential duplicate */
> + while (skb1 && skb1->ip_defrag_offset < offset)
> + skb1 = FRAG_CB(skb1)->next_frag;
> + if (skb1 && offset == skb1->ip_defrag_offset &&
> + skb->len == skb1->len)
> + goto err;

Maybe we should not care, if the node in the rbtree contains the range of this
incoming fragment, do not worry about finding if it is overlap or not ?

I am nervous about adding back a linear scan.

> + /* Found an overlap */
>   goto overlap;
> + }
>   } while (*rbn);
>   /* Here we have parent properly set, and rbn pointing to
>* one of its NULL left/right children. Insert skb.
> 

Thanks !

Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support

[kbuild test robot]

Hi Rafael,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc6 next-20181212]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rafael-David-Tinoco/mm-zsmalloc-c-Fix-zsmalloc-32-bit-PAE-support/20181211-020704
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips 

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

>> mm/zsmalloc.c:116:5: error: #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for 
>> this arch";
   #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
^
   In file included from include/linux/cache.h:5:0,
from arch/mips/include/asm/cpu-info.h:15,
from arch/mips/include/asm/cpu-features.h:13,
from arch/mips/include/asm/bitops.h:21,
from include/linux/bitops.h:19,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/module.h:9,
from mm/zsmalloc.c:33:
>> mm/zsmalloc.c:133:49: warning: right shift count is negative 
>> [-Wshift-count-negative]
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^
   include/uapi/linux/kernel.h:13:40: note: in definition of macro 
'__KERNEL_DIV_ROUND_UP'
#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   ^
>> mm/zsmalloc.c:133:2: note: in expansion of macro 'MAX'
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
 ^~~
>> mm/zsmalloc.c:151:59: note: in expansion of macro 'ZS_MIN_ALLOC_SIZE'
#define ZS_SIZE_CLASSES (DIV_ROUND_UP(ZS_MAX_ALLOC_SIZE - 
ZS_MIN_ALLOC_SIZE, \
  ^
>> mm/zsmalloc.c:256:32: note: in expansion of macro 'ZS_SIZE_CLASSES'
 struct size_class *size_class[ZS_SIZE_CLASSES];
   ^~~
>> mm/zsmalloc.c:133:49: warning: right shift count is negative 
>> [-Wshift-count-negative]
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^
   include/uapi/linux/kernel.h:13:40: note: in definition of macro 
'__KERNEL_DIV_ROUND_UP'
#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   ^
>> mm/zsmalloc.c:133:2: note: in expansion of macro 'MAX'
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
 ^~~
>> mm/zsmalloc.c:151:59: note: in expansion of macro 'ZS_MIN_ALLOC_SIZE'
#define ZS_SIZE_CLASSES (DIV_ROUND_UP(ZS_MAX_ALLOC_SIZE - 
ZS_MIN_ALLOC_SIZE, \
  ^
>> mm/zsmalloc.c:256:32: note: in expansion of macro 'ZS_SIZE_CLASSES'
 struct size_class *size_class[ZS_SIZE_CLASSES];
   ^~~
>> mm/zsmalloc.c:256:21: error: variably modified 'size_class' at file scope
 struct size_class *size_class[ZS_SIZE_CLASSES];
^~
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/module.h:9,
from mm/zsmalloc.c:33:
   mm/zsmalloc.c: In function 'get_size_class_index':
>> mm/zsmalloc.c:133:49: warning: right shift count is negative 
>> [-Wshift-count-negative]
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^
   include/linux/compiler.h:76:40: note: in definition of macro 'likely'
# define likely(x) __builtin_expect(!!(x), 1)
   ^
>> mm/zsmalloc.c:133:2: note: in expansion of macro 'MAX'
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
 ^~~
   mm/zsmalloc.c:543:20: note: in expansion of macro 'ZS_MIN_ALLOC_SIZE'
 if (likely(size > ZS_MIN_ALLOC_SIZE))
   ^
>> mm/zsmalloc.c:133:49: warning: right shift count is negative 
>> [-Wshift-count-negative]
 MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^
   include/linux/compiler.h:76:40: note: in definition o

[PATCH V6] iio: light: isl29018: add optional vcc regulator operation support

[Anson Huang]

The light sensor's power supply could be controlled by regulator
on some platforms, such as i.MX6Q-SABRESD board, the light sensor
isl29023's power supply is controlled by a GPIO fixed regulator,
need to make sure the regulator is enabled before any operation of
sensor, this patch adds optional vcc regulator operation support.

Signed-off-by: Anson Huang 
---
ChangeLog since V5:
Since the dt-binding doc states the power supply name is "vdd" and many 
dts files already using
"vcc" as the power supply name, althoug it does NOT match the datasheet 
which has "vdd", to make
it NOT breaking existing dtb files, just use "vcc" as the regulator 
name.
---
 drivers/iio/light/isl29018.c | 47 +---
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
index b45400f..76c3a48 100644
--- a/drivers/iio/light/isl29018.c
+++ b/drivers/iio/light/isl29018.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -95,6 +96,7 @@ struct isl29018_chip {
struct isl29018_scale   scale;
int prox_scheme;
boolsuspended;
+   struct regulator*vcc_reg;
 };
 
 static int isl29018_set_integration_time(struct isl29018_chip *chip,
@@ -735,6 +737,19 @@ static int isl29018_probe(struct i2c_client *client,
 
mutex_init(>lock);
 
+   chip->vcc_reg = devm_regulator_get_optional(>dev, "vcc");
+   if (!IS_ERR(chip->vcc_reg)) {
+   err = regulator_enable(chip->vcc_reg);
+   if (err) {
+   dev_err(>dev, "failed to enable VCC 
regulator\n");
+   return err;
+   }
+   } else {
+   err = PTR_ERR(chip->vcc_reg);
+   if (err != -ENODEV)
+   return err;
+   }
+
chip->type = dev_id;
chip->calibscale = 1;
chip->ucalibscale = 0;
@@ -747,12 +762,12 @@ static int isl29018_probe(struct i2c_client *client,
if (IS_ERR(chip->regmap)) {
err = PTR_ERR(chip->regmap);
dev_err(>dev, "regmap initialization fails: %d\n", err);
-   return err;
+   goto disable_regulator;
}
 
err = isl29018_chip_init(chip);
if (err)
-   return err;
+   goto disable_regulator;
 
indio_dev->info = isl29018_chip_info_tbl[dev_id].indio_info;
indio_dev->channels = isl29018_chip_info_tbl[dev_id].channels;
@@ -761,13 +776,22 @@ static int isl29018_probe(struct i2c_client *client,
indio_dev->dev.parent = >dev;
indio_dev->modes = INDIO_DIRECT_MODE;
 
-   return devm_iio_device_register(>dev, indio_dev);
+   err = devm_iio_device_register(>dev, indio_dev);
+   if (!err)
+   return 0;
+
+disable_regulator:
+   if (!IS_ERR(chip->vcc_reg))
+   regulator_disable(chip->vcc_reg);
+
+   return err;
 }
 
 #ifdef CONFIG_PM_SLEEP
 static int isl29018_suspend(struct device *dev)
 {
struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
+   int ret;
 
mutex_lock(>lock);
 
@@ -777,6 +801,14 @@ static int isl29018_suspend(struct device *dev)
 * So we do not have much to do here.
 */
chip->suspended = true;
+   if (!IS_ERR(chip->vcc_reg)) {
+   ret = regulator_disable(chip->vcc_reg);
+   if (ret) {
+   dev_err(dev, "failed to disable VCC regulator\n");
+   mutex_unlock(>lock);
+   return ret;
+   }
+   }
 
mutex_unlock(>lock);
 
@@ -790,6 +822,15 @@ static int isl29018_resume(struct device *dev)
 
mutex_lock(>lock);
 
+   if (!IS_ERR(chip->vcc_reg)) {
+   err = regulator_enable(chip->vcc_reg);
+   if (err) {
+   dev_err(dev, "failed to enable VCC regulator\n");
+   mutex_unlock(>lock);
+   return err;
+   }
+   }
+
err = isl29018_chip_init(chip);
if (!err)
chip->suspended = false;
-- 
2.7.4

Re: [PATCH v5 2/2] arm: dts: mt2712: add uart APDMA to device tree

[Yingjoe Chen]

On Tue, 2018-12-11 at 13:37 +0800, Long Cheng wrote:
> 1. add uart APDMA controller device node
> 2. add uart 0/1/2/3/4/5 DMA function
> 
> Signed-off-by: Long Cheng 
> ---
>  arch/arm64/boot/dts/mediatek/mt2712e.dtsi |   50 
> +
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> index 976d92a..a59728b 100644
> --- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> @@ -300,6 +300,9 @@
>   interrupts = ;
>   clocks = <_clk>, <_clk>;
>   clock-names = "baud", "bus";
> + dmas = < 10
> +  11>;
> + dma-names = "tx", "rx";
>   status = "disabled";
>   };
>  
> @@ -378,6 +381,38 @@
>   status = "disabled";
>   };
>  
> + apdma: dma-controller@11000400 {
> + compatible = "mediatek,mt2712-uart-dma",
> +  "mediatek,mt6577-uart-dma";

Sorting, please make sure this is before 

auxadc: adc@11001000 {


> + reg = <0 0x11000400 0 0x80>,
> +   <0 0x11000480 0 0x80>,
> +   <0 0x11000500 0 0x80>,
> +   <0 0x11000580 0 0x80>,
> +   <0 0x11000600 0 0x80>,
> +   <0 0x11000680 0 0x80>,
> +   <0 0x11000700 0 0x80>,
> +   <0 0x11000780 0 0x80>,
> +   <0 0x11000800 0 0x80>,
> +   <0 0x11000880 0 0x80>,
> +   <0 0x11000900 0 0x80>,
> +   <0 0x11000980 0 0x80>;
> + interrupts = ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ;
> + clocks = < CLK_PERI_AP_DMA>;
> + clock-names = "apdma";
> + #dma-cells = <1>;
> + };
> +
>   uart0: serial@11002000 {
>   compatible = "mediatek,mt2712-uart",
>"mediatek,mt6577-uart";
> @@ -385,6 +420,9 @@


...deleted

Re: [PATCH V2 1/1] device-dax: check for vma range while dax_mmap.

[Yi Zhang]

On 2018-12-10 at 16:10:31 -0800, Dan Williams wrote:
> On Tue, Aug 21, 2018 at 12:38 AM Yi Zhang  wrote:
> >
> > On 2018-08-20 at 12:50:31 -0700, Dave Jiang wrote:
> > >
> > >
> > > On 08/20/2018 10:53 AM, Verma, Vishal L wrote:
> > > >
> > > > On Mon, 2018-08-13 at 20:02 +0800, Zhang Yi wrote:
> > > >> This patch prevents a user mapping an illegal vma range that is larger
> > > >> than a dax device physical resource.
> > > >>
> > > >> When qemu maps the dax device for virtual nvdimm's backend device, the
> > > >> v-nvdimm label area is defined at the end of mapped range. By using an
> > > >> illegal size that exceeds the range of the device dax, it will trigger 
> > > >> a
> > > >> fault with qemu.
> > > >>
> > > >> Signed-off-by: Zhang Yi 
> > > >> ---
> > > >>  drivers/dax/device.c | 29 +
> > > >>  1 file changed, 29 insertions(+)
> > > >>
> > > >
> > > > Looks good to me:
> > > > Reviewed-by: Vishal Verma 
> > >
> > > Applied.
> > Thanks Dava and Vishal's kindly review. Thank you.
> 
> So, it turns out this patch did not get merged for 4.20. I fumbled it
> when returning from vacation. However, I'm not sure it is needed. As
> long as attempts to access the out-of-range capacity results in SIGBUS
> then the implementation is correct. This is similar to the case where
> a file is truncated after the vma is established. That size is
> validated at fault time.
The problem is that we didn't get the fault at we initial the mapping
until attempt to access it, then qemu will failed unexpect without any
output, I think is is better to mention user that we are starting at a 
illegal size, but not faulting at an uncertained time.
> 
> Could you be clearer about why this is a problem? The fault sounds
> like the correct result.
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host

[poza]

On 2018-12-12 11:16, Srinath Mannam wrote:

IPROC host has the limitation that it can use
only those address ranges given by dma-ranges
property as inbound address.
So that the memory address holes in dma-ranges
should be reserved to allocate as DMA address.

All such reserved addresses are created as resource
entries and add to dma_resv list of pci host bridge.

These dma reserve resources created by parsing
dma-ranges parameter.

Ex:
dma-ranges = < \
  0x4300 0x00 0x8000 0x00 0x8000 0x00 0x8000 \
  0x4300 0x08 0x 0x08 0x 0x08 0x \
  0x4300 0x80 0x 0x80 0x 0x40 0x>

In the above example of dma-ranges, memory address from
0x0 - 0x8000,
0x1 - 0x8,
0x10 - 0x80 and
0x100 - 0x.
are not allowed to use as inbound addresses.
So that we need to add these address range to dma_resv
list to reserve their IOVA address ranges.

Signed-off-by: Srinath Mannam 
---
 drivers/pci/controller/pcie-iproc.c | 49 
+

 1 file changed, 49 insertions(+)

diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index 3160e93..43e465a 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1154,25 +1154,74 @@ static int iproc_pcie_setup_ib(struct 
iproc_pcie *pcie,

return ret;
 }

+static int
+iproc_pcie_add_dma_resv_range(struct device *dev, struct list_head 
*resources,

+ uint64_t start, uint64_t end)
+{
+   struct resource *res;
+
+   res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
+   if (!res)
+   return -ENOMEM;
+
+   res->start = (resource_size_t)start;
+   res->end = (resource_size_t)end;
+   pci_add_resource_offset(resources, res, 0);
+
+   return 0;
+}
+
 static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie)
 {
+   struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
struct of_pci_range range;
struct of_pci_range_parser parser;
int ret;
+   uint64_t start, end;
+   LIST_HEAD(resources);

/* Get the dma-ranges from DT */
ret = of_pci_dma_range_parser_init(, pcie->dev->of_node);
if (ret)
return ret;

+   start = 0;
for_each_of_pci_range(, ) {
+   end = range.pci_addr;
+   /* dma-ranges list expected in sorted order */
+   if (end < start) {
+   ret = -EINVAL;
+   goto out;
+   }
/* Each range entry corresponds to an inbound mapping region */
ret = iproc_pcie_setup_ib(pcie, , IPROC_PCIE_IB_MAP_MEM);
if (ret)
return ret;
+
+   if (end - start) {
+   ret = iproc_pcie_add_dma_resv_range(pcie->dev,
+   ,
+   start, end);
+   if (ret)
+   goto out;
+   }
+   start = range.pci_addr + range.size;
}

+   end = ~0;

Hi Srinath,

this series is based on following patch sets.

https://lkml.org/lkml/2017/5/16/19
https://lkml.org/lkml/2017/5/16/23
https://lkml.org/lkml/2017/5/16/21,

some comments to be adapted from the patch-set I did.

end = ~0;
you should consider DMA_MASK, to see iproc controller is in 32 bit or 64 
bit system.

please check following code snippet.

if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+   reserve_iova(iovad, lo, hi);
+   }

Also if this controller is integrated to 64bit platform, but decide to 
restrict DMA to 32 bit for some reason, the code should address such 
scenarios.

so it is always safe to do

#define BITS_PER_BYTE 8
DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE)
so please use kernle macro to find the end of DMA region.


Also ideally according to SBSA v5

8.3 PCI Express device view of memory

Transactions from a PCI express device will either directly address the 
memory system of the base server system
or be presented to a SMMU for optional address translation and 
permission policing.
In systems that are compatible with level 3 or above of the SBSA, the 
addresses sent by PCI express devices
must be presented to the memory system or SMMU unmodified. In a system 
where the PCI express does not use
an SMMU, the PCI express devices have the same view of physical memory 
as the PEs. In a system with a
SMMU for PCI express there are no transformations to addresses being 
sent by PCI express devices before they

are presented as an input address to the SMMU.

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

[Stephen Rothwell]

Hi all,

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

  arch/arm64/mm/mmu.c

between commit:

  4ab215061554 ("arm64: Add memory hotplug support")

from the arm64 tree and commit:

  232619fcc076 ("lib/ioremap: ensure break-before-make is used for huge p4d 
mappings")

from the akpm-current 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 arch/arm64/mm/mmu.c
index da513a1facf4,cf9a26d3d7f5..
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@@ -1047,19 -1029,7 +1043,24 @@@ int pud_free_pmd_page(pud_t *pudp, unsi
return 1;
  }
  
 +#ifdef CONFIG_MEMORY_HOTPLUG
 +int arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
 +  bool want_memblock)
 +{
 +  int flags = 0;
 +
 +  if (rodata_full || debug_pagealloc_enabled())
 +  flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
 +
 +  __create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
 +   size, PAGE_KERNEL, pgd_pgtable_alloc, flags);
 +
 +  return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
 + altmap, want_memblock);
 +}
 +#endif
++
+ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
+ {
+   return 0;   /* Don't attempt a block mapping */
+ }


pgpFqWe1EeZO4.pgp
Description: OpenPGP digital signature

Re: [PATCH net V3 0/3] Fix various issue of vhost

[David Miller]

From: Jason Wang 
Date: Thu, 13 Dec 2018 10:53:36 +0800

> This series tries to fix various issues of vhost:
> 
> - Patch 1 adds a missing write barrier between used idx updating and
>   logging.
> - Patch 2-3 brings back the protection of device IOTLB through vq
>   mutex, this fixes possible use after free in device IOTLB entries.
> 
> Please consider them for -stable.
> 
> Thanks
> 
> Changes from V2:
> - drop dirty page fix and make it for net-next
> Changes from V1:
> - silent compiler warning for 32bit.
> - use mutex_trylock() on slowpath instead of mutex_lock() even on fast
>   path.

Series applied and queued up for -stable, thanks Jason.

Re: [PATCH] debugobjects: Move printk out of db lock critical sections

[Dmitry Safonov]

On Thu, 13 Dec 2018 at 05:19, Sergey Senozhatsky
 wrote:
>
> On (12/13/18 04:35), Dmitry Safonov wrote:
> > I've tried to review it and found minor issues like missed
> > debug_object_is_on_stack() for initializing already active object.
> >
> > But than I come to opinion that it's just generally unsafe:
> > debug_obj life-time is protected by bucket's spin_lock.
> > Check the conditions when free_object() is being called.
>
> I thought about it for a second, but couldn't figure out if this race
> was real.
>
> E.g. uart case - if there are two paths which concurrently free and
> access debug object, then the same race condition should exist for
> the xmit.buf page. debug object's lifespan should be the same as the
> lifespan of, ummm, whatever the thing that debug object is attached
> to? I'm surely missing something here.

I think the point of debugobjects is to reduce the damage caused
by an improper life-time of objects.

IIUC:
1. alloc_page()
2. dynamically allocate a workqueue on a new page
3. schedule some work
4. until the work has run free_page()

So, wroqueue fixup upon freeing should cancel the work TBD.

But maybe I've misunderstood something..
And it's 6 am in my timezone, I'll catch some sleep and
will glance this with some morning coffee.

Thanks,
 Dmitry

Re: linux-next: Signed-off-by missing for commits in the bpf-next tree

[Alexei Starovoitov]

On Thu, Dec 13, 2018 at 04:37:28PM +1100, Stephen Rothwell wrote:
> Hi Alexei,
> 
> On Wed, 12 Dec 2018 20:33:41 -0800 Alexei Starovoitov 
>  wrote:
> >
> > If Stephen's scripts can recognize SOB anywhere in the log then
> > --signoff can theoretically solve it.
> 
> My script just grabs all the Signed-off-by lines in the commit message.
> 
> > Unfortunately it's "Incompatible with the --interactive option"
> > So we have to do things manually
> > or fix scripts
> > or fix git.
> 
> My version (2.19.1 and 2.20.0) of git does not say it is incompatible
> with --interactive, so maybe the last is true :-)  It says:

Awesome! While 2.17.1 failed, 2.20.0 worked!

Re: [PATCH] net-next: stmmac: dwmac-mediatek: add module license info

[David Miller]

From: Biao Huang 
Date: Thu, 13 Dec 2018 10:41:37 +0800

> Add MODULE_LICENSE info to fix this:
> WARNING: modpost: missing MODULE_LICENSE() in 
> drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.o
> 
> Signed-off-by: Biao Huang 

Applied, thanks for fixing this properly.

Re: [PATCH net] net: ipv4: do not handle duplicate fragments as overlapping

[David Miller]

From: Michal Kubecek 
Date: Thu, 13 Dec 2018 03:28:00 +0100 (CET)

> Since commit 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping
> segments.") IPv4 reassembly code drops the whole queue whenever an
> overlapping fragment is received. However, the test is written in a way
> which detects duplicate fragments as overlapping so that in environments
> with many duplicate packets, fragmented packets may be undeliverable.
> 
> Add an extra test and for (potentially) duplicate fragment, only drop the
> new fragment rather than the whole queue. Only starting offset and length
> are checked, not the contents of the fragments as that would be too
> expensive.  Check for duplicity with last (tail) fragment first as in real
> life scenarios this should be the most frequent case and we would have to
> iterate through the whole "run" otherwise.
> 
> Fixes: 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping segments.")
> Signed-off-by: Michal Kubecek 

I'll give Eric a chance to review this, thanks Michal.

Re: [PATCH] arm64: invalidate TLB before turning MMU on

[Bhupesh Sharma]

Hi Qian Cai,

On Thu, Dec 13, 2018 at 10:53 AM Qian Cai  wrote:
>
> On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
> dump just hung. It has 4 threads on each core. Each 2-core share a same
> L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same
> L3 cache.
>
> It turned out that this was due to the TLB contained stale entries (or
> uninitialized junk which just happened to look valid) from the first
> kernel before turning the MMU on in the second kernel which caused this
> instruction hung,
>
> msr sctlr_el1, x0
>
> Signed-off-by: Qian Cai 
> ---
>  arch/arm64/kernel/head.S | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 4471f570a295..5196f3d729de 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -771,6 +771,10 @@ ENTRY(__enable_mmu)
> msr ttbr0_el1, x2   // load TTBR0
> msr ttbr1_el1, x1   // load TTBR1
> isb
> +   dsb nshst
> +   tlbivmalle1 // invalidate TLB
> +   dsb nsh
> +   isb

This will be executed both for the primary and kdump kernel, right? I
don't think we really want to invalidate the TLB when booting the
primary kernel.
It would be too slow and considering that we need to minimize boot
timings on embedded arm64 devices, I think it would not be a good
idea.

> msr sctlr_el1, x0
> isb
> /*
> --
> 2.17.2 (Apple Git-113)
>

Also did you check this issue I reported on the HPE apollo machines
some days back with the kdump kernel boot
.
Can you please confirm that you are not facing the same issue (as I
suspect from reading your earlier Bug Report) on the HPE apollo
machine. Also adding 'earlycon' to the bootargs being passed to the
kdump kernel you can see if you are able to atleast get some console
output from the kdump kernel.

Thanks,
Bhupesh

Re: [v7, PATCH 0/2] add Ethernet driver support for mt2712

[David Miller]

From: Biao Huang 
Date: Thu, 13 Dec 2018 09:56:11 +0800

> Changes in v7:
> Add MODULE_LICENSE info in driver.

Biao, I said I need a "fixup" patch, not the whole series again.

I've already applied your patches, and you need to send me a small
fix on top.

This shows that you are not generating your patches against my
net-next tree properly.  If you were, you would see that I applied
your changes already.

Re: [LKP] [tty] c96cf923a9: WARNING:possible_circular_locking_dependency_detected

[Sergey Senozhatsky]

On (12/12/18 10:07), Peter Zijlstra wrote:
> > +   uart_port_lock(state, flags);
> > +   xmit_buf = state->xmit.buf;
> > +   state->xmit.buf = NULL;
> > +   uart_port_unlock(uport, flags);
> > +
> > /*
> >  * Free the transmit buffer page.
> >  */
> > -   uart_port_lock(state, flags);
> > -   if (state->xmit.buf) {
> > -   free_page((unsigned long)state->xmit.buf);
> > -   state->xmit.buf = NULL;
> > -   }
> > -   uart_port_unlock(uport, flags);
> > +   if (xmit_buf)
> > +   free_page((unsigned long)xmit_buf);
> >  }
> 
> That looks sensible anyhow. One should strive to not do alloc or free
> under locks as much as possible anyway.

Right, good point.

-ss

Re: linux-next: Signed-off-by missing for commits in the bpf-next tree

[Stephen Rothwell]

Hi Alexei,

On Wed, 12 Dec 2018 20:33:41 -0800 Alexei Starovoitov 
 wrote:
>
> If Stephen's scripts can recognize SOB anywhere in the log then
> --signoff can theoretically solve it.

My script just grabs all the Signed-off-by lines in the commit message.

> Unfortunately it's "Incompatible with the --interactive option"
> So we have to do things manually
> or fix scripts
> or fix git.

My version (2.19.1 and 2.20.0) of git does not say it is incompatible
with --interactive, so maybe the last is true :-)  It says:

   Note that
   if --interactive is given then only commits marked to be picked,
   edited or reworded will have the trailer added.

-- 
Cheers,
Stephen Rothwell


pgp_mFWxZt5C4.pgp
Description: OpenPGP digital signature

Re: [PATCH] rtlwifi: Fix non-working BSS STA mode

[Kai Heng Feng]

> On Dec 13, 2018, at 08:35, Pkshih  wrote:
> 
> On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
>> Once BSS STA mode gets started, it can be scanned by other clients but
>> cannot entablish a connection.
>  ^^^ typo: establish
>> 
>> Turns out the set_bcn_reg() and its *_set_beacon_related_registers()
>> callbacks never get called so it has problem beaconing.
>> 
>> Enable the function in rtl_op_bss_info_changed() can make BSS STA mode
>> start to work.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>>  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
>> b/drivers/net/wireless/realtek/rtlwifi/core.c
>> index 4bf7967590ca..11d27a5cc576 100644
>> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
>> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
>> @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw
>> *hw,
>>   "BSS_CHANGED_BEACON_ENABLED\n");
>>  
>>  /*start hw beacon interrupt. */
>> -/*rtlpriv->cfg->ops->set_bcn_reg(hw); */
>> +rtlpriv->cfg->ops->set_bcn_reg(hw);
>>  mac->beacon_enabled = 1;
>>  rtlpriv->cfg->ops->update_interrupt_mask(hw,
>>  rtlpriv->cfg->maps
> 
> Which wifi chip do you use? And, please share your test scenario.

It’s Realtek 8723DE, which is currently not supported in mainline so I use 
rtl8723de in rtlwifi_new [1] to test it out.

The test scenario is simply enable hotspot through network manager, which uses 
wpa_supplicant to do the work.

[1] https://github.com/lwfinger/rtlwifi_new

Kai-Heng

> 
> Thanks
> 

[PATCH] arm64: invalidate TLB before turning MMU on

[Qian Cai]

On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
dump just hung. It has 4 threads on each core. Each 2-core share a same
L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same
L3 cache.

It turned out that this was due to the TLB contained stale entries (or
uninitialized junk which just happened to look valid) from the first
kernel before turning the MMU on in the second kernel which caused this
instruction hung,

msr sctlr_el1, x0

Signed-off-by: Qian Cai 
---
 arch/arm64/kernel/head.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4471f570a295..5196f3d729de 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -771,6 +771,10 @@ ENTRY(__enable_mmu)
msr ttbr0_el1, x2   // load TTBR0
msr ttbr1_el1, x1   // load TTBR1
isb
+   dsb nshst
+   tlbivmalle1 // invalidate TLB
+   dsb nsh
+   isb
msr sctlr_el1, x0
isb
/*
-- 
2.17.2 (Apple Git-113)

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

[Florian Weimer]

* Matthew Wilcox:

> On Wed, Dec 12, 2018 at 09:17:07AM +0100, Mickaël Salaün wrote:
>> The goal of this patch series is to control script interpretation.  A
>> new O_MAYEXEC flag used by sys_open() is added to enable userland script
>> interpreter to delegate to the kernel (and thus the system security
>> policy) the permission to interpret scripts or other files containing
>> what can be seen as commands.
>
> I don't have a problem with the concept, but we're running low on O_ bits.
> Does this have to be done before the process gets a file descriptor,
> or could we have a new syscall?  Since we're going to be changing the
> interpreters anyway, it doesn't seem like too much of an imposition to
> ask them to use:
>
>   int verify_for_exec(int fd)
>
> instead of adding an O_MAYEXEC.

Will this work for auditing?

Maybe add an interface which explicitly upgrades O_PATH descriptors, and
give that a separate flag argument?  I suppose that would be more
friendly to auditing.

Thanks,
Florian

Re: [PATCH] debugobjects: Move printk out of db lock critical sections

[Sergey Senozhatsky]

On (12/13/18 04:35), Dmitry Safonov wrote:
> I've tried to review it and found minor issues like missed
> debug_object_is_on_stack() for initializing already active object.
> 
> But than I come to opinion that it's just generally unsafe:
> debug_obj life-time is protected by bucket's spin_lock.
> Check the conditions when free_object() is being called.

I thought about it for a second, but couldn't figure out if this race
was real.

E.g. uart case - if there are two paths which concurrently free and
access debug object, then the same race condition should exist for
the xmit.buf page. debug object's lifespan should be the same as the
lifespan of, ummm, whatever the thing that debug object is attached
to? I'm surely missing something here.

-ss

[PATCH v3] mm: thp: fix flags for pmd migration when split

[Peter Xu]

When splitting a huge migrating PMD, we'll transfer all the existing
PMD bits and apply them again onto the small PTEs.  However we are
fetching the bits unconditionally via pmd_soft_dirty(), pmd_write()
or pmd_yound() while actually they don't make sense at all when it's
a migration entry.  Fix them up.  Since at it, drop the ifdef together
as not needed.

Note that if my understanding is correct about the problem then if
without the patch there is chance to lose some of the dirty bits in
the migrating pmd pages (on x86_64 we're fetching bit 11 which is part
of swap offset instead of bit 2) and it could potentially corrupt the
memory of an userspace program which depends on the dirty bit.

CC: Andrea Arcangeli 
CC: Andrew Morton 
CC: "Kirill A. Shutemov" 
CC: Matthew Wilcox 
CC: Michal Hocko 
CC: Dave Jiang 
CC: "Aneesh Kumar K.V" 
CC: Souptick Joarder 
CC: Konstantin Khlebnikov 
CC: Zi Yan 
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Peter Xu 
---
v2:
- fix it up for young/write/dirty bits too [Konstantin]
v3:
- fetch write correctly for migration entry; drop macro [Konstantin]
---
 mm/huge_memory.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f2d19e4fe854..aebade83cec9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2145,23 +2145,25 @@ static void __split_huge_pmd_locked(struct 
vm_area_struct *vma, pmd_t *pmd,
 */
old_pmd = pmdp_invalidate(vma, haddr, pmd);
 
-#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
pmd_migration = is_pmd_migration_entry(old_pmd);
-   if (pmd_migration) {
+   if (unlikely(pmd_migration)) {
swp_entry_t entry;
 
entry = pmd_to_swp_entry(old_pmd);
page = pfn_to_page(swp_offset(entry));
-   } else
-#endif
+   write = is_write_migration_entry(entry);
+   young = false;
+   soft_dirty = pmd_swp_soft_dirty(old_pmd);
+   } else {
page = pmd_page(old_pmd);
+   if (pmd_dirty(old_pmd))
+   SetPageDirty(page);
+   write = pmd_write(old_pmd);
+   young = pmd_young(old_pmd);
+   soft_dirty = pmd_soft_dirty(old_pmd);
+   }
VM_BUG_ON_PAGE(!page_count(page), page);
page_ref_add(page, HPAGE_PMD_NR - 1);
-   if (pmd_dirty(old_pmd))
-   SetPageDirty(page);
-   write = pmd_write(old_pmd);
-   young = pmd_young(old_pmd);
-   soft_dirty = pmd_soft_dirty(old_pmd);
 
/*
 * Withdraw the table only after we mark the pmd entry invalid.
-- 
2.17.1

Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC

[Florian Weimer]

* James Morris:

> On Wed, 12 Dec 2018, Florian Weimer wrote:
>
>> * James Morris:
>> 
>> > If you're depending on the script interpreter to flag that the user may 
>> > execute code, this seems to be equivalent in security terms to depending 
>> > on the user.  e.g. what if the user uses ptrace and clears O_MAYEXEC?
>> 
>> The argument I've heard is this: Using ptrace (and adding the +x
>> attribute) are auditable events.
>
> I guess you could also preload a modified libc which strips the flag.

My understanding is that this new libc would have to come somewhere, and
making it executable would be an auditable even as well.

Thanks,
Florian

Re: [PATCH] serial: 8250: Fix clearing FIFOs in RS485 mode again

[Paul Burton]

Hi Marek,

On Thu, Dec 13, 2018 at 05:18:19AM +0100, Marek Vasut wrote:
> >>> I wonder whether the issue may be the JZ4780 UART not automatically
> >>> resetting the FIFOs when FCR[0] changes. This is a guess, but the manual
> >>> doesn't explicitly say it'll happen & the programming example it gives
> >>> says to explicitly clear the FIFOs using FCR[2:1]. Since this is what
> >>> the kernel has been doing for at least the whole git era I wouldn't be
> >>> surprised if other devices are bitten by the change as people start
> >>> trying 4.20 on them.
> >>
> >> The patch you're complaining about is doing exactly that -- it sets
> >> UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT in FCR , and then clears it.
> >> Those two bits are exactly FCR[2:1]. It also explicitly does not touch
> >> any other bits in FCR.
> > 
> > No - your patch does that *only* if the FIFO enable bit is set, and
> > presumes that clearing FIFOs is a no-op when they're disabled. I don't
> > believe that's true on my system. I also believe that not touching the
> > FIFO enable bit is problematic, since some callers clearly expect that
> > to be cleared.
> 
> Why would you disable FIFO to clear it ? This doesn't make sense to me,
> the FIFO must be operational for it to be cleared. Moreover, it
> contradicts your previous statement, "the programming example it gives
> says to explicitly clear the FIFOs using FCR[2:1]" .

No, no, not at all... I'm saying that my theory is:

  - The JZ4780 requires that the FIFO be reset using FCR[2:1] in order
to not read garbage.

  - Prior to your patch serial8250_clear_fifos() did this,
unconditionally.

  - After your patch serial8250_clear_fifos() only clears the FIFOs if
the FIFO is already enabled.

  - When called from serial8250_do_startup() during boot, the FIFO may
not be enabled - for example if the bootloader didn't use the FIFO,
or if the UART is used with 8250_early which zeroes FCR.

  - Therefore after your patch the FIFO reset bits are never set if the
UART was used with 8250_early, or if it wasn't but the bootloader
didn't enable the FIFO.

I suspect that you get away with that because according to the PC16550D
documentation the FIFOs should reset when the FIFO enable bit changes,
so when the FIFO is later enabled it gets reset. I suspect that in the
JZ4780 this does not happen, and the FIFO contains garbage. Our previous
behaviour (always set FCR[2:1] to reset the FIFO) has been around for a
long time, so I would not be surprised to find other devices relying
upon it.

I'm also saying that if the FIFOs are enabled during boot then your
patch will leave them enabled after serial8250_do_startup() calls
serial8250_clear_fifos(), which a comment in serial8250_do_startup()
clearly states is not the expected behaviour:

> Clear the FIFO buffers and disable them.
> (they will be reenabled in set_termios())

(From 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/8250/8250_port.c?h=v4.20-rc6#n2209)

And further, with your patch serial8250_do_shutdown() will leave the
FIFO enabled which again does not match what comments suggest it expects
("Disable break condition and FIFOs").

> What exactly does your programming example for the JZ4780 say about the
> FIFO clearing ? And does it work in that example ?

It says to set FCR[2:1] to reset the FIFO after enabling it, which as
far as I can tell from the PC16550D documentation would not be necessary
there because when you enable the FIFO it would automatically be reset.
Linux did this until your patch.

> >>> @@ -558,25 +558,26 @@ static void serial8250_clear_fifos(struct 
> >>> uart_8250_port *p)
> >>>   if (p->capabilities & UART_CAP_FIFO) {
> >>>   /*
> >>>* Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
> >>> -  * In case ENABLE_FIFO is not set, there is nothing to flush
> >>> -  * so just return. Furthermore, on certain implementations of
> >>> -  * the 8250 core, the FCR[7:3] bits may only be changed under
> >>> -  * specific conditions and changing them if those conditions
> >>> -  * are not met can have nasty side effects. One such core is
> >>> -  * the 8250-omap present in TI AM335x.
> >>> +  * On certain implementations of the 8250 core, the FCR[7:3]
> >>> +  * bits may only be changed under specific conditions and
> >>> +  * changing them if those conditions are not met can have nasty
> >>> +  * side effects. One such core is the 8250-omap present in TI
> >>> +  * AM335x.
> >>>*/
> >>>   fcr = serial_in(p, UART_FCR);
> >>> + serial_out(p, UART_FCR, fcr | clr_mask);
> >>> + serial_out(p, UART_FCR, fcr & ~clr);
> >>
> >> Note that, if I understand the patch correctly, this will _not_ restore
> >> the original (broken) behavior. The original behavior cleared the entire
> >> FCR at the end, which cleared even bits that were 

Re: working toolchain for c-sky

[Guenter Roeck]

On 12/11/18 11:33 PM, Guo Ren wrote:

On Tue, Dec 11, 2018 at 11:57:15AM -0800, Guenter Roeck wrote:

Hi,

can someone point me to a working c-sky toolchain ?

I tried several from https://github.com/c-sky/tools/, but they all fail
to build csky:defconfig with various error messages.


Try this:
https://gitlab.com/c-sky/buildroot/-/jobs/131973812/artifacts/browse/output/images/

See readme.txt for run.



Thanks, that helped.

It would really be useful if you could consider upstreaming the toolchain
code as fast as possible to enable third party toolchain builds (and tests).
Bitrot happens fast. csky images already fail to build in linux-next.

Guenter

Re: [PATCH] ASoC: simple-card: Dereference pointer for memcpy sizeof in asoc_simple_card_probe

[Nathan Chancellor]

On Thu, Dec 13, 2018 at 02:07:42PM +0900, Kuninori Morimoto wrote:
> 
> Hi Nathan
> 
> > sound/soc/generic/simple-card.c:462:6: warning: argument to 'sizeof' in
> > 'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
> > source; expected 'struct asoc_simple_dai' or an explicit length
> > [-Wsizeof-pointer-memaccess]
> > sizeof(priv->dai_props->cpu_dai));
> > ^~~~
> > sound/soc/generic/simple-card.c:464:6: warning: argument to 'sizeof' in
> > 'memcpy' call is the same pointer type 'struct asoc_simple_dai *' as the
> > source; expected 'struct asoc_simple_dai' or an explicit length
> > [-Wsizeof-pointer-memaccess]
> > sizeof(priv->dai_props->codec_dai));
> > ^~
> > 2 warnings generated.
> > 
> > Commit 4fb7f4df49d3 ("ASoC: simple-card: use cpu/codec pointer on
> > simple_dai_props") updated {cpu,codec}_dai to be pointers in struct
> > simple_dai_props but didn't update these locations to dereference the
> > pointers to get the proper size of their contents.
> > 
> > Signed-off-by: Nathan Chancellor 
> > ---
> >  sound/soc/generic/simple-card.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/sound/soc/generic/simple-card.c 
> > b/sound/soc/generic/simple-card.c
> > index 766123485d7c..d4738d3eb2f1 100644
> > --- a/sound/soc/generic/simple-card.c
> > +++ b/sound/soc/generic/simple-card.c
> > @@ -459,9 +459,9 @@ static int asoc_simple_card_probe(struct 
> > platform_device *pdev)
> > dai_link->dai_fmt   = cinfo->daifmt;
> > dai_link->init  = asoc_simple_card_dai_init;
> > memcpy(>dai_props->cpu_dai, >cpu_dai,
> > -   sizeof(priv->dai_props->cpu_dai));
> > +   sizeof(*priv->dai_props->cpu_dai));
> > memcpy(>dai_props->codec_dai, >codec_dai,
> > -   sizeof(priv->dai_props->codec_dai));
> > +   sizeof(*priv->dai_props->codec_dai));
> > }
> 
> Ahh.. yes, simple-card is supporting non DT case, too.
> Thank you for your patch.
> But, I think ">dai_props->codec_dai" need to fix, too.
> And it needs to point cpu_dai/codec_dai.
> Thank you for pointing it. I will fixup and post with your name.
> 
> Best regards
> ---
> Kuninori Morimoto

Sure, whatever you think is best, thank you for the quick response!

Nathan

Re: [PATCH] ASoC: simple-card: Dereference pointer for memcpy sizeof in asoc_simple_card_probe

[Kuninori Morimoto]

Re: Can we drop upstream Linux x32 support?

[Kevin Easton]

On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
...
> I can't say anything about the syscall interface. However, what I do know
> is that the weird combination of a 32-bit userland with a 64-bit kernel
> interface is sometimes causing issues. For example, application code usually
> expects things like time_t to be 32-bit on a 32-bit system. However, this
> isn't the case for x32 which is why code fails to build.

OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
had for four or five years at this point.

- Kevin

[PATCH] tty/serial: do not free trasnmit buffer page under port lock

[Sergey Senozhatsky]

LKP has hit yet another circular locking dependency between uart
console drivers and debugobjects [1]:

 CPU0CPU1

rhltable_init()
 __init_work()
  debug_object_init
 uart_shutdown()  /* db->lock */
  /* uart_port->lock */debug_print_object()
   free_page()  printk()
 call_console_drivers()
debug_check_no_obj_freed()/* uart_port->lock */
 /* db->lock */
  debug_print_object()

So there are two dependency chains:
uart_port->lock -> db->lock
And
db->lock -> uart_port->lock

This particular circular locking dependency can be addressed in several
ways:

a) One way would be to move debug_print_object() out of db->lock scope
   and, thus, break the db->lock -> uart_port->lock chain.
b) Another one would be to free() transmit buffer page out of db->lock
   in UART code; which is what this patch does.

It makes sense to apply a) and b) independently: there are too many things
going on behind free(), none of which depend on uart_port->lock.

The patch fixes transmit buffer page free() in uart_shutdown() and,
additionally, in uart_port_startup() (as was suggested by Dmitry Safonov).

[1] https://lore.kernel.org/lkml/20181211091154.GL23332@shao2-debian/T/#u
Signed-off-by: Sergey Senozhatsky 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Andrew Morton 
Cc: Peter Zijlstra 
Cc: Waiman Long 
Cc: Dmitry Safonov 
Cc: Steven Rostedt 
Cc: Petr Mladek 
---
 drivers/tty/serial/serial_core.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index c439a5a1e6c0..d4cca5bdaf1c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -205,10 +205,15 @@ static int uart_port_startup(struct tty_struct *tty, 
struct uart_state *state,
if (!state->xmit.buf) {
state->xmit.buf = (unsigned char *) page;
uart_circ_clear(>xmit);
+   uart_port_unlock(uport, flags);
} else {
+   uart_port_unlock(uport, flags);
+   /*
+* Do not free() the page under the port lock, see
+* uart_shutdown().
+*/
free_page(page);
}
-   uart_port_unlock(uport, flags);
 
retval = uport->ops->startup(uport);
if (retval == 0) {
@@ -268,6 +273,7 @@ static void uart_shutdown(struct tty_struct *tty, struct 
uart_state *state)
struct uart_port *uport = uart_port_check(state);
struct tty_port *port = >port;
unsigned long flags = 0;
+   char *xmit_buf = NULL;
 
/*
 * Set the TTY IO error marker
@@ -298,14 +304,18 @@ static void uart_shutdown(struct tty_struct *tty, struct 
uart_state *state)
tty_port_set_suspended(port, 0);
 
/*
-* Free the transmit buffer page.
+* Do not free() the transmit buffer page under the port lock since
+* this can create various circular locking scenarios. For instance,
+* console driver may need to allocate/free a debug object, which
+* can endup in printk() recursion.
 */
uart_port_lock(state, flags);
-   if (state->xmit.buf) {
-   free_page((unsigned long)state->xmit.buf);
-   state->xmit.buf = NULL;
-   }
+   xmit_buf = state->xmit.buf;
+   state->xmit.buf = NULL;
uart_port_unlock(uport, flags);
+
+   if (xmit_buf)
+   free_page((unsigned long)xmit_buf);
 }
 
 /**
-- 
2.20.0

Re: [PATCH RESEND v7 3/4] clk: meson: add sub MMC clock controller driver

[Jianxin Pan]

On 2018/12/12 0:59, Jerome Brunet wrote:
> On Tue, 2018-12-11 at 00:04 +0800, Jianxin Pan wrote:
>> From: Yixun Lan 
>>
[...]
>>  
>> +config COMMON_CLK_MMC_MESON
>> +tristate "Meson MMC Sub Clock Controller Driver"
>> +select MFD_SYSCON
>> +select COMMON_CLK_AMLOGIC
>> +select COMMON_CLK_AMLOGIC_AUDIO
> 
> No it is wrong for the mmc to select AUDIO clocks.
> If as a result of your patch sclk is needed for things, make the necessary
> change in the Makefile.
OK, I will add COMMON_CLK_AMLOGIC_SCLKDIV for sclk-div.
> 
[...]>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "clkc.h"
>> +#include "clkc-audio.h"
> 
> Again having audio in the mmc controller is wrong.
> Please make the necessary rework.
Yes, I will split out sclk-div.h from clkc-audio.h in the next version.
Thanks for your time.
> 
>> +
>> +/* clock ID used by internal driver */
>> +#define CLKID_MMC_MUX   0
>> +
>> +#define   SD_EMMC_CLOCK 0
>^
> why the multiple space here ? this looks odd
I will check the alignement  in the whole patchset and fix them, Thank you.
> 
>> +#define   CLK_DELAY_STEP_PS 200
> 
> Please keep thing aligned aligned consistently.
> 
>> +
>> +#define MUX_CLK_NUM_PARENTS 2
>> +#define MMC_MAX_CLKS5
>> +
>> +struct mmc_clkc_data {
>> +struct meson_clk_phase_delay_data   tx;
>> +struct meson_clk_phase_delay_data   rx;
> 
> Why use a tab above ?
OK
> 
>> +};
>> +
>> +static struct clk_regmap_mux_data mmc_clkc_mux_data = {
>> +.offset = SD_EMMC_CLOCK,
>> +.mask   = 0x3,
>> +.shift  = 6,
>> +};
>> +
>> +static const struct meson_sclk_div_data mmc_clkc_div_data = {
>> +.div = {
>> +.reg_off = SD_EMMC_CLOCK,
>> +.shift   = (0),
>> +.width   = (6),
> 
> Please remove the unncessary parenthesis
OK, I will remove them.
> 
>> +},
>> +.hi = {
>> +.width   = 0,
>> +},
> 
> structure is a static const, all non-list members will be zero
> drop the 
OK, I will remove it in the next version. 
> 
>> +.flags = CLK_DIVIDER_ONE_BASED,
>> +};
>> +
>> +static struct meson_clk_phase_data mmc_clkc_core_phase = {
>> +.ph = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 8,
>> +.width  = 2,
>> +}
>> +};
>> +
>> +static const struct mmc_clkc_data mmc_clkc_gx_data = {
>> +.tx = {
>> +.phase = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 10,
>> +.width  = 2,
>> +},
>> +.delay = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 16,
>> +.width  = 4,
>> +},
> 
> Again, an effort on alignement would appreciated, same below
OK, I will fix them.
> 
>> +.delay_step_ps  = CLK_DELAY_STEP_PS,
>> +},
>> +.rx = {
>> +.phase = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 12,
>> +.width  = 2,
>> +},
>> +.delay = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 20,
>> +.width  = 4,
>> +},
>> +.delay_step_ps  = CLK_DELAY_STEP_PS,
>> +},
>> +};
>> +
>> +static const struct mmc_clkc_data mmc_clkc_axg_data = {
>> +.tx = {
>> +.phase = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 10,
>> +.width  = 2,
>> +},
>> +.delay = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 16,
>> +.width  = 6,
>> +},
>> +.delay_step_ps  = CLK_DELAY_STEP_PS,
>> +},
>> +.rx = {
>> +.phase = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 12,
>> +.width  = 2,
>> +},
>> +.delay = {
>> +.reg_off= SD_EMMC_CLOCK,
>> +.shift  = 22,
>> +.width  = 6,
>> +},
>> +.delay_step_ps  = CLK_DELAY_STEP_PS,
>> +},
>> +};
>> +
>> +static const struct of_device_id mmc_clkc_match_table[] = {
>> +{
>> +.compatible = "amlogic,gx-mmc-clkc",
>> +.data   = _clkc_gx_data
>> +},
>> +{
>> +.compatible = "amlogic,axg-mmc-clkc",
>> +.data   = _clkc_axg_data
>> +},
>> +{}
>> +};
>> +MODULE_DEVICE_TABLE(of, mmc_clkc_match_table);
>> +
>> +static struct clk_regmap *
>> +mmc_clkc_register_clk(struct device *dev, struct regmap *map,
>> +  struct clk_init_data *init,
>> + 

[PATCH AUTOSEL 4.19 03/73] i2c: rcar: check bus state before reinitializing

[Sasha Levin]

From: Wolfram Sang 

[ Upstream commit 0b57436f15bf40e432487086c4f2d01fd3529393 ]

We should check the bus state before reinitializing the IP core.
Otherwise, the internal bus busy state which also tracks multi-master
activity is lost.

Credits go to the Renesas BSP team for suggesting this change.

Reported-by: Yoshihiro Shimoda 
Signed-off-by: Wolfram Sang 
Fixes: ae481cc13965 ("i2c: rcar: fix resume by always initializing registers 
before transfer")
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
---
 drivers/i2c/busses/i2c-rcar.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 4aa7dde876f3..254e6219e538 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -779,6 +779,11 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
 
pm_runtime_get_sync(dev);
 
+   /* Check bus state before init otherwise bus busy info will be lost */
+   ret = rcar_i2c_bus_barrier(priv);
+   if (ret < 0)
+   goto out;
+
/* Gen3 needs a reset before allowing RXDMA once */
if (priv->devtype == I2C_RCAR_GEN3) {
priv->flags |= ID_P_NO_RXDMA;
@@ -791,10 +796,6 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
 
rcar_i2c_init(priv);
 
-   ret = rcar_i2c_bus_barrier(priv);
-   if (ret < 0)
-   goto out;
-
for (i = 0; i < num; i++)
rcar_i2c_request_dma(priv, msgs + i);
 
-- 
2.19.1

[PATCH AUTOSEL 4.19 05/73] scsi: vmw_pscsi: Rearrange code to avoid multiple calls to free_irq during unload

[Sasha Levin]

From: Cathy Avery 

[ Upstream commit 02f425f811cefcc4d325d7a72272651e622dc97e ]

Currently pvscsi_remove calls free_irq more than once as
pvscsi_release_resources and __pvscsi_shutdown both call
pvscsi_shutdown_intr. This results in a 'Trying to free already-free IRQ'
warning and stack trace. To solve the problem pvscsi_shutdown_intr has been
moved out of pvscsi_release_resources.

Signed-off-by: Cathy Avery 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/vmw_pvscsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index 0cd947f78b5b..890b8aaf95e1 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -1202,8 +1202,6 @@ static void pvscsi_shutdown_intr(struct pvscsi_adapter 
*adapter)
 
 static void pvscsi_release_resources(struct pvscsi_adapter *adapter)
 {
-   pvscsi_shutdown_intr(adapter);
-
if (adapter->workqueue)
destroy_workqueue(adapter->workqueue);
 
@@ -1535,6 +1533,7 @@ static int pvscsi_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 out_reset_adapter:
ll_adapter_reset(adapter);
 out_release_resources:
+   pvscsi_shutdown_intr(adapter);
pvscsi_release_resources(adapter);
scsi_host_put(host);
 out_disable_device:
@@ -1543,6 +1542,7 @@ static int pvscsi_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
return error;
 
 out_release_resources_and_disable:
+   pvscsi_shutdown_intr(adapter);
pvscsi_release_resources(adapter);
goto out_disable_device;
 }
-- 
2.19.1

[PATCH AUTOSEL 4.19 08/73] net: ethernet: ave: Replace NET_IP_ALIGN with AVE_FRAME_HEADROOM

[Sasha Levin]

From: Kunihiko Hayashi 

[ Upstream commit 88113957ddb7b7d5451e28cd708c82ea7e63b097 ]

In commit 26a4676faa1a ("arm64: mm: define NET_IP_ALIGN to 0"),
AVE controller affects this modification because the controller forces
to ignore lower 2bits of buffer start address, and make 2-byte headroom,
that is, data reception starts from (buffer + 2).

This patch defines AVE_FRAME_HEADROOM macro as hardware-specific value,
and replaces NET_IP_ALIGN with it.

Signed-off-by: Kunihiko Hayashi 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/socionext/sni_ave.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/socionext/sni_ave.c 
b/drivers/net/ethernet/socionext/sni_ave.c
index f7ecceeb1e28..f27d67a4d304 100644
--- a/drivers/net/ethernet/socionext/sni_ave.c
+++ b/drivers/net/ethernet/socionext/sni_ave.c
@@ -194,6 +194,7 @@
 
 /* Parameter for ethernet frame */
 #define AVE_MAX_ETHFRAME   1518
+#define AVE_FRAME_HEADROOM 2
 
 /* Parameter for interrupt */
 #define AVE_INTM_COUNT 20
@@ -585,12 +586,13 @@ static int ave_rxdesc_prepare(struct net_device *ndev, 
int entry)
 
skb = priv->rx.desc[entry].skbs;
if (!skb) {
-   skb = netdev_alloc_skb_ip_align(ndev,
-   AVE_MAX_ETHFRAME);
+   skb = netdev_alloc_skb(ndev, AVE_MAX_ETHFRAME);
if (!skb) {
netdev_err(ndev, "can't allocate skb for Rx\n");
return -ENOMEM;
}
+   skb->data += AVE_FRAME_HEADROOM;
+   skb->tail += AVE_FRAME_HEADROOM;
}
 
/* set disable to cmdsts */
@@ -603,12 +605,12 @@ static int ave_rxdesc_prepare(struct net_device *ndev, 
int entry)
 * - Rx buffer begins with 2 byte headroom, and data will be put from
 *   (buffer + 2).
 * To satisfy this, specify the address to put back the buffer
-* pointer advanced by NET_IP_ALIGN by netdev_alloc_skb_ip_align(),
-* and expand the map size by NET_IP_ALIGN.
+* pointer advanced by AVE_FRAME_HEADROOM, and expand the map size
+* by AVE_FRAME_HEADROOM.
 */
ret = ave_dma_map(ndev, >rx.desc[entry],
- skb->data - NET_IP_ALIGN,
- AVE_MAX_ETHFRAME + NET_IP_ALIGN,
+ skb->data - AVE_FRAME_HEADROOM,
+ AVE_MAX_ETHFRAME + AVE_FRAME_HEADROOM,
  DMA_FROM_DEVICE, );
if (ret) {
netdev_err(ndev, "can't map skb for Rx\n");
-- 
2.19.1

[PATCH AUTOSEL 4.19 14/73] drm/msm: fix handling of cmdstream offset

[Sasha Levin]

From: Rob Clark 

[ Upstream commit 47e7f506ee6590ceb2efa1f08aca7f9f2ee5c1d3 ]

Userspace hasn't used submit cmds with submit_offset != 0 for a while,
but this starts cropping up again with cmdstream sub-buffer-allocation
in libdrm_freedreno.

Doesn't do much good to increment the buf ptr before assigning it.

Fixes: 78b8e5b847b4 drm/msm: dump a rd GPUADDR header for all buffers in the 
command
Reviewed-by: Kristian H. Kristensen 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_rd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 3aa8a8576abe..f7a0edea4705 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -316,10 +316,11 @@ static void snapshot_buf(struct msm_rd_state *rd,
uint64_t iova, uint32_t size)
 {
struct msm_gem_object *obj = submit->bos[idx].obj;
+   unsigned offset = 0;
const char *buf;
 
if (iova) {
-   buf += iova - submit->bos[idx].iova;
+   offset = iova - submit->bos[idx].iova;
} else {
iova = submit->bos[idx].iova;
size = obj->base.size;
@@ -340,6 +341,8 @@ static void snapshot_buf(struct msm_rd_state *rd,
if (IS_ERR(buf))
return;
 
+   buf += offset;
+
rd_write_section(rd, RD_BUFFER_CONTENTS, buf, size);
 
msm_gem_put_vaddr(>base);
-- 
2.19.1

[PATCH AUTOSEL 4.19 09/73] net: phy: sfp: correct store of detected link modes

[Sasha Levin]

From: Baruch Siach 

[ Upstream commit d7f7e0018b96fd1a30a968faa9464eb57372c1ec ]

The link modes that sfp_parse_support() detects are stored in the
'modes' bitmap. There is no reason to make an exception for 1000Base-PX
or 1000Base-BX10.

Fixes: 03145864bd0f ("sfp: support 1G BiDi (eg, FiberStore SFP-GE-BX) modules")
Signed-off-by: Baruch Siach 
Acked-by: Russell King 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 83060fb349f4..ad9db652874d 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -162,7 +162,7 @@ void sfp_parse_support(struct sfp_bus *bus, const struct 
sfp_eeprom_id *id,
/* 1000Base-PX or 1000Base-BX10 */
if ((id->base.e_base_px || id->base.e_base_bx10) &&
br_min <= 1300 && br_max >= 1200)
-   phylink_set(support, 1000baseX_Full);
+   phylink_set(modes, 1000baseX_Full);
 
/* For active or passive cables, select the link modes
 * based on the bit rates and the cable compliance bytes.
-- 
2.19.1

[PATCH AUTOSEL 4.19 04/73] scsi: libiscsi: Fix NULL pointer dereference in iscsi_eh_session_reset

[Sasha Levin]

From: Fred Herard 

[ Upstream commit 5db6dd14b31397e8cccaaddab2ff44ebec1acf25 ]

This commit addresses NULL pointer dereference in iscsi_eh_session_reset.
Reference should not be made to session->leadconn when session->state is
set to ISCSI_STATE_TERMINATE.

Signed-off-by: Fred Herard 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Lee Duncan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/libiscsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 93c66ebad907..f78d2e5c1471 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -2416,8 +2416,8 @@ int iscsi_eh_session_reset(struct scsi_cmnd *sc)
 failed:
ISCSI_DBG_EH(session,
 "failing session reset: Could not log back into "
-"%s, %s [age %d]\n", session->targetname,
-conn->persistent_address, session->age);
+"%s [age %d]\n", session->targetname,
+session->age);
spin_unlock_bh(>frwd_lock);
mutex_unlock(>eh_mutex);
return FAILED;
-- 
2.19.1

[PATCH AUTOSEL 4.19 10/73] drm/amd/display: Fix 6x4K displays light-up on Vega20 (v2)

[Sasha Levin]

From: Roman Li 

[ Upstream commit c679fd55b1ba903c2a770127edbf6aef6f27 ]

[Why]
More than 4x4K didn't lightup on Vega20 due to low dcfclk value.
Powerplay expects valid min requirement for dcfclk from DC.

[How]
Update min_dcfclock_khz based on min_engine_clock value.

v2: backport to 4.20 (Alex)

Reviewed-by: Hersen Wu 
Reviewed-by: Feifei Xu 
Reviewed-by: Evan Quan 
Acked-by: Alex Deucher 
Signed-off-by: Roman Li 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
index b2f308766a9e..0941f3c689bc 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c
@@ -2530,6 +2530,8 @@ static void pplib_apply_display_requirements(
dc,
context->bw.dce.sclk_khz);
 
+   pp_display_cfg->min_dcfclock_khz = pp_display_cfg->min_engine_clock_khz;
+
pp_display_cfg->min_engine_clock_deep_sleep_khz
= context->bw.dce.sclk_deep_sleep_khz;
 
-- 
2.19.1

[PATCH AUTOSEL 4.19 15/73] drm/msm/dsi: configure VCO rate for 10nm PLL driver

[Sasha Levin]

From: Abhinav Kumar 

[ Upstream commit 8531f0587f5c9e1a74cd9543a97617349f5e0706 ]

Currenty the VCO rate in the 10nm PLL driver relies
on the parent rate which is not configured.

Configure the VCO rate to 19.2 Mhz as required by
the 10nm PLL driver.

Signed-off-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 4c03f0b7343e..41bec570c518 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -39,6 +39,8 @@
 #define DSI_PIXEL_PLL_CLK  1
 #define NUM_PROVIDED_CLKS  2
 
+#define VCO_REF_CLK_RATE   1920
+
 struct dsi_pll_regs {
u32 pll_prop_gain_rate;
u32 pll_lockdet_rate;
@@ -316,7 +318,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw, 
unsigned long rate,
parent_rate);
 
pll_10nm->vco_current_rate = rate;
-   pll_10nm->vco_ref_clk_rate = parent_rate;
+   pll_10nm->vco_ref_clk_rate = VCO_REF_CLK_RATE;
 
dsi_pll_setup_config(pll_10nm);
 
-- 
2.19.1

[PATCH AUTOSEL 4.19 18/73] drm/amdgpu: wait for IB test on first device open

[Sasha Levin]

From: Christian König 

[ Upstream commit 3bfa8897e4d08f822d1d58cf6cbbffbccef82e08 ]

Instead of delaying that to the first query. Otherwise we could try to use the
SDMA for VM updates before the IB tests are done.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Reviewed-by: Junwei Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index bd98cc5fb97b..fd825d30edf1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -292,9 +292,6 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
if (!info->return_size || !info->return_pointer)
return -EINVAL;
 
-   /* Ensure IB tests are run on ring */
-   flush_delayed_work(>late_init_work);
-
switch (info->query) {
case AMDGPU_INFO_ACCEL_WORKING:
ui32 = adev->accel_working;
@@ -861,6 +858,9 @@ int amdgpu_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
struct amdgpu_fpriv *fpriv;
int r, pasid;
 
+   /* Ensure IB tests are run on ring */
+   flush_delayed_work(>late_init_work);
+
file_priv->driver_priv = NULL;
 
r = pm_runtime_get_sync(dev->dev);
-- 
2.19.1

[PATCH AUTOSEL 4.19 17/73] drm/ttm: fix LRU handling in ttm_buffer_object_transfer

[Sasha Levin]

From: Christian König 

[ Upstream commit d6e820fcd4cf08b11d291a1dd7bbd0636914647c ]

We need to set the NO_EVICT flag on the ghost object or otherwise we are
adding it to the LRU.

When it is added to the LRU we can run into a race between destroying
and evicting it again.

Signed-off-by: Christian König 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..40904e84f883 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -492,8 +492,10 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
if (!fbo)
return -ENOMEM;
 
-   ttm_bo_get(bo);
fbo->base = *bo;
+   fbo->base.mem.placement |= TTM_PL_FLAG_NO_EVICT;
+
+   ttm_bo_get(bo);
fbo->bo = bo;
 
/**
-- 
2.19.1

[PATCH AUTOSEL 4.19 16/73] drm/msm: Grab a vblank reference when waiting for commit_done

[Sasha Levin]

From: Sean Paul 

[ Upstream commit 3b712e43e3876b42b38321ecf790a1f5fe59c834 ]

Similar to the atomic helpers, we should enable vblank while we're
waiting for the commit to finish. DPU needs this, MDP5 seems to work
fine without it.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Sean Paul 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/msm_atomic.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index c1f1779c980f..2b7bb6e166d3 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -32,7 +32,12 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
if (!new_crtc_state->active)
continue;
 
+   if (drm_crtc_vblank_get(crtc))
+   continue;
+
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
+
+   drm_crtc_vblank_put(crtc);
}
 }
 
-- 
2.19.1

RE: [PATCH AUTOSEL 4.9 21/34] net: phy: Fix not to call phy_resume() if PHY is not attached

[Yoshihiro Shimoda]

Hi,

> From: Sasha Levin, Sent: Thursday, December 13, 2018 1:32 PM
> 
> From: Yoshihiro Shimoda 
> 
> [ Upstream commit ef1b5bf506b1f0ee3edc98533e1f3ecb105eb46a ]

This upstream commit is reverted on mainline as I mentioned other email thread 
[1].
So, we should not backport this patch.

[1]
https://lore.kernel.org/lkml/osapr01mb2290fe36af50b2f29170383dd8...@osapr01mb2290.jpnprd01.prod.outlook.com/T/#u

Best regards,
Yoshihiro Shimoda

[PATCH AUTOSEL 4.19 19/73] ARC: io.h: Implement reads{x}()/writes{x}()

[Sasha Levin]

From: Jose Abreu 

[ Upstream commit 10d443431dc2bb733cf7add99b453e3fb9047a2e ]

Some ARC CPU's do not support unaligned loads/stores. Currently, generic
implementation of reads{b/w/l}()/writes{b/w/l}() is being used with ARC.
This can lead to misfunction of some drivers as generic functions do a
plain dereference of a pointer that can be unaligned.

Let's use {get/put}_unaligned() helpers instead of plain dereference of
pointer in order to fix. The helpers allow to get and store data from an
unaligned address whilst preserving the CPU internal alignment.
According to [1], the use of these helpers are costly in terms of
performance so we added an initial check for a buffer already aligned so
that the usage of the helpers can be avoided, when possible.

[1] Documentation/unaligned-memory-access.txt

Cc: Alexey Brodkin 
Cc: Joao Pinto 
Cc: David Laight 
Tested-by: Vitor Soares 
Signed-off-by: Jose Abreu 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/include/asm/io.h | 72 +++
 1 file changed, 72 insertions(+)

diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index c22b181e8206..2f39d9b3886e 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_ISA_ARCV2
 #include 
@@ -94,6 +95,42 @@ static inline u32 __raw_readl(const volatile void __iomem 
*addr)
return w;
 }
 
+/*
+ * {read,write}s{b,w,l}() repeatedly access the same IO address in
+ * native endianness in 8-, 16-, 32-bit chunks {into,from} memory,
+ * @count times
+ */
+#define __raw_readsx(t,f) \
+static inline void __raw_reads##f(const volatile void __iomem *addr,   \
+ void *ptr, unsigned int count)\
+{  \
+   bool is_aligned = ((unsigned long)ptr % ((t) / 8)) == 0;\
+   u##t *buf = ptr;\
+   \
+   if (!count) \
+   return; \
+   \
+   /* Some ARC CPU's don't support unaligned accesses */   \
+   if (is_aligned) {   \
+   do {\
+   u##t x = __raw_read##f(addr);   \
+   *buf++ = x; \
+   } while (--count);  \
+   } else {\
+   do {\
+   u##t x = __raw_read##f(addr);   \
+   put_unaligned(x, buf++);\
+   } while (--count);  \
+   }   \
+}
+
+#define __raw_readsb __raw_readsb
+__raw_readsx(8, b)
+#define __raw_readsw __raw_readsw
+__raw_readsx(16, w)
+#define __raw_readsl __raw_readsl
+__raw_readsx(32, l)
+
 #define __raw_writeb __raw_writeb
 static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
 {
@@ -126,6 +163,35 @@ static inline void __raw_writel(u32 w, volatile void 
__iomem *addr)
 
 }
 
+#define __raw_writesx(t,f) \
+static inline void __raw_writes##f(volatile void __iomem *addr,\
+  const void *ptr, unsigned int count) \
+{  \
+   bool is_aligned = ((unsigned long)ptr % ((t) / 8)) == 0;\
+   const u##t *buf = ptr;  \
+   \
+   if (!count) \
+   return; \
+   \
+   /* Some ARC CPU's don't support unaligned accesses */   \
+   if (is_aligned) {   \
+   do {\
+   __raw_write##f(*buf++, addr);   \
+   } while (--count);  \
+   } else {\
+   do {\
+   __raw_write##f(get_unaligned(buf++), addr); \
+   } while (--count);  \
+   

[PATCH AUTOSEL 4.19 23/73] bpf: Fix verifier log string check for bad alignment.

[Sasha Levin]

From: David Miller 

[ Upstream commit c01ac66b38660f2b507ccd0b75d28e3002d56fbb ]

The message got changed a lot time ago.

This was responsible for 36 test case failures on sparc64.

Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
Signed-off-by: David S. Miller 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin 
---
 tools/testing/selftests/bpf/test_verifier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/test_verifier.c 
b/tools/testing/selftests/bpf/test_verifier.c
index 67c412d19c09..d80c36465c1c 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -12746,7 +12746,7 @@ static void do_test_single(struct bpf_test *test, bool 
unpriv,
 
reject_from_alignment = fd_prog < 0 &&
(test->flags & 
F_NEEDS_EFFICIENT_UNALIGNED_ACCESS) &&
-   strstr(bpf_vlog, "Unknown alignment.");
+   strstr(bpf_vlog, "misaligned");
 #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
if (reject_from_alignment) {
printf("FAIL\nFailed due to alignment despite having efficient 
unaligned access: '%s'!\n",
-- 
2.19.1

[PATCH AUTOSEL 4.19 24/73] liquidio: read sc->iq_no before release sc

[Sasha Levin]

From: Pan Bian 

[ Upstream commit c0f53771ba45745e5870daf880127925c93f232f ]

The function lio_vf_rep_packet_sent_callback releases the occupation of
sc via octeon_free_soft_command. sc should not be used after that.
Unfortunately, sc->iq_no is read. To fix this, the patch stores sc->iq_no
into a local variable before releasing sc and then uses the local variable
instead of sc->iq_no.

Signed-off-by: Pan Bian 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c 
b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
index ddd7431579f4..c99b59fe4c8f 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c
@@ -367,13 +367,15 @@ lio_vf_rep_packet_sent_callback(struct octeon_device *oct,
struct octeon_soft_command *sc = (struct octeon_soft_command *)buf;
struct sk_buff *skb = sc->ctxptr;
struct net_device *ndev = skb->dev;
+   u32 iq_no;
 
dma_unmap_single(>pci_dev->dev, sc->dmadptr,
 sc->datasize, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
+   iq_no = sc->iq_no;
octeon_free_soft_command(oct, sc);
 
-   if (octnet_iq_is_full(oct, sc->iq_no))
+   if (octnet_iq_is_full(oct, iq_no))
return;
 
if (netif_queue_stopped(ndev))
-- 
2.19.1

[PATCH AUTOSEL 4.19 21/73] net: aquantia: fix rx checksum offload bits

[Sasha Levin]

From: Dmitry Bogdanov 

[ Upstream commit 37c4b91f955fdd5f4ad771956b97d35f1321098e ]

The last set of csum offload fixes had a leak:

Checksum enabled status bits from rx descriptor were incorrectly
interpreted. Consequently all the other valid logic worked on zero bits.
That caused rx checksum offloads never to trigger.

Tested by dumping rx descriptors and validating resulting csum_level.

Reported-by: Igor Russkikh 
Signed-off-by: Dmitry Bogdanov 
Signed-off-by: Igor Russkikh 
Fixes: ad703c2b9127f ("net: aquantia: invalid checksumm offload implementation")
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
index 88705dee5b95..56363ff5c891 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
@@ -667,7 +667,7 @@ static int hw_atl_b0_hw_ring_rx_receive(struct aq_hw_s 
*self,
 
rx_stat = (0x003CU & rxd_wb->status) >> 2;
 
-   is_rx_check_sum_enabled = (rxd_wb->type) & (0x3U << 19);
+   is_rx_check_sum_enabled = (rxd_wb->type >> 19) & 0x3U;
 
pkt_type = 0xFFU & (rxd_wb->type >> 4);
 
-- 
2.19.1

[PATCH AUTOSEL 4.19 25/73] nfs: don't dirty kernel pages read by direct-io

[Sasha Levin]

From: Dave Kleikamp 

[ Upstream commit ad3cba223ac02dc769c3bbe88efe277bbb457566 ]

When we use direct_IO with an NFS backing store, we can trigger a
WARNING in __set_page_dirty(), as below, since we're dirtying the page
unnecessarily in nfs_direct_read_completion().

To fix, replicate the logic in commit 53cbf3b157a0 ("fs: direct-io:
don't dirtying pages for ITER_BVEC/ITER_KVEC direct read").

Other filesystems that implement direct_IO handle this; most use
blockdev_direct_IO(). ceph and cifs have similar logic.

mount 127.0.0.1:/export /nfs
dd if=/dev/zero of=/nfs/image bs=1M count=200
losetup --direct-io=on -f /nfs/image
mkfs.btrfs /dev/loop0
mount -t btrfs /dev/loop0 /mnt/

kernel: WARNING: CPU: 0 PID: 8067 at fs/buffer.c:580 __set_page_dirty+0xaf/0xd0
kernel: Modules linked in: loop(E) nfsv3(E) rpcsec_gss_krb5(E) nfsv4(E) 
dns_resolver(E) nfs(E) fscache(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) 
grace(E) fuse(E) tun(E) ip6t_rpfilter(E) ipt_REJECT(E) nf_
kernel:  snd_seq(E) snd_seq_device(E) snd_pcm(E) video(E) snd_timer(E) snd(E) 
soundcore(E) ip_tables(E) xfs(E) libcrc32c(E) sd_mod(E) sr_mod(E) cdrom(E) 
ata_generic(E) pata_acpi(E) crc32c_intel(E) ahci(E) li
kernel: CPU: 0 PID: 8067 Comm: kworker/0:2 Tainted: GE 
4.20.0-rc1.master.2018.ol7.x86_64 #1
kernel: Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 
12/01/2006
kernel: Workqueue: nfsiod rpc_async_release [sunrpc]
kernel: RIP: 0010:__set_page_dirty+0xaf/0xd0
kernel: Code: c3 48 8b 02 f6 c4 04 74 d4 48 89 df e8 ba 05 f7 ff 48 89 c6 eb cb 
48 8b 43 08 a8 01 75 1f 48 89 d8 48 8b 00 a8 04 74 02 eb 87 <0f> 0b eb 83 48 83 
e8 01 eb 9f 48 83 ea 01 0f 1f 00 eb 8b 48 83 e8
kernel: RSP: :c1c8825b7d78 EFLAGS: 00013046
kernel: RAX: 000fc0020089 RBX: f2b603308b80 RCX: 0001
kernel: RDX: 0001 RSI: 9d11478115c8 RDI: 9d11478115d0
kernel: RBP: c1c8825b7da0 R08: 646f6973666e R09: 8080808080808080
kernel: R10: 0001 R11:  R12: 9d11478115d0
kernel: R13: 9d11478115c8 R14: 3246 R15: 0001
kernel: FS:  () GS:9d115ba0() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 7f408686f640 CR3: 000104d8e004 CR4: 000606f0
kernel: DR0:  DR1:  DR2: 
kernel: DR3:  DR6: fffe0ff0 DR7: 0400
kernel: Call Trace:
kernel:  __set_page_dirty_buffers+0xb6/0x110
kernel:  set_page_dirty+0x52/0xb0
kernel:  nfs_direct_read_completion+0xc4/0x120 [nfs]
kernel:  nfs_pgio_release+0x10/0x20 [nfs]
kernel:  rpc_free_task+0x30/0x70 [sunrpc]
kernel:  rpc_async_release+0x12/0x20 [sunrpc]
kernel:  process_one_work+0x174/0x390
kernel:  worker_thread+0x4f/0x3e0
kernel:  kthread+0x102/0x140
kernel:  ? drain_workqueue+0x130/0x130
kernel:  ? kthread_stop+0x110/0x110
kernel:  ret_from_fork+0x35/0x40
kernel: ---[ end trace 01341980905412c9 ]---

Signed-off-by: Dave Kleikamp 
Signed-off-by: Santosh Shilimkar 

[forward-ported to v4.20]
Signed-off-by: Calum Mackay 
Reviewed-by: Dave Kleikamp 
Reviewed-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 fs/nfs/direct.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index aa12c3063bae..33824a0a57bf 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -98,8 +98,11 @@ struct nfs_direct_req {
struct pnfs_ds_commit_info ds_cinfo;/* Storage for cinfo */
struct work_struct  work;
int flags;
+   /* for write */
 #define NFS_ODIRECT_DO_COMMIT  (1) /* an unstable reply was 
received */
 #define NFS_ODIRECT_RESCHED_WRITES (2) /* write verification failed */
+   /* for read */
+#define NFS_ODIRECT_SHOULD_DIRTY   (3) /* dirty user-space page after 
read */
struct nfs_writeverfverf;   /* unstable write verifier */
 };
 
@@ -412,7 +415,8 @@ static void nfs_direct_read_completion(struct 
nfs_pgio_header *hdr)
struct nfs_page *req = nfs_list_entry(hdr->pages.next);
struct page *page = req->wb_page;
 
-   if (!PageCompound(page) && bytes < hdr->good_bytes)
+   if (!PageCompound(page) && bytes < hdr->good_bytes &&
+   (dreq->flags == NFS_ODIRECT_SHOULD_DIRTY))
set_page_dirty(page);
bytes += req->wb_bytes;
nfs_list_remove_request(req);
@@ -587,6 +591,9 @@ ssize_t nfs_file_direct_read(struct kiocb *iocb, struct 
iov_iter *iter)
if (!is_sync_kiocb(iocb))
dreq->iocb = iocb;
 
+   if (iter_is_iovec(iter))
+   dreq->flags = NFS_ODIRECT_SHOULD_DIRTY;
+
nfs_start_io_direct(inode);
 
NFS_I(inode)->read_io += count;
-- 
2.19.1

Re: [PATCH] Allow hwrng to initialize crng.

[Louis Collard]

On Sun, Nov 18, 2018 at 4:15 AM Michael Niewöhner  wrote:
>
> Hi Louis,
>
> On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> > Some systems, for example embedded systems, do not generate
> > enough entropy on boot through interrupts, and boot may be blocked for
> > several minutes waiting for a call to getrandom to complete.
> >
> > Currently, random data is read from a hwrng when it is registered,
> > and is loaded into primary_crng. This data is treated in the same
> > way as data that is device-specific but otherwise unchanging, and
> > so primary_crng cannot become initialized with the data from the
> > hwrng.
> >
> > This change causes the data initially read from the hwrng to be
> > treated the same as subsequent data that is read from the hwrng if
> > it's quality score is non-zero.
> >
> > The implications of this are:
> >
> > The data read from hwrng can cause primary_crng to become
> > initialized, therefore avoiding problems of getrandom blocking
> > on boot.
> >
> > Calls to getrandom (with GRND_RANDOM) may be using entropy
> > exclusively (or in practise, almost exclusively) from the hwrng.
> >
> > Regarding the latter point; this behavior is the same as if a
> > user specified a quality score of 1 (bit of entropy per 1024 bits)
> > so hopefully this is not too scary a change to make.
> >
> > This change is the result of the discussion here:
> > https://patchwork.kernel.org/patch/10453893/
> >
> > Signed-off-by: Louis Collard 
> > Acked-by: Jarkko Sakkinen 
> > ---
> >  drivers/char/hw_random/core.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > index aaf9e5afaad4..47f358aa0c3d 100644
> > --- a/drivers/char/hw_random/core.c
> > +++ b/drivers/char/hw_random/core.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define RNG_MODULE_NAME  "hw_random"
> >
> > @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> >  static void add_early_randomness(struct hwrng *rng)
> >  {
> >   int bytes_read;
> > - size_t size = min_t(size_t, 16, rng_buffer_size());
> > + /* Read enough to initialize crng. */
> > + size_t size = 2*CHACHA20_KEY_SIZE;
> >
> >   mutex_lock(_mutex);
> >   bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> >   mutex_unlock(_mutex);
> >   if (bytes_read > 0)
> > - add_device_randomness(rng_buffer, bytes_read);
> > + /* Allow crng to become initialized, but do not add
> > +  * entropy to the pool.
> > +  */
> > + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> >  }
> >
> >  static inline void cleanup_rng(struct kref *kref)
>
> I found your patch by chance, searching for a solution for crng init delay on 
> my
> headless machine. Unfortunately it hardly makes any difference for me. With 
> the
> patch the system hangs for about 80s instead of 120s until the "crng init 
> done"
> message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
> initializes the crng instantly.
>
> Isn't that delay the problem this patch tries to fix? Any idea what is wrong
> here?
>
> Thanks!
>
> Best regards
> Michael
>
>

Yes that is the problem this is trying to address. My guess would be
rng_get_data() is not returning as much data as requested, so the
delay is reduced but not eliminated. Looking at implementation of
rng_get_data() it appears this could be caused by device support for
read() vs data_read(). I don't have a good feel for whether looping to
retrieve more data here would be acceptable, it is certainly a bigger
change than currently proposed.

Thanks,
Louis

[PATCH AUTOSEL 4.19 27/73] SUNRPC: Fix a potential race in xprt_connect()

[Sasha Levin]

From: Trond Myklebust 

[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]

If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the connection state after we've put the
task to sleep and set the XPRT_CONNECTING flag, when we know that there
can be no asynchronous connection attempts still in progress.

Fixes: 0b9e79431377d ("SUNRPC: Move the test for XPRT_CONNECTING into...")
Signed-off-by: Trond Myklebust 
Signed-off-by: Sasha Levin 
---
 net/sunrpc/xprt.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index a8db2e3f8904..d066aae3cb6d 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -781,8 +781,15 @@ void xprt_connect(struct rpc_task *task)
return;
if (xprt_test_and_set_connecting(xprt))
return;
-   xprt->stat.connect_start = jiffies;
-   xprt->ops->connect(xprt, task);
+   /* Race breaker */
+   if (!xprt_connected(xprt)) {
+   xprt->stat.connect_start = jiffies;
+   xprt->ops->connect(xprt, task);
+   } else {
+   xprt_clear_connecting(xprt);
+   task->tk_status = 0;
+   rpc_wake_up_queued_task(>pending, task);
+   }
}
xprt_release_write(xprt, task);
 }
-- 
2.19.1

[PATCH AUTOSEL 4.19 29/73] drivers/sbus/char: add of_node_put()

[Sasha Levin]

From: Yangtao Li 

[ Upstream commit 6bd520ab7cf69486ea81fd3cdfd2d5a390ad1100 ]

use of_node_put() to release the refcount.

Signed-off-by: Yangtao Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/sbus/char/envctrl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/sbus/char/envctrl.c b/drivers/sbus/char/envctrl.c
index 56e962a01493..b8481927bfe4 100644
--- a/drivers/sbus/char/envctrl.c
+++ b/drivers/sbus/char/envctrl.c
@@ -910,8 +910,10 @@ static void envctrl_init_i2c_child(struct device_node *dp,
for (len = 0; len < PCF8584_MAX_CHANNELS; ++len) {
pchild->mon_type[len] = ENVCTRL_NOMON;
}
+   of_node_put(root_node);
return;
}
+   of_node_put(root_node);
}
 
/* Get the monitor channels. */
-- 
2.19.1

RE: [PATCH AUTOSEL 4.14 25/41] net: phy: Fix not to call phy_resume() if PHY is not attached

[Yoshihiro Shimoda]

Hi,

> From: Sasha Levin, Sent: Thursday, December 13, 2018 1:31 PM
> 
> From: Yoshihiro Shimoda 
> 
> [ Upstream commit ef1b5bf506b1f0ee3edc98533e1f3ecb105eb46a ]

This upstream commit is also reverted on mainline
as I mentioned other email thread [1]. So, we should not backport this patch.

[1]
https://lore.kernel.org/lkml/osapr01mb2290fe36af50b2f29170383dd8...@osapr01mb2290.jpnprd01.prod.outlook.com/T/#u

Best regards,
Yoshihiro Shimoda

[PATCH AUTOSEL 4.19 32/73] drm/msm/hdmi: Enable HPD after HDMI IRQ is set up

[Sasha Levin]

From: Todor Tomov 

[ Upstream commit ee4456359640defe3f51cc6b728bfce4bc444c9e ]

SoCs that contain MDP5 have a top level wrapper called MDSS that
manages locks, power and irq for the sub-blocks within it.

Irq for HDMI is also routed through the MDSS.

Shortly after the Hot Plug Detection (HPD) is enabled in HDMI,
HDMI interrupts are recieved by the MDSS interrupt handler.
However at this moment the HDMI irq is still not mapped to
the MDSS irq domain so the HDMI irq handler cannot be called
to process the interrupts.

This leads to a flood of HDMI interrupts on CPU 0.

If we are lucky to have the HDMI initialization running on a
different CPU, it will eventually map the HDMI irq to MDSS irq
domain, the next HDMI interrupt will be handled by the HDMI irq
handler, the interrupt flood will stop and we will recover.

If the HDMI initialization is running on CPU 0, then it cannot
complete and there is nothing to stop the interrupt flood on
CPU 0. The system is stuck.

Fix this by moving the HPD enablement after the HDMI irq is
mapped to the MDSS irq domain.

Signed-off-by: Todor Tomov 
Signed-off-by: Rob Clark 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c   |  6 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 +
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 10 ++
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index c79659ca5706..33e083f71a17 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -332,6 +332,12 @@ int msm_hdmi_modeset_init(struct hdmi *hdmi,
goto fail;
}
 
+   ret = msm_hdmi_hpd_enable(hdmi->connector);
+   if (ret < 0) {
+   DRM_DEV_ERROR(>pdev->dev, "failed to enable HPD: %d\n", 
ret);
+   goto fail;
+   }
+
encoder->bridge = hdmi->bridge;
 
priv->bridges[priv->num_bridges++]   = hdmi->bridge;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index accc9a61611d..5c5df6ab2a57 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -245,6 +245,7 @@ void msm_hdmi_bridge_destroy(struct drm_bridge *bridge);
 
 void msm_hdmi_connector_irq(struct drm_connector *connector);
 struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi);
+int msm_hdmi_hpd_enable(struct drm_connector *connector);
 
 /*
  * i2c adapter for ddc:
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index e9c9a0af508e..30e908dfded7 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -167,8 +167,9 @@ static void enable_hpd_clocks(struct hdmi *hdmi, bool 
enable)
}
 }
 
-static int hpd_enable(struct hdmi_connector *hdmi_connector)
+int msm_hdmi_hpd_enable(struct drm_connector *connector)
 {
+   struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
struct hdmi *hdmi = hdmi_connector->hdmi;
const struct hdmi_platform_config *config = hdmi->config;
struct device *dev = >pdev->dev;
@@ -450,7 +451,6 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi 
*hdmi)
 {
struct drm_connector *connector = NULL;
struct hdmi_connector *hdmi_connector;
-   int ret;
 
hdmi_connector = kzalloc(sizeof(*hdmi_connector), GFP_KERNEL);
if (!hdmi_connector)
@@ -471,12 +471,6 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi 
*hdmi)
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
 
-   ret = hpd_enable(hdmi_connector);
-   if (ret) {
-   dev_err(>pdev->dev, "failed to enable HPD: %d\n", ret);
-   return ERR_PTR(ret);
-   }
-
drm_connector_attach_encoder(connector, hdmi->encoder);
 
return connector;
-- 
2.19.1

[PATCH AUTOSEL 4.19 39/73] Input: synaptics - enable SMBus for HP 15-ay000

[Sasha Levin]

From: Teika Kazura 

[ Upstream commit 5a6dab15f7a79817cab4af612ddd99eda793fce6 ]

SMBus works fine for the touchpad with id SYN3221, used in the HP 15-ay000
series,

This device has been reported in these messages in the "linux-input"
mailing list:
* https://marc.info/?l=linux-input=152016683003369=2
* https://www.spinics.net/lists/linux-input/msg52525.html

Reported-by: Nitesh Debnath 
Reported-by: Teika Kazura 
Signed-off-by: Teika Kazura 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/mouse/synaptics.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c42813d50591..2bd5bb11c8ba 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -178,6 +178,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN0096", /* X280 */
"LEN0097", /* X280 -> ALPS trackpoint */
"LEN200f", /* T450s */
+   "SYN3221", /* HP 15-ay000 */
NULL
 };
 
-- 
2.19.1