[PATCH v2 2/2] of: __of_detach_node() - remove node from phandle cache
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. Remove the node from the
cache.
Add paranoia checks in of_find_node_by_phandle() as a second level
of defense (do not return cached node if detached, do not add node
to cache if detached).
Reported-by: Michael Bringmann
Signed-off-by: Frank Rowand
---
changes since v1:
- add WARN_ON(1) for unexpected condition in of_find_node_by_phandle()
drivers/of/base.c | 30 +-
drivers/of/dynamic.c| 3 +++
drivers/of/of_private.h | 4
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 6c33d63361b8..ad71864cecf5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -162,6 +162,27 @@ int of_free_phandle_cache(void)
late_initcall_sync(of_free_phandle_cache);
#endif
+/*
+ * Caller must hold devtree_lock.
+ */
+void __of_free_phandle_cache_entry(phandle handle)
+{
+ phandle masked_handle;
+
+ if (!handle)
+ return;
+
+ masked_handle = handle & phandle_cache_mask;
+
+ if (phandle_cache) {
+ if (phandle_cache[masked_handle] &&
+ handle == phandle_cache[masked_handle]->phandle) {
+ of_node_put(phandle_cache[masked_handle]);
+ phandle_cache[masked_handle] = NULL;
+ }
+ }
+}
+
void of_populate_phandle_cache(void)
{
unsigned long flags;
@@ -1209,11 +1230,18 @@ struct device_node *of_find_node_by_phandle(phandle
handle)
if (phandle_cache[masked_handle] &&
handle == phandle_cache[masked_handle]->phandle)
np = phandle_cache[masked_handle];
+ if (np && of_node_check_flag(np, OF_DETACHED)) {
+ WARN_ON(1);
+ of_node_put(np);
+ phandle_cache[masked_handle] = NULL;
+ np = NULL;
+ }
}
if (!np) {
for_each_of_allnodes(np)
- if (np->phandle == handle) {
+ if (np->phandle == handle &&
+ !of_node_check_flag(np, OF_DETACHED)) {
if (phandle_cache) {
/* will put when removed from cache */
of_node_get(np);
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index f4f8ed9b5454..ecea92f68c87 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -268,6 +268,9 @@ void __of_detach_node(struct device_node *np)
}
of_node_set_flag(np, OF_DETACHED);
+
+ /* race with of_find_node_by_phandle() prevented by devtree_lock */
+ __of_free_phandle_cache_entry(np->phandle);
}
/**
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 5d1567025358..24786818e32e 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -84,6 +84,10 @@ static inline void __of_detach_node_sysfs(struct device_node
*np) {}
int of_resolve_phandles(struct device_node *tree);
#endif
+#if defined(CONFIG_OF_DYNAMIC)
+void __of_free_phandle_cache_entry(phandle handle);
+#endif
+
#if defined(CONFIG_OF_OVERLAY)
void of_overlay_mutex_lock(void);
void of_overlay_mutex_unlock(void);
--
Frank Rowand
Re: [PATCH v13 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
On Fri, Dec 14, 2018 at 9:40 AM Taniya Das wrote:
>
> 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
Tested-by: Amit Kucheria
> ---
> .../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..33856947
> --- /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";
[PATCH v2 1/2] of: of_node_get()/of_node_put() nodes held in phandle cache
From: Frank Rowand
The phandle cache contains struct device_node pointers. The refcount
of the pointers was not incremented while in the cache, allowing use
after free error after kfree() of the node. Add the proper increment
and decrement of the use count.
Fixes: 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of
of_find_node_by_phandle()")
Signed-off-by: Frank Rowand
---
changes since v1
- make __of_free_phandle_cache() static
drivers/of/base.c | 70 ---
1 file changed, 46 insertions(+), 24 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 09692c9b32a7..6c33d63361b8 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -116,9 +116,6 @@ int __weak of_node_to_nid(struct device_node *np)
}
#endif
-static struct device_node **phandle_cache;
-static u32 phandle_cache_mask;
-
/*
* Assumptions behind phandle_cache implementation:
* - phandle property values are in a contiguous range of 1..n
@@ -127,6 +124,44 @@ int __weak of_node_to_nid(struct device_node *np)
* - the phandle lookup overhead reduction provided by the cache
* will likely be less
*/
+
+static struct device_node **phandle_cache;
+static u32 phandle_cache_mask;
+
+/*
+ * Caller must hold devtree_lock.
+ */
+static void __of_free_phandle_cache(void)
+{
+ u32 cache_entries = phandle_cache_mask + 1;
+ u32 k;
+
+ if (!phandle_cache)
+ return;
+
+ for (k = 0; k < cache_entries; k++)
+ of_node_put(phandle_cache[k]);
+
+ kfree(phandle_cache);
+ phandle_cache = NULL;
+}
+
+int of_free_phandle_cache(void)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(_lock, flags);
+
+ __of_free_phandle_cache();
+
+ raw_spin_unlock_irqrestore(_lock, flags);
+
+ return 0;
+}
+#if !defined(CONFIG_MODULES)
+late_initcall_sync(of_free_phandle_cache);
+#endif
+
void of_populate_phandle_cache(void)
{
unsigned long flags;
@@ -136,8 +171,7 @@ void of_populate_phandle_cache(void)
raw_spin_lock_irqsave(_lock, flags);
- kfree(phandle_cache);
- phandle_cache = NULL;
+ __of_free_phandle_cache();
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
@@ -155,30 +189,15 @@ void of_populate_phandle_cache(void)
goto out;
for_each_of_allnodes(np)
- if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
+ if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL) {
+ of_node_get(np);
phandle_cache[np->phandle & phandle_cache_mask] = np;
+ }
out:
raw_spin_unlock_irqrestore(_lock, flags);
}
-int of_free_phandle_cache(void)
-{
- unsigned long flags;
-
- raw_spin_lock_irqsave(_lock, flags);
-
- kfree(phandle_cache);
- phandle_cache = NULL;
-
- raw_spin_unlock_irqrestore(_lock, flags);
-
- return 0;
-}
-#if !defined(CONFIG_MODULES)
-late_initcall_sync(of_free_phandle_cache);
-#endif
-
void __init of_core_init(void)
{
struct device_node *np;
@@ -1195,8 +1214,11 @@ struct device_node *of_find_node_by_phandle(phandle
handle)
if (!np) {
for_each_of_allnodes(np)
if (np->phandle == handle) {
- if (phandle_cache)
+ if (phandle_cache) {
+ /* will put when removed from cache */
+ of_node_get(np);
phandle_cache[masked_handle] = np;
+ }
break;
}
}
--
Frank Rowand
[PATCH v2 0/2] of: phandle_cache, fix refcounts, remove stale entry
From: Frank Rowand Non-overlay dynamic devicetree node removal may leave the node in the phandle cache. Subsequent calls to of_find_node_by_phandle() will incorrectly find the stale entry. This bug exposed the foloowing phandle cache refcount bug. The refcount of phandle_cache entries is not incremented while in the cache, allowing use after free error after kfree() of the cached entry. Changes since v1: - make __of_free_phandle_cache() static - add WARN_ON(1) for unexpected condition in of_find_node_by_phandle() Frank Rowand (2): of: of_node_get()/of_node_put() nodes held in phandle cache of: __of_detach_node() - remove node from phandle cache drivers/of/base.c | 100 drivers/of/dynamic.c| 3 ++ drivers/of/of_private.h | 4 ++ 3 files changed, 82 insertions(+), 25 deletions(-) -- Frank Rowand
Re: [PATCH v13 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On Fri, Dec 14, 2018 at 9:40 AM Taniya Das wrote:
>
> 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
Tested-by: Amit Kucheria
> ---
> drivers/cpufreq/Kconfig.arm | 11 ++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/qcom-cpufreq-hw.c | 308
> ++
> 3 files changed, 320 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..d83939a
> --- /dev/null
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -0,0 +1,308 @@
> +// 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)
> +
Re: [PATCH v8 15/26] pwm: jz4740: Add support for the JZ4725B
On Sun, Dec 16, 2018 at 03:18:52PM +0100, Paul Cercueil wrote: > Hi, > > Le ven. 14 déc. 2018 à 15:26, Uwe Kleine-König > a écrit : > > Hello, > > > > On Fri, Dec 14, 2018 at 02:50:20PM +0100, Linus Walleij wrote: > > > On Thu, Dec 13, 2018 at 9:42 PM Uwe Kleine-König > > > wrote: > > > > [Adding Linus Walleij to Cc:] > > > > On Thu, Dec 13, 2018 at 03:03:15PM +0100, Paul Cercueil wrote: > > > > > Le jeu. 13 déc. 2018 à 10:24, Uwe Kleine-König > > > > > a écrit : > > > > > > On Wed, Dec 12, 2018 at 11:09:10PM +0100, Paul Cercueil wrote: > > > > > > > The PWM in the JZ4725B works the same as in the JZ4740, > > > > > > > except that it only has 6 channels available instead of > > > > > > > 8. > > > > > > > > > > > > this driver is probed only from device tree? If yes, it > > > > > > might be sensible to specify the number of PWMs there and > > > > > > get it from there. > > > > > > There doesn't seem to be a generic binding for that, but there are > > > > > > several drivers that could benefit from it. (This is a bigger > > > > > > project > > > > > > though and shouldn't stop your patch. Still more as it already got > > > > > > Thierry's ack.) > > > > > > > > > > I think there needs to be a proper guideline, as there doesn't seem > > > > > to be > > > > > a consensus about this. I learned from emails with Rob and Linus > > > > > (Walleij) > > > > > that I should not have in devicetree what I can deduce from the > > > > > compatible > > > > > string. > > > > > > > > I understood them a bit differently. It is ok to deduce things from the > > > > compatible string. But if you define a generic property (say) "num-pwms" > > > > that is used uniformly in most bindings this is ok, too. (And then the > > > > two different devices could use the same compatible.) > > > > > > > > An upside of the generic "num-pwms" property is that the pwm core could > > > > sanity check pwm phandles before passing them to the hardware drivers. > > > > > > I don't know if this helps, but in GPIO we have "ngpios" which is > > > used to augment an existing block as to the number of lines actually > > > used with it. > > > > > > The typical case is that an ASIC engineer synthesize a block for > > > 32 GPIOs but only 12 of them are routed to external pads. So > > > we augment the behaviour of that driver to only use 12 of the > > > 32 lines. > > > > > > I guess using the remaining 20 lines "works" in a sense but they > > > have no practical use and will just bias electrons in the silicon > > > for no use. > > > > This looks very similar to the case under discussion. > > > > > So if the PWM case is something similar, then by all means add > > > num-pwms. > > > > .. or "npwms" to use the same nomenclature as the gpio binding? > > If we're going to do something like this, should it be the drivers or > the core (within pwmchip_add) that checks for this "npwms" property? Of course this should be done in the core. The driver than can rely on the validity of the index. But as I wrote before, this shouldn't stop your patch from going in. But if Thierry agrees that this npmws (or num-pwms) is a good idea, it would be great to start early to convert drivers. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629
On Thu, 2018-12-13 at 11:39 +0800, Ryder Lee wrote:
> Hi,
>
> On Thu, 2018-12-06 at 09:09 +0800, Jianjun Wang wrote:
> > MT7629 is an arm platform SoC which has the same PCIe IP with MT7622.
> >
> > The read value of BAR0 is 0x_, it's size will be calculated as 4GB
> > in arm64 but bogus alignment values at arm32, the pcie device and devices
> > behind this bridge will not be enabled. Fix it's BAR0 resource size to
> > guarantee the pcie devices will be enabled correctly.
> >
> > The HW default value of its device id is invalid, fix it's device id to
> > match the hardware implementation.
> >
> > Signed-off-by: Jianjun Wang
> > ---
> > drivers/pci/controller/pcie-mediatek.c | 26 ++
> > include/linux/pci_ids.h| 1 +
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mediatek.c
> > b/drivers/pci/controller/pcie-mediatek.c
> > index d20cf461ba00..f8937cc3c87c 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -73,6 +73,7 @@
> > #define PCIE_MSI_VECTOR0x0c0
> >
> > #define PCIE_CONF_VEND_ID 0x100
> > +#define PCIE_CONF_DEVICE_ID0x102
> > #define PCIE_CONF_CLASS_ID 0x106
> >
> > #define PCIE_INT_MASK 0x420
> > @@ -135,12 +136,14 @@ struct mtk_pcie_port;
> > /**
> > * struct mtk_pcie_soc - differentiate between host generations
> > * @need_fix_class_id: whether this host's class ID needed to be fixed or
> > not
> > + * @need_fix_device_id: whether this host's device ID needed to be fixed
> > or not
> > * @ops: pointer to configuration access functions
> > * @startup: pointer to controller setting functions
> > * @setup_irq: pointer to initialize IRQ functions
> > */
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > + bool need_fix_device_id;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -692,6 +695,11 @@ static int mtk_pcie_startup_port_v2(struct
> > mtk_pcie_port *port)
> > writew(val, port->base + PCIE_CONF_CLASS_ID);
> > }
> >
> > + if (soc->need_fix_device_id) {
> > + val = PCI_DEVICE_ID_MEDIATEK_7629;
>
>
> Could we have a generic way to fix it? It's better not to add SoC
> specific settings in shared function.
>
>
Yes, I will modify the code in next patch, thanks.
> > + writew(val, port->base + PCIE_CONF_DEVICE_ID);
> > + }
> > +
> > /* 100ms timeout value should be enough for Gen1/2 training */
> > err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> > !!(val & PCIE_PORT_LINKUP_V2), 20,
> > @@ -1238,11 +1246,29 @@ static const struct mtk_pcie_soc
> > mtk_pcie_soc_mt7622 = {
> > .setup_irq = mtk_pcie_setup_irq,
> > };
> >
> > +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> > + .need_fix_class_id = true,
> > + .need_fix_device_id = true,
> > + .ops = _pcie_ops_v2,
> > + .startup = mtk_pcie_startup_port_v2,
> > + .setup_irq = mtk_pcie_setup_irq,
> > +};
> > +
> > +static void mtk_fixup_bar_size(struct pci_dev *dev)
> > +{
> > + struct resource *dev_res = >resource[0];
> > + /* 32bit resource length will calculate size to 0, set it smaller */
> > + dev_res->end = 0xfffe;
> > +}
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MEDIATEK,
> > PCI_DEVICE_ID_MEDIATEK_7629,
> > +mtk_fixup_bar_size);
> > +
> > static const struct of_device_id mtk_pcie_ids[] = {
> > { .compatible = "mediatek,mt2701-pcie", .data = _pcie_soc_v1 },
> > { .compatible = "mediatek,mt7623-pcie", .data = _pcie_soc_v1 },
> > { .compatible = "mediatek,mt2712-pcie", .data = _pcie_soc_mt2712 },
> > { .compatible = "mediatek,mt7622-pcie", .data = _pcie_soc_mt7622 },
> > + { .compatible = "mediatek,mt7629-pcie", .data = _pcie_soc_mt7629 },
> > {},
> > };
> >
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index 69f0abe1ba1a..77b278bac3a8 100644
> > --- a/include/linux/pci_ids.h
> > +++ b/include/linux/pci_ids.h
> > @@ -2126,6 +2126,7 @@
> > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> >
> > #define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > +#define PCI_DEVICE_ID_MEDIATEK_76290x7629
> >
> > #define PCI_VENDOR_ID_TITAN0x14D2
> > #define PCI_DEVICE_ID_TITAN_010L 0x8001
>
>
[PATCH] irqchip: gic-v3: remove dead code in gic_iterate_rdists
In gic_iterate_rdists, ret will never be 0 when `ret ? -ENODEV : 0` at
the end of function, so let's directly return -ENODEV.
Signed-off-by: Peng Fan
---
drivers/irqchip/irq-gic-v3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 8f87f40c9460..9d6e802e29ce 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -425,7 +425,7 @@ static void __init gic_dist_init(void)
static int gic_iterate_rdists(int (*fn)(struct redist_region *, void __iomem
*))
{
- int ret = -ENODEV;
+ int ret;
int i;
for (i = 0; i < gic_data.nr_redist_regions; i++) {
@@ -459,7 +459,7 @@ static int gic_iterate_rdists(int (*fn)(struct
redist_region *, void __iomem *))
} while (!(typer & GICR_TYPER_LAST));
}
- return ret ? -ENODEV : 0;
+ return -ENODEV;
}
static int __gic_populate_rdist(struct redist_region *region, void __iomem
*ptr)
--
2.14.1
Re: [PATCH v7 6/9] mtd: fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c
Hi Han, On 14.12.18 18:05, Han Xu wrote: > > >> -Original Message- >> From: Schrempf Frieder >> Sent: Tuesday, December 4, 2018 8:15 AM >> To: linux-...@lists.infradead.org; boris.brezil...@bootlin.com; linux- >> s...@vger.kernel.org; Marek Vasut >> Cc: dw...@infradead.org; computersforpe...@gmail.com; >> rich...@nod.at; miquel.ray...@bootlin.com; broo...@kernel.org; David >> Wolfe ; Fabio Estevam ; >> Prabhakar Kushwaha ; Yogesh Narayan >> Gaur ; Han Xu ; >> shawn...@kernel.org; Schrempf Frieder ; >> linux-kernel@vger.kernel.org >> Subject: [PATCH v7 6/9] mtd: fsl-quadspi: Remove the driver as it was >> replaced by spi-fsl-qspi.c >> >> From: Frieder Schrempf >> >> There's a new driver using the SPI memory interface of the SPI framework at >> spi/spi-fsl-qspi.c, which can be used together with m25p80.c to replace the >> functionality of this SPI NOR driver. >> >> The new driver is already in use and this code is not compiled anymore, so >> let's remove it. >> >> Signed-off-by: Frieder Schrempf >> --- >> drivers/mtd/spi-nor/fsl-quadspi.c | 1224 >> 1 file changed, 1224 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl- >> quadspi.c >> deleted file mode 100644 >> index 1ff3430..000 >> --- a/drivers/mtd/spi-nor/fsl-quadspi.c >> +++ /dev/null >> @@ -1,1224 +0,0 @@ >> -/* >> - * Freescale QuadSPI driver. >> - * >> - * Copyright (C) 2013 Freescale Semiconductor, Inc. >> - * >> - * This program is free software; you can redistribute it and/or modify >> - * it under the terms of the GNU General Public License as published by >> - * the Free Software Foundation; either version 2 of the License, or >> - * (at your option) any later version. >> - */ >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> -#include >> - >> -/* Controller needs driver to swap endian */ >> -#define QUADSPI_QUIRK_SWAP_ENDIAN (1 << 0) >> -/* Controller needs 4x internal clock */ >> -#define QUADSPI_QUIRK_4X_INT_CLK(1 << 1) >> -/* >> - * TKT253890, Controller needs driver to fill txfifo till 16 byte to >> - * trigger data transfer even though extern data will not transferred. >> - */ >> -#define QUADSPI_QUIRK_TKT253890 (1 << 2) >> -/* Controller cannot wake up from wait mode, TKT245618 */ >> -#define QUADSPI_QUIRK_TKT245618 (1 << 3) >> - >> -/* The registers */ >> -#define QUADSPI_MCR 0x00 >> -#define QUADSPI_MCR_RESERVED_SHIFT 16 >> -#define QUADSPI_MCR_RESERVED_MASK (0xF << >> QUADSPI_MCR_RESERVED_SHIFT) >> -#define QUADSPI_MCR_MDIS_SHIFT 14 >> -#define QUADSPI_MCR_MDIS_MASK (1 << >> QUADSPI_MCR_MDIS_SHIFT) >> -#define QUADSPI_MCR_CLR_TXF_SHIFT 11 >> -#define QUADSPI_MCR_CLR_TXF_MASK(1 << >> QUADSPI_MCR_CLR_TXF_SHIFT) >> -#define QUADSPI_MCR_CLR_RXF_SHIFT 10 >> -#define QUADSPI_MCR_CLR_RXF_MASK(1 << >> QUADSPI_MCR_CLR_RXF_SHIFT) >> -#define QUADSPI_MCR_DDR_EN_SHIFT7 >> -#define QUADSPI_MCR_DDR_EN_MASK (1 << >> QUADSPI_MCR_DDR_EN_SHIFT) >> -#define QUADSPI_MCR_END_CFG_SHIFT 2 >> -#define QUADSPI_MCR_END_CFG_MASK(3 << >> QUADSPI_MCR_END_CFG_SHIFT) >> -#define QUADSPI_MCR_SWRSTHD_SHIFT 1 >> -#define QUADSPI_MCR_SWRSTHD_MASK(1 << >> QUADSPI_MCR_SWRSTHD_SHIFT) >> -#define QUADSPI_MCR_SWRSTSD_SHIFT 0 >> -#define QUADSPI_MCR_SWRSTSD_MASK(1 << >> QUADSPI_MCR_SWRSTSD_SHIFT) >> - >> -#define QUADSPI_IPCR0x08 >> -#define QUADSPI_IPCR_SEQID_SHIFT24 >> -#define QUADSPI_IPCR_SEQID_MASK (0xF << >> QUADSPI_IPCR_SEQID_SHIFT) >> - >> -#define QUADSPI_BUF0CR 0x10 >> -#define QUADSPI_BUF1CR 0x14 >> -#define QUADSPI_BUF2CR 0x18 >> -#define QUADSPI_BUFXCR_INVALID_MSTRID 0xe >> - >> -#define QUADSPI_BUF3CR 0x1c >> -#define QUADSPI_BUF3CR_ALLMST_SHIFT 31 >> -#define QUADSPI_BUF3CR_ALLMST_MASK (1 << >> QUADSPI_BUF3CR_ALLMST_SHIFT) >> -#define QUADSPI_BUF3CR_ADATSZ_SHIFT 8 >> -#define QUADSPI_BUF3CR_ADATSZ_MASK (0xFF << >> QUADSPI_BUF3CR_ADATSZ_SHIFT) >> - >> -#define QUADSPI_BFGENCR 0x20 >> -#define QUADSPI_BFGENCR_PAR_EN_SHIFT16 >> -#define QUADSPI_BFGENCR_PAR_EN_MASK (1 << >> (QUADSPI_BFGENCR_PAR_EN_SHIFT)) >> -#define QUADSPI_BFGENCR_SEQID_SHIFT 12 >> -#define QUADSPI_BFGENCR_SEQID_MASK (0xF << >> QUADSPI_BFGENCR_SEQID_SHIFT) >> - >> -#define QUADSPI_BUF0IND 0x30 >> -#define QUADSPI_BUF1IND 0x34 >> -#define QUADSPI_BUF2IND 0x38 >> -#define QUADSPI_SFAR0x100 >> - >> -#define QUADSPI_SMPR0x108 >> -#define QUADSPI_SMPR_DDRSMP_SHIFT 16 >> -#define
Re: [PATCH] staging:iio:adc: fix codestyle
The patch prefix should be "staging: iio: adc: ad7280a:". Do
git log --oneline drivers/staging/iio/adc/ad7280a.c and copy what
other people do.
On Mon, Dec 17, 2018 at 04:43:33AM +0300, Sergey Efimochkin wrote:
> staging:iio:adc: fix codestyle
Only to do one thing per patch. We need a better patch description.
> Signed-off-by: Sergey Efimochkin
> ---
> drivers/staging/iio/adc/ad7280a.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7280a.c
> b/drivers/staging/iio/adc/ad7280a.c
> index 58420dcb406d..52e12d1201b3 100644
> --- a/drivers/staging/iio/adc/ad7280a.c
> +++ b/drivers/staging/iio/adc/ad7280a.c
> @@ -706,8 +706,8 @@ static irqreturn_t ad7280_event_handler(int irq, void
> *private)
> st->cell_threshhigh)
> iio_push_event(indio_dev,
> IIO_EVENT_CODE(IIO_VOLTAGE,
> - 1,
> - 0,
> + 1,
> + 0,
> IIO_EV_DIR_RISING,
> IIO_EV_TYPE_THRESH,
> 0, 0, 0),
No. Now the IIO_EV_DIR_RISING, and later columns are not aligned
correctly. Just ignore the checkpatch warning. It's fine as-is.
> @@ -987,6 +985,6 @@ static struct spi_driver ad7280_driver = {
> };
> module_spi_driver(ad7280_driver);
>
> -MODULE_AUTHOR("Michael Hennerich ");
> +MODULE_AUTHOR("Michael Hennerich ");
This change needs to come from Michael. Just leave the code as-is.
regards,
dan carpenter
Re: [PATCH v8 12/26] pwm: jz4740: Allow selection of PWM channels 0 and 1
Hello Paul, On Sun, Dec 16, 2018 at 02:36:03PM +0100, Paul Cercueil wrote: > Le jeu. 13 déc. 2018 à 21:32, Uwe Kleine-König > a écrit : > > On Thu, Dec 13, 2018 at 02:58:31PM +0100, Paul Cercueil wrote: > > > Hi, > > > > > > Le jeu. 13 déc. 2018 à 10:18, Uwe Kleine-König > > > a écrit : > > > > On Wed, Dec 12, 2018 at 11:09:07PM +0100, Paul Cercueil wrote: > > > > > The TCU channels 0 and 1 were previously reserved for system > > > tasks, > > > > > and > > > > > thus unavailable for PWM. > > > > > > > > > > The driver will now only allow a PWM channel to be requested if > > > > > memory > > > > > resources corresponding to the register area of the channel > > > were > > > > > supplied to the driver. This allows the TCU channels to be > > > reserved > > > > > for > > > > > system tasks from within the devicetree. > > > > > > > > > > Signed-off-by: Paul Cercueil > > > > > > > > While there is someone caring for this driver I'd like to > > > complete (a > > > > bit) my picture about the different capabilities and specialities > > > of the > > > > supported PWMs. So I have a few questions: > > > > > > > > Is there a publicly available reference manual for this device? > > > (If > > > > yes, adding a link to the driver would be great.) > > > > > > I have them here: https://zcrc.me/~paul/jz_docs/ > > > > Is this link good enough to add it to the driver? From a quick view I'd > > say this is another pwm implementation that gets active on > > pwm_disable(). > > Can you confirm this? > > It's my website, so if these get moved, I can update the link. > > What do you mean it gets active on pwm_disable()? If pwm_disable() gets > called the PWM line goes back to inactive state, which is what it > should do. The register description for TCSRn.PWM_EN reads: 1: PWM pin output enable 0: PWM pin output disable, and the PWM pin will be set to the initial level according to INITL As I read the manual (but that differes from the driver) you should use INITL=1 for an uninverted PWM such that the period starts with the output being 1. And with that I'd expect that the output goes high on disable. Given that the driver inverts this and sets INITL (called JZ_TIMER_CTRL_PWM_ACTIVE_LOW in the driver) for an inverted pwm that behaviour is ok. With this approach the bug is not the level when pwm_disable was called but that the period doesn't start with the active part of the period. > > > > jz4740_pwm_config looks as if the currently running period isn't > > > > completed before the new config is in effect. Is that correct? If > > > yes, > > > > can this be fixed? A similar question for set_polarity: Does > > > setting the > > > > JZ_TIMER_CTRL_PWM_ACTIVE_LOW bit in the control register take > > > effect > > > > immediately or is this shadowed until the next period starts? > > > > > > I don't really know. We only use this driver for a rumble motor and > > > backlight. > > > Somebody would have to check with a logic analyzer. > > > > depending on the possible timings you might also be able to test this > > e.g. by setting: > > > > duty_cycle=1ms, period=5s > > > > and then > > > > duty_cycle=5s, period=5s > > > > . If the implementation is right your display should be dark for nearly > > 5 seconds. (And the second call to pwm_apply should also block until the > > display is on.) > > So it switches to full ON as soon as I set the duty cycle to 5s. Same for > the polarity, it is updated as soon as the register is written. So the > registers are not shadowed. Then I think the right thing to do is to gracefully disable the hardware on a duty/period change first to ensure the currently running period is completed before the next configuration gets active. > > > > How does the device's output behave after the PWM is disabled? > > > > Does it complete the currently running period? How does the output > > > > behave then? (active/inactive/high/low/high-z?) > > > > > > There's a bit to toggle between "graceful" shutdown (bit clear) and > > > "abrupt" > > > shutdown (bit set). TCSR bit 9. I think that graceful shutdown will > > > complete > > > the running period, then keep the level active. Abrupt shutdown > > > will keep > > > the > > > current level of the line. > > > > Can you confirm the things you think above? I'd like to have them > > eventually documented in the driver. > > From what I can see, with "abrupt" shutdown the line will always return to > its inactive state (be it low or high, depending on the polarity). Setting > this bit to "graceful" shutdown, the only difference is that the hardware > will keep its current state, active or inactive. That's why we use the > "abrupt" shutdown in the PWM driver. That sounds backwards from your last mail and the reference manual. As I read the manual "graceful" means the period is completed until FULL matches. And I understand "aprupt" as "immediatly freeze". If this is the case the
Re: [PATCH v3 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs
On Sun, Dec 16, 2018 at 9:03 PM Baruch Siach wrote: > > Hi Andrey, > > Andrey Smirnov writes: > > The driver now supports i.MX8MQ, so update bindings accordingly. > > > > Cc: p.za...@pengutronix.de > > Cc: Fabio Estevam > > Cc: cphe...@gmail.com > > Cc: l.st...@pengutronix.de > > Cc: Leonard Crestez > > Cc: "A.s. Dong" > > Cc: Richard Zhu > > Cc: Rob Herring > > Cc: devicet...@vger.kernel.org > > Cc: linux-...@nxp.com > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Andrey Smirnov > > --- > > .../bindings/reset/fsl,imx7-src.txt | 7 +- > > include/dt-bindings/reset/imx8mq-reset.h | 64 +++ > > This header file belongs at the next patch in this series, right? > I was asked to move it here, see lkml.kernel.org/r/20181211224349.GA30397@bogus Thanks, Andrey Smirnov
Re: [PATCH 1/3] 9p/net: implement asynchronous rpc
Hey Dominique,
sorry for the delay, I've been quite busy these days.
The patches looks good to me and should indeed speed up the code a bit.
I quickly tested them against Syzkaller tuned for the 9p subsystem and
everything seems fine.
And by the way, which refcount races?
Cheers,
Tomas
On 12/11/18 1:41 PM, Dominique Martinet wrote:
> From: Dominique Martinet
>
> Add p9_client_async_rpc that will let us send an rpc without waiting
> for the reply, as well as an async handler hook.
>
> The work done in the hook could mostly be done in the client callback,
> but I prefered not to for a couple of reasons:
> - the callback can be called in an IRQ for some transports, and the
> handler needs to call p9_tag_remove which takes the client lock that has
> recently been reworked to not be irq-compatible (as it was never taken
> in IRQs until now)
> - the handled replies can be handled anytime, there is nothing the
> userspace would care about and want to be notified of quickly
> - the async request list and this function would be needed anyway for
> when we disconnect the client, in order to not leak async requests that
> haven't been replied to
>
> Signed-off-by: Dominique Martinet
> Cc: Eric Van Hensbergen
> Cc: Latchesar Ionkov
> Cc: Tomas Bortoli
> Cc: Dmitry Vyukov
> ---
>
> I've been sitting on these patches for almost a month now because I
> wanted to fix the cancel race, but I think it's what the most recent
> syzbot email is about so if it could find it without this it probably
> won't hurt to at least get some reviews for these three patches first.
>
> I won't submit these for next cycle, so will only put them into -next
> after 4.20 is released; hopefully I'll have time to look at the two
> pending refcount races around that time.
> Until then, comments please!
>
>
> include/net/9p/client.h | 9 +-
> net/9p/client.c | 64 +
> 2 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/9p/client.h b/include/net/9p/client.h
> index 947a570307a6..a4ded7666c73 100644
> --- a/include/net/9p/client.h
> +++ b/include/net/9p/client.h
> @@ -89,7 +89,8 @@ enum p9_req_status_t {
> * @tc: the request fcall structure
> * @rc: the response fcall structure
> * @aux: transport specific data (provided for trans_fd migration)
> - * @req_list: link for higher level objects to chain requests
> + * @req_list: link used by trans_fd
> + * @async_list: link used to check on async requests
> */
> struct p9_req_t {
> int status;
> @@ -100,6 +101,7 @@ struct p9_req_t {
> struct p9_fcall rc;
> void *aux;
> struct list_head req_list;
> + struct list_head async_list;
> };
>
> /**
> @@ -110,6 +112,9 @@ struct p9_req_t {
> * @trans_mod: module API instantiated with this client
> * @status: connection state
> * @trans: tranport instance state and API
> + * @fcall_cache: kmem cache for client request data (msize-specific)
> + * @async_req_lock: protects @async_req_list
> + * @async_req_list: list of requests waiting a reply
> * @fids: All active FID handles
> * @reqs: All active requests.
> * @name: node name used as client id
> @@ -125,6 +130,8 @@ struct p9_client {
> enum p9_trans_status status;
> void *trans;
> struct kmem_cache *fcall_cache;
> + spinlock_t async_req_lock;
> + struct list_head async_req_list;
>
> union {
> struct {
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 357214a51f13..0a67c3ccd4fd 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -729,6 +729,62 @@ static struct p9_req_t *p9_client_prepare_req(struct
> p9_client *c,
> return ERR_PTR(err);
> }
>
> +static struct p9_req_t *
> +p9_client_async_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
> +{
> + va_list ap;
> + int err;
> + struct p9_req_t *req;
> +
> + va_start(ap, fmt);
> + req = p9_client_prepare_req(c, type, c->msize, fmt, ap);
> + va_end(ap);
> + if (IS_ERR(req))
> + return req;
> +
> + err = c->trans_mod->request(c, req);
> + if (err < 0) {
> + /* bail out without flushing... */
> + p9_req_put(req);
> + p9_tag_remove(c, req);
> + if (err != -ERESTARTSYS && err != -EFAULT)
> + c->status = Disconnected;
> + return ERR_PTR(safe_errno(err));
> + }
> +
> + return req;
> +}
> +
> +static void p9_client_handle_async(struct p9_client *c, bool free_all)
> +{
> + struct p9_req_t *req, *nreq;
> +
> + /* it's ok to miss some async replies here, do a quick check without
> + * lock first unless called with free_all
> + */
> + if (!free_all && list_empty(>async_req_list))
> + return;
> +
> + spin_lock_irq(>async_req_lock);
> + list_for_each_entry_safe(req, nreq, >async_req_list, async_list) {
> + if (free_all && req->status < REQ_STATUS_RCVD) {
> +
Re: [PATCH 1/3] 9p/net: implement asynchronous rpc
Hey Dominique,
sorry for the delay, I've been quite busy these days.
The patches looks good to me and should indeed speed up the code a bit.
I quickly tested them against Syzkaller tuned for the 9p subsystem and
everything seems fine.
And by the way, which refcount races?
Cheers,
Tomas
On 12/11/18 1:41 PM, Dominique Martinet wrote:
> From: Dominique Martinet
>
> Add p9_client_async_rpc that will let us send an rpc without waiting
> for the reply, as well as an async handler hook.
>
> The work done in the hook could mostly be done in the client callback,
> but I prefered not to for a couple of reasons:
> - the callback can be called in an IRQ for some transports, and the
> handler needs to call p9_tag_remove which takes the client lock that has
> recently been reworked to not be irq-compatible (as it was never taken
> in IRQs until now)
> - the handled replies can be handled anytime, there is nothing the
> userspace would care about and want to be notified of quickly
> - the async request list and this function would be needed anyway for
> when we disconnect the client, in order to not leak async requests that
> haven't been replied to
>
> Signed-off-by: Dominique Martinet
> Cc: Eric Van Hensbergen
> Cc: Latchesar Ionkov
> Cc: Tomas Bortoli
> Cc: Dmitry Vyukov
> ---
>
> I've been sitting on these patches for almost a month now because I
> wanted to fix the cancel race, but I think it's what the most recent
> syzbot email is about so if it could find it without this it probably
> won't hurt to at least get some reviews for these three patches first.
>
> I won't submit these for next cycle, so will only put them into -next
> after 4.20 is released; hopefully I'll have time to look at the two
> pending refcount races around that time.
> Until then, comments please!
>
>
> include/net/9p/client.h | 9 +-
> net/9p/client.c | 64 +
> 2 files changed, 72 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/9p/client.h b/include/net/9p/client.h
> index 947a570307a6..a4ded7666c73 100644
> --- a/include/net/9p/client.h
> +++ b/include/net/9p/client.h
> @@ -89,7 +89,8 @@ enum p9_req_status_t {
> * @tc: the request fcall structure
> * @rc: the response fcall structure
> * @aux: transport specific data (provided for trans_fd migration)
> - * @req_list: link for higher level objects to chain requests
> + * @req_list: link used by trans_fd
> + * @async_list: link used to check on async requests
> */
> struct p9_req_t {
> int status;
> @@ -100,6 +101,7 @@ struct p9_req_t {
> struct p9_fcall rc;
> void *aux;
> struct list_head req_list;
> + struct list_head async_list;
> };
>
> /**
> @@ -110,6 +112,9 @@ struct p9_req_t {
> * @trans_mod: module API instantiated with this client
> * @status: connection state
> * @trans: tranport instance state and API
> + * @fcall_cache: kmem cache for client request data (msize-specific)
> + * @async_req_lock: protects @async_req_list
> + * @async_req_list: list of requests waiting a reply
> * @fids: All active FID handles
> * @reqs: All active requests.
> * @name: node name used as client id
> @@ -125,6 +130,8 @@ struct p9_client {
> enum p9_trans_status status;
> void *trans;
> struct kmem_cache *fcall_cache;
> + spinlock_t async_req_lock;
> + struct list_head async_req_list;
>
> union {
> struct {
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 357214a51f13..0a67c3ccd4fd 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -729,6 +729,62 @@ static struct p9_req_t *p9_client_prepare_req(struct
> p9_client *c,
> return ERR_PTR(err);
> }
>
> +static struct p9_req_t *
> +p9_client_async_rpc(struct p9_client *c, int8_t type, const char *fmt, ...)
> +{
> + va_list ap;
> + int err;
> + struct p9_req_t *req;
> +
> + va_start(ap, fmt);
> + req = p9_client_prepare_req(c, type, c->msize, fmt, ap);
> + va_end(ap);
> + if (IS_ERR(req))
> + return req;
> +
> + err = c->trans_mod->request(c, req);
> + if (err < 0) {
> + /* bail out without flushing... */
> + p9_req_put(req);
> + p9_tag_remove(c, req);
> + if (err != -ERESTARTSYS && err != -EFAULT)
> + c->status = Disconnected;
> + return ERR_PTR(safe_errno(err));
> + }
> +
> + return req;
> +}
> +
> +static void p9_client_handle_async(struct p9_client *c, bool free_all)
> +{
> + struct p9_req_t *req, *nreq;
> +
> + /* it's ok to miss some async replies here, do a quick check without
> + * lock first unless called with free_all
> + */
> + if (!free_all && list_empty(>async_req_list))
> + return;
> +
> + spin_lock_irq(>async_req_lock);
> + list_for_each_entry_safe(req, nreq, >async_req_list, async_list) {
> + if (free_all && req->status < REQ_STATUS_RCVD) {
> +
Re: [PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE
Hello Marcin, On Mon, 17 Dec 2018 00:25:58 +0100, Marcin Wojtas wrote: > Thanks. Indeed, the patch is valid as a fix for current version of SW > BM. However, because this concept is broken, I will rework it and > submit patch/patches some time early 2019. I know some people are working on XDP support in mvneta, and this work also needs to change parts of the memory allocation strategy in this driver. I'd suggest to get in touch with those folks. Antoine can give you the contact details, I don't have them off-hand. Or perhaps they will see this e-mail :-) Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] mailbox: imx: Fix clk handling in imx_mu_probe()
On 17.12.18 08:24, Alexey Khoroshilov wrote:
Hi Oleksij,
By chance I took a look at another implementations:
arch/arm/mach-ep93xx/clock.c#L266
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (!clk)
return -EINVAL;
...
arch/c6x/platforms/pll.c#L48
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (clk == NULL || IS_ERR(clk))
return -EINVAL;
So, I am not sure the NULL resistance is a part of the clk_enable()
contract?
Main framework is always preferred. If some local code provide
replacement of a functions already provided by the clk framework and not
follow same rules, then this code should be fixed. If this code is even
exporting this function for global use, then it is probably buggy.
And if i see it correctly:
1d81eedb8f6c1 (Lennert Buytenhek 2006-06-24 10:33:02 +0100 266) int
clk_enable(struct clk *clk)
It is ancient code... it just can't be correct.
--
Alexey
On 17.12.2018 9:01, Oleksij Rempel wrote:
Hi Alexey,
On Sun, Dec 16, 2018 at 02:01:44AM +0300, Alexey Khoroshilov wrote:
Handling of devm_clk_get() suggests that the driver should support
lack of priv->clk. But imx_mu_probe() fails on clk_prepare_enable(NULL)
in that case.
The patch removes the try to enable absent clk and adds error handling
for mbox_controller_register().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/mailbox/imx-mailbox.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 363d35d5e49d..ddde398f576e 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -292,10 +292,12 @@ static int imx_mu_probe(struct platform_device *pdev)
priv->clk = NULL;
}
- ret = clk_prepare_enable(priv->clk);
- if (ret) {
- dev_err(dev, "Failed to enable clock\n");
- return ret;
+ if (priv->clk) {
+ ret = clk_prepare_enable(priv->clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable clock\n");
+ return ret;
+ }
}
for (i = 0; i < IMX_MU_CHANS; i++) {
@@ -324,7 +326,13 @@ static int imx_mu_probe(struct platform_device *pdev)
imx_mu_init_generic(priv);
- return mbox_controller_register(>mbox);
+ ret = mbox_controller_register(>mbox);
+ if (ret) {
+ clk_disable_unprepare(priv->clk);
+ return ret;
+ }
+
+ return 0;
}
static int imx_mu_remove(struct platform_device *pdev)
--
2.7.4
NACK for this patch.
Here are code snippets from clk framework:
/* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
static inline int clk_prepare_enable(struct clk *clk)
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
}
int clk_prepare(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_prepare_lock(clk->core);
}
int clk_enable(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_enable_lock(clk->core);
}
As you can see, complete code path is NULL resistant. Are you trying to
fix some real issue, or it is a theoretical work?
Re: Elantech SMBus support regression
Hi, > On Dec 12, 2018, at 22:25, Benjamin Tissoires > wrote: > > Hi, > > sorry for the late reply. I was always meaning to fix this the proper > way but couldn't dedicate a full day of work to go to the bottom of > elan_i2c. > > Meanwhile, I am thinking at simply having a blacklist of devices that > we know are not working well (P52, L480, L580 and P72). > > Could you get the value of /sys/bus/serio/devices/serio1/firmware_id > from all of these laptops? > I know the P52 is LEN2131, but I don't seem to find the other PNPIds. These are feedbacks from the users: L480: cat /sys/bus/serio/devices/serio1/firmware_id PNP: LEN2036 PNP0f13 P52: "cat /sys/bus/serio/devices/serio1/firmware_id": PNP: LEN2132 PNP0f13 So looks like it’s different to LEN2131. Kai-Heng > > Cheers, > Benjamin > > On Thu, Nov 22, 2018 at 5:22 AM Kai Heng Feng > wrote: >> >> Hi Benjamin, >> >> It appears the Elantech SMBus support breaks some users’ touchpad. >> >> Please have a look at [1] [2], thanks! >> >> [1] https://bugs.launchpad.net/bugs/1803600 >> [2] https://bugs.archlinux.org/task/59714 >> >> Kai-Heng
Re: [PATCH] mailbox: imx: Fix clk handling in imx_mu_probe()
Hi Oleksij,
By chance I took a look at another implementations:
arch/arm/mach-ep93xx/clock.c#L266
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (!clk)
return -EINVAL;
...
arch/c6x/platforms/pll.c#L48
int clk_enable(struct clk *clk)
{
unsigned long flags;
if (clk == NULL || IS_ERR(clk))
return -EINVAL;
So, I am not sure the NULL resistance is a part of the clk_enable()
contract?
--
Alexey
On 17.12.2018 9:01, Oleksij Rempel wrote:
> Hi Alexey,
>
> On Sun, Dec 16, 2018 at 02:01:44AM +0300, Alexey Khoroshilov wrote:
>> Handling of devm_clk_get() suggests that the driver should support
>> lack of priv->clk. But imx_mu_probe() fails on clk_prepare_enable(NULL)
>> in that case.
>>
>> The patch removes the try to enable absent clk and adds error handling
>> for mbox_controller_register().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Alexey Khoroshilov
>> ---
>> drivers/mailbox/imx-mailbox.c | 18 +-
>> 1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>> index 363d35d5e49d..ddde398f576e 100644
>> --- a/drivers/mailbox/imx-mailbox.c
>> +++ b/drivers/mailbox/imx-mailbox.c
>> @@ -292,10 +292,12 @@ static int imx_mu_probe(struct platform_device *pdev)
>> priv->clk = NULL;
>> }
>>
>> -ret = clk_prepare_enable(priv->clk);
>> -if (ret) {
>> -dev_err(dev, "Failed to enable clock\n");
>> -return ret;
>> +if (priv->clk) {
>> +ret = clk_prepare_enable(priv->clk);
>> +if (ret) {
>> +dev_err(dev, "Failed to enable clock\n");
>> +return ret;
>> +}
>> }
>>
>> for (i = 0; i < IMX_MU_CHANS; i++) {
>> @@ -324,7 +326,13 @@ static int imx_mu_probe(struct platform_device *pdev)
>>
>> imx_mu_init_generic(priv);
>>
>> -return mbox_controller_register(>mbox);
>> +ret = mbox_controller_register(>mbox);
>> +if (ret) {
>> +clk_disable_unprepare(priv->clk);
>> +return ret;
>> +}
>> +
>> +return 0;
>> }
>>
>> static int imx_mu_remove(struct platform_device *pdev)
>> --
>> 2.7.4
>>
>>
>
> NACK for this patch.
>
> Here are code snippets from clk framework:
>
> /* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
> static inline int clk_prepare_enable(struct clk *clk)
> {
> int ret;
>
> ret = clk_prepare(clk);
> if (ret)
> return ret;
> ret = clk_enable(clk);
> if (ret)
> clk_unprepare(clk);
>
> return ret;
> }
>
> int clk_prepare(struct clk *clk)
> {
> if (!clk)
> return 0;
>
> return clk_core_prepare_lock(clk->core);
> }
>
> int clk_enable(struct clk *clk)
> {
> if (!clk)
> return 0;
>
> return clk_core_enable_lock(clk->core);
> }
>
>
> As you can see, complete code path is NULL resistant. Are you trying to
> fix some real issue, or it is a theoretical work?
>
Re: [PATCH V1] mmc: tegra: HW Command Queue Support for Tegra SDMMC
On Sat, 15 Dec 2018 at 01:22, Sowjanya Komatineni
wrote:
>
> This patch adds HW Command Queue for supported Tegra SDMMC
> controllers.
>
> Tegra SDHCI with Quirk SDHCI_QUIRK2_BROKEN_64_BIT_DMA disables the
> use of 64_BIT DMA to disable 64-bit addressing mode access to the
> system memory and sdhci_cqe_enable using flag SDHCI_USE_64_BIT_DMA
> for ADMA32/ADMA2 Vs ADMA64/ADMA3 DMA selection.
>
> CQE need to use ADMA3 as it need to fetch task descriptor along
> with transfer descriptor, so this patch forces DMA Select to be
> ADMA3 for CQE.
>
> Note that this patch depends on below patches
> [0] DMA Config prior to CQE
> https://lkml.org/lkml/2018/12/14/1062
> [1] SDMMC address range
> https://lkml.org/lkml/2018/12/14/1323
> [2] Fix sdhci_do_enable_v4_mode
> https://lkml.org/lkml/2018/12/14/72
Can you please collect these into a series and while re-posting make
sure to also have a cover letter.
This makes 0-day builds build to pick up the decency, but also helps
when reviewing.
Kind regards
Uffe
>
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/mmc/host/sdhci-tegra.c | 76
> +-
> drivers/mmc/host/sdhci.c | 18 +-
> drivers/mmc/host/sdhci.h | 1 +
> 3 files changed, 93 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 7b95d088fdef..eaebe5e22183 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -33,6 +33,7 @@
> #include
>
> #include "sdhci-pltfm.h"
> +#include "cqhci.h"
>
> /* Tegra SDHOST controller vendor register definitions */
> #define SDHCI_TEGRA_VENDOR_CLOCK_CTRL 0x100
> @@ -89,6 +90,10 @@
> #define NVQUIRK_NEEDS_PAD_CONTROL BIT(7)
> #define NVQUIRK_DIS_CARD_CLK_CONFIG_TAPBIT(8)
>
> +/* SDMMC CQE Base Address for Tegra Host Ver 4.1 and Higher */
> +#define SDHCI_TEGRA_CQE_BASE_ADDR 0xF000
> +
> +
> struct sdhci_tegra_soc_data {
> const struct sdhci_pltfm_data *pdata;
> u32 nvquirks;
> @@ -128,6 +133,7 @@ struct sdhci_tegra {
> u32 default_tap;
> u32 default_trim;
> u32 dqs_trim;
> + bool enable_hwcq;
> };
>
> static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
> @@ -836,6 +842,17 @@ static void tegra_sdhci_voltage_switch(struct sdhci_host
> *host)
> tegra_host->pad_calib_required = true;
> }
>
> +static void sdhci_tegra_dumpregs(struct mmc_host *mmc)
> +{
> + sdhci_dumpregs(mmc_priv(mmc));
> +}
> +
> +static const struct cqhci_host_ops sdhci_tegra_cqhci_ops = {
> + .enable = sdhci_cqe_enable,
> + .disable = sdhci_cqe_disable,
> + .dumpregs = sdhci_tegra_dumpregs,
> +};
> +
> static const struct sdhci_ops tegra_sdhci_ops = {
> .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> @@ -989,6 +1006,7 @@ static const struct sdhci_ops tegra186_sdhci_ops = {
> .set_uhs_signaling = tegra_sdhci_set_uhs_signaling,
> .voltage_switch = tegra_sdhci_voltage_switch,
> .get_max_clock = tegra_sdhci_get_max_clock,
> + .irq = sdhci_cqhci_irq,
> };
>
> static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
> @@ -1030,6 +1048,55 @@ static const struct of_device_id
> sdhci_tegra_dt_match[] = {
> };
> MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
>
> +static int sdhci_tegra_add_host(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
> + struct cqhci_host *cq_host;
> + bool dma64;
> + int ret;
> +
> + if (!tegra_host->enable_hwcq)
> + return sdhci_add_host(host);
> +
> + host->v4_mode = true;
> +
> + ret = sdhci_setup_host(host);
> + if (ret)
> + return ret;
> +
> + host->mmc->caps2 |= MMC_CAP2_CQE | MMC_CAP2_CQE_DCMD;
> +
> + cq_host = devm_kzalloc(host->mmc->parent,
> + sizeof(*cq_host), GFP_KERNEL);
> + if (!cq_host) {
> + ret = -ENOMEM;
> + goto cleanup;
> + }
> +
> + cq_host->mmio = host->ioaddr + SDHCI_TEGRA_CQE_BASE_ADDR;
> + cq_host->ops = _tegra_cqhci_ops;
> +
> + dma64 = host->flags & SDHCI_USE_64_BIT_DMA;
> + if (dma64)
> + cq_host->caps |= CQHCI_TASK_DESC_SZ_128;
> +
> + ret = cqhci_init(cq_host, host->mmc, dma64);
> + if (ret)
> + goto cleanup;
> +
> + ret = __sdhci_add_host(host);
> + if (ret)
> + goto cleanup;
> +
> + return 0;
> +
> +cleanup:
> + sdhci_cleanup_host(host);
> + return ret;
> +
> +}
> +
> static int sdhci_tegra_probe(struct platform_device *pdev)
> {
> const struct of_device_id *match;
> @@ -1039,6 +1106,7 @@ static int sdhci_tegra_probe(struct platform_device
Re: kernel BUG at fs/inode.c:LINE!
On Sun, Dec 16, 2018 at 10:11:04PM -0800, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 > kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 > dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com > > slab_pre_alloc_hook mm/slab.h:423 [inline] > slab_alloc mm/slab.c:3365 [inline] > kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 > __d_alloc+0xc8/0xb90 fs/dcache.c:1599 > [ cut here ] > kernel BUG at fs/inode.c:1566! > d_alloc_anon fs/dcache.c:1698 [inline] > d_make_root+0x43/0xc0 fs/dcache.c:1885 > autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 Huh? BUG is in iput(), AFAICS, so the stack trace is rather misreported. iput() can be called by d_make_root(), provided that dentry allocation fails. So the most straightforward interpretation would be that we had an allocation failure (injected?), followed by iput() of the inode passed to d_make_root(). Which happened to find I_CLEAR in ->i_state of that inode somehow, which should be impossible short of seriously buggered inode refcounting somewhere - the inode has just been returned by new_inode(), which clears i_state, and it would have to have passed clear_inode() (i.e. has been through inode eviction) since then...
Re: KMSAN: uninit-value in __inet6_bind
syzbot has found a reproducer for the following crash on: HEAD commit:0a602458c72c kmsan: random: another take at unpoisoning CR.. git tree: https://github.com/google/kmsan.git/master console output: https://syzkaller.appspot.com/x/log.txt?x=129e103540 kernel config: https://syzkaller.appspot.com/x/.config?x=9b071100dcf8e641 dashboard link: https://syzkaller.appspot.com/bug?extid=c56449ed3652e6720f30 compiler: clang version 8.0.0 (trunk 348261) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10a97b2b40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108ec72b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c56449ed3652e6720...@syzkaller.appspotmail.com audit: type=1800 audit(1545030606.944:30): pid=6407 uid=0 auid=4294967295 ses=4294967295 subj==unconfined op=collect_data cause=failed(directio) comm="startpar" name="rmnologin" dev="sda1" ino=2423 res=0 Started in network mode Own node identity fe8000bb, cluster identity 4711 == BUG: KMSAN: uninit-value in __inet6_bind+0xb35/0x1a30 net/ipv6/af_inet6.c:340 CPU: 1 PID: 6557 Comm: syz-executor447 Not tainted 4.20.0-rc5+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:113 kmsan_report+0x12d/0x290 mm/kmsan/kmsan.c:682 __msan_warning+0x76/0xc0 mm/kmsan/kmsan_instr.c:316 __inet6_bind+0xb35/0x1a30 net/ipv6/af_inet6.c:340 inet6_bind+0x206/0x300 net/ipv6/af_inet6.c:441 kernel_bind+0xc6/0xf0 net/socket.c:3230 udp_sock_create6+0x2ee/0x890 net/ipv6/ip6_udp_tunnel.c:39 udp_sock_create include/net/udp_tunnel.h:61 [inline] tipc_udp_enable+0x166f/0x1d70 net/tipc/udp_media.c:742 tipc_enable_bearer net/tipc/bearer.c:302 [inline] __tipc_nl_bearer_enable+0x1213/0x1da0 net/tipc/bearer.c:897 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:905 genl_family_rcv_msg net/netlink/genetlink.c:601 [inline] genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626 netlink_rcv_skb+0x444/0x640 net/netlink/af_netlink.c:2477 genl_rcv+0x63/0x80 net/netlink/genetlink.c:637 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0xf80/0x1060 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x129d/0x1310 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg net/socket.c:631 [inline] ___sys_sendmsg+0xdbc/0x11d0 net/socket.c:2116 __sys_sendmsg net/socket.c:2154 [inline] __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg+0x305/0x460 net/socket.c:2161 __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2161 do_syscall_64+0xcd/0x110 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x63/0xe7 RIP: 0033:0x444199 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 1b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe96b1eb28 EFLAGS: 0213 ORIG_RAX: 002e RAX: ffda RBX: 004002e0 RCX: 00444199 RDX: RSI: 28c0 RDI: 0003 RBP: 006ce018 R08: R09: 004002e0 R10: R11: 0213 R12: 00401e40 R13: 00401ed0 R14: R15: Local variable description: udp6_addr@udp_sock_create6 Variable was created at: udp_sock_create6+0x80/0x890 net/ipv6/ip6_udp_tunnel.c:17 udp_sock_create include/net/udp_tunnel.h:61 [inline] tipc_udp_enable+0x166f/0x1d70 net/tipc/udp_media.c:742 ==
divide error in alarm_forward
Hello, syzbot found the following crash on: HEAD commit:6531e115b7ab Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10c68f6d40 kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 dashboard link: https://syzkaller.appspot.com/bug?extid=9d38bedac9cc77b8ad5e compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+9d38bedac9cc77b8a...@syzkaller.appspotmail.com divide error: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8629 Comm: syz-executor0 Not tainted 4.20.0-rc6+ #374 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ktime_divns include/linux/ktime.h:172 [inline] RIP: 0010:alarm_forward+0xe7/0x180 kernel/time/alarmtimer.c:458 Code: 41 5d 41 5e 41 5f 5d c3 e8 56 44 10 00 31 ff 4c 89 ee e8 7c 45 10 00 4d 85 ed 78 62 e8 42 44 10 00 48 89 d8 48 8b 4d c8 48 99 <49> f7 fd 48 89 c3 49 89 c6 48 ba 00 00 00 00 00 fc ff df 49 0f af RSP: 0018:8881b85b77e0 EFLAGS: 00010046 RAX: 8a1c RBX: 8a1c RCX: 8881b88e8aa0 RDX: RSI: 816f402e RDI: 0007 RBP: 8881b85b7820 R08: 8881b85a8040 R09: 0004 R10: fbfff14a7409 R11: 0001 R12: 8881b88e8a88 R13: R14: 0001 R15: 003d6987822d FS: 7f31b5e40700() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f31b5e1edb8 CR3: 0001b9024000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: alarm_forward_now kernel/time/alarmtimer.c:481 [inline] alarm_timer_rearm+0xbb/0x150 kernel/time/alarmtimer.c:575 posixtimer_rearm+0x200/0x3e0 kernel/time/posix-timers.c:321 dequeue_signal+0x1b0/0x630 kernel/signal.c:680 signalfd_dequeue fs/signalfd.c:173 [inline] signalfd_read+0x295/0x7f0 fs/signalfd.c:226 __vfs_read+0x117/0x9b0 fs/read_write.c:416 vfs_read+0x17f/0x3c0 fs/read_write.c:452 ksys_read+0x101/0x260 fs/read_write.c:578 __do_sys_read fs/read_write.c:588 [inline] __se_sys_read fs/read_write.c:586 [inline] __x64_sys_read+0x73/0xb0 fs/read_write.c:586 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457669 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f31b5e3fc78 EFLAGS: 0246 ORIG_RAX: RAX: ffda RBX: 0003 RCX: 00457669 RDX: 0ae3f1a6 RSI: 2080 RDI: 0005 RBP: 0072bfa0 R08: R09: R10: R11: 0246 R12: 7f31b5e406d4 R13: 004c2b0b R14: 004d6608 R15: Modules linked in: ---[ end trace a0d2cc178e3c2817 ]--- RIP: 0010:ktime_divns include/linux/ktime.h:172 [inline] RIP: 0010:alarm_forward+0xe7/0x180 kernel/time/alarmtimer.c:458 Code: 41 5d 41 5e 41 5f 5d c3 e8 56 44 10 00 31 ff 4c 89 ee e8 7c 45 10 00 4d 85 ed 78 62 e8 42 44 10 00 48 89 d8 48 8b 4d c8 48 99 <49> f7 fd 48 89 c3 49 89 c6 48 ba 00 00 00 00 00 fc ff df 49 0f af RSP: 0018:8881b85b77e0 EFLAGS: 00010046 RAX: 8a1c RBX: 8a1c RCX: 8881b88e8aa0 RDX: RSI: 816f402e RDI: 0007 RBP: 8881b85b7820 R08: 8881b85a8040 R09: 0004 R10: fbfff14a7409 R11: 0001 R12: 8881b88e8a88 R13: R14: 0001 R15: 003d6987822d FS: 7f31b5e40700() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f31b5e1edb8 CR3: 0001b9024000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
[PATCH 0/3] arm64: kprobes: Fix blacklist checking on arm64
Hello, Here is a short series about fixing kprobe blacklist checking on arm64. I found that some blacklist checking code were mis-placed in arch_prepare_kprobe() and arch_within_kprobe_blacklist(). Some sub-function (instruction-level) accept/decline check should be done in arch_prepare_kprobe() and that should not be in the blacklist. Also, all function (symbol) level check must be done by blacklist. For arm64, it checks the extable entry address in blacklist and exception/irqentry function in arch_prepare_kprobe(). Moreover, RODATA check is unneeded since kernel/kprobes.c already ensures the probe address is in kernel-text area. Thank you, --- Masami Hiramatsu (3): arm64: kprobes: Move extable address check into arch_prepare_kprobe() arm64: kprobes: Remove unneeded RODATA check arm64: kprobes: Move exception_text check in blacklist arch/arm64/kernel/probes/kprobes.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) -- Signature
[PATCH 1/3] arm64: kprobes: Move extable address check into arch_prepare_kprobe()
Move extable address check into arch_prepare_kprobe() from
arch_within_kprobe_blacklist().
Please do not blacklisting instructions on exception_table,
since it is a kind of architectural unsupported instruction.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index 2a5b338b2542..b2d4b7428ebc 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -102,6 +102,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
if (in_exception_text(probe_addr))
return -EINVAL;
+
+ if (search_exception_tables(probe_addr))
+ return -EINVAL;
+
if (probe_addr >= (unsigned long) __start_rodata &&
probe_addr <= (unsigned long) __end_rodata)
return -EINVAL;
@@ -477,8 +481,7 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
(addr >= (unsigned long)__entry_text_start &&
addr < (unsigned long)__entry_text_end) ||
(addr >= (unsigned long)__idmap_text_start &&
- addr < (unsigned long)__idmap_text_end) ||
- !!search_exception_tables(addr))
+ addr < (unsigned long)__idmap_text_end))
return true;
if (!is_kernel_in_hyp_mode()) {
[PATCH 2/3] arm64: kprobes: Remove unneeded RODATA check
Remove unneeded RODATA check from arch_prepare_kprobe().
Since check_kprobe_address_safe() already ensured that
the probe address is in kernel text, we don't need to
check whether the address in RODATA or not. That must
be always false.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index b2d4b7428ebc..1dae500d0a81 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -91,8 +91,6 @@ static void __kprobes arch_simulate_insn(struct kprobe *p,
struct pt_regs *regs)
int __kprobes arch_prepare_kprobe(struct kprobe *p)
{
unsigned long probe_addr = (unsigned long)p->addr;
- extern char __start_rodata[];
- extern char __end_rodata[];
if (probe_addr & 0x3)
return -EINVAL;
@@ -106,10 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
if (search_exception_tables(probe_addr))
return -EINVAL;
- if (probe_addr >= (unsigned long) __start_rodata &&
- probe_addr <= (unsigned long) __end_rodata)
- return -EINVAL;
-
/* decode instruction */
switch (arm_kprobe_decode_insn(p->addr, >ainsn)) {
case INSN_REJECTED: /* insn not supported */
[PATCH 3/3] arm64: kprobes: Move exception_text check in blacklist
Move exception/irqentry text address check in blacklist,
since those are symbol based rejection.
If we prohibit probing on the symbols in exception_text,
those should be blacklisted.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
b/arch/arm64/kernel/probes/kprobes.c
index 1dae500d0a81..b9e9758b6534 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -98,9 +98,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
/* copy instruction */
p->opcode = le32_to_cpu(*p->addr);
- if (in_exception_text(probe_addr))
- return -EINVAL;
-
if (search_exception_tables(probe_addr))
return -EINVAL;
@@ -475,7 +472,8 @@ bool arch_within_kprobe_blacklist(unsigned long addr)
(addr >= (unsigned long)__entry_text_start &&
addr < (unsigned long)__entry_text_end) ||
(addr >= (unsigned long)__idmap_text_start &&
- addr < (unsigned long)__idmap_text_end))
+ addr < (unsigned long)__idmap_text_end) ||
+ in_exception_text(addr))
return true;
if (!is_kernel_in_hyp_mode()) {
Re: [RFC PATCH net v3] net: phy: Fix the issue that netif always links up after resuming
Hi,
Gentle ping...
Are there any comments about changes since v2?
v2: https://www.spinics.net/lists/netdev/msg536926.html
Thank you,
On Mon, 3 Dec 2018 17:22:29 +0900 wrote:
> Even though the link is down before entering hibernation,
> there is an issue that the network interface always links up after resuming
> from hibernation.
>
> The phydev->state is PHY_READY before enabling the network interface, so
> the link is down. After resuming from hibernation, the phydev->state is
> forcibly set to PHY_UP in mdio_bus_phy_restore(), and the link becomes up.
>
> This patch adds a new convenient function to check whether the PHY is in
> a started state, and expects to solve the issue by changing phydev->state
> to PHY_UP and calling phy_start_machine() only when the PHY is started.
>
> Suggested-by: Heiner Kallweit
> Signed-off-by: Kunihiko Hayashi
> ---
>
> Changes since v2:
> - add mutex lock/unlock for changing phydev->state
> - check whether the mutex is locked in phy_is_started()
>
> Changes since v1:
> - introduce a new helper function phy_is_started() and use it instead of
>checking link status
> - replace checking phydev->state with phy_is_started() in
>phy_stop_machine()
>
> drivers/net/phy/phy.c| 2 +-
> drivers/net/phy/phy_device.c | 12 +---
> include/linux/phy.h | 13 +
> 3 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 1d73ac3..f484d03 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -670,7 +670,7 @@ void phy_stop_machine(struct phy_device *phydev)
> cancel_delayed_work_sync(>state_queue);
>
> mutex_lock(>lock);
> - if (phydev->state > PHY_UP && phydev->state != PHY_HALTED)
> + if (phy_is_started(phydev))
> phydev->state = PHY_UP;
> mutex_unlock(>lock);
> }
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index ab33d17..4897d24 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -309,10 +309,16 @@ static int mdio_bus_phy_restore(struct device *dev)
> return ret;
>
> /* The PHY needs to renegotiate. */
> - phydev->link = 0;
> - phydev->state = PHY_UP;
> + mutex_lock(>lock);
> + if (phy_is_started(phydev)) {
> + phydev->state = PHY_UP;
> + mutex_unlock(>lock);
> + phydev->link = 0;
> + phy_start_machine(phydev);
> + } else {
> + mutex_unlock(>lock);
> + }
>
> - phy_start_machine(phydev);
>
> return 0;
> }
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 3ea87f7..dd21537 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -898,6 +898,19 @@ static inline bool phy_is_pseudo_fixed_link(struct
> phy_device *phydev)
> }
>
> /**
> + * phy_is_started - Convenience function for testing whether a PHY is in
> + * a started state
> + * @phydev: the phy_device struct
> + *
> + * The caller must have taken the phy_device mutex lock.
> + */
> +static inline bool phy_is_started(struct phy_device *phydev)
> +{
> + WARN_ON(!mutex_is_locked(>lock));
> + return phydev->state >= PHY_UP && phydev->state != PHY_HALTED;
> +}
> +
> +/**
> * phy_write_mmd - Convenience function for writing a register
> * on an MMD on a given PHY.
> * @phydev: The phy_device struct
> --
> 2.7.4
---
Best Regards,
Kunihiko Hayashi
[PATCH 1/1] net-next/hinic:optmize rx refill buffer mechanism
In rx_alloc_pkts(), there is no need to schedule a different tasklet for
refill and it will cause some extra overhead. this patch remove it.
Suggested-by: Neil Horman
Signed-off-by: Xue Chaojing
---
drivers/net/ethernet/huawei/hinic/hinic_rx.c | 23 +---
drivers/net/ethernet/huawei/hinic/hinic_rx.h | 2 --
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
index f86f2e693224..0098b206e7e9 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.c
@@ -43,6 +43,7 @@
#define RX_IRQ_NO_LLI_TIMER 0
#define RX_IRQ_NO_CREDIT0
#define RX_IRQ_NO_RESEND_TIMER 0
+#define HINIC_RX_BUFFER_WRITE 16
/**
* hinic_rxq_clean_stats - Clean the statistics of specific queue
@@ -229,7 +230,6 @@ static int rx_alloc_pkts(struct hinic_rxq *rxq)
wmb(); /* write all the wqes before update PI */
hinic_rq_update(rxq->rq, prod_idx);
- tasklet_schedule(>rx_task);
}
return i;
@@ -258,17 +258,6 @@ static void free_all_rx_skbs(struct hinic_rxq *rxq)
}
}
-/**
- * rx_alloc_task - tasklet for queue allocation
- * @data: rx queue
- **/
-static void rx_alloc_task(unsigned long data)
-{
- struct hinic_rxq *rxq = (struct hinic_rxq *)data;
-
- (void)rx_alloc_pkts(rxq);
-}
-
/**
* rx_recv_jumbo_pkt - Rx handler for jumbo pkt
* @rxq: rx queue
@@ -333,6 +322,7 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
struct hinic_qp *qp = container_of(rxq->rq, struct hinic_qp, rq);
u64 pkt_len = 0, rx_bytes = 0;
struct hinic_rq_wqe *rq_wqe;
+ unsigned int free_wqebbs;
int num_wqes, pkts = 0;
struct hinic_sge sge;
struct sk_buff *skb;
@@ -376,8 +366,9 @@ static int rxq_recv(struct hinic_rxq *rxq, int budget)
rx_bytes += pkt_len;
}
- if (pkts)
- tasklet_schedule(>rx_task); /* rx_alloc_pkts */
+ free_wqebbs = hinic_get_rq_free_wqebbs(rxq->rq);
+ if (free_wqebbs > HINIC_RX_BUFFER_WRITE)
+ rx_alloc_pkts(rxq);
u64_stats_update_begin(>rxq_stats.syncp);
rxq->rxq_stats.pkts += pkts;
@@ -494,8 +485,6 @@ int hinic_init_rxq(struct hinic_rxq *rxq, struct hinic_rq
*rq,
sprintf(rxq->irq_name, "hinic_rxq%d", qp->q_id);
- tasklet_init(>rx_task, rx_alloc_task, (unsigned long)rxq);
-
pkts = rx_alloc_pkts(rxq);
if (!pkts) {
err = -ENOMEM;
@@ -512,7 +501,6 @@ int hinic_init_rxq(struct hinic_rxq *rxq, struct hinic_rq
*rq,
err_req_rx_irq:
err_rx_pkts:
- tasklet_kill(>rx_task);
free_all_rx_skbs(rxq);
devm_kfree(>dev, rxq->irq_name);
return err;
@@ -528,7 +516,6 @@ void hinic_clean_rxq(struct hinic_rxq *rxq)
rx_free_irq(rxq);
- tasklet_kill(>rx_task);
free_all_rx_skbs(rxq);
devm_kfree(>dev, rxq->irq_name);
}
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_rx.h
b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
index ab3fabab91b2..f8ed3fa6c8ee 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_rx.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_rx.h
@@ -42,8 +42,6 @@ struct hinic_rxq {
char*irq_name;
- struct tasklet_struct rx_task;
-
struct napi_struct napi;
};
--
2.17.1
Re: [PATCH 1/4] dmaengine: amba-pl08x: convert to DEFINE_SHOW_ATTRIBUTE
On 05-12-18, 11:18, Yangtao Li wrote: > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Applied all 4, thanks -- ~Vinod
Re: [PATCH] dmaengine: fsl-qdma: add MODULE_LICENSE
On 10-12-18, 21:55, Arnd Bergmann wrote: > The newly added driver lacks a MODULE_LICENSE tag, which now produces > a warning: > > WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-qdma.o > > Add the license according to the SPDX specifier. Applied, thanks -- ~Vinod
kernel BUG at fs/inode.c:LINE!
Hello, syzbot found the following crash on: HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1370634740 kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 dashboard link: https://syzkaller.appspot.com/bug?extid=5399ed0832693e29f392 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101032b340 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1653406340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5399ed0832693e29f...@syzkaller.appspotmail.com slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 __d_alloc+0xc8/0xb90 fs/dcache.c:1599 [ cut here ] kernel BUG at fs/inode.c:1566! d_alloc_anon fs/dcache.c:1698 [inline] d_make_root+0x43/0xc0 fs/dcache.c:1885 autofs_fill_super+0x6f1/0x1c30 fs/autofs/inode.c:273 invalid opcode: [#1] PREEMPT SMP KASAN CPU: 1 PID: 6100 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:iput+0x915/0xa90 fs/inode.c:1566 Code: e4 0f 84 a8 fe ff ff e8 e9 fe a6 ff 48 89 df e8 61 f4 ff ff 48 8b bd f0 fe ff ff e8 35 41 08 06 e9 69 fd ff ff e8 cb fe a6 ff <0f> 0b e8 c4 fe a6 ff 0f 0b e9 d5 fb ff ff e8 b8 fe a6 ff 0f 0b e9 RSP: 0018:8881c0ff76b8 EFLAGS: 00010293 RAX: 8881c0fdc100 RBX: 8881b25f44a0 RCX: 81d8fc14 RDX: RSI: 81d90455 RDI: 0007 RBP: 8881c0ff77f0 R08: 8881c0fdc100 R09: 0006 R10: R11: 8881c0fdc100 R12: 0040 R13: 8881c0ff7910 R14: ffea R15: 8881d0c4d200 mount_nodev+0x73/0x120 fs/super.c:1402 FS: 01e1a880() GS:8881dad0() knlGS: CS: 0010 DS: ES: CR0: 80050033 autofs_mount+0x34/0x40 fs/autofs/init.c:16 CR2: 006cd0a0 CR3: 0001b2c56000 CR4: 001406e0 DR0: DR1: DR2: legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 autofs_fill_super+0x15fb/0x1c30 fs/autofs/inode.c:352 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 mount_nodev+0x73/0x120 fs/super.c:1402 entry_SYSCALL_64_after_hwframe+0x49/0xbe autofs_mount+0x34/0x40 fs/autofs/init.c:16 RIP: 0033:0x441be9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 legacy_get_tree+0x12f/0x260 fs/fs_context.c:714 RSP: 002b:76330f88 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: RCX: 00441be9 vfs_get_tree+0x1cb/0x5c0 fs/super.c:1795 RDX: 2180 RSI: 2100 RDI: RBP: 76330fe0 R08: R09: 0100 R10: R11: 0246 R12: do_new_mount fs/namespace.c:2716 [inline] do_mount+0x82a/0x1ff0 fs/namespace.c:3042 R13: 0003 R14: R15: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 6107 Comm: syz-executor637 Not tainted 4.20.0-rc6-next-20181214+ #171 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 ksys_mount+0x12d/0x140 fs/namespace.c:3258 __do_sys_mount fs/namespace.c:3272 [inline] __se_sys_mount fs/namespace.c:3269 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3269 fail_dump lib/fault-inject.c:51 [inline] should_fail.cold.4+0xa/0x17 lib/fault-inject.c:149 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe __should_failslab+0x124/0x180 mm/failslab.c:32 RIP: 0033:0x441be9 should_failslab+0x9/0x14 mm/slab_common.c:1576 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 3b 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00 slab_pre_alloc_hook mm/slab.h:423 [inline] slab_alloc mm/slab.c:3365 [inline] kmem_cache_alloc+0x2c4/0x730 mm/slab.c:3539 RSP: 002b:76330f88 EFLAGS: 0246 ORIG_RAX:
KASAN: slab-out-of-bounds Read in tick_sched_handle
Hello, syzbot found the following crash on: HEAD commit:c151acc6e9ff l2tp: Add protocol field decompression git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1231955d40 kernel config: https://syzkaller.appspot.com/x/.config?x=d9655b05acfc97ff dashboard link: https://syzkaller.appspot.com/bug?extid=09d51a30df9fe76edb2a compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11e68f6d40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1737c94340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+09d51a30df9fe76ed...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 kasan: CONFIG_KASAN_INLINE enabled == BUG: KASAN: slab-out-of-bounds in tick_sched_handle+0x16c/0x180 kernel/time/tick-sched.c:164 kasan: GPF could be caused by NULL-ptr deref or user memory access Read of size 8 at addr 8881d8b67b70 by task syz-executor132/5936 general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 5936 Comm: syz-executor132 Not tainted 4.20.0-rc6+ #347 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.20.0-rc6+ #347 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: RIP: 0010:lookup_object lib/debugobjects.c:156 [inline] RIP: 0010:debug_object_deactivate+0x191/0x450 lib/debugobjects.c:542 Code: 02 00 00 48 8b 1b 41 bf 01 00 00 00 48 85 db 74 46 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 18 41 83 c7 01 48 89 fe 48 c1 ee 03 <80> 3c 06 00 0f 85 04 02 00 00 48 3b 53 18 0f 84 53 01 00 00 48 89 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 RSP: 0018:8881daf078b0 EFLAGS: 00010807 RAX: dc00 RBX: da3ef506c4b2a03d RCX: 83939c1a RDX: 8881bb4ed108 RSI: 1b47dea0d896540a RDI: da3ef506c4b2a055 RBP: 8881daf07968 R08: ed103b5e0f03 R09: ed103b5e0f02 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 R10: ed103b5e0f02 R11: 0003 R12: 11103b5e0f18 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 R13: 8b23e7a8 R14: 895a5980 R15: 0003 FS: () GS:8881daf0() knlGS: __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 CS: 0010 DS: ES: CR0: 80050033 tick_sched_handle+0x16c/0x180 kernel/time/tick-sched.c:164 CR2: 00619570 CR3: 0001c3506000 CR4: 001406e0 DR0: DR1: DR2: tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274 DR3: DR6: fffe0ff0 DR7: 0400 __run_hrtimer kernel/time/hrtimer.c:1398 [inline] __hrtimer_run_queues+0x41c/0x10d0 kernel/time/hrtimer.c:1460 Call Trace: debug_timer_deactivate kernel/time/timer.c:714 [inline] debug_deactivate kernel/time/timer.c:770 [inline] detach_timer kernel/time/timer.c:815 [inline] expire_timers kernel/time/timer.c:1353 [inline] __run_timers+0x56f/0xc70 kernel/time/timer.c:1682 hrtimer_interrupt+0x313/0x780 kernel/time/hrtimer.c:1518 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1034 [inline] smp_apic_timer_interrupt+0x1a1/0x760 arch/x86/kernel/apic/apic.c:1059 run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1695 __do_softirq+0x308/0xb7e kernel/softirq.c:292 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 Allocated by task 5092: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x730 mm/slab.c:3554 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x17f/0x1c0 kernel/softirq.c:413 getname_flags+0xd0/0x590 fs/namei.c:140 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061 user_path_at_empty+0x2d/0x50 fs/namei.c:2608 user_path_at include/linux/namei.h:57 [inline] do_faccessat+0x254/0x800 fs/open.c:378 __do_sys_access fs/open.c:430 [inline] __se_sys_access fs/open.c:428 [inline] __x64_sys_access+0x59/0x80 fs/open.c:428 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5092: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x83/0x290 mm/slab.c:3760 apic_timer_interrupt+0xf/0x20
KASAN: use-after-free Read in tipc_mcast_xmit
Hello, syzbot found the following crash on: HEAD commit:8203e2d844d3 net: clear skb->tstamp in forwarding paths git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=17d37c1b40 kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 dashboard link: https://syzkaller.appspot.com/bug?extid=99f20222fc5018d2b97a compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d7c94340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+99f20222fc5018d2b...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 == BUG: KASAN: use-after-free in tipc_mcast_xmit+0xb77/0xdb0 net/tipc/bcast.c:305 Read of size 1 at addr 8881d219454e by task syz-executor0/6307 CPU: 0 PID: 6307 Comm: syz-executor0 Not tainted 4.20.0-rc6+ #234 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430 tipc_mcast_xmit+0xb77/0xdb0 net/tipc/bcast.c:305 tipc_send_group_bcast+0xa5f/0xdf0 net/tipc/socket.c:1054 __tipc_sendmsg+0xeec/0x1d40 net/tipc/socket.c:1310 tipc_sendmsg+0x50/0x70 net/tipc/socket.c:1275 sock_sendmsg_nosec net/socket.c:621 [inline] sock_sendmsg+0xd5/0x120 net/socket.c:631 ___sys_sendmsg+0x7fd/0x930 net/socket.c:2116 __sys_sendmsg+0x11d/0x280 net/socket.c:2154 __do_sys_sendmsg net/socket.c:2163 [inline] __se_sys_sendmsg net/socket.c:2161 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2161 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457669 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fbfc19b2c78 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 0003 RCX: 00457669 RDX: RSI: 21c0 RDI: 0004 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7fbfc19b36d4 R13: 004c44bd R14: 004d74a8 R15: Allocated by task 6307: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620 kmalloc include/linux/slab.h:546 [inline] kzalloc include/linux/slab.h:741 [inline] tipc_group_create+0x152/0xa70 net/tipc/group.c:171 tipc_sk_join net/tipc/socket.c:2836 [inline] tipc_setsockopt+0x2d1/0xd70 net/tipc/socket.c:2951 __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902 __do_sys_setsockopt net/socket.c:1913 [inline] __se_sys_setsockopt net/socket.c:1910 [inline] __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 6308: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3817 tipc_group_delete+0x2e4/0x3f0 net/tipc/group.c:227 tipc_sk_leave+0x113/0x220 net/tipc/socket.c:2870 tipc_setsockopt+0x97d/0xd70 net/tipc/socket.c:2954 __sys_setsockopt+0x1ba/0x3c0 net/socket.c:1902 __do_sys_setsockopt net/socket.c:1913 [inline] __se_sys_setsockopt net/socket.c:1910 [inline] __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8881d2194500 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 78 bytes inside of 192-byte region [8881d2194500, 8881d21945c0) The buggy address belongs to the page: page:ea0007486500 count:1 mapcount:0 mapping:8881da800040 index:0x0 flags: 0x2fffc000200(slab) raw: 02fffc000200 ea00074e6dc8 ea000748fa88 8881da800040 raw: 8881d2194000 00010010 page dumped because: kasan: bad access detected Memory state around the buggy address: 8881d2194400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 8881d2194480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
Re: [PATCH 1/6] driver core: Introduce device_iommu_mapped() function
On 11-12-18, 14:43, Joerg Roedel wrote: > From: Joerg Roedel > > Some places in the kernel check the iommu_group pointer in > 'struct device' in order to find ot whether a device is ^^ Typo -- ~Vinod
Re: [PATCH 6/6] dmaengine: sh: rcar-dmac: Use device_iommu_mapped()
On 11-12-18, 14:43, Joerg Roedel wrote: > From: Joerg Roedel > > Use Use device_iommu_mapped() to check if the device is > already mapped by an IOMMU. Acked-by: Vinod Koul -- ~Vinod
[PATCH] Prevent race condition between USB authorisation and USB discovery events
A sysfs driven USB authorisation change can trigger a usb_set_configuration
while a hub_event worker thread is running. This can result in a USB device
being disabled just after it was configured and bringing down all the
devices and impacting hardware and user processes that were established on
top of this these interfaces. In some cases the USB disable never completed
and the whole system hung.
At my work I had an occasional hang due to this race condition. Roughly 1
in 50 boots had the race occurrence and 1 in 4 of those resulted in a hang.
This patch fixed the problem and I had no problems (spurious disables
or hangs) in 750+ boots.
Signed-off-by: Andrew Worsley
---
drivers/usb/core/hub.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f76b2e0aba9d..dabd07aa8602 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -51,6 +51,9 @@ static DEFINE_SPINLOCK(device_state_lock);
static struct workqueue_struct *hub_wq;
static void hub_event(struct work_struct *work);
+/* synchronize hub_event and authorize_device operations */
+DEFINE_MUTEX(usb_authorize_mutex);
+
/* synchronize hub-port add/remove and peering operations */
DEFINE_MUTEX(usb_port_peer_mutex);
@@ -2538,6 +2541,7 @@ int usb_new_device(struct usb_device *udev)
*/
int usb_deauthorize_device(struct usb_device *usb_dev)
{
+ mutex_lock(_authorize_mutex);
usb_lock_device(usb_dev);
if (usb_dev->authorized == 0)
goto out_unauthorized;
@@ -2547,6 +2551,7 @@ int usb_deauthorize_device(struct usb_device *usb_dev)
out_unauthorized:
usb_unlock_device(usb_dev);
+ mutex_unlock(_authorize_mutex);
return 0;
}
@@ -2555,6 +2560,7 @@ int usb_authorize_device(struct usb_device *usb_dev)
{
int result = 0, c;
+ mutex_lock(_authorize_mutex);
usb_lock_device(usb_dev);
if (usb_dev->authorized == 1)
goto out_authorized;
@@ -2596,6 +2602,7 @@ int usb_authorize_device(struct usb_device *usb_dev)
error_autoresume:
out_authorized:
usb_unlock_device(usb_dev); /* complements locktree */
+ mutex_unlock(_authorize_mutex);
return result;
}
@@ -5320,6 +5327,7 @@ static void hub_event(struct work_struct *work)
hub_dev = hub->intfdev;
intf = to_usb_interface(hub_dev);
+ mutex_lock(_authorize_mutex);
dev_dbg(hub_dev, "state %d ports %d chg %04x evt %04x\n",
hdev->state, hdev->maxchild,
/* NOTE: expects max 15 ports... */
@@ -5422,6 +5430,7 @@ static void hub_event(struct work_struct *work)
usb_autopm_put_interface_no_suspend(intf);
out_hdev_lock:
usb_unlock_device(hdev);
+ mutex_unlock(_authorize_mutex);
/* Balance the stuff in kick_hub_wq() and allow autosuspend */
usb_autopm_put_interface(intf);
--
2.19.2
[PATCH 1/2] EDAC: Add Aspeed AST2500 EDAC driver
From: Stefan M Schaeckeler
Add support for the Aspeed AST2500 SoC EDAC driver.
Signed-off-by: Stefan M Schaeckeler
---
MAINTAINERS | 6 +
arch/arm/boot/dts/aspeed-g5.dtsi | 7 +
drivers/edac/Kconfig | 7 +
drivers/edac/Makefile| 1 +
drivers/edac/aspeed_edac.c | 457 +++
5 files changed, 478 insertions(+)
create mode 100644 drivers/edac/aspeed_edac.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3318f30903b2..1feb92b14029 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5315,6 +5315,12 @@ L: linux-e...@vger.kernel.org
S: Maintained
F: drivers/edac/amd64_edac*
+EDAC-AST2500
+M: Stefan Schaeckeler
+S: Supported
+F: drivers/edac/aspeed_edac.c
+F: Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
+
EDAC-CALXEDA
M: Robert Richter
L: linux-e...@vger.kernel.org
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index d107459fc0f8..b4e479ab5a2d 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -47,6 +47,13 @@
reg = <0x8000 0>;
};
+ edac: sdram@1e6e {
+ compatible = "aspeed,ast2500-sdram-edac";
+ reg = <0x1e6e 0x174>;
+ interrupts = <0>;
+ status = "disabled";
+ };
+
ahb {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 41c9ccdd20d6..67834430b0a1 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -475,4 +475,11 @@ config EDAC_QCOM
For debugging issues having to do with stability and overall system
health, you should probably say 'Y' here.
+config EDAC_ASPEED
+ tristate "Aspeed AST 2500 SoC"
+ depends on MACH_ASPEED_G5
+ help
+ Support for error detection and correction on the
+ Aspeed AST 2500 SoC.
+
endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 716096d08ea0..e1f23d4ff860 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_EDAC_SYNOPSYS) += synopsys_edac.o
obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
obj-$(CONFIG_EDAC_TI) += ti_edac.o
obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
+obj-$(CONFIG_EDAC_ASPEED) += aspeed_edac.o
diff --git a/drivers/edac/aspeed_edac.c b/drivers/edac/aspeed_edac.c
new file mode 100644
index ..d6ed119909eb
--- /dev/null
+++ b/drivers/edac/aspeed_edac.c
@@ -0,0 +1,457 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 Cisco Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "edac_module.h"
+
+
+#define DRV_NAME "aspeed-edac"
+
+
+/* registers */
+#define ASPEED_MCR_PROT0x00 /* protection key register */
+#define ASPEED_MCR_CONF0x04 /* configuration register */
+#define ASPEED_MCR_INTR_CTRL 0x50 /* interrupt control/status register */
+#define ASPEED_MCR_ADDR_UNREC 0x58 /* address of first un-recoverable error */
+#define ASPEED_MCR_ADDR_REC0x5c /* address of last recoverable error */
+#define ASPEED_MCR_LASTASPEED_MCR_ADDR_REC
+
+
+/* bits and masks */
+#define ASPEED_MCR_PROT_PASSWD 0xfc600309
+#define ASPEED_MCR_CONF_DRAM_TYPE BIT(4)
+#define ASPEED_MCR_CONF_ECC BIT(7)
+#define ASPEED_MCR_INTR_CTRL_CLEAR BIT(31)
+#define ASPEED_MCR_INTR_CTRL_CNT_REC GENMASK(23, 16)
+#define ASPEED_MCR_INTR_CTRL_CNT_UNREC GENMASK(15, 12)
+#define ASPEED_MCR_INTR_CTRL_ENABLE (BIT(0) | BIT(1))
+
+
+
+static int aspeed_edac_regmap_reg_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+ void __iomem *regs = (void __iomem *)context;
+
+ /* enable write to MCR register set */
+ writel(ASPEED_MCR_PROT_PASSWD, regs + ASPEED_MCR_PROT);
+
+ writel(val, regs + reg);
+
+ /* disable write to MCR register set */
+ writel(~ASPEED_MCR_PROT_PASSWD, regs + ASPEED_MCR_PROT);
+
+ return 0;
+}
+
+
+static int aspeed_edac_regmap_reg_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ void __iomem *regs = (void __iomem *)context;
+
+ *val = readl(regs + reg);
+
+ return 0;
+}
+
+static bool aspeed_edac_regmap_is_volatile(struct device *dev,
+ unsigned int reg)
+{
+ switch (reg) {
+ case ASPEED_MCR_PROT:
+ case ASPEED_MCR_INTR_CTRL:
+
[PATCH 2/2] dt-bindings: edac: Aspeed AST2500
From: Stefan M Schaeckeler
Add support for the Aspeed AST2500 SoC EDAC driver.
Signed-off-by: Stefan M Schaeckeler
---
.../bindings/edac/aspeed-sdram-edac.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
diff --git a/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
new file mode 100644
index ..57ba852883c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt
@@ -0,0 +1,34 @@
+Aspeed AST2500 SoC EDAC device driver
+
+The Aspeed AST2500 SoC supports DDR3 and DDR4 memory with and without ECC
(error
+correction check).
+
+The memory controller supports SECDED (single bit error correction, double bit
+error detection) and single bit error auto scrubbing by reserving 8 bits for
+every 64 bit word (effectively reducing available memory to 8/9).
+
+First, ECC must be configured in u-boot. Then, this driver will expose error
+counters via the edac kernel framework.
+
+A note on memory organization in ECC mode: every 512 bytes are followed by 64
+bytes of ECC codes. The address remapping is done in hardware and is fully
+transparent to firmware and software. Because of this, ECC mode must be
+configured in u-boot as part of the memory initialization as one can not switch
+from one mode to another when executing in memory.
+
+
+
+Required properties:
+- compatible: should be "aspeed,ast2500-sdram-edac"
+- reg:sdram controller register set should be <0x1e6e 0x174>
+- interrupts: should be AVIC interrupt #0
+
+
+Example:
+
+ edac: sdram@1e6e {
+ compatible = "aspeed,ast2500-sdram-edac";
+ reg = <0x1e6e 0x174>;
+ interrupts = <0>;
+ status = "okay";
+ };
--
2.19.1
[PATCH] usb: gadget: uvc: add uvcg_warn macro
We only have uvcg_dbg, uvcg_info, and uvcg_err, so add uvcg_warn macro to print gadget device name and function name along with format. Signed-off-by: Paul Elder --- drivers/usb/gadget/function/uvc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h index 1d89b1df4ba0..c381ce9e 100644 --- a/drivers/usb/gadget/function/uvc.h +++ b/drivers/usb/gadget/function/uvc.h @@ -56,6 +56,8 @@ extern unsigned int uvc_gadget_trace_param; dev_dbg(&(f)->config->cdev->gadget->dev, "%s: " fmt, (f)->name, ##args) #define uvcg_info(f, fmt, args...) \ dev_info(&(f)->config->cdev->gadget->dev, "%s: " fmt, (f)->name, ##args) +#define uvcg_warn(f, fmt, args...) \ + dev_warn(&(f)->config->cdev->gadget->dev, "%s: " fmt, (f)->name, ##args) #define uvcg_err(f, fmt, args...) \ dev_err(&(f)->config->cdev->gadget->dev, "%s: " fmt, (f)->name, ##args) -- 2.19.2
[PATCH v2 2/6] usb: gadget: uvc: enqueue usb request in setup handler for control OUT
Currently, for uvc class-specific control IN and OUT requests, in the
setup handler a UVC_EVENT_SETUP with the setup control is enqueued to
userspace. In response to this, the uvc function driver expects
userspace to call ioctl UVCIOC_SEND_RESPONSE containing uvc request
data.
In the case of control IN this is fine, but for control OUT it causes a
problem. Since the host sends data immediately after the setup stage
completes, it is possible that the empty uvc request data is not
enqueued in time for the UDC driver to put the data stage data into
(this causes some UDC drivers, such as MUSB, to reply with a STALL).
This problem is remedied by having the setup handler enqueue the empty
uvc request data, instead of waiting for userspace to do it.
Signed-off-by: Paul Elder
Reviewed-by: Laurent Pinchart
---
No change from v1
drivers/usb/gadget/function/f_uvc.c| 25 +++--
drivers/usb/gadget/function/uvc_v4l2.c | 7 +++
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uvc.c
b/drivers/usb/gadget/function/f_uvc.c
index 3e07dcb885b7..772c99c297fc 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -223,8 +223,6 @@ static int
uvc_function_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl)
{
struct uvc_device *uvc = to_uvc(f);
- struct v4l2_event v4l2_event;
- struct uvc_event *uvc_event = (void *)_event.u.data;
if ((ctrl->bRequestType & USB_TYPE_MASK) != USB_TYPE_CLASS) {
uvcg_info(f, "invalid request type\n");
@@ -241,10 +239,25 @@ uvc_function_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl)
uvc->event_setup_out = !(ctrl->bRequestType & USB_DIR_IN);
uvc->event_length = le16_to_cpu(ctrl->wLength);
- memset(_event, 0, sizeof(v4l2_event));
- v4l2_event.type = UVC_EVENT_SETUP;
- memcpy(_event->req, ctrl, sizeof(uvc_event->req));
- v4l2_event_queue(>vdev, _event);
+ if (uvc->event_setup_out) {
+ struct usb_request *req = uvc->control_req;
+
+ /*
+* Enqueue the request immediately for control OUT as the
+* host will start the data stage straight away.
+*/
+ req->length = uvc->event_length;
+ req->zero = 0;
+ usb_ep_queue(f->config->cdev->gadget->ep0, req, GFP_KERNEL);
+ } else {
+ struct v4l2_event v4l2_event;
+ struct uvc_event *uvc_event = (void *)_event.u.data;
+
+ memset(_event, 0, sizeof(v4l2_event));
+ v4l2_event.type = UVC_EVENT_SETUP;
+ memcpy(_event->req, ctrl, sizeof(uvc_event->req));
+ v4l2_event_queue(>vdev, _event);
+ }
return 0;
}
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c
b/drivers/usb/gadget/function/uvc_v4l2.c
index 7bfa43dbef9e..35353ffdf3b4 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -35,6 +35,13 @@ uvc_send_response(struct uvc_device *uvc, struct
uvc_request_data *data)
struct usb_composite_dev *cdev = uvc->func.config->cdev;
struct usb_request *req = uvc->control_req;
+ /*
+* For control OUT transfers the request has been enqueued synchronously
+* by the setup handler, there's nothing to be done here.
+*/
+ if (uvc->event_setup_out)
+ return 0;
+
if (data->length < 0)
return usb_ep_set_halt(cdev->gadget->ep0);
--
2.19.2
[PATCH 0/2] Add support for the Aspeed AST2500 SoC EDAC driver.
From: Stefan M Schaeckeler Add support for the Aspeed AST2500 SoC EDAC driver. Note, I only have access to AST2500 hardware and documentation. The AST2500 documentation explicitly states that the sdram controller is not backward compatible with AST2400 and hence this driver is not supporting it. Best, Stefan Stefan M Schaeckeler (2): EDAC: Add Aspeed AST2500 EDAC driver dt-bindings: edac: Aspeed AST2500 .../bindings/edac/aspeed-sdram-edac.txt | 34 ++ MAINTAINERS | 6 + arch/arm/boot/dts/aspeed-g5.dtsi | 7 + drivers/edac/Kconfig | 7 + drivers/edac/Makefile | 1 + drivers/edac/aspeed_edac.c| 457 ++ 6 files changed, 512 insertions(+) create mode 100644 Documentation/devicetree/bindings/edac/aspeed-sdram-edac.txt create mode 100644 drivers/edac/aspeed_edac.c -- 2.19.1
[PATCH v2 0/6] usb: gadget: add mechanism to asynchronously validate data stage of ctrl out request
This patch series adds a mechanism to allow asynchronously validating the data stage of a control OUT request, and for stalling or suceeding the request accordingly. This mechanism is implemented for MUSB, and is used by UVC. At the same time, UVC packages the setup stage and data stage data together to send to userspace to save on a pair of context switches per control out request. This patch series does change the userspace API. We however believe that it is justified because the current API is broken, and because it isn't being used (because it's broken). The current API is broken such that it is subject to race conditions that cause fatal errors with a high frequency. This is actually what motivated this patch series in the first place. In the current API, not only is there no way to asynchronously validate the data stage of a control OUT request, but an empty buffer is expected to be provided to hold the data stage data -- which is more likely than not to be late. There is even a warning in musb_g_ep0_queue: /* else for sequence #2 (OUT), caller provides a buffer * before the next packet arrives. deferred responses * (after SETUP is acked) are racey. */ This problem has never been reported in years, which is a sign that the API isn't used. Furthermore, the vendor kernels that we have seen using the UVC gadget driver (such as QC and Huawei) are heavily patched with local changes to the API. This corroborates the suspicion that the current mainline API is not being used. Additionally, this API isn't meant to be used by generic applications, but by a dedicated userspace helper. uvc-gadget is one such example, but it has bitrotten and isn't compatible with the current kernel API. The fact that nobody has submitted patches nor complained for a long time again shows that it isn't being used. The conclusion is that since the API hasn't been used for a long time, it is safe to fix it. Changes in v2: Overhaul of status stage delay mechanism/API. Now if a function driver desires an explicit/delayed status stage, it specifies so in a flag in the usb_request that is queued for the data stage. The function driver later enqueues another usb_request for the status stage, also with the explicit_status flag set, and with the zero flag acting as the status. If a function driver does not desire an explicit status stage, then it can set (or ignore) the explicit_status flag in the usb_request that is queued for the data stage. To allow the optional explicit status stage, a UDC driver should call the newly added usb_gadget_control_complete right after usb_gadget_giveback_request, and in its queue function should check if the usb_request is for the status stage and if it has been requested to be explicit, and if so check the status that should be sent. (See 5/6 "usb: musb: gadget: implement optional explicit status stage" for an implementation for MUSB) Paul Elder (6): usb: uvc: include videodev2.h in g_uvc.h usb: gadget: uvc: enqueue usb request in setup handler for control OUT usb: gadget: uvc: package setup and data for control OUT requests usb: gadget: add mechanism to specify an explicit status stage usb: musb: gadget: implement optional explicit status stage usb: gadget: uvc: allow ioctl to send response in status stage drivers/usb/gadget/function/f_uvc.c| 32 ++--- drivers/usb/gadget/function/uvc.h | 1 + drivers/usb/gadget/function/uvc_v4l2.c | 20 drivers/usb/gadget/udc/core.c | 33 ++ drivers/usb/musb/musb_gadget.c | 1 + drivers/usb/musb/musb_gadget_ep0.c | 28 ++ include/linux/usb/gadget.h | 10 include/uapi/linux/usb/g_uvc.h | 4 +++- 8 files changed, 120 insertions(+), 9 deletions(-) -- 2.19.2
[PATCH v2 1/6] usb: uvc: include videodev2.h in g_uvc.h
V4L2_EVENT_PRIVATE_START is used in g_uvc.h but is defined in videodev2.h, which is not included and causes a compiler warning: linux/usb/g_uvc.h:15:28: error: ‘V4L2_EVENT_PRIVATE_START’ undeclared here (not in a function) #define UVC_EVENT_FIRST (V4L2_EVENT_PRIVATE_START + 0) Include videodev2.h in g_uvc.h. Signed-off-by: Paul Elder Reviewed-by: Laurent Pinchart --- No change from v1 include/uapi/linux/usb/g_uvc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/usb/g_uvc.h b/include/uapi/linux/usb/g_uvc.h index 3c9ee3020cbb..6698c3263ae8 100644 --- a/include/uapi/linux/usb/g_uvc.h +++ b/include/uapi/linux/usb/g_uvc.h @@ -11,6 +11,7 @@ #include #include #include +#include #define UVC_EVENT_FIRST(V4L2_EVENT_PRIVATE_START + 0) #define UVC_EVENT_CONNECT (V4L2_EVENT_PRIVATE_START + 0) -- 2.19.2
[PATCH v2 6/6] usb: gadget: uvc: allow ioctl to send response in status stage
We now have a mechanism to signal the UDC driver to reply to a control
OUT request with STALL or ACK, and we have packaged the setup stage data
and the data stage data of a control OUT request into a single
UVC_EVENT_DATA for userspace to consume. The ioctl UVCIOC_SEND_RESPONSE
in the case of a control OUT request sends a response to the data stage,
and so the ioctl now notifies the UDC driver to reply with STALL or ACK.
In the case of a control IN request, the ioctl sends the UVC data as
before.
Also tell the UDC to delay the status stage for this to work.
Signed-off-by: Paul Elder
---
Changes from v1:
- remove usb_ep_delay_status call from the old proposed API
- changed portions of uvc_send_response to match v2 API
- remove UDC warning that send_response is not implemented
drivers/usb/gadget/function/f_uvc.c| 4 ++--
drivers/usb/gadget/function/uvc_v4l2.c | 19 ---
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uvc.c
b/drivers/usb/gadget/function/f_uvc.c
index d08957124e42..91388bb647e0 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -209,14 +209,13 @@ uvc_function_ep0_complete(struct usb_ep *ep, struct
usb_request *req)
struct uvc_event *uvc_event = (void *)_event.u.data;
if (uvc->event_setup_out) {
- uvc->event_setup_out = 0;
-
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_DATA;
uvc_event->data.length = req->actual;
memcpy(_event->data.data, req->buf, req->actual);
memcpy(_event->data.setup, >control_setup,
sizeof(uvc_event->data.setup));
+
v4l2_event_queue(>vdev, _event);
}
}
@@ -251,6 +250,7 @@ uvc_function_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl)
*/
req->length = uvc->event_length;
req->zero = 0;
+ req->explicit_status = 1;
usb_ep_queue(f->config->cdev->gadget->ep0, req, GFP_KERNEL);
} else {
struct v4l2_event v4l2_event;
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c
b/drivers/usb/gadget/function/uvc_v4l2.c
index 35353ffdf3b4..f09aa92a1b01 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -37,10 +37,23 @@ uvc_send_response(struct uvc_device *uvc, struct
uvc_request_data *data)
/*
* For control OUT transfers the request has been enqueued synchronously
-* by the setup handler, there's nothing to be done here.
+* by the setup handler, we just need to tell the UDC whether to ACK or
+* STALL the control transfer.
*/
- if (uvc->event_setup_out)
- return 0;
+ if (uvc->event_setup_out) {
+ /*
+* The length field carries the control request status.
+* Negative values signal a STALL and zero values an ACK.
+* Positive values are not valid as there is no data to send
+* back in the status stage.
+*/
+ if (data->length > 0)
+ return -EINVAL;
+
+ req->zero = !data->length;
+ req->explicit_status = 1;
+ return usb_ep_queue(cdev->gadget->ep0, req, GFP_KERNEL);
+ }
if (data->length < 0)
return usb_ep_set_halt(cdev->gadget->ep0);
--
2.19.2
[PATCH v2 4/6] usb: gadget: add mechanism to specify an explicit status stage
A usb gadget function driver may or may not want to delay the status
stage of a control OUT request. An instance it might want to is to
asynchronously validate the data of a class-specific request.
A function driver that wants an explicit status stage should set the
newly added explicit_status flag of the usb_request corresponding to the
data stage. Later on the function driver can explicitly complete the
status stage by enqueueing a usb_request also with the explicit_status
flag set, and with the zero flag set to 1 for ACK, or 0 for STALL.
To support both explicit and implicit status stages, a UDC driver must
call the newly added usb_gadget_control_complete function right after
calling usb_gadget_giveback_request. To support the explicit status
stage, it might then check what stage the usb_request was queued in, or
the explicit_status flag, and the zero flag for what status to send.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
---
Changes from v1:
Complete change of API. Now we use a flag that should be set in the
usb_request that is queued for the data stage to signal to the UDC that
we want to delay the status stage (as opposed to setting a flag in the
UDC itself, that persists across all requests). We now also provide a
function for UDC drivers to very easily allow implicit status stages, to
mitigate the need to convert all function drivers to this new API at
once, and to make it easier for UDC drivers to convert.
drivers/usb/gadget/udc/core.c | 33 +
include/linux/usb/gadget.h| 10 ++
2 files changed, 43 insertions(+)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index af88b48c1cea..e99481ef9147 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -894,6 +894,39 @@ EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
/* - */
+/**
+ * usb_gadget_control_complete - complete the status stage of a control
+ * request, or delay it
+ * Context: in_interrupt()
+ *
+ * @gadget: gadget whose control request's status stage should be completed
+ * @explicit_status: true to delay status stage, false to complete here
+ *
+ * This is called by device controller drivers after returning the completed
+ * request back to the gadget layer, to either complete or delay the status
+ * stage.
+ */
+void usb_gadget_control_complete(struct usb_gadget *gadget,
+ unsigned int explicit_status)
+{
+ struct usb_request *req;
+
+ if (explicit_status)
+ return;
+
+ /* Send an implicit status-stage request for ep0 */
+ req = usb_ep_alloc_request(gadget->ep0, GFP_ATOMIC);
+ if (req) {
+ req->length = 0;
+ req->explicit_status = 0;
+ req->complete = usb_ep_free_request;
+ usb_ep_queue(gadget->ep0, req, GFP_ATOMIC);
+ }
+}
+EXPORT_SYMBOL_GPL(usb_gadget_control_complete);
+
+/* - */
+
/**
* gadget_find_ep_by_name - returns ep whose name is the same as sting passed
* in second parameter or NULL if searched endpoint not found
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e5cd84a0f84a..7a5283a224c7 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -73,6 +73,7 @@ struct usb_ep;
* Note that for writes (IN transfers) some data bytes may still
* reside in a device-side FIFO when the request is reported as
* complete.
+ * @explicit_status: If true, delays the status stage
*
* These are allocated/freed through the endpoint they're used with. The
* hardware's driver can add extra per-request data to the memory it returns,
@@ -114,6 +115,8 @@ struct usb_request {
int status;
unsignedactual;
+
+ unsignedexplicit_status:1;
};
/*-*/
@@ -850,6 +853,13 @@ extern void usb_gadget_giveback_request(struct usb_ep *ep,
/*-*/
+/* utility to complete or delay status stage */
+
+void usb_gadget_control_complete(struct usb_gadget *gadget,
+ unsigned int explicit_status);
+
+/*-*/
+
/* utility to find endpoint by name */
extern struct usb_ep *gadget_find_ep_by_name(struct usb_gadget *g,
--
2.19.2
[PATCH v2 3/6] usb: gadget: uvc: package setup and data for control OUT requests
Since "usb: gadget: uvc: enqueue uvc_request_data in setup handler
for control OUT requests" it is no longer necessary for userspace to
call ioctl UVCIOC_SEND_RESPONSE in response to receiving a
UVC_EVENT_SETUP from the uvc function driver for a control OUT request.
This change means that for control OUT userspace will receive a
UVC_EVENT_SETUP and not do anything with it. This is a waste of a pair
of context switches, so we put the setup and data stage data into a
single UVC_EVENT_DATA to give to userspace. Previously struct
uvc_request_data had 60 bytes allocated for data, and since uvc data at
most is 34 bytes in UVC 1.1 and 48 bytes in UVC 1.5, we can afford to
cut out 8 bytes to store the setup control.
Since the setup control is discarded after the handling of the setup
stage, it must be saved in struct uvc_device during the setup handler in
order for the data stage handler to be able to read it and send it to
userspace.
Signed-off-by: Paul Elder
Reviewed-by: Laurent Pinchart
---
No change from v1
drivers/usb/gadget/function/f_uvc.c | 3 +++
drivers/usb/gadget/function/uvc.h | 1 +
include/uapi/linux/usb/g_uvc.h | 3 ++-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_uvc.c
b/drivers/usb/gadget/function/f_uvc.c
index 772c99c297fc..d08957124e42 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -215,6 +215,8 @@ uvc_function_ep0_complete(struct usb_ep *ep, struct
usb_request *req)
v4l2_event.type = UVC_EVENT_DATA;
uvc_event->data.length = req->actual;
memcpy(_event->data.data, req->buf, req->actual);
+ memcpy(_event->data.setup, >control_setup,
+ sizeof(uvc_event->data.setup));
v4l2_event_queue(>vdev, _event);
}
}
@@ -238,6 +240,7 @@ uvc_function_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl)
*/
uvc->event_setup_out = !(ctrl->bRequestType & USB_DIR_IN);
uvc->event_length = le16_to_cpu(ctrl->wLength);
+ memcpy(>control_setup, ctrl, sizeof(uvc->control_setup));
if (uvc->event_setup_out) {
struct usb_request *req = uvc->control_req;
diff --git a/drivers/usb/gadget/function/uvc.h
b/drivers/usb/gadget/function/uvc.h
index 671020c8a836..1d89b1df4ba0 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -163,6 +163,7 @@ struct uvc_device {
unsigned int control_intf;
struct usb_ep *control_ep;
struct usb_request *control_req;
+ struct usb_ctrlrequest control_setup;
void *control_buf;
unsigned int streaming_intf;
diff --git a/include/uapi/linux/usb/g_uvc.h b/include/uapi/linux/usb/g_uvc.h
index 6698c3263ae8..10fbb4382925 100644
--- a/include/uapi/linux/usb/g_uvc.h
+++ b/include/uapi/linux/usb/g_uvc.h
@@ -24,7 +24,8 @@
struct uvc_request_data {
__s32 length;
- __u8 data[60];
+ struct usb_ctrlrequest setup;
+ __u8 data[52];
};
struct uvc_event {
--
2.19.2
[PATCH v2 5/6] usb: musb: gadget: implement optional explicit status stage
Implement the mechanism for optional explicit status stage for the MUSB
driver. This allows a function driver to specify what to reply for the
status stage. The functionality for an implicit status stage is
retained.
Signed-off-by: Paul Elder
v1 Reviewed-by: Laurent Pinchart
v1 Acked-by: Bin Liu
---
Changes from v1:
- obvious change to implement v2 mechanism laid out by 4/6 of this
series (send_response, and musb_g_ep0_send_response function has
been removed, call to usb_gadget_control_complete has been added)
- ep0_send_response's ack argument has been changed from stall
- last_packet flag in ep0_rxstate has been removed, since it is equal to
req != NULL
drivers/usb/musb/musb_gadget.c | 1 +
drivers/usb/musb/musb_gadget_ep0.c | 28
2 files changed, 29 insertions(+)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d3f33f449445..d83315dd22b2 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -145,6 +145,7 @@ __acquires(ep->musb->lock)
trace_musb_req_gb(req);
usb_gadget_giveback_request(>ep->end_point, >request);
+ usb_gadget_control_complete(>g, request->explicit_status);
spin_lock(>lock);
ep->busy = busy;
}
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index 91a5027b5c1f..b3da48f4c63c 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -458,6 +458,25 @@ __acquires(musb->lock)
return handled;
}
+static int ep0_send_response(struct musb *musb, bool ack)
+{
+ void __iomem *regs = musb->control_ep->regs;
+ u16 ackpend;
+
+ if (musb->ep0_state != MUSB_EP0_STAGE_RX &&
+ musb->ep0_state != MUSB_EP0_STAGE_STATUSIN)
+ return -EINVAL;
+
+ ackpend = MUSB_CSR0_P_DATAEND
+ | MUSB_CSR0_P_SVDRXPKTRDY
+ | (ack ? 0 : MUSB_CSR0_P_SENDSTALL);
+
+ musb_ep_select(musb->mregs, 0);
+ musb_writew(regs, MUSB_CSR0, ackpend);
+
+ return 0;
+}
+
/* we have an ep0out data packet
* Context: caller holds controller lock
*/
@@ -504,10 +523,13 @@ static void ep0_rxstate(struct musb *musb)
if (req) {
musb->ackpend = csr;
musb_g_ep0_giveback(musb, req);
+ if (req->explicit_status)
+ return;
if (!musb->ackpend)
return;
musb->ackpend = 0;
}
+
musb_ep_select(musb->mregs, 0);
musb_writew(regs, MUSB_CSR0, csr);
}
@@ -939,6 +961,12 @@ musb_g_ep0_queue(struct usb_ep *e, struct usb_request *r,
gfp_t gfp_flags)
case MUSB_EP0_STAGE_ACKWAIT:/* zero-length data */
status = 0;
break;
+ case MUSB_EP0_STAGE_STATUSIN:
+ if (r->explicit_status)
+ status = ep0_send_response(musb, r->zero);
+ else
+ status = ep0_send_response(musb, 1);
+ goto cleanup;
default:
musb_dbg(musb, "ep0 request queued in state %d",
musb->ep0_state);
--
2.19.2
Re: [PATCH] tps65218.c: fix IRQ resource leak in tps65218_probe()
On 12/14/2018 5:56 PM, Lee Jones wrote: On Fri, 14 Dec 2018, Lee Jones wrote: On Thu, 06 Dec 2018, Christian Hohnstaedt wrote: Free allocated IRQ if reading the device ID fails. The patch is fine. However, in future please submit patches using the format set (by precedent) by the subsystem. I will fix the subject for you this time. To check the format, you can do: `git log --oneline -- ` Patch applied, by the way. This would no longer be needed as the bigger clean up is here: https://lkml.org/lkml/2018/12/9/86 As both are applied it results in a compilation issue. Lee Jones, Do you want me to submit a fix patch? Or you can revert this patch? Anything fine by me. Let me know. Thanks, Keerthy
Re: [PATCH] mailbox: imx: Fix clk handling in imx_mu_probe()
Hi Alexey,
On Sun, Dec 16, 2018 at 02:01:44AM +0300, Alexey Khoroshilov wrote:
> Handling of devm_clk_get() suggests that the driver should support
> lack of priv->clk. But imx_mu_probe() fails on clk_prepare_enable(NULL)
> in that case.
>
> The patch removes the try to enable absent clk and adds error handling
> for mbox_controller_register().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> ---
> drivers/mailbox/imx-mailbox.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 363d35d5e49d..ddde398f576e 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -292,10 +292,12 @@ static int imx_mu_probe(struct platform_device *pdev)
> priv->clk = NULL;
> }
>
> - ret = clk_prepare_enable(priv->clk);
> - if (ret) {
> - dev_err(dev, "Failed to enable clock\n");
> - return ret;
> + if (priv->clk) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "Failed to enable clock\n");
> + return ret;
> + }
> }
>
> for (i = 0; i < IMX_MU_CHANS; i++) {
> @@ -324,7 +326,13 @@ static int imx_mu_probe(struct platform_device *pdev)
>
> imx_mu_init_generic(priv);
>
> - return mbox_controller_register(>mbox);
> + ret = mbox_controller_register(>mbox);
> + if (ret) {
> + clk_disable_unprepare(priv->clk);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static int imx_mu_remove(struct platform_device *pdev)
> --
> 2.7.4
>
>
NACK for this patch.
Here are code snippets from clk framework:
/* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
static inline int clk_prepare_enable(struct clk *clk)
{
int ret;
ret = clk_prepare(clk);
if (ret)
return ret;
ret = clk_enable(clk);
if (ret)
clk_unprepare(clk);
return ret;
}
int clk_prepare(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_prepare_lock(clk->core);
}
int clk_enable(struct clk *clk)
{
if (!clk)
return 0;
return clk_core_enable_lock(clk->core);
}
As you can see, complete code path is NULL resistant. Are you trying to
fix some real issue, or it is a theoretical work?
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
RE: [PATCH v1 2/2] usb:cdns3 Add Cadence USB3 DRD Driver
Hi,
>
>On 12/12/18 12:22 PM, Felipe Balbi wrote:
>>
>> Hi
>>
>> Pawel Laszczak writes:
> + cdns->phy = devm_phy_get(dev, "cdns3,usbphy");
> + if (IS_ERR(cdns->phy)) {
> + ret = PTR_ERR(cdns->phy);
> + if (ret == -ENOSYS || ret == -ENODEV) {
Are you sure you can get ENOSYS here? Have you checked output of
checkpatch --strict?
-:852: WARNING: ENOSYS means 'invalid syscall nr' and nothing else
>>>
>>> Yes this error code can be returned by related to phy function if
>>> CONFIG_GENERIC_PHY is disabled.
>>>
>>> I have seen this warning in output of checkpatch --strict .
>>
>> Kishon, seems like you shouldn't be using that error value.
>
>hmm, yeah should change the return value to -ENODEV when GENERIC_PHY is
>disabled.
>
So I will remove this ENOSYS from next patch. I assume that it will be removed
also from generic phy driver.
Thanks,
Pawel
Re: [PATCH] dts: rockchip: rk3066: add qos_hdmi and HCLK_HDMI to pmu node
Hi Johan,
On Sun, Dec 16, 2018 at 12:03 AM Johan Jonker wrote:
>
> A MK808 TV stick with rk3066 processor boots normal with logo and console.
> After the boot the monitor remains black.
> This patch fixes a vblank timeout crash by adding qos_hdmi and
> HCLK_HDMI to the pmu node.
> The HCLK_HDMI clock and the RK3066_PD_VIO power domain
> will now turn on and off together.
>
> Signed-off-by: Johan Jonker
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 6 --
> arch/arm/boot/dts/rk3xxx.dtsi | 5 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
Thanks for the patch. Unfortunately, it looks like you didn't add the
necessary mailing lists to the recipient list. For reference, the
./scripts/get_maintainer.pl script in the kernel source tree should be
able to give you a reasonable recipient list. For now, I added the
mailing lists on CC and replied without snipping, so people should be
still able to review the patch.
Other than that, It looks reasonable to me, but we need someone with
access to SoC documentation to check it. Heiko, Sandy, is that
something you would be able to help with?
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 30dc8af0b..6e7cdde84 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -672,13 +672,15 @@
> < ACLK_IPP>,
> < HCLK_IPP>,
> < ACLK_RGA>,
> -< HCLK_RGA>;
> +< HCLK_RGA>,
> +< HCLK_HDMI>;
> pm_qos = <_lcdc0>,
> <_lcdc1>,
> <_cif0>,
> <_cif1>,
> <_ipp>,
> -<_rga>;
> +<_rga>,
> +<_hdmi>;
> };
>
> pd_video@RK3066_PD_VIDEO {
> diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
> index 97307a405..1f9496e81 100644
> --- a/arch/arm/boot/dts/rk3xxx.dtsi
> +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> @@ -187,6 +187,11 @@
> reg = <0x1012f280 0x20>;
> };
>
> + qos_hdmi: qos@1012f300 {
> + compatible = "syscon";
> + reg = <0x1012f300 0x20>;
> + };
> +
Is this really common for all rk3xxx SoCs?
> usb_otg: usb@1018 {
> compatible = "rockchip,rk3066-usb", "snps,dwc2";
> reg = <0x1018 0x4>;
> --
> 2.11.0
>
Best regards,
Tomasz
linux-next: build failure after merge of the mfd tree
Hi all,
After merging the mfd tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mfd/tps65218.c: In function 'tps65218_probe':
drivers/mfd/tps65218.c:247:3: error: label 'err_irq' used but not defined
goto err_irq;
^~~~
Caused by commit
05ba643fa2ce ("mfd: tps65218: Use devm_regmap_add_irq_chip and clean up error
path in probe()")
I have used the mfd tree from next-20181214 for today.
--
Cheers,
Stephen Rothwell
pgpBydFGXBP_F.pgp
Description: OpenPGP digital signature
Re: [RESEND PATCH v4 1/1] dt-bindings: arm-smmu: Add binding doc for Qcom smmu-500
On Thu, Dec 13, 2018 at 4:16 PM Will Deacon wrote: > > On Thu, Dec 13, 2018 at 02:35:07PM +0530, Vivek Gautam wrote: > > Qcom's implementation of arm,mmu-500 works well with current > > arm-smmu driver implementation. Adding a soc specific compatible > > along with arm,mmu-500 makes the bindings future safe. > > > > Signed-off-by: Vivek Gautam > > Reviewed-by: Rob Herring > > Cc: Will Deacon > > --- > > > > Hi Joerg, > > I am picking this out separately from the sdm845 smmu support > > series [1], so that this can go through iommu tree. > > The dt patch from the series [1] can be taken through arm-soc tree. > > > > Hi Will, > > As asked [2], here's the resend version of dt binding patch for sdm845. > > Kindly ack this so that Joerg can pull this in. > > Acked-by: Will Deacon Thanks a lot Will for the Ack. Regards Vivek > > Joerg -- please can you take this on top of the pull request I sent already? > Vivek included it as part of a separate series which I thought was going > via arm-soc, but actually it needs to go with the other arm-smmu patches > in order to avoid conflicts. > > Cheers, > > Will > > > Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > index a6504b37cc21..3133f3ba7567 100644 > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > > @@ -27,6 +27,10 @@ conditions. > >"qcom,msm8996-smmu-v2", "qcom,smmu-v2", > >"qcom,sdm845-smmu-v2", "qcom,smmu-v2". > > > > + Qcom SoCs implementing "arm,mmu-500" must also include, > > + as below, SoC-specific compatibles: > > + "qcom,sdm845-smmu-500", "arm,mmu-500" > > + > > - reg : Base address and size of the SMMU. > > > > - #global-interrupts : The number of global interrupts exposed by the > > -- > > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > > of Code Aurora Forum, hosted by The Linux Foundation > > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774c0
On 13-12-18, 20:21, Fabrizio Castro wrote: > This patch adds bindings for the r8a774c0 (RZ/G2E). Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: Document R8A774C0 bindings
On 13-12-18, 20:17, Fabrizio Castro wrote: > Renesas' RZ/G2E (R8A774C0) SoC has DMA controllers compatible > with this driver, therefore document RZ/G2E specific bindings. Applied, thanks -- ~Vinod
[PATCH V5 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support
The accelerometer's power supply could be controllable on some
platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
are controlled by a GPIO fixed regulator, need to make sure the
regulators are enabled before any communication with mma8451, this
patch adds vdd/vddio regulator operation support.
Signed-off-by: Anson Huang
Acked-by: Martin Kepplinger
---
ChangeLog since V4:
- using devm_regulator_get() instead of devm_regulator_get_optional() since
the regulator is
there always, if dtb does NOT specify one, regulator framework will
assign dummy regulator for it.
---
drivers/iio/accel/mma8452.c | 183 +---
1 file changed, 172 insertions(+), 11 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index 421a0a8..9a52426 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#define MMA8452_STATUS 0x00
#define MMA8452_STATUS_DRDY (BIT(2) | BIT(1) | BIT(0))
@@ -107,6 +108,8 @@ struct mma8452_data {
u8 data_cfg;
const struct mma_chip_info *chip_info;
int sleep_val;
+ struct regulator *vdd_reg;
+ struct regulator *vddio_reg;
};
/**
@@ -1534,9 +1537,37 @@ static int mma8452_probe(struct i2c_client *client,
mutex_init(>lock);
data->chip_info = match->data;
+ data->vdd_reg = devm_regulator_get(>dev, "vdd");
+ if (IS_ERR(data->vdd_reg)) {
+ ret = PTR_ERR(data->vdd_reg);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "failed to get VDD regulator!\n");
+ return ret;
+ }
+
+ ret = regulator_enable(data->vdd_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDD regulator!\n");
+ return ret;
+ }
+
+ data->vddio_reg = devm_regulator_get(>dev, "vddio");
+ if (IS_ERR(data->vddio_reg)) {
+ ret = PTR_ERR(data->vddio_reg);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "failed to get VDDIO
regulator!\n");
+ goto disable_regulator_vdd;
+ }
+
+ ret = regulator_enable(data->vddio_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDDIO regulator!\n");
+ goto disable_regulator_vdd;
+ }
+
ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
if (ret < 0)
- return ret;
+ goto disable_regulators;
switch (ret) {
case MMA8451_DEVICE_ID:
@@ -1549,7 +1580,8 @@ static int mma8452_probe(struct i2c_client *client,
break;
/* else: fall through */
default:
- return -ENODEV;
+ ret = -ENODEV;
+ goto disable_regulators;
}
dev_info(>dev, "registering %s accelerometer; ID 0x%x\n",
@@ -1566,13 +1598,13 @@ static int mma8452_probe(struct i2c_client *client,
ret = mma8452_reset(client);
if (ret < 0)
- return ret;
+ goto disable_regulators;
data->data_cfg = MMA8452_DATA_CFG_FS_2G;
ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
data->data_cfg);
if (ret < 0)
- return ret;
+ goto disable_regulators;
/*
* By default set transient threshold to max to avoid events if
@@ -1581,7 +1613,7 @@ static int mma8452_probe(struct i2c_client *client,
ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
MMA8452_TRANSIENT_THS_MASK);
if (ret < 0)
- return ret;
+ goto disable_regulators;
if (client->irq) {
int irq2;
@@ -1595,7 +1627,7 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG5,
data->chip_info->all_events);
if (ret < 0)
- return ret;
+ goto disable_regulators;
dev_dbg(>dev, "using interrupt line INT1\n");
}
@@ -1604,11 +1636,11 @@ static int mma8452_probe(struct i2c_client *client,
MMA8452_CTRL_REG4,
data->chip_info->enabled_events);
if (ret < 0)
- return ret;
+ goto disable_regulators;
ret = mma8452_trigger_setup(indio_dev);
if (ret < 0)
- return ret;
+ goto disable_regulators;
}
data->ctrl_reg1 = MMA8452_CTRL_ACTIVE |
@@ -1661,12 +1693,20 @@ static int mma8452_probe(struct i2c_client *client,
[PATCH V5 1/2] dt-bindings: iio: accel: mma8452: add power supplies property
The accelerometer's power supplies could be controllable on some
platforms, add property "vdd/vddio" power supply to let device tree
to pass phandles to the regulators to driver.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
index 2100e9a..e132394 100644
--- a/Documentation/devicetree/bindings/iio/accel/mma8452.txt
+++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt
@@ -20,6 +20,10 @@ Optional properties:
- interrupt-names: should contain "INT1" and/or "INT2", the accelerometer's
interrupt line in use.
+ - vdd-supply: phandle to the regulator that provides vdd power to the
accelerometer.
+
+ - vddio-supply: phandle to the regulator that provides vddio power to the
accelerometer.
+
Example:
mma8453fc@1d {
--
2.7.4
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kvm/vmx.c
between commit:
a97673a1c43d ("x86: Fix various typos in comments")
from the tip tree and commit:
a821bab2d1ee ("KVM: VMX: Move VMX specific files to a "vmx" subdirectory")
from the kvm tree.
I fixed it up (I removed the file and then made the same changes to
the file in its new position (one change was already fixed)) 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 --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index b8fa74ce3af2..c90fffdc5a93 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -2214,7 +2214,7 @@ static __init int alloc_kvm_area(void)
* vmcs->revision_id to KVM_EVMCS_VERSION instead of
* revision_id reported by MSR_IA32_VMX_BASIC.
*
-* However, even though not explictly documented by
+* However, even though not explicitly documented by
* TLFS, VMXArea passed as VMXON argument should
* still be marked with revision_id reported by
* physical CPU.
pgpAYRwgOvxrW.pgp
Description: OpenPGP digital signature
[PATCH v2] net/smc: fix TCP fallback socket release
clcsock can be released while kernel_accept() references it in TCP
listen worker. Also, clcsock needs to wake up before released if TCP
fallback is used and the clcsock is blocked by accept. Add a lock to
safely release clcsock and call kernel_sock_shutdown() to wake up
clcsock from accept in smc_release().
Reported-by: syzbot+0bf2e01269f1274b4...@syzkaller.appspotmail.com
Reported-by: syzbot+e3132895630f95730...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung
---
net/smc/af_smc.c | 14 --
net/smc/smc.h| 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 5fbaf1901571..5d06fb1bbccf 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -147,8 +147,14 @@ static int smc_release(struct socket *sock)
sk->sk_shutdown |= SHUTDOWN_MASK;
}
if (smc->clcsock) {
+ if (smc->use_fallback && sk->sk_state == SMC_LISTEN) {
+ /* wake up clcsock accept */
+ rc = kernel_sock_shutdown(smc->clcsock, SHUT_RDWR);
+ }
+ mutex_lock(>clcsock_release_lock);
sock_release(smc->clcsock);
smc->clcsock = NULL;
+ mutex_unlock(>clcsock_release_lock);
}
if (smc->use_fallback) {
if (sk->sk_state != SMC_LISTEN && sk->sk_state != SMC_INIT)
@@ -205,6 +211,7 @@ static struct sock *smc_sock_alloc(struct net *net, struct
socket *sock,
spin_lock_init(>conn.send_lock);
sk->sk_prot->hash(sk);
sk_refcnt_debug_inc(sk);
+ mutex_init(>clcsock_release_lock);
return sk;
}
@@ -821,7 +828,7 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct
smc_sock **new_smc)
struct socket *new_clcsock = NULL;
struct sock *lsk = >sk;
struct sock *new_sk;
- int rc;
+ int rc = 0;
release_sock(lsk);
new_sk = smc_sock_alloc(sock_net(lsk), NULL, lsk->sk_protocol);
@@ -834,7 +841,10 @@ static int smc_clcsock_accept(struct smc_sock *lsmc,
struct smc_sock **new_smc)
}
*new_smc = smc_sk(new_sk);
- rc = kernel_accept(lsmc->clcsock, _clcsock, 0);
+ mutex_lock(>clcsock_release_lock);
+ if (lsmc->clcsock)
+ rc = kernel_accept(lsmc->clcsock, _clcsock, 0);
+ mutex_unlock(>clcsock_release_lock);
lock_sock(lsk);
if (rc < 0)
lsk->sk_err = -rc;
diff --git a/net/smc/smc.h b/net/smc/smc.h
index 08786ace6010..9a2795cf5d30 100644
--- a/net/smc/smc.h
+++ b/net/smc/smc.h
@@ -219,6 +219,8 @@ struct smc_sock { /* smc sock
container */
* started, waiting for unsent
* data to be sent
*/
+ struct mutexclcsock_release_lock;
+ /* protects clcsock */
};
static inline struct smc_sock *smc_sk(const struct sock *sk)
--
2.17.1
Re: [PATCH] net/smc: fix TCP fallback socket release
Hi Myungho,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.20-rc7 next-20181214]
[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/Myungho-Jung/net-smc-fix-TCP-fallback-socket-release/20181217-122513
config: x86_64-randconfig-x015-201850 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
net/smc/af_smc.c: In function 'smc_tcp_listen_work':
>> net/smc/af_smc.c:1318:6: warning: 'rc' may be used uninitialized in this
>> function [-Wmaybe-uninitialized]
if (rc)
^
vim +/rc +1318 net/smc/af_smc.c
a046d57d Ursula Braun 2017-01-09 1306
a046d57d Ursula Braun 2017-01-09 1307 static void smc_tcp_listen_work(struct
work_struct *work)
a046d57d Ursula Braun 2017-01-09 1308 {
a046d57d Ursula Braun 2017-01-09 1309 struct smc_sock *lsmc =
container_of(work, struct smc_sock,
a046d57d Ursula Braun 2017-01-09 1310
tcp_listen_work);
3163c507 Ursula Braun 2018-01-24 1311 struct sock *lsk = >sk;
a046d57d Ursula Braun 2017-01-09 1312 struct smc_sock *new_smc;
a046d57d Ursula Braun 2017-01-09 1313 int rc = 0;
a046d57d Ursula Braun 2017-01-09 1314
3163c507 Ursula Braun 2018-01-24 1315 lock_sock(lsk);
3163c507 Ursula Braun 2018-01-24 1316 while (lsk->sk_state ==
SMC_LISTEN) {
a046d57d Ursula Braun 2017-01-09 1317 rc =
smc_clcsock_accept(lsmc, _smc);
a046d57d Ursula Braun 2017-01-09 @1318 if (rc)
a046d57d Ursula Braun 2017-01-09 1319 goto out;
a046d57d Ursula Braun 2017-01-09 1320 if (!new_smc)
a046d57d Ursula Braun 2017-01-09 1321 continue;
a046d57d Ursula Braun 2017-01-09 1322
a046d57d Ursula Braun 2017-01-09 1323 new_smc->listen_smc =
lsmc;
ee9dfbef Ursula Braun 2018-04-26 1324 new_smc->use_fallback =
lsmc->use_fallback;
603cc149 Karsten Graul 2018-07-25 1325 new_smc->fallback_rsn =
lsmc->fallback_rsn;
3163c507 Ursula Braun 2018-01-24 1326 sock_hold(lsk); /*
sock_put in smc_listen_work */
a046d57d Ursula Braun 2017-01-09 1327
INIT_WORK(_smc->smc_listen_work, smc_listen_work);
a046d57d Ursula Braun 2017-01-09 1328
smc_copy_sock_settings_to_smc(new_smc);
bd58c7e0 Ursula Braun 2018-08-08 1329 new_smc->sk.sk_sndbuf =
lsmc->sk.sk_sndbuf;
bd58c7e0 Ursula Braun 2018-08-08 1330 new_smc->sk.sk_rcvbuf =
lsmc->sk.sk_rcvbuf;
51f1de79 Ursula Braun 2018-01-26 1331
sock_hold(_smc->sk); /* sock_put in passive closing */
51f1de79 Ursula Braun 2018-01-26 1332 if
(!schedule_work(_smc->smc_listen_work))
51f1de79 Ursula Braun 2018-01-26 1333
sock_put(_smc->sk);
a046d57d Ursula Braun 2017-01-09 1334 }
a046d57d Ursula Braun 2017-01-09 1335
a046d57d Ursula Braun 2017-01-09 1336 out:
3163c507 Ursula Braun 2018-01-24 1337 release_sock(lsk);
51f1de79 Ursula Braun 2018-01-26 1338 sock_put(>sk); /*
sock_hold in smc_listen */
a046d57d Ursula Braun 2017-01-09 1339 }
a046d57d Ursula Braun 2017-01-09 1340
:: The code at line 1318 was first introduced by commit
:: a046d57da19f812216f393e7c535f5858f793ac3 smc: CLC handshake (incl.
preparation steps)
:: TO: Ursula Braun
:: CC: David S. Miller
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] arc: remove redundant kernel-space generic-y
On 12/16/18 6:17 AM, Masahiro Yamada wrote: > This commit removes redundant generic-y defines in > arch/arc/include/asm/Kbuild. > > It is redundant to define generic-y when arch-specific implementation > exists in arch/$(ARCH)/include/asm/*.h > > Remove the following generic-y: > > dma-mapping.h > fb.h > kmap_types.h > pci.h > > Signed-off-by: Masahiro Yamada Acked-by: Vineet Gupta
[PATCH V5 1/2] dt-bindings: iio: magnetometer: add dt-bindings for freescale mag3110
Add Freescale MAG3110 dt-bindings and remove it from trivial-devices
dt-bingding doc.
Signed-off-by: Anson Huang
---
.../bindings/iio/magnetometer/mag3110.txt | 27 ++
.../devicetree/bindings/trivial-devices.txt| 1 -
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
b/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
new file mode 100644
index 000..bdd40bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/mag3110.txt
@@ -0,0 +1,27 @@
+* FREESCALE MAG3110 magnetometer sensor
+
+Required properties:
+
+ - compatible : should be "fsl,mag3110"
+ - reg : the I2C address of the magnetometer
+
+Optional properties:
+
+ - interrupts: the sole interrupt generated by the device
+
+ Refer to interrupt-controller/interrupts.txt for generic interrupt client
+ node bindings.
+
+ - vdd-supply: phandle to the regulator that provides power to the sensor.
+ - vddio-supply: phandle to the regulator that provides power to the sensor's
IO.
+
+Example:
+
+magnetometer@e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c3_mag3110_int>;
+ interrupt-parent = <>;
+ interrupts = <16 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt
b/Documentation/devicetree/bindings/trivial-devices.txt
index 6ab001f..5f086ac 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -43,7 +43,6 @@ domintech,dmard10 DMARD10: 3-axis Accelerometer
epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
emmicro,em3027 EM Microelectronic EM3027 Real-time Clock
-fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mma7660MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic
Accelerometer
fsl,mpl3115MPL3115: Absolute Digital Pressure Sensor
--
2.7.4
[PATCH V5 2/2] iio: magnetometer: mag3110: add vdd/vddio regulator operation support
The magnetometer's power supplies could be controllable on some platforms,
such as i.MX6Q-SABRESD board, the mag3110's power supplies are controlled
by a GPIO fixed regulator, need to make sure the regulators are enabled
before any communication with mag3110, this patch adds vdd/vddio regulator
operation support.
Signed-off-by: Anson Huang
---
ChangeLog since V4:
- using devm_regulator_get() instead of devm_regulator_get_optional()
since the regulator is
there always, if dtb does NOT specify one, regulator framework will
assign dummy regulator for it
---
drivers/iio/magnetometer/mag3110.c | 92 ++
1 file changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/magnetometer/mag3110.c
b/drivers/iio/magnetometer/mag3110.c
index f063355..32660ce 100644
--- a/drivers/iio/magnetometer/mag3110.c
+++ b/drivers/iio/magnetometer/mag3110.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#define MAG3110_STATUS 0x00
#define MAG3110_OUT_X 0x01 /* MSB first */
@@ -56,6 +57,8 @@ struct mag3110_data {
struct mutex lock;
u8 ctrl_reg1;
int sleep_val;
+ struct regulator *vdd_reg;
+ struct regulator *vddio_reg;
};
static int mag3110_request(struct mag3110_data *data)
@@ -469,17 +472,48 @@ static int mag3110_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
int ret;
- ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
- if (ret < 0)
- return ret;
- if (ret != MAG3110_DEVICE_ID)
- return -ENODEV;
-
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (!indio_dev)
return -ENOMEM;
data = iio_priv(indio_dev);
+
+ data->vdd_reg = devm_regulator_get(>dev, "vdd");
+ if (IS_ERR(data->vdd_reg)) {
+ ret = PTR_ERR(data->vdd_reg);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "failed to get VDD regulator!\n");
+ return ret;
+ }
+
+ ret = regulator_enable(data->vdd_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDD regulator!\n");
+ return ret;
+ }
+
+ data->vddio_reg = devm_regulator_get(>dev, "vddio");
+ if (IS_ERR(data->vddio_reg)) {
+ ret = PTR_ERR(data->vddio_reg);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>dev, "failed to get VDDIO
regulator!\n");
+ goto disable_regulator_vdd;
+ }
+
+ ret = regulator_enable(data->vddio_reg);
+ if (ret) {
+ dev_err(>dev, "failed to enable VDDIO regulator!\n");
+ goto disable_regulator_vdd;
+ }
+
+ ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
+ if (ret < 0)
+ goto disable_regulators;
+ if (ret != MAG3110_DEVICE_ID) {
+ ret = -ENODEV;
+ goto disable_regulators;
+ }
+
data->client = client;
mutex_init(>lock);
@@ -499,7 +533,7 @@ static int mag3110_probe(struct i2c_client *client,
ret = mag3110_change_config(data, MAG3110_CTRL_REG1, data->ctrl_reg1);
if (ret < 0)
- return ret;
+ goto disable_regulators;
ret = i2c_smbus_write_byte_data(client, MAG3110_CTRL_REG2,
MAG3110_CTRL_AUTO_MRST_EN);
@@ -520,16 +554,24 @@ static int mag3110_probe(struct i2c_client *client,
iio_triggered_buffer_cleanup(indio_dev);
standby_on_error:
mag3110_standby(iio_priv(indio_dev));
+disable_regulators:
+ regulator_disable(data->vddio_reg);
+disable_regulator_vdd:
+ regulator_disable(data->vdd_reg);
+
return ret;
}
static int mag3110_remove(struct i2c_client *client)
{
struct iio_dev *indio_dev = i2c_get_clientdata(client);
+ struct mag3110_data *data = iio_priv(indio_dev);
iio_device_unregister(indio_dev);
iio_triggered_buffer_cleanup(indio_dev);
mag3110_standby(iio_priv(indio_dev));
+ regulator_disable(data->vddio_reg);
+ regulator_disable(data->vdd_reg);
return 0;
}
@@ -537,14 +579,48 @@ static int mag3110_remove(struct i2c_client *client)
#ifdef CONFIG_PM_SLEEP
static int mag3110_suspend(struct device *dev)
{
- return mag3110_standby(iio_priv(i2c_get_clientdata(
+ struct mag3110_data *data = iio_priv(i2c_get_clientdata(
+ to_i2c_client(dev)));
+ int ret;
+
+ ret = mag3110_standby(iio_priv(i2c_get_clientdata(
to_i2c_client(dev;
+ if (ret)
+ return ret;
+
+ ret = regulator_disable(data->vddio_reg);
+ if (ret) {
+ dev_err(dev, "failed to disable VDDIO regulator\n");
+ return ret;
+ }
+
+ ret = regulator_disable(data->vdd_reg);
+ if (ret) {
+ dev_err(dev, "failed to disable VDD regulator\n");
+
Re: [PATCH v9 RESEND 0/4] KASLR feature to randomize each loadable module
+++ Edgecombe, Rick P [12/12/18 23:05 +]: On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote: On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote: > On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote: > > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote: > > > +++ Rick Edgecombe [20/11/18 15:23 -0800]: > > > > [snip] > > > Hi Rick! > > > > > > Sorry for the delay. I'd like to take a step back and ask some broader > > > questions - > > > > > > - Is the end goal of this patchset to randomize loading kernel modules, > > > or > > > most/all > > >executable kernel memory allocations, including bpf, kprobes, etc? > > > > Thanks for taking a look! > > > > It started with the goal of just randomizing modules (hence the name), but > > I > > think there is maybe value in randomizing the placement of all runtime > > added > > executable code. Beyond just trying to make executable code placement less > > deterministic in general, today all of the usages have the property of > > starting > > with RW permissions and then becoming RO executable, so there is the > > benefit > > of > > narrowing the chances a bug could successfully write to it during the RW > > window. > > > > > - It seems that a lot of complexity and heuristics are introduced just > > > to > > >accommodate the potential fragmentation that can happen when the > > > module > > > vmalloc > > >space starts to get fragmented with bpf filters. I'm partial to the > > > idea of > > >splitting or having bpf own its own vmalloc space, similar to what > > > Ard > > > is > > > already > > >implementing for arm64. > > > > > >So a question for the bpf and x86 folks, is having a dedicated > > > vmalloc > > > region > > >(as well as a seperate bpf_alloc api) for bpf feasible or desirable > > > on > > > x86_64? > > > > I actually did some prototyping and testing on this. It seems there would > > be > > some slowdown from the required changes to the JITed code to support > > calling > > back from the vmalloc region into the kernel, and so module space would > > still be > > the preferred region. > > Yes, any runtime slow-down would be no-go as BPF sits in the middle of > critical > networking fast-path and e.g. on XDP or tc layer and is used in load- > balancing, > firewalling, DDoS protection scenarios, some recent examples in [0-3]. > > [0] http://vger.kernel.org/lpc-networking2018.html#session-10 > [1] http://vger.kernel.org/lpc-networking2018.html#session-15 > [2] https://blog.cloudflare.com/how-to-drop-10-million-packets/ > [3] http://vger.kernel.org/lpc-bpf2018.html#session-1 > > > >If bpf filters need to be within 2 GB of the core kernel, would it > > > make > > > sense > > >to carve out a portion of the current module region for bpf > > > filters? According > > >to Documentation/x86/x86_64/mm.txt, the module region is ~1.5 GB. I > > > am > > > doubtful > > >that any real system will actually have 1.5 GB worth of kernel > > > modules > > > loaded. > > >Is there a specific reason why that much space is dedicated to kernel > > > modules, > > >and would it be feasible to split that region cleanly with bpf? > > > > Hopefully someone from BPF side of things will chime in, but my > > understanding > > was that they would like even more space than today if possible and so > > they > > may > > not like the reduced space. > > I wouldn't mind of the region is split as Jessica suggests but in a way > where > there would be _no_ runtime regressions for BPF. This might also allow to > have > more flexibility in sizing the area dedicated for BPF in future, and could > potentially be done in similar way as Ard was proposing recently [4]. > > [4] https://patchwork.ozlabs.org/project/netdev/list/?series=9 CCing Ard. The benefit of sharing the space, for randomization at least, is that you can spread the allocations over a larger area. I think there are also other benefits to unifying how this memory is managed though, rather than spreading it further. Today there are various patterns and techniques used like calling different combinations of set_memory_* before freeing, zeroing in modules or setting invalid instructions like BPF does, etc. There is also special care to be taken on vfree-ing executable memory. So this way things only have to be done right once and there is less duplication. Not saying there shouldn't be __weak alloc and free method in BPF for arch specific behavior, just that there is quite a few other concerns that could be good to centralize even more than today. What if there was a unified executable alloc API with support for things like: - Concepts of two regions for Ard's usage, near(modules) and far(vmalloc) from kernel text. Won't apply for every arch, but maybe enough that some logic could be unified - Limits for each of the usages (modules, bpf, kprobes, ftrace) - Centralized logic for moving between RW and RO+X - Options for exclusive regions or all
Re: [PATCH v3 2/3] dt-bindings: reset: imx7: Document usage on i.MX8MQ SoCs
Hi Andrey,
Andrey Smirnov writes:
> The driver now supports i.MX8MQ, so update bindings accordingly.
>
> Cc: p.za...@pengutronix.de
> Cc: Fabio Estevam
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez
> Cc: "A.s. Dong"
> Cc: Richard Zhu
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov
> ---
> .../bindings/reset/fsl,imx7-src.txt | 7 +-
> include/dt-bindings/reset/imx8mq-reset.h | 64 +++
This header file belongs at the next patch in this series, right?
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 v3 3/3] reset: imx7: Add support for i.MX8MQ IP block variant
> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: Monday, December 17, 2018 10:38 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andrey Smirnov ; p.za...@pengutronix.de;
> Fabio Estevam ; cphe...@gmail.com;
> l.st...@pengutronix.de; Leonard Crestez ; Aisheng
> Dong ; Richard Zhu ; Rob
> Herring ; devicet...@vger.kernel.org; dl-linux-imx
> ; linux-arm-ker...@lists.infradead.org
> Subject: [PATCH v3 3/3] reset: imx7: Add support for i.MX8MQ IP block variant
>
> Add bits and pieces needed to support IP block variant found on i.MX8MQ
> SoCs.
>
> Cc: p.za...@pengutronix.de
> Cc: Fabio Estevam
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez
> Cc: "A.s. Dong"
> Cc: Richard Zhu
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov
> ---
> drivers/reset/Kconfig | 2 +-
> drivers/reset/reset-imx7.c | 106
> +
> 2 files changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> c21da9fe51ec..4909aab7401b 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -50,7 +50,7 @@ config RESET_HSDK
> config RESET_IMX7
> bool "i.MX7 Reset Driver" if COMPILE_TEST
> depends on HAS_IOMEM
> - default SOC_IMX7D
> + default SOC_IMX7D || SOC_IMX8MQ
SOC_IMX8MQ has been removed in Shawn's tree.
I'd suggest simply using ARCH_MXC.
Regards
Dong Aisheng
> select MFD_SYSCON
> help
> This enables the reset controller driver for i.MX7 SoCs.
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c index
> 3a36d5863891..bb826935db6d 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> struct imx7_src_signal {
> unsigned int offset, bit;
> @@ -113,6 +114,110 @@ static const struct imx7_src_variant variant_imx7 =
> {
> .prepare = imx7_src_prepare,
> };
>
> +enum imx8mq_src_registers {
> + SRC_A53RCR0 = 0x0004,
> + SRC_HDMI_RCR= 0x0030,
> + SRC_DISP_RCR= 0x0034,
> + SRC_GPU_RCR = 0x0040,
> + SRC_VPU_RCR = 0x0044,
> + SRC_PCIE2_RCR = 0x0048,
> + SRC_MIPIPHY1_RCR= 0x004c,
> + SRC_MIPIPHY2_RCR= 0x0050,
> + SRC_DDRC2_RCR = 0x1004,
> +};
> +
> +static const struct imx7_src_signal
> imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
> + [IMX8MQ_RESET_A53_CORE_POR_RESET0] = { SRC_A53RCR0, BIT(0) },
> + [IMX8MQ_RESET_A53_CORE_POR_RESET1] = { SRC_A53RCR0, BIT(1) },
> + [IMX8MQ_RESET_A53_CORE_POR_RESET2] = { SRC_A53RCR0, BIT(2) },
> + [IMX8MQ_RESET_A53_CORE_POR_RESET3] = { SRC_A53RCR0, BIT(3) },
> + [IMX8MQ_RESET_A53_CORE_RESET0] = { SRC_A53RCR0, BIT(4) },
> + [IMX8MQ_RESET_A53_CORE_RESET1] = { SRC_A53RCR0, BIT(5) },
> + [IMX8MQ_RESET_A53_CORE_RESET2] = { SRC_A53RCR0, BIT(6) },
> + [IMX8MQ_RESET_A53_CORE_RESET3] = { SRC_A53RCR0, BIT(7) },
> + [IMX8MQ_RESET_A53_DBG_RESET0] = { SRC_A53RCR0, BIT(8) },
> + [IMX8MQ_RESET_A53_DBG_RESET1] = { SRC_A53RCR0, BIT(9) },
> + [IMX8MQ_RESET_A53_DBG_RESET2] = { SRC_A53RCR0, BIT(10) },
> + [IMX8MQ_RESET_A53_DBG_RESET3] = { SRC_A53RCR0, BIT(11) },
> + [IMX8MQ_RESET_A53_ETM_RESET0] = { SRC_A53RCR0, BIT(12) },
> + [IMX8MQ_RESET_A53_ETM_RESET1] = { SRC_A53RCR0, BIT(13) },
> + [IMX8MQ_RESET_A53_ETM_RESET2] = { SRC_A53RCR0, BIT(14) },
> + [IMX8MQ_RESET_A53_ETM_RESET3] = { SRC_A53RCR0, BIT(15) },
> + [IMX8MQ_RESET_A53_SOC_DBG_RESET]= { SRC_A53RCR0, BIT(20) },
> + [IMX8MQ_RESET_A53_L2RESET] = { SRC_A53RCR0, BIT(21) },
> + [IMX8MQ_RESET_SW_NON_SCLR_M4C_RST] = { SRC_M4RCR, BIT(0) },
> + [IMX8MQ_RESET_OTG1_PHY_RESET] = { SRC_USBOPHY1_RCR,
> BIT(0) },
> + [IMX8MQ_RESET_OTG2_PHY_RESET] = { SRC_USBOPHY2_RCR,
> BIT(0) },
> + [IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N]= { SRC_MIPIPHY_RCR,
> BIT(1) },
> + [IMX8MQ_RESET_MIPI_DSI_RESET_N] = { SRC_MIPIPHY_RCR,
> BIT(2) },
> + [IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N] = { SRC_MIPIPHY_RCR,
> BIT(3) },
> + [IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N] = { SRC_MIPIPHY_RCR,
> BIT(4) },
> + [IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N]= { SRC_MIPIPHY_RCR,
> BIT(5) },
> + [IMX8MQ_RESET_PCIEPHY] = { SRC_PCIEPHY_RCR,
> + BIT(2) | BIT(1) },
> + [IMX8MQ_RESET_PCIEPHY_PERST]= { SRC_PCIEPHY_RCR,
> BIT(3) },
> + [IMX8MQ_RESET_PCIE_CTRL_APPS_EN]= { SRC_PCIEPHY_RCR,
> BIT(6) },
> + [IMX8MQ_RESET_PCIE_CTRL_APPS_TURNOFF] = {
Re: rcu_preempt caused oom
On Mon, Dec 17, 2018 at 03:15:42AM +, He, Bo wrote:
> for double confirm the issue is not reproduce after 90 hours, we tried only
> add the enclosed patch on the easy reproduced build, the issue is not
> reproduced after 63 hours in the whole weekend on 16 boards.
> so current conclusion is the debug patch has extreme effect on the rcu issue.
This is not a surprise. (Please see the end of this email for a
replacement patch that won't suppress the bug.)
To see why this is not a surprise, let's take a closer look at your patch,
in light of the comment header for wait_event_idle_timeout_exclusive():
* Returns:
* 0 if the @condition evaluated to %false after the @timeout elapsed,
* 1 if the @condition evaluated to %true after the @timeout elapsed,
* or the remaining jiffies (at least 1) if the @condition evaluated
* to %true before the @timeout elapsed.
The situation we are seeing is that the RCU_GP_FLAG_INIT is set, but
the rcu_preempt task does not wake up. This would correspond to
the second case above, that is, a return value of 1. Looking now
at your patch, with comments interspersed below:
>From e8b583aa685b3b4f304f72398a80461bba09389c Mon Sep 17 00:00:00 2001
From: "he, bo"
Date: Sun, 9 Dec 2018 18:11:33 +0800
Subject: [PATCH] rcu: detect the preempt_rcu hang for triage jing's board
Change-Id: I2ffceec2ae4847867753609e45c99afc66956003
Tracked-On:
Signed-off-by: he, bo
---
kernel/rcu/tree.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 78c0cf2..d6de363 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2192,8 +2192,13 @@ static int __noreturn rcu_gp_kthread(void *arg)
int ret;
struct rcu_state *rsp = arg;
struct rcu_node *rnp = rcu_get_root(rsp);
+ pid_t rcu_preempt_pid;
rcu_bind_gp_kthread();
+ if(!strcmp(rsp->name, "rcu_preempt")) {
+ rcu_preempt_pid = rsp->gp_kthread->pid;
+ }
+
for (;;) {
/* Handle grace-period start. */
@@ -2202,8 +2207,19 @@ static int __noreturn rcu_gp_kthread(void *arg)
READ_ONCE(rsp->gp_seq),
TPS("reqwait"));
rsp->gp_state = RCU_GP_WAIT_GPS;
- swait_event_idle_exclusive(rsp->gp_wq,
READ_ONCE(rsp->gp_flags) &
-RCU_GP_FLAG_INIT);
+ if (current->pid != rcu_preempt_pid) {
+ swait_event_idle_exclusive(rsp->gp_wq,
READ_ONCE(rsp->gp_flags) &
+ RCU_GP_FLAG_INIT);
+ } else {
+ ret =
swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) &
+ RCU_GP_FLAG_INIT, 2*HZ);
+
+ if(!ret) {
We get here if ret==0. Therefore, the above "if" statement needs to
instead be "if (ret == 1) {".
In addition, in order to get event traces dumped, we also need:
rcu_ftrace_dump(DUMP_ALL);
+ show_rcu_gp_kthreads();
+ panic("hung_task: blocked in
rcu_gp_kthread init");
+ }
+ }
+
rsp->gp_state = RCU_GP_DONE_GPS;
/* Locking provides needed memory barrier. */
if (rcu_gp_init(rsp))
--
2.7.4
So, again, please change the "if(!ret) {" to "if (ret == 1) {", and
please add "rcu_ftrace_dump(DUMP_ALL);" right after this "if" statement,
as shown above.
With that change, I bet that you will again see failures.
> Compared with the swait_event_idle_timeout_exclusive will do 3 times to check
> the condition, while swait_event_idle_ exclusive will do 2 times check the
> condition.
>
> so today I will do another experiment, only change as below:
> - swait_event_idle_exclusive(rsp->gp_wq,
> READ_ONCE(rsp->gp_flags) &
> - RCU_GP_FLAG_INIT);
> + ret = swait_event_idle_timeout_exclusive(rsp->gp_wq,
> READ_ONCE(rsp->gp_flags) &
> + RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT);
> +
>
> Can you get some clues from the experiment?
Again, please instead make the changes that I called out above, with
the replacement for your patch 0001 shown below.
Thanx, Paul
PS. I have been testing for quite some time, but am still unable
to reproduce this. So we must depend on you to reproduce it.
Re: > [PATCH] Security: Handle hidepid option correctly
Actually I'm pretty sure kernel calls proc_mount() Here is the call stack [0.003450] [] proc_mount+0x2c/0x98 [0.003459] [] mount_fs+0x164/0x190 [0.003465] [] vfs_kern_mount+0x74/0x168 [0.003469] [] kern_mount_data+0x18/0x30 [0.003474] [] pid_ns_prepare_proc+0x24/0x40 [0.003484] [] alloc_pid+0x498/0x4b4 [0.003492] [] copy_process.isra.73.part.74+0xed0/0x1708 [0.003496] [] _do_fork+0xdc/0x3f8 [0.003501] [] kernel_thread+0x34/0x3c [0.003511] [] rest_init+0x20/0x80 [0.003522] [] start_kernel+0x3e4/0x43c [0.003527] [] __primary_switched+0x64/0x90 Alexey Dobriyan 于2018年12月14日周五 下午11:44写道： > > On Wed, Dec 05, 2018 at 03:26:04PM +0800, 程洋 wrote: > > Anyone who can review my patch? > > > > 程洋 于2018年11月30日周五 上午10:34写道： > > > > > > Here is an article illustrates the details. > > > https://medium.com/@topjohnwu/from-anime-game-to-android-system-security-vulnerability-9b955a182f20 > > > > > > And There is a similar fix on kernel-4.4: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99663be772c827b8f5f594fe87eb4807be1994e5 > > > > > > Q: Other filesystems parse the options from fill_super(). Is proc > > > special in some fashion? > > > A: According to my research, start_kernel will call proc_mount first, and > > > initialize sb->s_root before any userspace process runs. If others want > > > to mount it, all options will be ignored. > > > AOSP change here: > > > https://android-review.googlesource.com/c/platform/system/core/+/181345/4/init/init.cpp > > > At first I though we should mount it with MS_REMOUNT flag. But > > > kernel will crash if we did this. > > This is not true: /proc is mounted by userspace (and it is easy to see > from the fact that proc_mount() is not called from kernel anywhere). > > hidepid= in its current form is misdesigned, so might as well not bother > changing anything. IIRC there were(?) patches to make it per-mount.
Re: [PATCH v5] arm64: implement ftrace with regs
Hi, On Sat, Dec 15, 2018 at 6:14 PM Torsten Duwe wrote: > > On Fri, 14 Dec 2018 21:45:03 +0530 > Amit Daniel Kachhap wrote: > > > Sorry I didn't mention my environment. I am using 4.20-rc3 and it has > > all the above 8 extra patches > > mentioned by you. > > So that should be fine. ok thanks. > > > I read your change description in v3 patchset. You had mentioned there > > that graph caller > > is broken. > > No, actually I thought I had fixed that for v4. Would you care to show > us an actual error message or some symptom? There is no error message or crash but no useful output like below, /sys/kernel/tracing # echo wake_up_process > set_graph_function /sys/kernel/tracing # echo function_graph > current_tracer /sys/kernel/tracing # cat trace # tracer: function_graph # # CPU DURATION FUNCTION CALLS # | | | | | | | //Amit > > Torsten
Re: [PATCH] dt-bindings: watchdog: update bindings for MT7629 SoC
On Sun, 2018-12-16 at 19:53 -0800, Guenter Roeck wrote: > On 12/16/18 7:39 PM, Ryder Lee wrote: > > Hi Matthias, > > > > On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote: > >> > >> On 07/11/2018 08:10, Ryder Lee wrote: > >>> This updates dt-binding documentation for MT7629 SoC > >>> > >>> Signed-off-by: Ryder Lee > >> > >> Acked-by: Matthias Brugger > >> > >>> --- > >>> Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >>> b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >>> index 859dee1..8682d6a 100644 > >>> --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >>> +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > >>> @@ -8,6 +8,7 @@ Required properties: > >>> "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 > >>> "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 > >>> "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 > >>> + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > >>> > >>> - reg : Specifies base physical address and size of the registers. > >>> > >>> > > > > Could you take this through your tree? > > > > Why ? We usually take watchdog binding updates through the watchdog tree. > > Guenter Oh, okay :) Ryder
[PATCH v3 01/15] dt-bindings: net: broadcom-bluetooth: Fix external clock names
The Broadcom Bluetooth controllers can take up to two external clocks: an external frequency reference, substituting the main crystal, and a LPO clock at 32.768 kHz substituting the internal LPO clock. In particular, the external LPO clock must be used when the controller does not have NVRAM connected, and the main reference frequency is not the default 20 MHz. This is described in detail in the datasheet. The original "extclk" clock name is ambiguous as to which of these it refers to, and some designs might even require both. This patch deprecates the existing name, and adds "txco" and "lpo". Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai --- .../devicetree/bindings/net/broadcom-bluetooth.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt index 4194ff7e6ee6..711c75ac2bb5 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt @@ -18,8 +18,11 @@ Optional properties: - shutdown-gpios: GPIO specifier, used to enable the BT module - device-wakeup-gpios: GPIO specifier, used to wakeup the controller - host-wakeup-gpios: GPIO specifier, used to wakeup the host processor - - clocks: clock specifier if external clock provided to the controller - - clock-names: should be "extclk" + - clocks: 1 or 2 clocks as defined in clock-names below, in that order + - clock-names: names for clock inputs, matching the clocks given + - "extclk": deprecated, replaced by "txco" + - "txco": external reference clock (not a standalone crystal) + - "lpo": external low power 32.768 kHz clock Example: -- 2.20.0
[PATCH v3 08/15] Bluetooth: hci_bcm: Add support for LPO clock
The Broadcom Bluetooth controllers support a secondary LPO clock at
32.768 kHz. This external clock provides low power timing, and also
a way to detect the frequency of the main reference clock. On many
designs without NVRAM and a non-default reference clock, this must
be used or the controller will not function correctly.
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 41 -
1 file changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 1584c95c9c34..345d728a5434 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -72,7 +72,8 @@
* @btpu: Apple ACPI method to drive BT_REG_ON pin high ("Bluetooth Power Up")
* @btpd: Apple ACPI method to drive BT_REG_ON pin low ("Bluetooth Power Down")
* @txco_clk: external reference frequency clock used by Bluetooth device
- * @clk_enabled: whether @txco_clk is prepared and enabled
+ * @lpo_clk: external LPO clock used by Bluetooth device
+ * @clk_enabled: whether clocks are prepared and enabled
* @init_speed: default baudrate of Bluetooth device;
* the host UART is initially set to this baudrate so that
* it can configure the Bluetooth device for @oper_speed
@@ -103,6 +104,7 @@ struct bcm_device {
#endif
struct clk *txco_clk;
+ struct clk *lpo_clk;
boolclk_enabled;
u32 init_speed;
@@ -215,21 +217,34 @@ static int bcm_gpio_set_power(struct bcm_device *dev,
bool powered)
int err;
if (powered && !dev->clk_enabled) {
- err = clk_prepare_enable(dev->txco_clk);
+ /* LPO clock needs to be 32.768 kHz */
+ err = clk_set_rate(dev->lpo_clk, 32768);
+ if (err) {
+ dev_err(dev->dev, "Could not set LPO clock rate\n");
+ return err;
+ }
+
+ err = clk_prepare_enable(dev->lpo_clk);
if (err)
return err;
+
+ err = clk_prepare_enable(dev->txco_clk);
+ if (err)
+ goto err_lpo_clk_disable;
}
err = dev->set_shutdown(dev, powered);
if (err)
- goto err_clk_disable;
+ goto err_txco_clk_disable;
err = dev->set_device_wakeup(dev, powered);
if (err)
goto err_revert_shutdown;
- if (!powered && dev->clk_enabled)
+ if (!powered && dev->clk_enabled) {
clk_disable_unprepare(dev->txco_clk);
+ clk_disable_unprepare(dev->lpo_clk);
+ }
dev->clk_enabled = powered;
@@ -237,9 +252,12 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
err_revert_shutdown:
dev->set_shutdown(dev, !powered);
-err_clk_disable:
+err_txco_clk_disable:
if (powered && !dev->clk_enabled)
clk_disable_unprepare(dev->txco_clk);
+err_lpo_clk_disable:
+ if (powered && !dev->clk_enabled)
+ clk_disable_unprepare(dev->lpo_clk);
return err;
}
@@ -934,6 +952,19 @@ static int bcm_get_resources(struct bcm_device *dev)
if (IS_ERR(dev->txco_clk))
dev->txco_clk = NULL;
+ dev->lpo_clk = devm_clk_get(dev->dev, "lpo");
+ if (dev->lpo_clk == ERR_PTR(-EPROBE_DEFER))
+ return PTR_ERR(dev->lpo_clk);
+
+ if (IS_ERR(dev->lpo_clk))
+ dev->lpo_clk = NULL;
+
+ /* Check if we accidentally fetched the lpo clock twice */
+ if (dev->lpo_clk && clk_is_match(dev->lpo_clk, dev->txco_clk)) {
+ devm_clk_put(dev->dev, dev->txco_clk);
+ dev->txco_clk = NULL;
+ }
+
dev->device_wakeup = devm_gpiod_get_optional(dev->dev, "device-wakeup",
GPIOD_OUT_LOW);
if (IS_ERR(dev->device_wakeup))
--
2.20.0
[PATCH v3 00/15] ARM: sunxi: Enable Broadcom-based Bluetooth controllers
Hi everyone, This is v3 of my Broadcom-based Bluetooth controllers on Allwinner SoC- based SBCs series. v2 was sent on 11/15, with a follow up ping on 11/28. No response from either Bluetooth maintainer. Would the maintainers acknowledge or provide feedback so we can move forward? WiFi for the Broadcom chips has been supported and enabled for many years. Bluetooth on the other hand has required userspace trickery to get it working. With serdev support, this now requires minimal interaction from users to get working. Changes since v2: - Collected tags from Ondrej for applicable patches Changes since v1: - Collected tags - Re-organize dt binding clocks and clock-names properties - Simplify check for deferred probe when getting clocks - Add explanation of Cubietruck's clk_out_a pinmux setting placement to commit message. - Add missing "uart-has-rtscts" property to Cubietruck device tree Original cover letter follows. On many Allwinner SBCs / developer boards, there is a WiFi+BT combo module from AMPAK. Inside is either one or two Broadcom chips, depending on the model. This series enables the Bluetooth controllers for AMPAK AP6210, AP6212, and AP6330 found on several boards. More will come later as other SoCs require changes to some other parts. I did not cover the SCO PCM connections from the controller to the SoC's I2S interface. It seems no one is actually doing this, so I was not sure how to proceed. Any suggestions? I deliberately left out the netdev mailing list and Dave Miller, as the only thing that is under net is the binding document. Maybe we should move that out of Documentation/devicetree/bindings/net/ ? Also, I'm not subscribed to the linux-bluetooth ML, so please CC me for any discussions. Patches 1 through 4 are device tree binding changes: 1 - Make the external clock name unambiguous, and add a second entry for the LPO clock. 2 - Add regulator supply properties for the VBAT and VDDIO power pins. 3 - Add a compatible string for BCM20702A1. 4 - Add a compatible string for BCM4330. Patches 5 through 13 are changes to the driver, either improvements, or updates to handle the updated device tree binding. 5 - Make the driver handle deferred probing for the external clock. 6 - Simplify clock error checking for subsequent clk API calls. 7 - Handle clock-names for the main external clock. 8 - Support a new external clock, the LPO. 9 - Support regulator supplies. 10 - Wait a small amount of time after toggling the GPIO for the device to settle. 11 - Add support for BCM20702A1, including its default address. 12 - Add BCM4330 compatible string to the driver. 13 - Handle default address for BCM43430A0. 14 - Enable Broadcom-based serdev Bluetooth for multiple Allwinner ARMv7 boards. 15 - Enable Broadcom-based serdev Bluetooth for the Bananapi M64. checkpatch reports an error for both patch 11 and patch 13: ERROR: space required after that close brace '}' I followed the existing code's style. If this is undesirable, I can send a follow-up patch fixing the entire code block. The first 13 patches should go through the Bluetooth tree, while we, the sunxi maintainers, will take the last 2. Thanks ChenYu Chen-Yu Tsai (14): dt-bindings: net: broadcom-bluetooth: Fix external clock names dt-bindings: net: broadcom-bluetooth: Add VBAT and VDDIO supplies dt-bindings: net: broadcom-bluetooth: Add BCM20702A1 compatible string dt-bindings: net: broadcom-bluetooth: Add BCM4330 compatible string Bluetooth: hci_bcm: Handle deferred probing for the clock supply Bluetooth: hci_bcm: Simplify clk_get error handling Bluetooth: hci_bcm: Use "txco" and "extclk" to get clock reference Bluetooth: hci_bcm: Add support for LPO clock Bluetooth: hci_bcm: Add support for regulator supplies Bluetooth: hci_bcm: Wait for device to come out of reset after power on Bluetooth: hci_bcm: Add compatible string for BCM4330 Bluetooth: btbcm: Add default address for BCM43430A0 ARM: dts: sunxi: Enable Broadcom-based Bluetooth for multiple boards arm64: dts: allwinner: a64: bananapi-m64: Add Bluetooth device node Maxime Ripard (1): Bluetooth: hci_bcm: Add BCM20702A1 variant .../bindings/net/broadcom-bluetooth.txt | 11 +- arch/arm/boot/dts/sun7i-a20-cubietruck.dts| 25 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 18 +++ .../boot/dts/sun8i-a83t-cubietruck-plus.dts | 18 +++ arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 14 +++ .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 14 +++ drivers/bluetooth/btbcm.c | 13 +- drivers/bluetooth/hci_bcm.c | 112 +++--- 8 files changed, 208 insertions(+), 17 deletions(-) -- 2.20.0
[PATCH v3 11/15] Bluetooth: hci_bcm: Add BCM20702A1 variant
From: Maxime Ripard
The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and
transceiver. It is found in the AMPAK AP6210 WiFi+BT package.
Signed-off-by: Maxime Ripard
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/btbcm.c | 6 ++
drivers/bluetooth/hci_bcm.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index e3e4d929e74f..22d4b530da03 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -33,6 +33,7 @@
#define VERSION "0.1"
#define BDADDR_BCM20702A0 (&(bdaddr_t) {{0x00, 0xa0, 0x02, 0x70, 0x20, 0x00}})
+#define BDADDR_BCM20702A1 (&(bdaddr_t) {{0x00, 0x00, 0xa0, 0x02, 0x70, 0x20}})
#define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}})
#define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}})
@@ -64,6 +65,9 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
* The address 00:20:70:02:A0:00 indicates a BCM20702A0 controller
* with no configured address.
*
+* The address 20:70:02:A0:00:00 indicates a BCM20702A1 controller
+* with no configured address.
+*
* The address 43:24:B3:00:00:00 indicates a BCM4324B3 controller
* with waiting for configuration state.
*
@@ -71,6 +75,7 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
* with waiting for configuration state.
*/
if (!bacmp(>bdaddr, BDADDR_BCM20702A0) ||
+ !bacmp(>bdaddr, BDADDR_BCM20702A1) ||
!bacmp(>bdaddr, BDADDR_BCM4324B3) ||
!bacmp(>bdaddr, BDADDR_BCM4330B1)) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
@@ -330,6 +335,7 @@ static const struct bcm_subver_table
bcm_uart_subver_table[] = {
{ 0x2209, "BCM43430A1" }, /* 001.002.009 */
{ 0x6119, "BCM4345C0" }, /* 003.001.025 */
{ 0x230f, "BCM4356A2" }, /* 001.003.015 */
+ { 0x220e, "BCM20702A1" }, /* 001.002.014 */
{ }
};
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 538ce8059bff..8c75e7a67379 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1396,6 +1396,7 @@ static void bcm_serdev_remove(struct serdev_device
*serdev)
#ifdef CONFIG_OF
static const struct of_device_id bcm_bluetooth_of_match[] = {
+ { .compatible = "brcm,bcm20702a1" },
{ .compatible = "brcm,bcm43438-bt" },
{ },
};
--
2.20.0
[PATCH v3 13/15] Bluetooth: btbcm: Add default address for BCM43430A0
The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none
is given. This address was found when enabling Bluetooth on a bunch of
boards with the AMPAK AP6210 module, all sharing the same address. It
also contains the sequence 4343A0, which is suspicious as that is also
the name the chip identifies itself as.
Add this to the list of default MAC addresses and leave it to the user
to configure a valid one.
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/btbcm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
index 22d4b530da03..08e1f3dd4e03 100644
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -34,6 +34,7 @@
#define BDADDR_BCM20702A0 (&(bdaddr_t) {{0x00, 0xa0, 0x02, 0x70, 0x20, 0x00}})
#define BDADDR_BCM20702A1 (&(bdaddr_t) {{0x00, 0x00, 0xa0, 0x02, 0x70, 0x20}})
+#define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xac, 0x1f, 0x12, 0xa0, 0x43, 0x43}})
#define BDADDR_BCM4324B3 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb3, 0x24, 0x43}})
#define BDADDR_BCM4330B1 (&(bdaddr_t) {{0x00, 0x00, 0x00, 0xb1, 0x30, 0x43}})
@@ -73,11 +74,15 @@ int btbcm_check_bdaddr(struct hci_dev *hdev)
*
* The address 43:30:B1:00:00:00 indicates a BCM4330B1 controller
* with waiting for configuration state.
+*
+* The address 43:43:A0:12:1F:AC indicates a BCM43430A0 controller
+* with no configured address.
*/
if (!bacmp(>bdaddr, BDADDR_BCM20702A0) ||
!bacmp(>bdaddr, BDADDR_BCM20702A1) ||
!bacmp(>bdaddr, BDADDR_BCM4324B3) ||
- !bacmp(>bdaddr, BDADDR_BCM4330B1)) {
+ !bacmp(>bdaddr, BDADDR_BCM4330B1) ||
+ !bacmp(>bdaddr, BDADDR_BCM43430A0)) {
bt_dev_info(hdev, "BCM: Using default device address (%pMR)",
>bdaddr);
set_bit(HCI_QUIRK_INVALID_BDADDR, >quirks);
--
2.20.0
[PATCH v3 14/15] ARM: dts: sunxi: Enable Broadcom-based Bluetooth for multiple boards
This patch adds the Bluetooth node, and the underlying UART node if it's
missing, to the board device tree file for several boards. The LPO clock
is also added to the WiFi side's power sequencing node if it's missing,
to correctly represent the shared connections. There is also a PCM
connection for Bluetooth, but this is not covered in this patch.
These boards all have a WiFi+BT module from AMPAK, which contains one or
two Broadcom chips, depending on the model. The older AP6210 contains
two, while the newer AP6212 and AP6330 contain just one, as they use
two-in-one combo chips.
The Bluetooth side of the module is always connected to a UART on the
same pingroup as the SDIO pins for the WiFi side, in a 4 wire
configuration. Power to the VBAT and VDDIO pins are provided either by
the PMIC, using one or several of its regulator outputs, or other fixed
regulators on the board. The VBAT and VDDIO pins are shared with the
WiFi side, which would correspond to vmmc-supply and vqmmc-supply in the
mmc host node. A clock output from the SoC or the external X-Powers RTC
provides the LPO low power clock at 32.768 kHz.
All the boards covered in this patch are ones that do not require extra
changes to the SoC's dtsi file. For the remaining boards that I have
worked on, properties or device nodes for the LPO clock's source are
missing.
For the Cubietruck, the LPO clock is fed from CLK_OUT_A, which needs to
be muxed on pin PI12. This can be represented in multiple ways. This
patch puts the pinctrl property in the pin controller node. This is due
to limitations in Linux, where pinmux settings, even the same one, can
not be shared by multiple devices. Thus we cannot put it in both the
WiFi and Bluetooth device nodes. Putting it the CCU node is another
option, but Linux's CCU driver does not handle pinctrl. Also the pin
controller is guaranteed to be initialized after the CCU, when clocks
are available. And any other devices that use muxed pins are guaranteed
to be initialized after the pin controller. Thus having the CLK_OUT_A
pinmux reference be in the pin controller node is a good choice without
having to deal with implementation issues.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts| 25 +++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 18 +
.../boot/dts/sun8i-a83t-cubietruck-plus.dts | 18 +
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 14 +++
4 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 15c5eae4ca7b..99f531b8d2a7 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -99,6 +99,8 @@
mmc3_pwrseq: mmc3_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = < 7 9 GPIO_ACTIVE_LOW>; /* PH9 WIFI_EN */
+ clocks = < CLK_OUT_A>;
+ clock-names = "ext_clock";
};
sound {
@@ -227,6 +229,12 @@
status = "okay";
};
+ {
+ /* Pin outputs low power clock for WiFi and BT */
+ pinctrl-0 = <_out_a_pin>;
+ pinctrl-names = "default";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pin>, <_pin>;
@@ -298,6 +306,23 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pi_pins>, <_cts_rts_pi_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm20702a1";
+ clocks = < CLK_OUT_A>;
+ clock-names = "lpo";
+ device-wakeup-gpios = < 7 24 GPIO_ACTIVE_LOW>; /* PH24 */
+ host-wakeup-gpios = < 7 25 GPIO_ACTIVE_LOW>; /* PH25 */
+ shutdown-gpios = < 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
+ max-speed = <150>;
+ };
+};
+
_otg {
dr_mode = "otg";
status = "okay";
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 583a5a01642f..7d30d3e530fb 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -363,6 +363,24 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>, <_rts_cts_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <_rtc 1>;
+ clock-names = "lpo";
+ vbat-supply = <_dldo1>;
+ vddio-supply = <_dldo1>;
+ device-wakeup-gpios = < 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+ host-wakeup-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ shutdown-gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ };
+};
+
{
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
[PATCH v3 10/15] Bluetooth: hci_bcm: Wait for device to come out of reset after power on
The datasheets for BCM20702 and BCM43438 both have power up time sequence graphs, however they are slightly different. Both chips also have an internal power-on-reset, which holds the chip in reset for a short time after the regulators are enabled. For the BCM20702, the time period from when the regulators are enabled, until the chip settles and comes out of sleep state, is 6564 ~ 8171 us. For the BCM43438, the graph only shows the time period from when the regulators are enabled until the chip responds by driving the host's CTS line low, assuming the host has already driven its RTS line low. This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768 kHz. This is around 2 ms. Wait a full 10 ms after the regulators are enabled to account for signal rising times. Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai --- drivers/bluetooth/hci_bcm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index f2101038284e..538ce8059bff 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -256,6 +256,9 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool powered) regulator_bulk_disable(BCM_NUM_SUPPLIES, dev->supplies); } + /* wait for device to power on and come out of reset */ + usleep_range(1, 2); + dev->res_enabled = powered; return 0; -- 2.20.0
[PATCH v3 03/15] dt-bindings: net: broadcom-bluetooth: Add BCM20702A1 compatible string
The BCM20702A1 is a Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6210 WiFi+BT module, identified from the read verbose config info command response. However the Bluetooth firmware provided by vendors uses the name BCM20710. This patch elects to use the chip ID returned by the chip for the compatible string. Reviewed-by: Rob Herring Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/net/broadcom-bluetooth.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt index 78cfa0fbece9..d9d734a07faf 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt @@ -10,6 +10,7 @@ device the slave device is attached to. Required properties: - compatible: should contain one of the following: + * "brcm,bcm20702a1" * "brcm,bcm43438-bt" Optional properties: -- 2.20.0
[PATCH v3 04/15] dt-bindings: net: broadcom-bluetooth: Add BCM4330 compatible string
The BCM4330 is a 802.11 a/b/g/n WiFi + Bluetooth 4.0 chip from Broadcom. It is found in the Ampak AP6330 WiFi+BT module. The partiular one I have identifies as BCM4330B1 for Bluetooth and BCM4330/4 for WiFi. It is unclear if the AP6330 module uses this revision of the BCM4330, or if there are multiple revisions. The module does not have revision markings. This patch elects to use just BCM4330 for the compatible string. Reviewed-by: Rob Herring Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/net/broadcom-bluetooth.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt index d9d734a07faf..c26f4e11037c 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt @@ -11,6 +11,7 @@ Required properties: - compatible: should contain one of the following: * "brcm,bcm20702a1" + * "brcm,bcm4330-bt" * "brcm,bcm43438-bt" Optional properties: -- 2.20.0
[PATCH v3 09/15] Bluetooth: hci_bcm: Add support for regulator supplies
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO.
The former provides overall power for the chip, while the latter powers
the I/O pins and buffers.
Model these two as regulator supplies, and let the driver manage them
in the same way as it does the clock supply.
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 39 -
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 345d728a5434..f2101038284e 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -53,6 +54,8 @@
#define BCM_AUTOSUSPEND_DELAY 5000 /* default autosleep delay */
+#define BCM_NUM_SUPPLIES 2
+
/**
* struct bcm_device - device driver resources
* @serdev_hu: HCI UART controller struct
@@ -73,7 +76,8 @@
* @btpd: Apple ACPI method to drive BT_REG_ON pin low ("Bluetooth Power Down")
* @txco_clk: external reference frequency clock used by Bluetooth device
* @lpo_clk: external LPO clock used by Bluetooth device
- * @clk_enabled: whether clocks are prepared and enabled
+ * @supplies: VBAT and VDDIO supplies used by Bluetooth device
+ * @res_enabled: whether clocks and supplies are prepared and enabled
* @init_speed: default baudrate of Bluetooth device;
* the host UART is initially set to this baudrate so that
* it can configure the Bluetooth device for @oper_speed
@@ -105,7 +109,8 @@ struct bcm_device {
struct clk *txco_clk;
struct clk *lpo_clk;
- boolclk_enabled;
+ struct regulator_bulk_data supplies[BCM_NUM_SUPPLIES];
+ boolres_enabled;
u32 init_speed;
u32 oper_speed;
@@ -216,17 +221,21 @@ static int bcm_gpio_set_power(struct bcm_device *dev,
bool powered)
{
int err;
- if (powered && !dev->clk_enabled) {
+ if (powered && !dev->res_enabled) {
+ err = regulator_bulk_enable(BCM_NUM_SUPPLIES, dev->supplies);
+ if (err)
+ return err;
+
/* LPO clock needs to be 32.768 kHz */
err = clk_set_rate(dev->lpo_clk, 32768);
if (err) {
dev_err(dev->dev, "Could not set LPO clock rate\n");
- return err;
+ goto err_regulator_disable;
}
err = clk_prepare_enable(dev->lpo_clk);
if (err)
- return err;
+ goto err_regulator_disable;
err = clk_prepare_enable(dev->txco_clk);
if (err)
@@ -241,23 +250,27 @@ static int bcm_gpio_set_power(struct bcm_device *dev,
bool powered)
if (err)
goto err_revert_shutdown;
- if (!powered && dev->clk_enabled) {
+ if (!powered && dev->res_enabled) {
clk_disable_unprepare(dev->txco_clk);
clk_disable_unprepare(dev->lpo_clk);
+ regulator_bulk_disable(BCM_NUM_SUPPLIES, dev->supplies);
}
- dev->clk_enabled = powered;
+ dev->res_enabled = powered;
return 0;
err_revert_shutdown:
dev->set_shutdown(dev, !powered);
err_txco_clk_disable:
- if (powered && !dev->clk_enabled)
+ if (powered && !dev->res_enabled)
clk_disable_unprepare(dev->txco_clk);
err_lpo_clk_disable:
- if (powered && !dev->clk_enabled)
+ if (powered && !dev->res_enabled)
clk_disable_unprepare(dev->lpo_clk);
+err_regulator_disable:
+ if (powered && !dev->res_enabled)
+ regulator_bulk_disable(BCM_NUM_SUPPLIES, dev->supplies);
return err;
}
@@ -936,6 +949,7 @@ static struct clk *bcm_get_txco(struct device *dev)
static int bcm_get_resources(struct bcm_device *dev)
{
const struct dmi_system_id *dmi_id;
+ int err;
dev->name = dev_name(dev->dev);
@@ -978,6 +992,13 @@ static int bcm_get_resources(struct bcm_device *dev)
dev->set_device_wakeup = bcm_gpio_set_device_wakeup;
dev->set_shutdown = bcm_gpio_set_shutdown;
+ dev->supplies[0].supply = "vbat";
+ dev->supplies[1].supply = "vddio";
+ err = devm_regulator_bulk_get(dev->dev, BCM_NUM_SUPPLIES,
+ dev->supplies);
+ if (err)
+ return err;
+
/* IRQ can be declared in ACPI table as Interrupt or GpioInt */
if (dev->irq <= 0) {
struct gpio_desc *gpio;
--
2.20.0
[PATCH v3 07/15] Bluetooth: hci_bcm: Use "txco" and "extclk" to get clock reference
Originally the device tree binding only specified one clock reference,
with the name "extclk". The driver simply retrieves the clock without
bothering to specify a name.
Since we added a second clock to the binding, we need to fetch the
clocks by name now. First we try the new name "txco", then fall back
to the old name "extclk", and finally try retrieving a clock without
using any name, to cover any instances where a bad device tree or
firmware worked by accident.
In the last case, we should take care that we don't get the same
clock twice when we add support for the "lpo" clock.
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 41 +++--
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index ff73ecb8215f..1584c95c9c34 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -71,8 +71,8 @@
* @btlp: Apple ACPI method to toggle BT_WAKE pin ("Bluetooth Low Power")
* @btpu: Apple ACPI method to drive BT_REG_ON pin high ("Bluetooth Power Up")
* @btpd: Apple ACPI method to drive BT_REG_ON pin low ("Bluetooth Power Down")
- * @clk: clock used by Bluetooth device
- * @clk_enabled: whether @clk is prepared and enabled
+ * @txco_clk: external reference frequency clock used by Bluetooth device
+ * @clk_enabled: whether @txco_clk is prepared and enabled
* @init_speed: default baudrate of Bluetooth device;
* the host UART is initially set to this baudrate so that
* it can configure the Bluetooth device for @oper_speed
@@ -102,7 +102,7 @@ struct bcm_device {
int gpio_int_idx;
#endif
- struct clk *clk;
+ struct clk *txco_clk;
boolclk_enabled;
u32 init_speed;
@@ -215,7 +215,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
int err;
if (powered && !dev->clk_enabled) {
- err = clk_prepare_enable(dev->clk);
+ err = clk_prepare_enable(dev->txco_clk);
if (err)
return err;
}
@@ -229,7 +229,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
goto err_revert_shutdown;
if (!powered && dev->clk_enabled)
- clk_disable_unprepare(dev->clk);
+ clk_disable_unprepare(dev->txco_clk);
dev->clk_enabled = powered;
@@ -239,7 +239,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
dev->set_shutdown(dev, !powered);
err_clk_disable:
if (powered && !dev->clk_enabled)
- clk_disable_unprepare(dev->clk);
+ clk_disable_unprepare(dev->txco_clk);
return err;
}
@@ -896,6 +896,25 @@ static int bcm_gpio_set_shutdown(struct bcm_device *dev,
bool powered)
return 0;
}
+/* Try a bunch of names for TXCO */
+static struct clk *bcm_get_txco(struct device *dev)
+{
+ struct clk *clk;
+
+ /* New explicit name */
+ clk = devm_clk_get(dev, "txco");
+ if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
+ return clk;
+
+ /* Deprecated name */
+ clk = devm_clk_get(dev, "extclk");
+ if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
+ return clk;
+
+ /* Original code used no name at all */
+ return devm_clk_get(dev, NULL);
+}
+
static int bcm_get_resources(struct bcm_device *dev)
{
const struct dmi_system_id *dmi_id;
@@ -905,15 +924,15 @@ static int bcm_get_resources(struct bcm_device *dev)
if (x86_apple_machine && !bcm_apple_get_resources(dev))
return 0;
- dev->clk = devm_clk_get(dev->dev, NULL);
+ dev->txco_clk = bcm_get_txco(dev->dev);
/* Handle deferred probing */
- if (dev->clk == ERR_PTR(-EPROBE_DEFER))
- return PTR_ERR(dev->clk);
+ if (dev->txco_clk == ERR_PTR(-EPROBE_DEFER))
+ return PTR_ERR(dev->txco_clk);
/* Ignore all other errors as before */
- if (IS_ERR(dev->clk))
- dev->clk = NULL;
+ if (IS_ERR(dev->txco_clk))
+ dev->txco_clk = NULL;
dev->device_wakeup = devm_gpiod_get_optional(dev->dev, "device-wakeup",
GPIOD_OUT_LOW);
--
2.20.0
[PATCH v3 06/15] Bluetooth: hci_bcm: Simplify clk_get error handling
The driver currently checks the clk pointer for an error condition, as
returned by clk_get, before every invocation of the clk consumer API.
This is redundant if the goal is simply to ignore the errors, thereby
making the clk optional. The clk consumer API already checks if the
pointer is NULL or not.
Simplify the code a bit by assigning NULL to the clk pointer if the
error condition is one we want to ignore, which is every error except
deferred probing.
Tested-by: Ondrej Jirman
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 800132369134..ff73ecb8215f 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -214,7 +214,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
{
int err;
- if (powered && !IS_ERR(dev->clk) && !dev->clk_enabled) {
+ if (powered && !dev->clk_enabled) {
err = clk_prepare_enable(dev->clk);
if (err)
return err;
@@ -228,7 +228,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
if (err)
goto err_revert_shutdown;
- if (!powered && !IS_ERR(dev->clk) && dev->clk_enabled)
+ if (!powered && dev->clk_enabled)
clk_disable_unprepare(dev->clk);
dev->clk_enabled = powered;
@@ -238,7 +238,7 @@ static int bcm_gpio_set_power(struct bcm_device *dev, bool
powered)
err_revert_shutdown:
dev->set_shutdown(dev, !powered);
err_clk_disable:
- if (powered && !IS_ERR(dev->clk) && !dev->clk_enabled)
+ if (powered && !dev->clk_enabled)
clk_disable_unprepare(dev->clk);
return err;
}
@@ -911,6 +911,10 @@ static int bcm_get_resources(struct bcm_device *dev)
if (dev->clk == ERR_PTR(-EPROBE_DEFER))
return PTR_ERR(dev->clk);
+ /* Ignore all other errors as before */
+ if (IS_ERR(dev->clk))
+ dev->clk = NULL;
+
dev->device_wakeup = devm_gpiod_get_optional(dev->dev, "device-wakeup",
GPIOD_OUT_LOW);
if (IS_ERR(dev->device_wakeup))
--
2.20.0
[PATCH v3 15/15] arm64: dts: allwinner: a64: bananapi-m64: Add Bluetooth device node
The AP6212 is based on the Broadcom BCM43430 or BCM43438. The WiFi side
identifies as BCM43430, while the Bluetooth side identifies as BCM43438.
The Bluetooth side is connected to UART1 in a 4 wire configuration. Same
as the WiFi side, due to being the same chip and package, DLDO2 provides
overall power via VBAT, and DLDO4 provides I/O power via VDDIO. The RTC
clock output provides the LPO low power clock at 32.768 kHz.
This patch enables Bluetooth on this board, and also adds the missing
LPO clock on the WiFi side. There is also a PCM connection for Bluetooth,
but this is not covered here.
Acked-by: Maxime Ripard
Signed-off-by: Chen-Yu Tsai
---
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 83e30e0afe5b..9d0afd7d50ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -94,6 +94,8 @@
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+ clocks = < 1>;
+ clock-names = "ext_clock";
};
};
@@ -364,7 +366,19 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins>, <_rts_cts_pins>;
+ uart-has-rtscts;
status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = < 1>;
+ clock-names = "lpo";
+ vbat-supply = <_dldo2>;
+ vddio-supply = <_dldo4>;
+ device-wakeup-gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ host-wakeup-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ shutdown-gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ };
};
_otg {
--
2.20.0
[PATCH v3 05/15] Bluetooth: hci_bcm: Handle deferred probing for the clock supply
On some systems that actually have the bluetooth controller wired up with an extra clock signal, it's possible the bluetooth controller probes before the clock provider. clk_get would return a defer probe error, which was not handled by this driver. Handle this properly, so that these systems can work reliably. Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai --- drivers/bluetooth/hci_bcm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c index ddbd8c6a0ceb..800132369134 100644 --- a/drivers/bluetooth/hci_bcm.c +++ b/drivers/bluetooth/hci_bcm.c @@ -907,6 +907,10 @@ static int bcm_get_resources(struct bcm_device *dev) dev->clk = devm_clk_get(dev->dev, NULL); + /* Handle deferred probing */ + if (dev->clk == ERR_PTR(-EPROBE_DEFER)) + return PTR_ERR(dev->clk); + dev->device_wakeup = devm_gpiod_get_optional(dev->dev, "device-wakeup", GPIOD_OUT_LOW); if (IS_ERR(dev->device_wakeup)) -- 2.20.0
[PATCH v3 12/15] Bluetooth: hci_bcm: Add compatible string for BCM4330
The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller.
This patch adds a compatible string match to the serdev driver for the
Bluetooth part of the chip.
Signed-off-by: Chen-Yu Tsai
---
drivers/bluetooth/hci_bcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 8c75e7a67379..a5cb580a07de 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -1397,6 +1397,7 @@ static void bcm_serdev_remove(struct serdev_device
*serdev)
#ifdef CONFIG_OF
static const struct of_device_id bcm_bluetooth_of_match[] = {
{ .compatible = "brcm,bcm20702a1" },
+ { .compatible = "brcm,bcm4330-bt" },
{ .compatible = "brcm,bcm43438-bt" },
{ },
};
--
2.20.0
[PATCH v3 02/15] dt-bindings: net: broadcom-bluetooth: Add VBAT and VDDIO supplies
The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO. The former provides overall power for the chip, while the latter powers the I/O pins and buffers. This patch adds properties for the two so we can describe the power supply relationships. Reviewed-by: Rob Herring Tested-by: Ondrej Jirman Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/net/broadcom-bluetooth.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt index 711c75ac2bb5..78cfa0fbece9 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt @@ -23,6 +23,8 @@ Optional properties: - "extclk": deprecated, replaced by "txco" - "txco": external reference clock (not a standalone crystal) - "lpo": external low power 32.768 kHz clock + - vbat-supply: phandle to regulator supply for VBAT + - vddio-supply: phandle to regulator supply for VDDIO Example: -- 2.20.0
Re: [PATCH] eint: add gpio vritual number select
On Mon, 2018-12-17 at 11:15 +0800, Chuanjia Liu wrote:
> On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote:
> > On Thu, Dec 13, 2018 at 1:36 AM wrote:
> > >
> > > From: Chuanjia Liu
> > >
> > > This patch add gpio vritual number select,avoid virtual gpio set SMT.
> >
> > s/gpio/GPIO/
> > s/vritual/virtual/
> >
> > Virtual GPIOs you said here that means these pins only used inside SoC
> > and not being exported to outside SoC, right? It seems this kind of
> > pins doesn't need SMT.
> >
> Yes,virtual gpio only used inside SOC and these pins doesn't need set
> SMT
Hi,
I don't see full patch in linux-mediatek archive. Maybe you are not
subscribed so it is rejected?
Please add this description to commit message and/or code comment.
I think 'internal GPIO' might be a better name for this. Does the name
'virtual GPIO' come from datasheet?
> > >
> > > Signed-off-by: Chuanjia Liu
> > > ---
> > > drivers/pinctrl/mediatek/mtk-eint.h |1 +
> > > drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> > > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> > > 3 files changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > > b/drivers/pinctrl/mediatek/mtk-eint.h
> > > index 48468d0..c16beaf 100644
> > > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > > @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> > > u8 ports;
> > > unsigned intap_num;
> > > unsigned intdb_cnt;
> > > + unsigned intvir_start;
Since it is about GPIO and SMT, maybe it should be added to mtk_pin_soc
instead of mtk_eint_hw ?
Joe.C
> > > };
> > >
> > > struct mtk_eint;
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > index 6262fd3..bbeafd3 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > > @@ -497,6 +497,7 @@
> > > .ports = 6,
> > > .ap_num= 212,
> > > .db_cnt= 13,
> > > + .vir_start = 180,
> > > };
> > >
> > > static const struct mtk_pin_soc mt8183_data = {
> > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > index 4a9e0d4..ca3bae1 100644
> > > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > > @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data,
> > > unsigned long eint_n)
> > > if (err)
> > > return err;
> > >
> > > - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> > > - if (err)
> > > - return err;
> > > + if (gpio_n < hw->eint->hw->vir_start) {
> > > + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > > + MTK_ENABLE);
> > > + if (err)
> > > + return err;
> > > + }
> >
> > The changes will break these SoCs without a properly configured vir_start.
> >
> > If SMT seems unnecessary for these kinds of virtual GPIOs pin in the
> > path, we can do it as
> >
> > err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > MTK_ENABLE);
> > /* please add comments for the exclusion condition */
> > if (err && err != -ENOTSUPP)
> > return err;
> >
> > If there is getting much special on certain pins between SoCs, and
> > then we can consider creating a desc->flag to split logic.
>
> Yes,SMT unnecessary for these kinds of virtual GPIOS pin in the path,if
> do it as
> err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> MTK_ENABLE);
> if (err && err != -ENOTSUPP)
> return err;
> I wonder if system will lose -ENOTSUPP information when smt was not
> successfully set by real gpio?
> >
> > >
> > > return 0;
> > > }
> > > --
> > > 1.7.9.5
>
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
include/config/auto.conf not sync up with .config
This bug can be reproduced this way on x86_64. * make sure none of libelf-dev, libelf-devel or elfutils-libelf-devel installed. # make distclean * generate a default .config where CONFIG_UNWINDER_ORC is enabled by default. # make menuconfig (exit -> save) # grep CONFIG_UNWINDER_ORC .config CONFIG_UNWINDER_ORC=y # make menuconfig (unselect CONFIG_UNWINDER_ORC) # grep CONFIG_UNWINDER_ORC .config # CONFIG_UNWINDER_ORC is not set # make Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel # grep CONFIG_UNWINDER_ORC include/config/auto.conf CONFIG_UNWINDER_ORC=y This is due to this receipe in Makefile had never been executed even though .config has is more recent than auto.conf. # The actual configuration files used during the build are # stored in include/generated/ and include/config/. Update # them if .config is newer than include/config/auto.conf #(which mirrors .config). include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig Actually, replaced that rule with any rule would never executed the recipe there, For example, /tmp/noexist: $(warning "never print anything")
Re: [PATCH] dt-bindings: watchdog: update bindings for MT7629 SoC
On 12/16/18 7:39 PM, Ryder Lee wrote: Hi Matthias, On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote: On 07/11/2018 08:10, Ryder Lee wrote: This updates dt-binding documentation for MT7629 SoC Signed-off-by: Ryder Lee Acked-by: Matthias Brugger --- Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 859dee1..8682d6a 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -8,6 +8,7 @@ Required properties: "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 - reg : Specifies base physical address and size of the registers. Could you take this through your tree? Why ? We usually take watchdog binding updates through the watchdog tree. Guenter
Re: [PATCH] squashfs: enable __GFP_FS in ->readpage to prevent hang in mem alloc
On Sun, Dec 16, 2018 at 05:38:13PM +0800, Hou Tao wrote: > Hi, > > On 2018/12/15 22:38, Matthew Wilcox wrote: > > On Tue, Dec 04, 2018 at 10:08:40AM +0800, Hou Tao wrote: > >> There is no need to disable __GFP_FS in ->readpage: > >> * It's a read-only fs, so there will be no dirty/writeback page and > >> there will be no deadlock against the caller's locked page > >> * It just allocates one page, so compaction will not be invoked > >> * It doesn't take any inode lock, so the reclamation of inode will be fine > >> > >> And no __GFP_FS may lead to hang in __alloc_pages_slowpath() if a > >> squashfs page fault occurs in the context of a memory hogger, because > >> the hogger will not be killed due to the logic in __alloc_pages_may_oom(). > > > > I don't understand your argument here. There's a comment in > > __alloc_pages_may_oom() saying that we _should_ treat GFP_NOFS > > specially, but we currently don't. > I am trying to say that if __GFP_FS is used in pagecache_get_page() when it > tries > to allocate a new page for squashfs, that will be no possibility of dead-lock > for > squashfs. > > We do treat GFP_NOFS specially in out_of_memory(): > > /* > * The OOM killer does not compensate for IO-less reclaim. > * pagefault_out_of_memory lost its gfp context so we have to > * make sure exclude 0 mask - all other users should have at least > * ___GFP_DIRECT_RECLAIM to get here. > */ > if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS)) > return true; > > So if GFP_FS is used, no task will be killed because we will return from > out_of_memory() prematurely. And that will lead to an infinite loop in > __alloc_pages_slowpath() as we have observed: > > * a squashfs page fault occurred in the context of a memory hogger > * the page used for page fault allocated successfully > * in squashfs_readpage() squashfs will try to allocate other pages > in the same 128KB block, and __GFP_NOFS is used (actually > GFP_HIGHUSER_MOVABLE & ~__GFP_FS) > * in __alloc_pages_slowpath() we can not get any pages through reclamation > (because most of memory is used by the current task) and we also can not > kill > the current task (due to __GFP_NOFS), and it will loop forever until it's > killed. Ah, yes, that makes perfect sense. Thank you for the explanation. I wonder if the correct fix, however, is not to move the check for GFP_NOFS in out_of_memory() down to below the check whether to kill the current task. That would solve your problem, and I don't _think_ it would cause any new ones. Michal, you touched this code last, what do you think?
<<>
Good Day, Hope you are doing great Today.I have a proposed BUSINESS DEAL that will benefit both parties. This is legitimate,legal and your personality will not be compromised.Please Reply to me ONLY if you are interested and consider your self capable for details. Sincerely, Peter OWEN
Re: [PATCH] dt-bindings: watchdog: update bindings for MT7629 SoC
Hi Matthias, On Sun, 2018-12-16 at 11:31 +0100, Matthias Brugger wrote: > > On 07/11/2018 08:10, Ryder Lee wrote: > > This updates dt-binding documentation for MT7629 SoC > > > > Signed-off-by: Ryder Lee > > Acked-by: Matthias Brugger > > > --- > > Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > index 859dee1..8682d6a 100644 > > --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > > @@ -8,6 +8,7 @@ Required properties: > > "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 > > "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 > > "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 > > + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > > > > - reg : Specifies base physical address and size of the registers. > > > > Could you take this through your tree? Ryder
[PATCH V7] iio: light: isl29018: add vcc regulator operation support
The light sensor's power supply could be controllable 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 vcc regulator operation support.
Signed-off-by: Anson Huang
---
ChangeLog since V6
- using devm_regulator_get() instead of devm_regulator_get_optional() since
the regulator is
there anyway, if dtb does NOT specify one, regulator framework will
assign dummy regulator for it;
- Setup devm action for cleaning up regulator resource for error handling.
---
drivers/iio/light/isl29018.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
index b45400f..63f7b9d 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,
@@ -708,6 +710,17 @@ static const char *isl29018_match_acpi_device(struct
device *dev, int *data)
return dev_name(dev);
}
+static void isl29018_disable_regulator_action(void *_data)
+{
+ struct isl29018_chip *chip = _data;
+ int err;
+
+ err = regulator_disable(chip->vcc_reg);
+ if (err)
+ dev_err(regmap_get_device(chip->regmap),
+ "failed to disable VCC regulator!\n");
+}
+
static int isl29018_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -742,6 +755,37 @@ static int isl29018_probe(struct i2c_client *client,
chip->scale = isl29018_scales[chip->int_time][0];
chip->suspended = false;
+ chip->vcc_reg = devm_regulator_get(>dev, "vcc");
+ if (IS_ERR(chip->vcc_reg)) {
+ err = PTR_ERR(chip->vcc_reg);
+ if (err != -EPROBE_DEFER)
+ dev_err(>dev, "failed to get VCC regulator!\n");
+ return err;
+ }
+
+ err = regulator_enable(chip->vcc_reg);
+ if (err) {
+ dev_err(>dev, "failed to enable VCC regulator!\n");
+ return err;
+ }
+
+ chip->regmap = devm_regmap_init_i2c(client,
+ isl29018_chip_info_tbl[dev_id].regmap_cfg);
+ if (IS_ERR(chip->regmap)) {
+ err = PTR_ERR(chip->regmap);
+ dev_err(>dev, "regmap initialization fails: %d\n", err);
+ regulator_disable(chip->vcc_reg);
+ return err;
+ }
+
+ err = devm_add_action(>dev, isl29018_disable_regulator_action,
+chip);
+ if (err) {
+ isl29018_disable_regulator_action(chip);
+ dev_err(>dev, "failed to setup regulator cleanup
action!\n");
+ return err;
+ }
+
chip->regmap = devm_regmap_init_i2c(client,
isl29018_chip_info_tbl[dev_id].regmap_cfg);
if (IS_ERR(chip->regmap)) {
@@ -768,6 +812,7 @@ static int isl29018_probe(struct i2c_client *client,
static int isl29018_suspend(struct device *dev)
{
struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
+ int ret;
mutex_lock(>lock);
@@ -777,6 +822,12 @@ static int isl29018_suspend(struct device *dev)
* So we do not have much to do here.
*/
chip->suspended = true;
+ 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 +841,13 @@ static int isl29018_resume(struct device *dev)
mutex_lock(>lock);
+ 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] eint: add gpio vritual number select
On Fri, 2018-12-14 at 03:51 +0800, Sean Wang wrote:
> And the subject should be also corrected with prefix starting with
> "pinctrl: mediatek:", typo fixup, and having a better subject close to
> the content.
I will change it in next patch.
> On Thu, Dec 13, 2018 at 1:36 AM wrote:
> >
> > From: Chuanjia Liu
> >
> > This patch add gpio vritual number select,avoid virtual gpio set SMT.
> >
> > Signed-off-by: Chuanjia Liu
> > ---
> > drivers/pinctrl/mediatek/mtk-eint.h |1 +
> > drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> > 3 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > b/drivers/pinctrl/mediatek/mtk-eint.h
> > index 48468d0..c16beaf 100644
> > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> > u8 ports;
> > unsigned intap_num;
> > unsigned intdb_cnt;
> > + unsigned intvir_start;
> > };
> >
> > struct mtk_eint;
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > index 6262fd3..bbeafd3 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > @@ -497,6 +497,7 @@
> > .ports = 6,
> > .ap_num= 212,
> > .db_cnt= 13,
> > + .vir_start = 180,
> > };
> >
> > static const struct mtk_pin_soc mt8183_data = {
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > index 4a9e0d4..ca3bae1 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data,
> > unsigned long eint_n)
> > if (err)
> > return err;
> >
> > - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> > - if (err)
> > - return err;
> > + if (gpio_n < hw->eint->hw->vir_start) {
> > + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > + MTK_ENABLE);
> > + if (err)
> > + return err;
> > + }
> >
> > return 0;
> > }
> > --
> > 1.7.9.5
RE: rcu_preempt caused oom
for double confirm the issue is not reproduce after 90 hours, we tried only add
the enclosed patch on the easy reproduced build, the issue is not reproduced
after 63 hours in the whole weekend on 16 boards.
so current conclusion is the debug patch has extreme effect on the rcu issue.
Compared with the swait_event_idle_timeout_exclusive will do 3 times to check
the condition, while swait_event_idle_ exclusive will do 2 times check the
condition.
so today I will do another experiment, only change as below:
- swait_event_idle_exclusive(rsp->gp_wq,
READ_ONCE(rsp->gp_flags) &
-RCU_GP_FLAG_INIT);
+ ret = swait_event_idle_timeout_exclusive(rsp->gp_wq,
READ_ONCE(rsp->gp_flags) &
+ RCU_GP_FLAG_INIT, MAX_SCHEDULE_TIMEOUT);
+
Can you get some clues from the experiment?
-Original Message-
From: Paul E. McKenney
Sent: Friday, December 14, 2018 1:39 PM
To: He, Bo
Cc: Zhang, Jun ; Steven Rostedt ;
linux-kernel@vger.kernel.org; j...@joshtriplett.org;
mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Xiao, Jin
; Zhang, Yanmin ; Bai, Jie A
; Sun, Yi J
Subject: Re: rcu_preempt caused oom
On Thu, Dec 13, 2018 at 09:10:12PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 14, 2018 at 02:40:50AM +, He, Bo wrote:
> > another experiment we have done with the enclosed debug patch, and also
> > have more rcu trace event enable but without CONFIG_RCU_BOOST config, we
> > don't reproduce the issue after 90 Hours until now on 10 boards(the issue
> > should reproduce on one night per previous experience).
>
> That certainly supports the hypothesis that a wakeup is either not
> being sent or is being lost. Your patch is great for debugging (thank
> you!), but the real solution of course needs to avoid the extra
> wakeups, especially on battery-powered systems.
>
> One suggested change below, to get rid of potential false positives.
>
> > the purposes are to capture the more rcu event trace close to the issue
> > happen, because I check the __wait_rcu_gp is not always in running, so we
> > think even it trigger the panic for 3s timeout, the issue is already
> > happened before 3s.
>
> Agreed, it would be really good to have trace information from the cause.
> In the case you sent yesterday, it would be good to have trace
> information from 308.256 seconds prior to the sysrq-v, for example, by
> collecting the same event traces you did a few days ago. It would
> also be good to know whether the scheduler tick is providing
> interrupts, and if so, why
> rcu_check_gp_start_stall() isn't being invoked. ;-)
>
> If collecting this information with your setup is not feasible (for
> example, you might need a large trace buffer to capture five minutes
> of traces), please let me know and I can provide additional debug
> code. Or you could add "rcu_ftrace_dump(DUMP_ALL);" just before the
> "show_rcu_gp_kthreads();" in your patch below.
>
> > And Actually the rsp->gp_flags = 1, but RCU_GP_WAIT_GPS(1) ->state: 0x402,
> > it means the kthread is not schedule for 300s but the RCU_GP_FLAG_INIT is
> > set. What's your ideas?
>
> The most likely possibility is that my analysis below is confused and
> there really is some way that the code can set the RCU_GP_FLAG_INIT
> bit without later doing a wakeup. The trace data above could help
> unconfuse me.
>
> Thanx, Paul
>
> > -
> > - swait_event_idle_exclusive(rsp->gp_wq,
> > READ_ONCE(rsp->gp_flags) &
> > -RCU_GP_FLAG_INIT);
> > + if (current->pid != rcu_preempt_pid) {
> > + swait_event_idle_exclusive(rsp->gp_wq,
> > READ_ONCE(rsp->gp_flags) &
> > + RCU_GP_FLAG_INIT);
> > + } else {
>
> wait_again:
>
> > + ret =
> > swait_event_idle_timeout_exclusive(rsp->gp_wq, READ_ONCE(rsp->gp_flags) &
> > + RCU_GP_FLAG_INIT, 2*HZ);
> > +
> > + if(!ret) {
>
> This would avoid complaining if RCU was legitimately idle for a long time:
Let's try this again. Unless I am confused (quite possible) your original
would panic if RCU was idle for more than two seconds. What we instead want is
to panic if we time out, but end up with RCU_GP_FLAG_INIT set.
So something like this:
if (ret == 1) {
/* Timed out with RCU_GP_FLAG_INIT. */
rcu_ftrace_dump(DUMP_ALL);
show_rcu_gp_kthreads();
Re: [PATCH] eint: add gpio vritual number select
On Thu, 2018-12-13 at 11:33 -0800, Sean Wang wrote:
> On Thu, Dec 13, 2018 at 1:36 AM wrote:
> >
> > From: Chuanjia Liu
> >
> > This patch add gpio vritual number select,avoid virtual gpio set SMT.
>
> s/gpio/GPIO/
> s/vritual/virtual/
>
> Virtual GPIOs you said here that means these pins only used inside SoC
> and not being exported to outside SoC, right? It seems this kind of
> pins doesn't need SMT.
>
Yes,virtual gpio only used inside SOC and these pins doesn't need set
SMT
> >
> > Signed-off-by: Chuanjia Liu
> > ---
> > drivers/pinctrl/mediatek/mtk-eint.h |1 +
> > drivers/pinctrl/mediatek/pinctrl-mt8183.c|1 +
> > drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c |9 ++---
> > 3 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > b/drivers/pinctrl/mediatek/mtk-eint.h
> > index 48468d0..c16beaf 100644
> > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > @@ -37,6 +37,7 @@ struct mtk_eint_hw {
> > u8 ports;
> > unsigned intap_num;
> > unsigned intdb_cnt;
> > + unsigned intvir_start;
> > };
> >
> > struct mtk_eint;
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > index 6262fd3..bbeafd3 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8183.c
> > @@ -497,6 +497,7 @@
> > .ports = 6,
> > .ap_num= 212,
> > .db_cnt= 13,
> > + .vir_start = 180,
> > };
> >
> > static const struct mtk_pin_soc mt8183_data = {
> > diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > index 4a9e0d4..ca3bae1 100644
> > --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> > @@ -289,9 +289,12 @@ static int mtk_xt_set_gpio_as_eint(void *data,
> > unsigned long eint_n)
> > if (err)
> > return err;
> >
> > - err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT, MTK_ENABLE);
> > - if (err)
> > - return err;
> > + if (gpio_n < hw->eint->hw->vir_start) {
> > + err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> > + MTK_ENABLE);
> > + if (err)
> > + return err;
> > + }
>
> The changes will break these SoCs without a properly configured vir_start.
>
> If SMT seems unnecessary for these kinds of virtual GPIOs pin in the
> path, we can do it as
>
> err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
> MTK_ENABLE);
> /* please add comments for the exclusion condition */
> if (err && err != -ENOTSUPP)
> return err;
>
> If there is getting much special on certain pins between SoCs, and
> then we can consider creating a desc->flag to split logic.
Yes,SMT unnecessary for these kinds of virtual GPIOS pin in the path,if
do it as
err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_SMT,
MTK_ENABLE);
if (err && err != -ENOTSUPP)
return err;
I wonder if system will lose -ENOTSUPP information when smt was not
successfully set by real gpio?
>
> >
> > return 0;
> > }
> > --
> > 1.7.9.5
Re: [PATCH v1 1/3] of: add nvidia,thermtrips property
On 14/12/2018 10:29 PM, Thierry Reding wrote:
> On Fri, Dec 07, 2018 at 06:10:05PM +0800, Wei Ni wrote:
>> Add optional property "nvidia,thermtrips".
>> If present, these trips will be used as HW shutdown trips,
>> and critical trips will be used as SW shutdown trips.
>>
>> Signed-off-by: Wei Ni
>> ---
>> .../bindings/thermal/nvidia,tegra124-soctherm.txt| 20
>> +---
>> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> This seems like an odd exception. Why not extend the list of trip point
> types with a "shutdown" or "emergency" type that can be used for this?
> This doesn't seem like NVIDIA specific functionality, so adding an
> NVIDIA specific property doesn't seem right.
The thermal framework only support four types "active", "passive",
"hot", "critical". Normally if the "critical" trip is triggered, the
thermal framework will implement a software shutdown. In our soctherm
driver, we also set this "critical" trips to hardware, so it will cause
the HW shutdown directly.
This serial added the "nvidia,thermtrips" to set HW shutdown trips for
our NVIDIA specific functionality, and keep the "critical" trips to
implement SW shutdown.
For example, we will set "critical" trip to 102C, and set
""nvidia,thermtrips" to 103C, it mean if the temperature hit to 102, the
system will be software shutdown, if the temperature increase fast and
up to 103 directly, then it will cause the hardware shutdown.
Thanks.
Wei.
>
> Also, please always Cc devicet...@vger.kernel.org and the device tree
> bindings maintainers when sending updates for a binding. They need to
> ack these kinds of patches and they can't do that if they don't get a
> copy of the patch.
>
> Cc'ing them now and quoting the full patch for reference.
>
> Thierry
>
>>
>> diff --git
>> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> index b6c0ae53d4dc..ab66d6feab4b 100644
>> --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> @@ -55,10 +55,21 @@ Required properties :
>>- #cooling-cells: Should be 1. This cooling device only support
>> on/off state.
>> See ./thermal.txt for a description of this property.
>>
>> +Optional properties:
>> +- nvidia,thermtrips : When present, this property specifies the temperature
>> at
>> + which the soctherm hardware will assert the thermal trigger signal to the
>> + Power Management IC, which can be configured to reset or shutdown the
>> device.
>> + It is an array of pairs where each pair represents a tsensor id followed
>> by a
>> + temperature in milli Celcius. In the absence of this property the critical
>> + trip point will be used for thermtrip temperature.
>> +
>> Note:
>> -- the "critical" type trip points will be set to SOC_THERM hardware as the
>> -shut down temperature. Once the temperature of this thermal zone is higher
>> -than it, the system will be shutdown or reset by hardware.
>> +- the "critical" type trip points will be used to set the temperature at
>> which
>> +the SOC_THERM hardware will assert a thermal trigger if the
>> "nvidia,thermtrips"
>> +property is missing. When the thermtrips property is present, the breach of
>> a
>> +critical trip point is reported back to the thermal framework to implement
>> +software shutdown.
>> +
>> - the "hot" type trip points will be set to SOC_THERM hardware as the
>> throttle
>> temperature. Once the the temperature of this thermal zone is higher
>> than it, it will trigger the HW throttle event.
>> @@ -79,6 +90,9 @@ Example :
>>
>> #thermal-sensor-cells = <1>;
>>
>> +nvidia,thermtrips = > + TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
>> +
>> throttle-cfgs {
>> /*
>> * When the "heavy" cooling device triggered,
>> --
>> 2.7.4
Re: [PATCH] usb: typec: tcpm: Extend the matching rules on PPS APDO selection
On 12/16/18 6:48 PM, Kyle Tso wrote:
Current matching rules ensure that the voltage range of selected Source
Capability is entirely within the range defined in one of the Sink
Capabilities. This is reasonable but not practical because Sink may not
support wide range of voltage when sinking power while Source could
advertise its capabilities in raletively wider range. For example, a
Source PDO advertising 3.3V-11V@3A (9V Prog of Fixed Nominal Voltage)
will not be selected if the Sink requires 5V-12V@3A PPS power. However,
the Sink could work well if the requested voltage range in RDOs is
5V-11V@3A.
Currently accepted:
|- source -|
|--- sink ---|
Currently not accepted:
|- source -|
|--- sink ---|
|- source -|
|--- sink ---|
|- source -|
|-- sink ---|
To improve the usability, change the matching rules to what listed
below:
a. The Source PDO is selectable if any portion of the voltage range
overlaps one of the Sink PDO's voltage range.
b. The maximum operational voltage will be the lower one between the
selected Source PDO and the matching Sink PDO.
c. The maximum power will be the maximum operational voltage times the
maximum current defined in the selected Source PDO
d. Select the Source PDO with the highest maximum power
Signed-off-by: Kyle Tso
Reviewed-by: Guenter Roeck
---
Changelog since v1:
- updated the commit message as suggested by Guenter Roeck
---
drivers/usb/typec/tcpm/tcpm.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 3620efee2688..3001df7bd602 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -2213,7 +2213,8 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
tcpm_port *port)
unsigned int i, j, max_mw = 0, max_mv = 0;
unsigned int min_src_mv, max_src_mv, src_ma, src_mw;
unsigned int min_snk_mv, max_snk_mv;
- u32 pdo;
+ unsigned int max_op_mv;
+ u32 pdo, src, snk;
unsigned int src_pdo = 0, snk_pdo = 0;
/*
@@ -2263,16 +2264,18 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
tcpm_port *port)
continue;
}
-if (max_src_mv <= max_snk_mv &&
- min_src_mv >= min_snk_mv) {
+ if (min_src_mv <= max_snk_mv &&
+ max_src_mv >= min_snk_mv) {
+ max_op_mv = min(max_src_mv, max_snk_mv);
+ src_mw = (max_op_mv * src_ma) / 1000;
/* Prefer higher voltages if available
*/
if ((src_mw == max_mw &&
-min_src_mv > max_mv) ||
+max_op_mv > max_mv) ||
src_mw > max_mw) {
src_pdo = i;
snk_pdo = j;
max_mw = src_mw;
- max_mv = max_src_mv;
+ max_mv = max_op_mv;
}
}
}
@@ -2285,14 +2288,16 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
tcpm_port *port)
}
if (src_pdo) {
- pdo = port->source_caps[src_pdo];
-
- port->pps_data.min_volt = pdo_pps_apdo_min_voltage(pdo);
- port->pps_data.max_volt = pdo_pps_apdo_max_voltage(pdo);
- port->pps_data.max_curr =
- min_pps_apdo_current(pdo, port->snk_pdo[snk_pdo]);
+ src = port->source_caps[src_pdo];
+ snk = port->snk_pdo[snk_pdo];
+
+ port->pps_data.min_volt = max(pdo_pps_apdo_min_voltage(src),
+ pdo_pps_apdo_min_voltage(snk));
+ port->pps_data.max_volt = min(pdo_pps_apdo_max_voltage(src),
+ pdo_pps_apdo_max_voltage(snk));
+ port->pps_data.max_curr = min_pps_apdo_current(src, snk);
port->pps_data.out_volt =
- min(pdo_pps_apdo_max_voltage(pdo),
port->pps_data.out_volt);
+ min(port->pps_data.max_volt, port->pps_data.out_volt);
port->pps_data.op_curr =
min(port->pps_data.max_curr, port->pps_data.op_curr);
}
Re: [PATCH v2] x86, kbuild: revert macrofying inline assembly code
On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit wrote:
>
> > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada
> > wrote:
> >
> > Revert the following 9 commits:
> >
> > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
> >work around GCC inlining bugs")
> >
> >This was partially reverted because it made good cleanups
> >irrespective of the inlining issue; the error message is still
> >unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should
> >be kept.
> >
> > [2] d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to
> >work around GCC inlining bugs")
> >
> > [3] 0474d5d9d2f7 ("x86/extable: Macrofy inline assembly code to work
> >around GCC inlining bugs")
> >
> > [4] 494b5168f2de ("x86/paravirt: Work around GCC inlining bugs when
> >compiling paravirt ops")
> >
> > [5] f81f8ad56fd1 ("x86/bug: Macrofy the BUG table section handling,
> >to work around GCC inlining bugs")
> >
> > [6] 77f48ec28e4c ("x86/alternatives: Macrofy lock prefixes to work
> > around GCC inlining bugs")
> >
> > [7] 9e1725b41059 ("x86/refcount: Work around GCC inlining bug")
> >
> >Resolved conflicts in arch/x86/include/asm/refcount.h caused by
> >288e4521f0f6 ("x86/asm: 'Simplify' GEN_*_RMWcc() macros").
> >
> > [8] c06c4d809051 ("x86/objtool: Use asm macros to work around GCC
> >inlining bugs")
> >
> > [9] 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in inline
> >assembly code to work around asm() related GCC inlining bugs")
> >
> > A few days after those commits applied, discussion started to solve
> > the issue more elegantly with the help of compiler:
> >
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92data=02%7C01%7Cnamit%40vmware.com%7Ce893ce88065e4c59236308d663019424%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636805255787607178sdata=miiUndmPfGNKvrzD5mttC1%2Bn6rNaoIFebjZOAkBr24Y%3Dreserved=0
> >
> > The new syntax "asm inline" was implemented by Segher Boessenkool, and
> > now queued up for GCC 9. (People were positive even for back-porting it
> > to older compilers).
> >
> > Since the in-kernel workarounds merged, some issues have been reported:
> > breakage of building with distcc/icecc, breakage of distro packages for
> > module building. (More fundamentally, we cannot build external modules
> > after 'make clean'.)
> >
> > I do not want to mess up the build system any more.
> >
> > Given that this issue will be solved in a cleaner way sooner or later,
> > let's revert the in-kernel workarounds, and wait for GCC 9.
> >
> > Reported-by: Logan Gunthorpe # distcc
> > Reported-by: Sedat Dilek # deb/rpm package
>
> It is customary to cc those who report an issue.
OK.
> The distcc issue has already been resolved both in distcc
Precisely, the fix-up was submitted,
but not pulled yet as of writing.
https://github.com/distcc/distcc/pull/313
> and in the patches
> I’ve sent: https://lkml.org/lkml/2018/11/15/467 .
I was scared by this ugly fix-up, so I rejected it.
> So I cannot understand why
> it is mentioned as a motivation.
>
> It sounds that the external modules can easily be resolved. Can you please
> provide a link for the bug report?
https://www.spinics.net/lists/linux-kbuild/msg20037.html
We can fix it under circumstances "we can do anything"
although I am scared by endless Makefile hacks.
> Please regard my comments regarding v1.
I will try my best, although I felt some of your requests were too much.
I am not an x86 developer.
I posted this so people can play with 'asm inline'
https://lore.kernel.org/patchwork/patch/1024590/
You can confirm vmlinux size is increased,
and some symbols disappears.
> I must admit that I’m very surprised
> that you don’t like the patches since you ack’d the original patch-set
I think ack and "I like it" are different.
There are situations where we had to accept something reluctantly.
Without my ack, your patch series would not have been
merged via x86 tree.
There was no other solution at that time.
Also, I could not predict potential problems, which turned out later.
So I let it go.
It would have been better if
the following discussion had stared earlier.
https://lkml.org/lkml/2018/10/7/92
Now, we got a much cleaner solution.
I believe we should replace the workarounds with it.
> (and
> actually assisted me in changing the Makefile).
You were clearly breaking the build system.
So, I provided a less ugly solution.
Again, the in-kernel hack was the only solution at that time,
but the situation has changed then.
--
Best Regards
Masahiro Yamada
Re: [PATCH] uapi: linux/blkzoned.h: fix BLKGETZONESZ and BLKGETNRZONES definitions
On 12/15/18 6:49 PM, Dmitry V. Levin wrote: > According to the documentation in include/uapi/asm-generic/ioctl.h, > _IOW means userspace is writing and kernel is reading, and > _IOR means userspace is reading and kernel is writing. > > In case of these two ioctls, kernel is writing and userspace is reading, > so they have to be _IOR instead of _IOW. Applied, thanks. -- Jens Axboe
