[PATCH v2 1/2] dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
Add as370 to existing berlin pinctrl device tree binding. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt index f8fa28ce163e..0a2d5516e1f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt @@ -23,7 +23,8 @@ Required properties: "marvell,berlin2q-system-pinctrl", "marvell,berlin4ct-avio-pinctrl", "marvell,berlin4ct-soc-pinctrl", - "marvell,berlin4ct-system-pinctrl" + "marvell,berlin4ct-system-pinctrl", + "syna,as370-soc-pinctrl" Required subnode-properties: - groups: a list of strings describing the group names. -- 2.18.0
[PATCH v2 1/2] dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
Add as370 to existing berlin pinctrl device tree binding. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt index f8fa28ce163e..0a2d5516e1f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt @@ -23,7 +23,8 @@ Required properties: "marvell,berlin2q-system-pinctrl", "marvell,berlin4ct-avio-pinctrl", "marvell,berlin4ct-soc-pinctrl", - "marvell,berlin4ct-system-pinctrl" + "marvell,berlin4ct-system-pinctrl", + "syna,as370-soc-pinctrl" Required subnode-properties: - groups: a list of strings describing the group names. -- 2.18.0
[PATCH v2 0/2] pinctrl: berlin: add as370 SoC support
This series is to add the Synaptics AS370 SoC pinctrl driver. since v1: - remove MODULE_DEVICE_TABLE since the driver is non-modular. Thank kbuild test robot to report this issue. Jisheng Zhang (2): dt-binding: pinctrl: berlin: document AS370 SoC pinctrl pinctrl: berlin: add the as370 SoC pinctrl driver .../bindings/pinctrl/berlin,pinctrl.txt | 3 +- drivers/pinctrl/berlin/Kconfig| 5 + drivers/pinctrl/berlin/Makefile | 1 + drivers/pinctrl/berlin/pinctrl-as370.c| 368 ++ 4 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c -- 2.18.0
[PATCH v2 0/2] pinctrl: berlin: add as370 SoC support
This series is to add the Synaptics AS370 SoC pinctrl driver. since v1: - remove MODULE_DEVICE_TABLE since the driver is non-modular. Thank kbuild test robot to report this issue. Jisheng Zhang (2): dt-binding: pinctrl: berlin: document AS370 SoC pinctrl pinctrl: berlin: add the as370 SoC pinctrl driver .../bindings/pinctrl/berlin,pinctrl.txt | 3 +- drivers/pinctrl/berlin/Kconfig| 5 + drivers/pinctrl/berlin/Makefile | 1 + drivers/pinctrl/berlin/pinctrl-as370.c| 368 ++ 4 files changed, 376 insertions(+), 1 deletion(-) create mode 100644 drivers/pinctrl/berlin/pinctrl-as370.c -- 2.18.0
Re: [PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs
On 26-05-18, 19:21, Wei Xu wrote: > Hi Viresh, > > On 2018/5/26 19:00, Wei Xu wrote: > > Hi Viresh, > > > > On 2018/5/25 6:40, Viresh Kumar wrote: > >> The cooling device properties, like "#cooling-cells" and > >> "dynamic-power-coefficient", should either be present for all the CPUs > >> of a cluster or none. If these are present only for a subset of CPUs of > >> a cluster then things will start falling apart as soon as the CPUs are > >> brought online in a different order. For example, this will happen > >> because the operating system looks for such properties in the CPU node > >> it is trying to bring up, so that it can register a cooling device. > >> > >> Add such missing properties. > >> > >> Do minor rearrangement as well to keep ordering consistent. > >> > >> Signed-off-by: Viresh Kumar > > > > Thanks! > > Applied to the hisilicon fix tree. > > Sorry for the noise! > It seems this patch is still under discussion. > I will drop it firstly. Wei, can you please apply it again now that all the discussions are over ? -- viresh
Re: [PATCH 3/6] arm64: dts: hisilicon: Add missing cooling device properties for CPUs
On 26-05-18, 19:21, Wei Xu wrote: > Hi Viresh, > > On 2018/5/26 19:00, Wei Xu wrote: > > Hi Viresh, > > > > On 2018/5/25 6:40, Viresh Kumar wrote: > >> The cooling device properties, like "#cooling-cells" and > >> "dynamic-power-coefficient", should either be present for all the CPUs > >> of a cluster or none. If these are present only for a subset of CPUs of > >> a cluster then things will start falling apart as soon as the CPUs are > >> brought online in a different order. For example, this will happen > >> because the operating system looks for such properties in the CPU node > >> it is trying to bring up, so that it can register a cooling device. > >> > >> Add such missing properties. > >> > >> Do minor rearrangement as well to keep ordering consistent. > >> > >> Signed-off-by: Viresh Kumar > > > > Thanks! > > Applied to the hisilicon fix tree. > > Sorry for the noise! > It seems this patch is still under discussion. > I will drop it firstly. Wei, can you please apply it again now that all the discussions are over ? -- viresh
Re: [PATCH V3 11/16] cpufreq: dt: Pass regulator name to the OPP core
On 17-07-18, 09:46, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> CC device-tree folks
>
> Replying to an old email, because that's the most accurate reference I
> could find.
>
> On Tue, Feb 9, 2016 at 6:06 AM Viresh Kumar wrote:
> > OPP core can handle the regulators by itself, and but it needs to know
> > the name of the regulator to fetch. Add support for that.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > drivers/cpufreq/cpufreq-dt.c | 46
> >
> > 1 file changed, 46 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> > index 4c9f8a828f6f..2af75f8088bb 100644
> > --- a/drivers/cpufreq/cpufreq-dt.c
> > +++ b/drivers/cpufreq/cpufreq-dt.c
>
> > @@ -119,6 +120,30 @@ static int set_target(struct cpufreq_policy *policy,
> > unsigned int index)
> > return ret;
> > }
> >
> > +/*
> > + * An earlier version of opp-v1 bindings used to name the regulator
> > + * "cpu0-supply", we still need to handle that for backwards compatibility.
> > + */
> > +static const char *find_supply_name(struct device *dev, struct device_node
> > *np)
> > +{
> > + struct property *pp;
> > + int cpu = dev->id;
> > +
> > + /* Try "cpu0" for older DTs */
> > + if (!cpu) {
> > + pp = of_find_property(np, "cpu0-supply", NULL);
> > + if (pp)
> > + return "cpu0";
> > + }
> > +
> > + pp = of_find_property(np, "cpu-supply", NULL);
> > + if (pp)
> > + return "cpu";
>
> Despite the existence of lots of users of these properties, I couldn't find
> both the "earlier version" and the "current version" of the opp-v1 bindings
> documenting the "cpu0-supply" and "cpu-supply" properties?
They are part of the device nodes and don't fall under the
jurisdiction of OPP tables and so aren't defined there. We rely on the
"-supply" property from the regulator bindings for the devices.
> Even for opp-v2, they are not documented in
> Documentation/devicetree/bindings/opp/opp.txt, but cpu-supply is used in
> the examples?
Same reasoning here as well.
> For v2, I did find "[PATCH 01/16] PM / OPP: Add 'supply-names' binding"
> https://lore.kernel.org/lkml/2b87b162eabd1570ae2311e1ef8655acda72f678.1441972771.git.viresh.ku...@linaro.org/
> but presumably that's an even further evolution?
Yeah, that never made it to mainline is abandoned.
> Can you please document these properties?
I don't think we need to, do we ?
--
viresh
Re: [PATCH V3 11/16] cpufreq: dt: Pass regulator name to the OPP core
On 17-07-18, 09:46, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> CC device-tree folks
>
> Replying to an old email, because that's the most accurate reference I
> could find.
>
> On Tue, Feb 9, 2016 at 6:06 AM Viresh Kumar wrote:
> > OPP core can handle the regulators by itself, and but it needs to know
> > the name of the regulator to fetch. Add support for that.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > drivers/cpufreq/cpufreq-dt.c | 46
> >
> > 1 file changed, 46 insertions(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> > index 4c9f8a828f6f..2af75f8088bb 100644
> > --- a/drivers/cpufreq/cpufreq-dt.c
> > +++ b/drivers/cpufreq/cpufreq-dt.c
>
> > @@ -119,6 +120,30 @@ static int set_target(struct cpufreq_policy *policy,
> > unsigned int index)
> > return ret;
> > }
> >
> > +/*
> > + * An earlier version of opp-v1 bindings used to name the regulator
> > + * "cpu0-supply", we still need to handle that for backwards compatibility.
> > + */
> > +static const char *find_supply_name(struct device *dev, struct device_node
> > *np)
> > +{
> > + struct property *pp;
> > + int cpu = dev->id;
> > +
> > + /* Try "cpu0" for older DTs */
> > + if (!cpu) {
> > + pp = of_find_property(np, "cpu0-supply", NULL);
> > + if (pp)
> > + return "cpu0";
> > + }
> > +
> > + pp = of_find_property(np, "cpu-supply", NULL);
> > + if (pp)
> > + return "cpu";
>
> Despite the existence of lots of users of these properties, I couldn't find
> both the "earlier version" and the "current version" of the opp-v1 bindings
> documenting the "cpu0-supply" and "cpu-supply" properties?
They are part of the device nodes and don't fall under the
jurisdiction of OPP tables and so aren't defined there. We rely on the
"-supply" property from the regulator bindings for the devices.
> Even for opp-v2, they are not documented in
> Documentation/devicetree/bindings/opp/opp.txt, but cpu-supply is used in
> the examples?
Same reasoning here as well.
> For v2, I did find "[PATCH 01/16] PM / OPP: Add 'supply-names' binding"
> https://lore.kernel.org/lkml/2b87b162eabd1570ae2311e1ef8655acda72f678.1441972771.git.viresh.ku...@linaro.org/
> but presumably that's an even further evolution?
Yeah, that never made it to mainline is abandoned.
> Can you please document these properties?
I don't think we need to, do we ?
--
viresh
Re: [PATCH v6 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On 18-07-18, 11:07, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu,
> +unsigned long xo_rate)
> +{
> + struct cpufreq_qcom *c;
> + struct resource res;
> + struct device *dev = >dev;
> + const u16 *offsets;
> + cpumask_t cpus_related;
> + int ret, i, cpu_r;
> + void __iomem *base;
> +
> + cpumask_clear(_related);
> +
> + ret = qcom_get_related_cpus(np, _related);
> + if (ret) {
> + dev_err(dev, "%s failed to get related CPUs\n", np->name);
> + return ret;
> + }
> +
> + /* Related CPUs */
> + cpu_r = cpumask_first(_related);
> + if (cpu != cpu_r) {
> + qcom_freq_domain_map[cpu] = qcom_freq_domain_map[cpu_r];
> + return 0;
> + }
> +
> + c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
> + if (!c)
> + return -ENOMEM;
> +
> + offsets = of_device_get_match_data(>dev);
> + if (!offsets)
> + return -EINVAL;
> +
> + if (of_address_to_resource(np, 0, ))
> + return -ENOMEM;
> +
> + base = devm_ioremap_resource(dev, );
> + if (!base)
> + return -ENOMEM;
> +
> + for (i = REG_ENABLE; i < REG_ARRAY_SIZE; i++)
> + c->reg_bases[i] = base + offsets[i];
> +
> + /* HW should be in enabled state to proceed */
> + if (!(readl_relaxed(c->reg_bases[REG_ENABLE]) & 0x1)) {
> + dev_err(dev, "%s cpufreq hardware not enabled\n", np->name);
> + return -ENODEV;
> + }
> +
> + cpumask_copy(>related_cpus, _related);
> +
> + c->max_cores = cpumask_weight(>related_cpus);
> + if (!c->max_cores)
> + return -ENOENT;
> +
> + c->xo_rate = xo_rate;
> +
> + ret = qcom_cpufreq_hw_read_lut(pdev, c);
> + if (ret) {
> + dev_err(dev, "%s failed to read LUT\n", np->name);
> + return ret;
> + }
> +
> + qcom_freq_domain_map[cpu] = c;
Set this for all related CPUs here and then the check at the top of
this routine will be simply:
if (qcom_freq_domain_map[cpu])
return 0;
> +
> + return 0;
> +}
> +
--
viresh
Re: [PATCH v6 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
On 18-07-18, 11:07, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu,
> +unsigned long xo_rate)
> +{
> + struct cpufreq_qcom *c;
> + struct resource res;
> + struct device *dev = >dev;
> + const u16 *offsets;
> + cpumask_t cpus_related;
> + int ret, i, cpu_r;
> + void __iomem *base;
> +
> + cpumask_clear(_related);
> +
> + ret = qcom_get_related_cpus(np, _related);
> + if (ret) {
> + dev_err(dev, "%s failed to get related CPUs\n", np->name);
> + return ret;
> + }
> +
> + /* Related CPUs */
> + cpu_r = cpumask_first(_related);
> + if (cpu != cpu_r) {
> + qcom_freq_domain_map[cpu] = qcom_freq_domain_map[cpu_r];
> + return 0;
> + }
> +
> + c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
> + if (!c)
> + return -ENOMEM;
> +
> + offsets = of_device_get_match_data(>dev);
> + if (!offsets)
> + return -EINVAL;
> +
> + if (of_address_to_resource(np, 0, ))
> + return -ENOMEM;
> +
> + base = devm_ioremap_resource(dev, );
> + if (!base)
> + return -ENOMEM;
> +
> + for (i = REG_ENABLE; i < REG_ARRAY_SIZE; i++)
> + c->reg_bases[i] = base + offsets[i];
> +
> + /* HW should be in enabled state to proceed */
> + if (!(readl_relaxed(c->reg_bases[REG_ENABLE]) & 0x1)) {
> + dev_err(dev, "%s cpufreq hardware not enabled\n", np->name);
> + return -ENODEV;
> + }
> +
> + cpumask_copy(>related_cpus, _related);
> +
> + c->max_cores = cpumask_weight(>related_cpus);
> + if (!c->max_cores)
> + return -ENOENT;
> +
> + c->xo_rate = xo_rate;
> +
> + ret = qcom_cpufreq_hw_read_lut(pdev, c);
> + if (ret) {
> + dev_err(dev, "%s failed to read LUT\n", np->name);
> + return ret;
> + }
> +
> + qcom_freq_domain_map[cpu] = c;
Set this for all related CPUs here and then the check at the top of
this routine will be simply:
if (qcom_freq_domain_map[cpu])
return 0;
> +
> + return 0;
> +}
> +
--
viresh
Re: [PATCH] x86/boot: Fix if_changed build flip/flop
2018-07-16 7:58 GMT+09:00 Ingo Molnar :
>
> * Kees Cook wrote:
>
>> The if_changed kbuild function can only be used once per target. If not
>> it will effectively always trigger, flipping back and forth between the
>> two commands getting recorded. Instead, merge the two commands into a
>> single function to get stable build artifacts (i.e. .vmlinux.cmd).
>>
>> Reported-by: Dirk Gouders
>
> What actual symptoms does this bug have?
>
> I.e. it would be nice if the changelog started with such an explanation:
>
> Dirk Gouders reported that ...
> and bisected it back to:
>
> 98f78525371b ("x86/boot: Refuse to build with data relocations")
>
> The root cause of the bug is that the if_changed kbuild function ...
>
> Or something like that.
>
> Thanks,
>
> Ingo
Anyway, the code diff looks good to me.
Reviewed-by: Masahiro Yamada
--
Best Regards
Masahiro Yamada
Re: [PATCH] x86/boot: Fix if_changed build flip/flop
2018-07-16 7:58 GMT+09:00 Ingo Molnar :
>
> * Kees Cook wrote:
>
>> The if_changed kbuild function can only be used once per target. If not
>> it will effectively always trigger, flipping back and forth between the
>> two commands getting recorded. Instead, merge the two commands into a
>> single function to get stable build artifacts (i.e. .vmlinux.cmd).
>>
>> Reported-by: Dirk Gouders
>
> What actual symptoms does this bug have?
>
> I.e. it would be nice if the changelog started with such an explanation:
>
> Dirk Gouders reported that ...
> and bisected it back to:
>
> 98f78525371b ("x86/boot: Refuse to build with data relocations")
>
> The root cause of the bug is that the if_changed kbuild function ...
>
> Or something like that.
>
> Thanks,
>
> Ingo
Anyway, the code diff looks good to me.
Reviewed-by: Masahiro Yamada
--
Best Regards
Masahiro Yamada
[PATCH v6 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
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: Taniya Das
---
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/qcom-cpufreq-hw.c | 348 ++
3 files changed, 360 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 52f5f1a..0abd0a0 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -312,3 +312,14 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+ bool "QCOM CPUFreq HW driver"
+ depends on ARCH_QCOM
+ 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.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fb4a2ec..1226a3e 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW) += qcom-cpufreq-hw.o
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..794ffc4
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE 32
+
+enum {
+ REG_ENABLE,
+ REG_LUT_TABLE,
+ REG_PERF_STATE,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+ struct cpufreq_frequency_table *table;
+ struct device *dev;
+ void __iomem *reg_bases[REG_ARRAY_SIZE];
+ cpumask_t related_cpus;
+ unsigned int max_cores;
+ unsigned long xo_rate;
+};
+
+static const u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
+ [REG_ENABLE]= 0x0,
+ [REG_LUT_TABLE] = 0x110,
+ [REG_PERF_STATE]= 0x920,
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+
+ writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+ return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct cpufreq_policy *policy;
+ unsigned int index;
+
+ policy = cpufreq_cpu_get_raw(cpu);
+ if (!policy)
+ return 0;
+
+ c = policy->driver_data;
+
+ index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+ 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)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ int index;
+
+ index = policy->cached_resolved_idx;
+ if (index < 0)
+ return 0;
+
+ writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+ return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_qcom *c;
+
+ c = qcom_freq_domain_map[policy->cpu];
+ if (!c) {
+ pr_err("No scaling support for CPU%d\n", policy->cpu);
+ return -ENODEV;
+ }
+
+ cpumask_copy(policy->cpus, >related_cpus);
+
+ policy->fast_switch_possible = true;
+ policy->freq_table = c->table;
+ policy->driver_data = c;
+
+ return 0;
+}
+
+static struct freq_attr *qcom_cpufreq_hw_attr[] = {
+ _freq_attr_scaling_available_freqs,
+ _freq_attr_scaling_boost_freqs,
+ NULL
+};
+
+static struct cpufreq_driver cpufreq_qcom_hw_driver = {
+ .flags = CPUFREQ_STICKY |
[PATCH v6 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
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: Taniya Das
---
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/qcom-cpufreq-hw.c | 348 ++
3 files changed, 360 insertions(+)
create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 52f5f1a..0abd0a0 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -312,3 +312,14 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+ bool "QCOM CPUFreq HW driver"
+ depends on ARCH_QCOM
+ 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.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index fb4a2ec..1226a3e 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW) += qcom-cpufreq-hw.o
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..794ffc4
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE 32
+
+enum {
+ REG_ENABLE,
+ REG_LUT_TABLE,
+ REG_PERF_STATE,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+ struct cpufreq_frequency_table *table;
+ struct device *dev;
+ void __iomem *reg_bases[REG_ARRAY_SIZE];
+ cpumask_t related_cpus;
+ unsigned int max_cores;
+ unsigned long xo_rate;
+};
+
+static const u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
+ [REG_ENABLE]= 0x0,
+ [REG_LUT_TABLE] = 0x110,
+ [REG_PERF_STATE]= 0x920,
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+
+ writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+ return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct cpufreq_policy *policy;
+ unsigned int index;
+
+ policy = cpufreq_cpu_get_raw(cpu);
+ if (!policy)
+ return 0;
+
+ c = policy->driver_data;
+
+ index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+ 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)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ int index;
+
+ index = policy->cached_resolved_idx;
+ if (index < 0)
+ return 0;
+
+ writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+ return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_qcom *c;
+
+ c = qcom_freq_domain_map[policy->cpu];
+ if (!c) {
+ pr_err("No scaling support for CPU%d\n", policy->cpu);
+ return -ENODEV;
+ }
+
+ cpumask_copy(policy->cpus, >related_cpus);
+
+ policy->fast_switch_possible = true;
+ policy->freq_table = c->table;
+ policy->driver_data = c;
+
+ return 0;
+}
+
+static struct freq_attr *qcom_cpufreq_hw_attr[] = {
+ _freq_attr_scaling_available_freqs,
+ _freq_attr_scaling_boost_freqs,
+ NULL
+};
+
+static struct cpufreq_driver cpufreq_qcom_hw_driver = {
+ .flags = CPUFREQ_STICKY |
[PATCH v6 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
[v6] * Renamed match table 'qcom_cpufreq_hw_match'. * Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'. * Updated the logic to check for related CPUs at the beginning of the 'qcom_cpu_resources_init'. * Use devm_ioremap_resource instead of devm_ioremap. * Update the use of of_node_put to handle error conditions. * Use policy->cached_resolved_idx in fast switch callback. * Keep precalculated offsets 'reg_bases'. * XO clock is taken from Device tree. * Update documentation binding for clocks/clock-names. * Minor comments in Kconfig.arm. * Comments to move dev_info to dev_dbg. [v5] * Remove mapping different register regions of perf/lut/enable, instead map the entire HW region. * Add reg_offset/cpufreq_qcom_std_offsets to be supplied as device data. * Check of src == 0 during lut read. * Add of_node_put(cpu_np) in qcom_get_related_cpus * Update the qcom_cpu_resources_init for register offset data, and cleanup the related cpus to keep a single copy of CPUfreq. * Replace FW with HW, update Kconfig, rename filename qcom-cpufreq-hw.c * Update the documentation binding to reflect the changes of mapping the * entire HW region. [v4] * Fixed console messages as per comments. * Return error from qcom_resources_init() in the cases where failed to get frequency domain. * Rename cpu_dev to cpu_np in qcom_resources_init, qcom_get_related_cpus(). Also use temp variable freq_np in qcom_get_related_cpus(). * Update qcom_cpufreq_fw_get() to use the policy data to incoporate the hotplug use case. * Update code to use of fast_switching. * Check for !c->max_cores instead of cpumask_empty in qcom_get_related_cpus(). * Update the logic of assigning 'c' to qcom_freq_domain_map[cpu]. [v3] * Remove index check from 'qcom_cpufreq_fw_target_index'. * Update the Documentation binding to add the platform specific properties in the CPU nodes, node name "qcom,freq-domain". * Update return value to '0' from -ENODEV from 'qcom_cpufreq_fw_get'. * Update the logic for boost frequency to use local variables instead of cpufreq driver data in 'qcom_read_lut'. * Update the logic in 'qcom_get_related_cpus' to find the related cpus. * Update the reg-names to remove "_base" and also update the binding with the description of these registers. * Update the logic in 'qcom_resources_init' to address the new device tree notation of handling the frequency domain phandles. [v2] * Fixed the alignment issues in "qcom_cpufreq_fw_target_index" for dev_err and also for "qcom_cpu_resources_init". * Removed ret = 0 from qcom_get_related_cpus and added to check for cpu_mask_empty to return -ENOENT. * Fixes qcom_cpu_resources_init function * Remove initialization of 'index' * Check for valid 'c' * Removed initialization of 'prev_cc' from 'qcom_read_lut'. Taniya Das (2): dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver .../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 ++ drivers/cpufreq/Kconfig.arm| 11 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/qcom-cpufreq-hw.c | 348 + 4 files changed, 532 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v6 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.
Signed-off-by: Taniya Das
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 +
1 file changed, 172 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
new file mode 100644
index 000..22d4355
--- /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.
+
+- clock-names
+ Usage: required
+ Value type: From common clock binding.
+ Definition: must be "xo".
+
+* Property qcom,freq-domain
+Devices supporting freq-domain must set their "qcom,freq-domain" property with
+phandle to a freq_domain_table in their DT node.
+
+* Frequency Domain Table Node
+
+This describes the frequency domain belonging to a device.
+This node can have following properties:
+
+- reg
+ Usage: required
+ Value type:
+ Definition: Addresses and sizes for the memory of the HW bases.
+
+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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ L2_300: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU4: cpu@400 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x400>;
+ enable-method = "psci";
+ next-level-cache = <_400>;
+ qcom,freq-domain = <_domain_table1>;
+ L2_400: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU5: cpu@500 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x500>;
+
[PATCH v6 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
[v6] * Renamed match table 'qcom_cpufreq_hw_match'. * Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'. * Updated the logic to check for related CPUs at the beginning of the 'qcom_cpu_resources_init'. * Use devm_ioremap_resource instead of devm_ioremap. * Update the use of of_node_put to handle error conditions. * Use policy->cached_resolved_idx in fast switch callback. * Keep precalculated offsets 'reg_bases'. * XO clock is taken from Device tree. * Update documentation binding for clocks/clock-names. * Minor comments in Kconfig.arm. * Comments to move dev_info to dev_dbg. [v5] * Remove mapping different register regions of perf/lut/enable, instead map the entire HW region. * Add reg_offset/cpufreq_qcom_std_offsets to be supplied as device data. * Check of src == 0 during lut read. * Add of_node_put(cpu_np) in qcom_get_related_cpus * Update the qcom_cpu_resources_init for register offset data, and cleanup the related cpus to keep a single copy of CPUfreq. * Replace FW with HW, update Kconfig, rename filename qcom-cpufreq-hw.c * Update the documentation binding to reflect the changes of mapping the * entire HW region. [v4] * Fixed console messages as per comments. * Return error from qcom_resources_init() in the cases where failed to get frequency domain. * Rename cpu_dev to cpu_np in qcom_resources_init, qcom_get_related_cpus(). Also use temp variable freq_np in qcom_get_related_cpus(). * Update qcom_cpufreq_fw_get() to use the policy data to incoporate the hotplug use case. * Update code to use of fast_switching. * Check for !c->max_cores instead of cpumask_empty in qcom_get_related_cpus(). * Update the logic of assigning 'c' to qcom_freq_domain_map[cpu]. [v3] * Remove index check from 'qcom_cpufreq_fw_target_index'. * Update the Documentation binding to add the platform specific properties in the CPU nodes, node name "qcom,freq-domain". * Update return value to '0' from -ENODEV from 'qcom_cpufreq_fw_get'. * Update the logic for boost frequency to use local variables instead of cpufreq driver data in 'qcom_read_lut'. * Update the logic in 'qcom_get_related_cpus' to find the related cpus. * Update the reg-names to remove "_base" and also update the binding with the description of these registers. * Update the logic in 'qcom_resources_init' to address the new device tree notation of handling the frequency domain phandles. [v2] * Fixed the alignment issues in "qcom_cpufreq_fw_target_index" for dev_err and also for "qcom_cpu_resources_init". * Removed ret = 0 from qcom_get_related_cpus and added to check for cpu_mask_empty to return -ENOENT. * Fixes qcom_cpu_resources_init function * Remove initialization of 'index' * Check for valid 'c' * Removed initialization of 'prev_cc' from 'qcom_read_lut'. Taniya Das (2): dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver .../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 ++ drivers/cpufreq/Kconfig.arm| 11 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/qcom-cpufreq-hw.c | 348 + 4 files changed, 532 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.
[PATCH v6 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.
Signed-off-by: Taniya Das
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 +
1 file changed, 172 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
new file mode 100644
index 000..22d4355
--- /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.
+
+- clock-names
+ Usage: required
+ Value type: From common clock binding.
+ Definition: must be "xo".
+
+* Property qcom,freq-domain
+Devices supporting freq-domain must set their "qcom,freq-domain" property with
+phandle to a freq_domain_table in their DT node.
+
+* Frequency Domain Table Node
+
+This describes the frequency domain belonging to a device.
+This node can have following properties:
+
+- reg
+ Usage: required
+ Value type:
+ Definition: Addresses and sizes for the memory of the HW bases.
+
+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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ 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 = <_domain_table0>;
+ L2_300: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU4: cpu@400 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x400>;
+ enable-method = "psci";
+ next-level-cache = <_400>;
+ qcom,freq-domain = <_domain_table1>;
+ L2_400: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU5: cpu@500 {
+ device_type = "cpu";
+ compatible = "qcom,kryo385";
+ reg = <0x0 0x500>;
+
Re: [PATCH v5 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
Hello Stephen,
Thanks for the review comments.
On 7/13/2018 5:14 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 11:05:45)
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: Taniya Das
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 52f5f1a..141ec3e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -312,3 +312,13 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+ bool "QCOM CPUFreq HW driver"
Why can't it be a module?
I am of the opinion to keep it in-built.
+ 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 interafce to the High-level OS.
typo on interface. Why is High capitalized? Just say OS?
Taken care in the next patch.
+The driver implements the cpufreq driver interface for this HW engine.
So much 'driver'.
Taken care in the next patch.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..fa25a95
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
This doesn't need to be configured from DT? Or more likely be specified
as some sort of PLL that is part of the clocks property so we know what
the 'safe' or 'default' frequency is?
The source is RCG which is pre-configured by HW and is not modeled in SW
code. That is the reason to keep it as a macro.
+#define XO_RATE1920UL
This should come from DT via some clocks property.
This would be taken as an input from DT clocks.
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE 32
+
+enum {
+ REG_ENABLE,
+ REG_LUT_TABLE,
+ REG_PERF_STATE,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+ struct cpufreq_frequency_table *table;
+ struct device *dev;
+ const u16 *reg_offset;
+ void __iomem *base;
+ cpumask_t related_cpus;
+ unsigned int max_cores;
+};
+
+static u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
const?
Updated to use const.
+ [REG_ENABLE]= 0x0,
+ [REG_LUT_TABLE] = 0x110,
+ [REG_PERF_STATE]= 0x920,
Is the register map going to change again for the next device? It may be
better to precalculate the offset for the fast switch so that the
addition isn't in the hotpath.
Taken care in the next patch set.
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ unsigned int offset = c->reg_offset[REG_PERF_STATE];
+
+ writel_relaxed(index, c->base + offset);
+
+ return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct cpufreq_policy *policy;
+ unsigned int index, offset;
+
+ policy = cpufreq_cpu_get_raw(cpu);
+ if (!policy)
+ return 0;
+
+ c = policy->driver_data;
+ offset = c->reg_offset[REG_PERF_STATE];
+
+ index = readl_relaxed(c->base + offset);
+ 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)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ unsigned int offset;
+ int index;
+
+ index = cpufreq_table_find_index_l(policy, target_freq);
It's unfortunate that we have to search the table in software again.
Why can't we use policy->cached_resolved_idx to avoid this search twice?
Yeah, I just checked the call flow
get_next_freq(already determines the idx and keeps a cached copy of the
index) and then invokes the 'sugov_update_commit' for fast switch.
My understanding is we could use policy->cached_resolved_idx instead of
searching again.
+ if (index < 0)
+ return 0;
+
+ offset = c->reg_offset[REG_PERF_STATE];
+
+ writel_relaxed(index, c->base + offset);
+
+
Re: [PATCH v5 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver
Hello Stephen,
Thanks for the review comments.
On 7/13/2018 5:14 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 11:05:45)
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: Taniya Das
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 52f5f1a..141ec3e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -312,3 +312,13 @@ config ARM_PXA2xx_CPUFREQ
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+ bool "QCOM CPUFreq HW driver"
Why can't it be a module?
I am of the opinion to keep it in-built.
+ 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 interafce to the High-level OS.
typo on interface. Why is High capitalized? Just say OS?
Taken care in the next patch.
+The driver implements the cpufreq driver interface for this HW engine.
So much 'driver'.
Taken care in the next patch.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..fa25a95
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INIT_RATE 3UL
This doesn't need to be configured from DT? Or more likely be specified
as some sort of PLL that is part of the clocks property so we know what
the 'safe' or 'default' frequency is?
The source is RCG which is pre-configured by HW and is not modeled in SW
code. That is the reason to keep it as a macro.
+#define XO_RATE1920UL
This should come from DT via some clocks property.
This would be taken as an input from DT clocks.
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE 32
+
+enum {
+ REG_ENABLE,
+ REG_LUT_TABLE,
+ REG_PERF_STATE,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+ struct cpufreq_frequency_table *table;
+ struct device *dev;
+ const u16 *reg_offset;
+ void __iomem *base;
+ cpumask_t related_cpus;
+ unsigned int max_cores;
+};
+
+static u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
const?
Updated to use const.
+ [REG_ENABLE]= 0x0,
+ [REG_LUT_TABLE] = 0x110,
+ [REG_PERF_STATE]= 0x920,
Is the register map going to change again for the next device? It may be
better to precalculate the offset for the fast switch so that the
addition isn't in the hotpath.
Taken care in the next patch set.
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ unsigned int offset = c->reg_offset[REG_PERF_STATE];
+
+ writel_relaxed(index, c->base + offset);
+
+ return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct cpufreq_policy *policy;
+ unsigned int index, offset;
+
+ policy = cpufreq_cpu_get_raw(cpu);
+ if (!policy)
+ return 0;
+
+ c = policy->driver_data;
+ offset = c->reg_offset[REG_PERF_STATE];
+
+ index = readl_relaxed(c->base + offset);
+ 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)
+{
+ struct cpufreq_qcom *c = policy->driver_data;
+ unsigned int offset;
+ int index;
+
+ index = cpufreq_table_find_index_l(policy, target_freq);
It's unfortunate that we have to search the table in software again.
Why can't we use policy->cached_resolved_idx to avoid this search twice?
Yeah, I just checked the call flow
get_next_freq(already determines the idx and keeps a cached copy of the
index) and then invokes the 'sugov_update_commit' for fast switch.
My understanding is we could use policy->cached_resolved_idx instead of
searching again.
+ if (index < 0)
+ return 0;
+
+ offset = c->reg_offset[REG_PERF_STATE];
+
+ writel_relaxed(index, c->base + offset);
+
+
Re: [PATCH 05/14] dmaengine: dma-jz4780: Add support for the JZ4740 SoC
On 17-07-18, 11:40, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 9:34 AM Vinod wrote:
> >
> > On 16-07-18, 15:33, Rob Herring wrote:
> > > On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > > > On 03-07-18, 14:32, Paul Cercueil wrote:
> > > >
> > > > > enum jz_version {
> > > > > + ID_JZ4740,
> > > > > ID_JZ4770,
> > > > > ID_JZ4780,
> > > > > };
> > > > > @@ -247,6 +248,7 @@ static void jz4780_dma_desc_free(struct
> > > > > virt_dma_desc *vdesc)
> > > > > }
> > > > >
> > > > > static const unsigned int jz4780_dma_ord_max[] = {
> > > > > + [ID_JZ4740] = 5,
> > > > > [ID_JZ4770] = 6,
> > > > > [ID_JZ4780] = 7,
> > > > > };
> > > > > @@ -801,11 +803,13 @@ static struct dma_chan
> > > > > *jz4780_of_dma_xlate(struct of_phandle_args *dma_spec,
> > > > > }
> > > > >
> > > > > static const unsigned int jz4780_dma_nb_channels[] = {
> > > > > + [ID_JZ4740] = 6,
> > > > > [ID_JZ4770] = 6,
> > > > > [ID_JZ4780] = 32,
> > > > > };
> > > >
> > > > I feel these should be done away with if we describe hardware in DT
> > >
> > > The compatible property can imply things like this.
> >
> > So what is the general recommendation, let DT describe hardware
> > including version delta or use compatible to code that in driver?
>
> Compatible is the version. Looking at the above, the version or ID
> isn't even stable.
>
> > Is it documented anywhere?
>
> Not really. It's a judgment call generally. Maybe # of DMA channels
> should be a property because that is something most controllers have.
> But you really have to define the property up front, not when the 2nd
> version of h/w shows up with different properties.
>
> To start defining guidelines, a couple of things come to mind:
>
> - Define properties for parameters that vary from board to board (for one
> SoC).
> - You can't add new required properties to existing bindings, so the
> not present default must work for all existing compatibles (or you
> need per compatible driver data).
> - Bugs/quirks/errata should be handled by compatible, not adding a
> property. Because bugs should be fixable without a dtb update and only
> a kernel update.
Sounds good to me, thanks for the guide.
--
~Vinod
Re: [PATCH 05/14] dmaengine: dma-jz4780: Add support for the JZ4740 SoC
On 17-07-18, 11:40, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 9:34 AM Vinod wrote:
> >
> > On 16-07-18, 15:33, Rob Herring wrote:
> > > On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > > > On 03-07-18, 14:32, Paul Cercueil wrote:
> > > >
> > > > > enum jz_version {
> > > > > + ID_JZ4740,
> > > > > ID_JZ4770,
> > > > > ID_JZ4780,
> > > > > };
> > > > > @@ -247,6 +248,7 @@ static void jz4780_dma_desc_free(struct
> > > > > virt_dma_desc *vdesc)
> > > > > }
> > > > >
> > > > > static const unsigned int jz4780_dma_ord_max[] = {
> > > > > + [ID_JZ4740] = 5,
> > > > > [ID_JZ4770] = 6,
> > > > > [ID_JZ4780] = 7,
> > > > > };
> > > > > @@ -801,11 +803,13 @@ static struct dma_chan
> > > > > *jz4780_of_dma_xlate(struct of_phandle_args *dma_spec,
> > > > > }
> > > > >
> > > > > static const unsigned int jz4780_dma_nb_channels[] = {
> > > > > + [ID_JZ4740] = 6,
> > > > > [ID_JZ4770] = 6,
> > > > > [ID_JZ4780] = 32,
> > > > > };
> > > >
> > > > I feel these should be done away with if we describe hardware in DT
> > >
> > > The compatible property can imply things like this.
> >
> > So what is the general recommendation, let DT describe hardware
> > including version delta or use compatible to code that in driver?
>
> Compatible is the version. Looking at the above, the version or ID
> isn't even stable.
>
> > Is it documented anywhere?
>
> Not really. It's a judgment call generally. Maybe # of DMA channels
> should be a property because that is something most controllers have.
> But you really have to define the property up front, not when the 2nd
> version of h/w shows up with different properties.
>
> To start defining guidelines, a couple of things come to mind:
>
> - Define properties for parameters that vary from board to board (for one
> SoC).
> - You can't add new required properties to existing bindings, so the
> not present default must work for all existing compatibles (or you
> need per compatible driver data).
> - Bugs/quirks/errata should be handled by compatible, not adding a
> property. Because bugs should be fixable without a dtb update and only
> a kernel update.
Sounds good to me, thanks for the guide.
--
~Vinod
Re: 4.18.0-rc1-next-20180619 boot failed on beagle board x15
On Tuesday 17 July 2018 01:33 PM, Tony Lindgren wrote:
> * Stephen Rothwell [180717 08:03]:
>> Hi Tony,
>>
>> On Mon, 16 Jul 2018 23:08:08 -0700 Tony Lindgren wrote:
>>>
>>> The following regression is still pending in next, see below.
>>>
>>> * Samuel Morris [180702 13:35]:
On Mon, Jul 2, 2018 at 5:32 AM, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros [180621 14:56]:
>> On 21/06/18 17:31, Samuel Morris wrote:
>>> On Thu, Jun 21, 2018 at 3:58 AM, Roger Quadros wrote:
+Rafael
On 20/06/18 18:30, Samuel Morris wrote:
> On Wed, Jun 20, 2018 at 8:58 AM, Roger Quadros wrote:
>
>> Tony,
>>
>> On 20/06/18 13:29, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Naresh Kamboju [180620 05:55]:
Linux next (4.18.0-rc1-next-20180619) boot failed on beagle board
x15.
>>>
>>> Bisect points to commit aece27a2f01b ("ata: ahci_platform: allow
>>> disabling of
>>> hotplug to save power").
>>>
>>> Reverting the patch makes things work again. Any ideas what
>>> might be going wrong here? Things clearly idle but then there
>>> seems to be some register access with clocks disabled.
>
> So this issue is still happening as of next-20180702. Can you guys
> please revert the commit above while working on a better solution?
That's fine with me. I'm not very familiar with the process here, does
this require anything on my end? And would that require the
accompanying patch to be reverted: "ata: ahci: rpm_put port on
port_stop to match rpm_get in port_start"? There shouldn't be any
problem leaving that one in, but I just want to know before submitting
my next patch set.
>>>
>>> Well usually the maintainer just reverts the regression causing
>>> patch in the related branch and that's it.
>>>
>>> Stephen, can you please revert in next until we hear back from
>>> Tejun?
>>
>> OK, I have reverted that commit from today. Please let me know when the
>> problem is fixed in the libata tree ...
Hi Stephen,
Thanks for the revert.
commit 1dcbe5f2c615337cb7d4e13fab198ab716180733
Author: Stephen Rothwell
Date: Tue Jul 17 19:02:59 2018 +1000
With the above top commit i confirm that BEAGLE-X15, AM572X-IDK,
AM574X-IDK, DRA7, DRA72 TI platforms booted to prompt.
Regards,
Keerthy
>
> Thanks!
>
> Tony
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: 4.18.0-rc1-next-20180619 boot failed on beagle board x15
On Tuesday 17 July 2018 01:33 PM, Tony Lindgren wrote:
> * Stephen Rothwell [180717 08:03]:
>> Hi Tony,
>>
>> On Mon, 16 Jul 2018 23:08:08 -0700 Tony Lindgren wrote:
>>>
>>> The following regression is still pending in next, see below.
>>>
>>> * Samuel Morris [180702 13:35]:
On Mon, Jul 2, 2018 at 5:32 AM, Tony Lindgren wrote:
> Hi,
>
> * Roger Quadros [180621 14:56]:
>> On 21/06/18 17:31, Samuel Morris wrote:
>>> On Thu, Jun 21, 2018 at 3:58 AM, Roger Quadros wrote:
+Rafael
On 20/06/18 18:30, Samuel Morris wrote:
> On Wed, Jun 20, 2018 at 8:58 AM, Roger Quadros wrote:
>
>> Tony,
>>
>> On 20/06/18 13:29, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Naresh Kamboju [180620 05:55]:
Linux next (4.18.0-rc1-next-20180619) boot failed on beagle board
x15.
>>>
>>> Bisect points to commit aece27a2f01b ("ata: ahci_platform: allow
>>> disabling of
>>> hotplug to save power").
>>>
>>> Reverting the patch makes things work again. Any ideas what
>>> might be going wrong here? Things clearly idle but then there
>>> seems to be some register access with clocks disabled.
>
> So this issue is still happening as of next-20180702. Can you guys
> please revert the commit above while working on a better solution?
That's fine with me. I'm not very familiar with the process here, does
this require anything on my end? And would that require the
accompanying patch to be reverted: "ata: ahci: rpm_put port on
port_stop to match rpm_get in port_start"? There shouldn't be any
problem leaving that one in, but I just want to know before submitting
my next patch set.
>>>
>>> Well usually the maintainer just reverts the regression causing
>>> patch in the related branch and that's it.
>>>
>>> Stephen, can you please revert in next until we hear back from
>>> Tejun?
>>
>> OK, I have reverted that commit from today. Please let me know when the
>> problem is fixed in the libata tree ...
Hi Stephen,
Thanks for the revert.
commit 1dcbe5f2c615337cb7d4e13fab198ab716180733
Author: Stephen Rothwell
Date: Tue Jul 17 19:02:59 2018 +1000
With the above top commit i confirm that BEAGLE-X15, AM572X-IDK,
AM574X-IDK, DRA7, DRA72 TI platforms booted to prompt.
Regards,
Keerthy
>
> Thanks!
>
> Tony
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH] cpufreq: qcom-kryo: Silently error out on EPROBE_DEFER
On 17-07-18, 22:48, Niklas Cassel wrote:
> If of_nvmem_cell_get() fails due to probe deferal, we shouldn't print an
> error message. Just be silent in this case.
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index 29389accf3e9..b8d1e6875f16 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -109,8 +109,9 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
> *pdev)
> speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> of_node_put(np);
> if (IS_ERR(speedbin_nvmem)) {
> - dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
> - PTR_ERR(speedbin_nvmem));
> + if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER)
> + dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
> + PTR_ERR(speedbin_nvmem));
> return PTR_ERR(speedbin_nvmem);
> }
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH] cpufreq: qcom-kryo: Silently error out on EPROBE_DEFER
On 17-07-18, 22:48, Niklas Cassel wrote:
> If of_nvmem_cell_get() fails due to probe deferal, we shouldn't print an
> error message. Just be silent in this case.
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index 29389accf3e9..b8d1e6875f16 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -109,8 +109,9 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
> *pdev)
> speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> of_node_put(np);
> if (IS_ERR(speedbin_nvmem)) {
> - dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
> - PTR_ERR(speedbin_nvmem));
> + if (PTR_ERR(speedbin_nvmem) != -EPROBE_DEFER)
> + dev_err(cpu_dev, "Could not get nvmem cell: %ld\n",
> + PTR_ERR(speedbin_nvmem));
> return PTR_ERR(speedbin_nvmem);
> }
Acked-by: Viresh Kumar
--
viresh
BUG: unable to handle kernel NULL pointer dereference in corrupted (2)
Hello, syzbot found the following crash on: HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=10a9a97840 kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3 dashboard link: https://syzkaller.appspot.com/bug?extid=c9ebf7fd9683e40ccebc compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11974b2c40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14de7a5840 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c9ebf7fd9683e40cc...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) IPVS: ftp: loaded support on port[0] = 21 BUG: unable to handle kernel NULL pointer dereference at 0072 == PGD 1acfe1067 BUG: KASAN: stack-out-of-bounds in rcu_cblist_dequeue+0xaa/0xe0 kernel/rcu/rcu_segcblist.c:54 P4D 1acfe1067 Read of size 8 at addr 8801cfe1e340 by task syz-executor568/12240 PUD 1c551a067 PMD 0 CPU: 0 PID: 12240 Comm: syz-executor568 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Oops: 0002 [#1] SMP KASAN Call Trace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 RIP: 0010:K512_4+0x6792/0x120eac Code: 20 36 34 print_address_description+0x6c/0x20b mm/kasan/report.c:256 20 34 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 20 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 74 rcu_cblist_dequeue+0xaa/0xe0 kernel/rcu/rcu_segcblist.c:54 68 69 rcu_do_batch kernel/rcu/tree.c:2556 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2818 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2785 [inline] rcu_process_callbacks+0xf7e/0x1850 kernel/rcu/tree.c:2802 73 20 32 35 36 20 36 34 20 34 20 __do_softirq+0x2e8/0xb17 kernel/softirq.c:288 74 68 61 74 20 00 00 00 00 00 invoke_softirq kernel/softirq.c:368 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:408 00 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052 00 20 30 20 33 32 20 38 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 20 31 32 Allocated by task 0: <20> (stack is not available) 74 61 Freed by task 3487688240: 72 67 65 74 5f 65 6e 74 72 79 20 39 36 20 32 34 20 35 20 RSP: 0018:8801daf07980 EFLAGS: 00010202 RAX: 81674dc6 RBX: 88bf2c08 RCX: RDX: 88bf2c08 RSI: RDI: 8801cfea94a0 RBP: 8801daf07c88 R08: R09: R10: fbfff157bc71 R11: 8abde38b R12: 8801cfea94a0 R13: 8801cfea94a8 R14: dc00 R15: 8801daf07c60 FS: () GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0072 CR3: 0001cae8d000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __do_softirq+0x2e8/0xb17 kernel/softirq.c:288 invoke_softirq kernel/softirq.c:368 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:408 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54 Code: c7 48 89 45 d8 e8 8a 2d 23 fa 48 8b 45 d8 e9 d2 fe ff ff 48 89 df e8 79 2d 23 fa eb 8a 90 90 90 90 90 90 90 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 90 90 90 90 90 RSP: 0018:8801d9af7c38 EFLAGS: 0282 ORIG_RAX: ff13 RAX: dc00 RBX: 11003b35ef8a RCX: 81667982 RDX: 111e3610 RSI: 0004 RDI: 88f1b080 RBP: 8801d9af7c38 R08: ed003b5e46d7 R09: ed003b5e46d6 R10: ed003b5e46d6 R11: 8801daf236b3 R12: 0001 R13: 8801d9af7cf0 R14: 899ee920 R15: arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0xc7/0x450 arch/x86/kernel/process.c:500 arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491 default_idle_call+0x6d/0x90 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x3aa/0x570 kernel/sched/idle.c:262 cpu_startup_entry+0x10c/0x120
KASAN: slab-out-of-bounds Read in corrupted
Hello, syzbot found the following crash on: HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=1428957840 kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3 dashboard link: https://syzkaller.appspot.com/bug?extid=a7429c9ff268823af453 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=106314c840 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1495b4c840 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a7429c9ff268823af...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in do_error_trap+0x3b6/0x4d0 arch/x86/kernel/traps.c:296 Read of size 8 at addr 8801c0ce3cb0 by task syz-executor113/9480 CPU: 1 PID: 9480 Comm: syz-executor113 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: Allocated by task 2164292896: BUG: unable to handle kernel paging request at 8c433958 PGD 8e6d067 P4D 8e6d067 PUD 8e6e063 PMD 0 Thread overran stack, or stack corrupted Oops: [#1] SMP KASAN CPU: 1 PID: 9480 Comm: syz-executor113 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:depot_fetch_stack+0x10/0x30 lib/stackdepot.c:201 Code: e8 c5 2e 47 fe e9 b3 fd ff ff e8 bb 2e 47 fe e9 55 fd ff ff 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 60 39 43 8b 8b 47 0c 48 83 c7 18 c7 46 10 00 00 00 00 RSP: 0018:8801c0ce3a08 EFLAGS: 00010006 RAX: 001f RBX: 8801c0ce3bc4 RCX: RDX: RSI: 8801c0ce3a10 RDI: 3ff0 RBP: 8801c0ce3a38 R08: 8801b2632440 R09: ed003b5e3ec2 R10: ed003b5e3ec2 R11: 8801daf1f617 R12: 8801c0ce2bc0 R13: 8801c0ce3cb0 R14: 8801da987dc0 R15: 8801c0ce3bc0 FS: 00b43940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c433958 CR3: 0001ae01a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 8c433958 ---[ end trace 3b9527e7dfd4d0bc ]--- RIP: 0010:depot_fetch_stack+0x10/0x30 lib/stackdepot.c:201 Code: e8 c5 2e 47 fe e9 b3 fd ff ff e8 bb 2e 47 fe e9 55 fd ff ff 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 60 39 43 8b 8b 47 0c 48 83 c7 18 c7 46 10 00 00 00 00 RSP: 0018:8801c0ce3a08 EFLAGS: 00010006 RAX: 001f RBX: 8801c0ce3bc4 RCX: RDX: RSI: 8801c0ce3a10 RDI: 3ff0 RBP: 8801c0ce3a38 R08: 8801b2632440 R09: ed003b5e3ec2 R10: ed003b5e3ec2 R11: 8801daf1f617 R12: 8801c0ce2bc0 R13: 8801c0ce3cb0 R14: 8801da987dc0 R15: 8801c0ce3bc0 FS: 00b43940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c433958 CR3: 0001ae01a000 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. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
BUG: unable to handle kernel NULL pointer dereference in corrupted (2)
Hello, syzbot found the following crash on: HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=10a9a97840 kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3 dashboard link: https://syzkaller.appspot.com/bug?extid=c9ebf7fd9683e40ccebc compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11974b2c40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14de7a5840 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c9ebf7fd9683e40cc...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) IPVS: ftp: loaded support on port[0] = 21 BUG: unable to handle kernel NULL pointer dereference at 0072 == PGD 1acfe1067 BUG: KASAN: stack-out-of-bounds in rcu_cblist_dequeue+0xaa/0xe0 kernel/rcu/rcu_segcblist.c:54 P4D 1acfe1067 Read of size 8 at addr 8801cfe1e340 by task syz-executor568/12240 PUD 1c551a067 PMD 0 CPU: 0 PID: 12240 Comm: syz-executor568 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Oops: 0002 [#1] SMP KASAN Call Trace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 RIP: 0010:K512_4+0x6792/0x120eac Code: 20 36 34 print_address_description+0x6c/0x20b mm/kasan/report.c:256 20 34 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 20 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 74 rcu_cblist_dequeue+0xaa/0xe0 kernel/rcu/rcu_segcblist.c:54 68 69 rcu_do_batch kernel/rcu/tree.c:2556 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2818 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2785 [inline] rcu_process_callbacks+0xf7e/0x1850 kernel/rcu/tree.c:2802 73 20 32 35 36 20 36 34 20 34 20 __do_softirq+0x2e8/0xb17 kernel/softirq.c:288 74 68 61 74 20 00 00 00 00 00 invoke_softirq kernel/softirq.c:368 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:408 00 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052 00 20 30 20 33 32 20 38 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 20 31 32 Allocated by task 0: <20> (stack is not available) 74 61 Freed by task 3487688240: 72 67 65 74 5f 65 6e 74 72 79 20 39 36 20 32 34 20 35 20 RSP: 0018:8801daf07980 EFLAGS: 00010202 RAX: 81674dc6 RBX: 88bf2c08 RCX: RDX: 88bf2c08 RSI: RDI: 8801cfea94a0 RBP: 8801daf07c88 R08: R09: R10: fbfff157bc71 R11: 8abde38b R12: 8801cfea94a0 R13: 8801cfea94a8 R14: dc00 R15: 8801daf07c60 FS: () GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0072 CR3: 0001cae8d000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __do_softirq+0x2e8/0xb17 kernel/softirq.c:288 invoke_softirq kernel/softirq.c:368 [inline] irq_exit+0x1d1/0x200 kernel/softirq.c:408 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1052 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863 RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54 Code: c7 48 89 45 d8 e8 8a 2d 23 fa 48 8b 45 d8 e9 d2 fe ff ff 48 89 df e8 79 2d 23 fa eb 8a 90 90 90 90 90 90 90 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 90 90 90 90 90 RSP: 0018:8801d9af7c38 EFLAGS: 0282 ORIG_RAX: ff13 RAX: dc00 RBX: 11003b35ef8a RCX: 81667982 RDX: 111e3610 RSI: 0004 RDI: 88f1b080 RBP: 8801d9af7c38 R08: ed003b5e46d7 R09: ed003b5e46d6 R10: ed003b5e46d6 R11: 8801daf236b3 R12: 0001 R13: 8801d9af7cf0 R14: 899ee920 R15: arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0xc7/0x450 arch/x86/kernel/process.c:500 arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491 default_idle_call+0x6d/0x90 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x3aa/0x570 kernel/sched/idle.c:262 cpu_startup_entry+0x10c/0x120
KASAN: slab-out-of-bounds Read in corrupted
Hello, syzbot found the following crash on: HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=1428957840 kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3 dashboard link: https://syzkaller.appspot.com/bug?extid=a7429c9ff268823af453 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=106314c840 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1495b4c840 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a7429c9ff268823af...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in do_error_trap+0x3b6/0x4d0 arch/x86/kernel/traps.c:296 Read of size 8 at addr 8801c0ce3cb0 by task syz-executor113/9480 CPU: 1 PID: 9480 Comm: syz-executor113 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: Allocated by task 2164292896: BUG: unable to handle kernel paging request at 8c433958 PGD 8e6d067 P4D 8e6d067 PUD 8e6e063 PMD 0 Thread overran stack, or stack corrupted Oops: [#1] SMP KASAN CPU: 1 PID: 9480 Comm: syz-executor113 Not tainted 4.18.0-rc3+ #57 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:depot_fetch_stack+0x10/0x30 lib/stackdepot.c:201 Code: e8 c5 2e 47 fe e9 b3 fd ff ff e8 bb 2e 47 fe e9 55 fd ff ff 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 60 39 43 8b 8b 47 0c 48 83 c7 18 c7 46 10 00 00 00 00 RSP: 0018:8801c0ce3a08 EFLAGS: 00010006 RAX: 001f RBX: 8801c0ce3bc4 RCX: RDX: RSI: 8801c0ce3a10 RDI: 3ff0 RBP: 8801c0ce3a38 R08: 8801b2632440 R09: ed003b5e3ec2 R10: ed003b5e3ec2 R11: 8801daf1f617 R12: 8801c0ce2bc0 R13: 8801c0ce3cb0 R14: 8801da987dc0 R15: 8801c0ce3bc0 FS: 00b43940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c433958 CR3: 0001ae01a000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 8c433958 ---[ end trace 3b9527e7dfd4d0bc ]--- RIP: 0010:depot_fetch_stack+0x10/0x30 lib/stackdepot.c:201 Code: e8 c5 2e 47 fe e9 b3 fd ff ff e8 bb 2e 47 fe e9 55 fd ff ff 90 90 90 90 90 90 89 f8 c1 ef 11 25 ff ff 1f 00 81 e7 f0 3f 00 00 <48> 03 3c c5 60 39 43 8b 8b 47 0c 48 83 c7 18 c7 46 10 00 00 00 00 RSP: 0018:8801c0ce3a08 EFLAGS: 00010006 RAX: 001f RBX: 8801c0ce3bc4 RCX: RDX: RSI: 8801c0ce3a10 RDI: 3ff0 RBP: 8801c0ce3a38 R08: 8801b2632440 R09: ed003b5e3ec2 R10: ed003b5e3ec2 R11: 8801daf1f617 R12: 8801c0ce2bc0 R13: 8801c0ce3cb0 R14: 8801da987dc0 R15: 8801c0ce3bc0 FS: 00b43940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 8c433958 CR3: 0001ae01a000 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. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] security: export security_kernel_load_data function
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
> The firmware_loader can be built as a loadable module, which now
> fails when CONFIG_SECURITY is enabled, because a call to the
> security_kernel_load_data() function got added, and this is
> not exported to modules:
>
> ERROR: "security_kernel_load_data"
> [drivers/base/firmware_loader/firmware_class.ko] undefined!
>
> Add an EXPORT_SYMBOL_GPL() to make it available here.
>
> Fixes: 6e852651f28e ("firmware: add call to LSM hook before firmware sysfs
> fallback")
> Signed-off-by: Arnd Bergmann
Thanks!
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
next-general
--
James Morris
Re: [PATCH] security: export security_kernel_load_data function
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
> The firmware_loader can be built as a loadable module, which now
> fails when CONFIG_SECURITY is enabled, because a call to the
> security_kernel_load_data() function got added, and this is
> not exported to modules:
>
> ERROR: "security_kernel_load_data"
> [drivers/base/firmware_loader/firmware_class.ko] undefined!
>
> Add an EXPORT_SYMBOL_GPL() to make it available here.
>
> Fixes: 6e852651f28e ("firmware: add call to LSM hook before firmware sysfs
> fallback")
> Signed-off-by: Arnd Bergmann
Thanks!
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
next-general
--
James Morris
Re: [PATCH v5 05/11] clk: mediatek: add mt6765 clock IDs
Hi Matthias On Tue, 2018-07-17 at 12:24 +0200, Matthias Brugger wrote: > > On 17/07/18 10:52, Mars Cheng wrote: > > Signed-off-by: Mars Cheng > > Signed-off-by: Owen Chen > > Please provide a commit message. > > Thanks, > Matthias Got it, it is my bad, will add it. Thanks. > > > --- > > include/dt-bindings/clock/mt6765-clk.h | 313 > > > > 1 file changed, 313 insertions(+) > > create mode 100644 include/dt-bindings/clock/mt6765-clk.h > > > > diff --git a/include/dt-bindings/clock/mt6765-clk.h > > b/include/dt-bindings/clock/mt6765-clk.h > > new file mode 100644 > > index 000..eb97e56 > > --- /dev/null > > +++ b/include/dt-bindings/clock/mt6765-clk.h > > @@ -0,0 +1,313 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +#ifndef _DT_BINDINGS_CLK_MT6765_H > > +#define _DT_BINDINGS_CLK_MT6765_H > > + > > +/* FIX Clks */ > > +#define CLK_TOP_CLK26M 0 > > + > > +/* APMIXEDSYS */ > > +#define CLK_APMIXED_ARMPLL_L 0 > > +#define CLK_APMIXED_ARMPLL 1 > > +#define CLK_APMIXED_CCIPLL 2 > > +#define CLK_APMIXED_MAINPLL3 > > +#define CLK_APMIXED_MFGPLL 4 > > +#define CLK_APMIXED_MMPLL 5 > > +#define CLK_APMIXED_UNIV2PLL 6 > > +#define CLK_APMIXED_MSDCPLL7 > > +#define CLK_APMIXED_APLL1 8 > > +#define CLK_APMIXED_MPLL 9 > > +#define CLK_APMIXED_ULPOSC110 > > +#define CLK_APMIXED_ULPOSC211 > > +#define CLK_APMIXED_SSUSB26M 12 > > +#define CLK_APMIXED_APPLL26M 13 > > +#define CLK_APMIXED_MIPIC0_26M 14 > > +#define CLK_APMIXED_MDPLLGP26M 15 > > +#define CLK_APMIXED_MMSYS_F26M 16 > > +#define CLK_APMIXED_UFS26M 17 > > +#define CLK_APMIXED_MIPIC1_26M 18 > > +#define CLK_APMIXED_MEMPLL26M 19 > > +#define CLK_APMIXED_CLKSQ_LVPLL_26M20 > > +#define CLK_APMIXED_MIPID0_26M 21 > > +#define CLK_APMIXED_NR_CLK 22 > > + > > +/* TOPCKGEN */ > > +#define CLK_TOP_SYSPLL 0 > > +#define CLK_TOP_SYSPLL_D2 1 > > +#define CLK_TOP_SYSPLL1_D2 2 > > +#define CLK_TOP_SYSPLL1_D4 3 > > +#define CLK_TOP_SYSPLL1_D8 4 > > +#define CLK_TOP_SYSPLL1_D165 > > +#define CLK_TOP_SYSPLL_D3 6 > > +#define CLK_TOP_SYSPLL2_D2 7 > > +#define CLK_TOP_SYSPLL2_D4 8 > > +#define CLK_TOP_SYSPLL2_D8 9 > > +#define CLK_TOP_SYSPLL_D5 10 > > +#define CLK_TOP_SYSPLL3_D2 11 > > +#define CLK_TOP_SYSPLL3_D4 12 > > +#define CLK_TOP_SYSPLL_D7 13 > > +#define CLK_TOP_SYSPLL4_D2 14 > > +#define CLK_TOP_SYSPLL4_D4 15 > > +#define CLK_TOP_USB20_192M 16 > > +#define CLK_TOP_USB20_192M_D4 17 > > +#define CLK_TOP_USB20_192M_D8 18 > > +#define CLK_TOP_USB20_192M_D16 19 > > +#define CLK_TOP_USB20_192M_D32 20 > > +#define CLK_TOP_UNIVPLL21 > > +#define CLK_TOP_UNIVPLL_D2 22 > > +#define CLK_TOP_UNIVPLL1_D223 > > +#define CLK_TOP_UNIVPLL1_D424 > > +#define CLK_TOP_UNIVPLL_D3 25 > > +#define CLK_TOP_UNIVPLL2_D226 > > +#define CLK_TOP_UNIVPLL2_D427 > > +#define CLK_TOP_UNIVPLL2_D828 > > +#define CLK_TOP_UNIVPLL2_D32 29 > > +#define CLK_TOP_UNIVPLL_D5 30 > > +#define CLK_TOP_UNIVPLL3_D231 > > +#define CLK_TOP_UNIVPLL3_D432 > > +#define CLK_TOP_MMPLL 33 > > +#define CLK_TOP_MMPLL_D2 34 > > +#define CLK_TOP_MPLL 35 > > +#define CLK_TOP_DA_MPLL_104M_DIV 36 > > +#define CLK_TOP_DA_MPLL_52M_DIV37 > > +#define CLK_TOP_MFGPLL 38 > > +#define CLK_TOP_MSDCPLL39 > > +#define CLK_TOP_MSDCPLL_D2 40 > > +#define CLK_TOP_APLL1 41 > > +#define CLK_TOP_APLL1_D2 42 > > +#define CLK_TOP_APLL1_D4 43 > > +#define CLK_TOP_APLL1_D8 44 > > +#define CLK_TOP_ULPOSC145 > > +#define CLK_TOP_ULPOSC1_D2 46 > > +#define CLK_TOP_ULPOSC1_D4 47 > > +#define CLK_TOP_ULPOSC1_D8 48 > > +#define CLK_TOP_ULPOSC1_D1649 > > +#define CLK_TOP_ULPOSC1_D3250 > > +#define CLK_TOP_DMPLL 51 > > +#define CLK_TOP_F_FRTC 52 > > +#define CLK_TOP_F_F26M 53 > > +#define CLK_TOP_AXI54 > > +#define CLK_TOP_MM 55 > > +#define CLK_TOP_SCP56 > > +#define CLK_TOP_MFG57 > > +#define CLK_TOP_F_FUART58 > > +#define CLK_TOP_SPI59 > > +#define CLK_TOP_MSDC50_0 60 > > +#define CLK_TOP_MSDC30_1
Re: [PATCH v5 05/11] clk: mediatek: add mt6765 clock IDs
Hi Matthias On Tue, 2018-07-17 at 12:24 +0200, Matthias Brugger wrote: > > On 17/07/18 10:52, Mars Cheng wrote: > > Signed-off-by: Mars Cheng > > Signed-off-by: Owen Chen > > Please provide a commit message. > > Thanks, > Matthias Got it, it is my bad, will add it. Thanks. > > > --- > > include/dt-bindings/clock/mt6765-clk.h | 313 > > > > 1 file changed, 313 insertions(+) > > create mode 100644 include/dt-bindings/clock/mt6765-clk.h > > > > diff --git a/include/dt-bindings/clock/mt6765-clk.h > > b/include/dt-bindings/clock/mt6765-clk.h > > new file mode 100644 > > index 000..eb97e56 > > --- /dev/null > > +++ b/include/dt-bindings/clock/mt6765-clk.h > > @@ -0,0 +1,313 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > + > > +#ifndef _DT_BINDINGS_CLK_MT6765_H > > +#define _DT_BINDINGS_CLK_MT6765_H > > + > > +/* FIX Clks */ > > +#define CLK_TOP_CLK26M 0 > > + > > +/* APMIXEDSYS */ > > +#define CLK_APMIXED_ARMPLL_L 0 > > +#define CLK_APMIXED_ARMPLL 1 > > +#define CLK_APMIXED_CCIPLL 2 > > +#define CLK_APMIXED_MAINPLL3 > > +#define CLK_APMIXED_MFGPLL 4 > > +#define CLK_APMIXED_MMPLL 5 > > +#define CLK_APMIXED_UNIV2PLL 6 > > +#define CLK_APMIXED_MSDCPLL7 > > +#define CLK_APMIXED_APLL1 8 > > +#define CLK_APMIXED_MPLL 9 > > +#define CLK_APMIXED_ULPOSC110 > > +#define CLK_APMIXED_ULPOSC211 > > +#define CLK_APMIXED_SSUSB26M 12 > > +#define CLK_APMIXED_APPLL26M 13 > > +#define CLK_APMIXED_MIPIC0_26M 14 > > +#define CLK_APMIXED_MDPLLGP26M 15 > > +#define CLK_APMIXED_MMSYS_F26M 16 > > +#define CLK_APMIXED_UFS26M 17 > > +#define CLK_APMIXED_MIPIC1_26M 18 > > +#define CLK_APMIXED_MEMPLL26M 19 > > +#define CLK_APMIXED_CLKSQ_LVPLL_26M20 > > +#define CLK_APMIXED_MIPID0_26M 21 > > +#define CLK_APMIXED_NR_CLK 22 > > + > > +/* TOPCKGEN */ > > +#define CLK_TOP_SYSPLL 0 > > +#define CLK_TOP_SYSPLL_D2 1 > > +#define CLK_TOP_SYSPLL1_D2 2 > > +#define CLK_TOP_SYSPLL1_D4 3 > > +#define CLK_TOP_SYSPLL1_D8 4 > > +#define CLK_TOP_SYSPLL1_D165 > > +#define CLK_TOP_SYSPLL_D3 6 > > +#define CLK_TOP_SYSPLL2_D2 7 > > +#define CLK_TOP_SYSPLL2_D4 8 > > +#define CLK_TOP_SYSPLL2_D8 9 > > +#define CLK_TOP_SYSPLL_D5 10 > > +#define CLK_TOP_SYSPLL3_D2 11 > > +#define CLK_TOP_SYSPLL3_D4 12 > > +#define CLK_TOP_SYSPLL_D7 13 > > +#define CLK_TOP_SYSPLL4_D2 14 > > +#define CLK_TOP_SYSPLL4_D4 15 > > +#define CLK_TOP_USB20_192M 16 > > +#define CLK_TOP_USB20_192M_D4 17 > > +#define CLK_TOP_USB20_192M_D8 18 > > +#define CLK_TOP_USB20_192M_D16 19 > > +#define CLK_TOP_USB20_192M_D32 20 > > +#define CLK_TOP_UNIVPLL21 > > +#define CLK_TOP_UNIVPLL_D2 22 > > +#define CLK_TOP_UNIVPLL1_D223 > > +#define CLK_TOP_UNIVPLL1_D424 > > +#define CLK_TOP_UNIVPLL_D3 25 > > +#define CLK_TOP_UNIVPLL2_D226 > > +#define CLK_TOP_UNIVPLL2_D427 > > +#define CLK_TOP_UNIVPLL2_D828 > > +#define CLK_TOP_UNIVPLL2_D32 29 > > +#define CLK_TOP_UNIVPLL_D5 30 > > +#define CLK_TOP_UNIVPLL3_D231 > > +#define CLK_TOP_UNIVPLL3_D432 > > +#define CLK_TOP_MMPLL 33 > > +#define CLK_TOP_MMPLL_D2 34 > > +#define CLK_TOP_MPLL 35 > > +#define CLK_TOP_DA_MPLL_104M_DIV 36 > > +#define CLK_TOP_DA_MPLL_52M_DIV37 > > +#define CLK_TOP_MFGPLL 38 > > +#define CLK_TOP_MSDCPLL39 > > +#define CLK_TOP_MSDCPLL_D2 40 > > +#define CLK_TOP_APLL1 41 > > +#define CLK_TOP_APLL1_D2 42 > > +#define CLK_TOP_APLL1_D4 43 > > +#define CLK_TOP_APLL1_D8 44 > > +#define CLK_TOP_ULPOSC145 > > +#define CLK_TOP_ULPOSC1_D2 46 > > +#define CLK_TOP_ULPOSC1_D4 47 > > +#define CLK_TOP_ULPOSC1_D8 48 > > +#define CLK_TOP_ULPOSC1_D1649 > > +#define CLK_TOP_ULPOSC1_D3250 > > +#define CLK_TOP_DMPLL 51 > > +#define CLK_TOP_F_FRTC 52 > > +#define CLK_TOP_F_F26M 53 > > +#define CLK_TOP_AXI54 > > +#define CLK_TOP_MM 55 > > +#define CLK_TOP_SCP56 > > +#define CLK_TOP_MFG57 > > +#define CLK_TOP_F_FUART58 > > +#define CLK_TOP_SPI59 > > +#define CLK_TOP_MSDC50_0 60 > > +#define CLK_TOP_MSDC30_1
Re: [PATCH] drivers: fpga: fix two trivial spelling mistakes
On Tue, Jul 17, 2018 at 10:21:38AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trival fix to two spellling mistakes
Thank you very much for this fixing. Only one minor thing here.
s/Trival/Trivial/
s/spellling/spelling/
Thanks
Hao
> "execeeded" -> "exceeded"
> "Invaild" -> "Invalid"
>
> Signed-off-by: Colin Ian King
> ---
> drivers/fpga/dfl-afu-dma-region.c | 2 +-
> drivers/fpga/dfl-fme-mgr.c| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/dfl-afu-dma-region.c
> b/drivers/fpga/dfl-afu-dma-region.c
> index 0e81d33af856..025aba3ea76c 100644
> --- a/drivers/fpga/dfl-afu-dma-region.c
> +++ b/drivers/fpga/dfl-afu-dma-region.c
> @@ -70,7 +70,7 @@ static int afu_dma_adjust_locked_vm(struct device *dev,
> long npages, bool incr)
> dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> incr ? '+' : '-', npages << PAGE_SHIFT,
> current->mm->locked_vm << PAGE_SHIFT, rlimit(RLIMIT_MEMLOCK),
> - ret ? "- execeeded" : "");
> + ret ? "- exceeded" : "");
>
> up_write(>mm->mmap_sem);
>
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index b5ef405b6d88..9f045d058cfd 100644
> --- a/drivers/fpga/dfl-fme-mgr.c
> +++ b/drivers/fpga/dfl-fme-mgr.c
> @@ -201,7 +201,7 @@ static int fme_mgr_write(struct fpga_manager *mgr,
> }
>
> if (count < 4) {
> - dev_err(dev, "Invaild PR bitstream size\n");
> + dev_err(dev, "Invalid PR bitstream size\n");
> return -EINVAL;
> }
>
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
(cc linux-mm) On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote: > Hi > > I've run into an odd performance issue in the kernel, and not being a > kernel dev or knowing terribly much about cgroups, am looking for > advice on diagnosing the problem further (I discovered this while > trying to pin down high CPU load in cadvisor). > > On some machines in our production system, cat > /sys/fs/cgroup/memory/memory.stat is extremely slow (500ms on one > machine), while on other nominally identical machines it is fast > (2ms). > > One other thing I've noticed is that the affected machines generally > have much larger values for SUnreclaim in /proc/memstat (up to several > GB), and slabtop reports >1GB of dentry. > > Before I tracked the original problem (high CPU usage in cadvisor) > down to this, I rebooted one of the machines and the original problem > went away, so it seems to be cleared by a reboot; I'm reluctant to > reboot more machines to confirm since I don't have a sure-fire way to > reproduce the problem again to debug it. > > The machines are running Ubuntu 16.04 with kernel 4.13.0-41-generic. > They're running Docker, which creates a bunch of cgroups, but not an > excessive number: there are 106 memory.stat files in > /sys/fs/cgroup/memory. > > Digging a bit further, cat > /sys/fs/cgroup/memory/system.slice/memory.stat also takes ~500ms, but > "find /sys/fs/cgroup/memory/system.slice -mindepth 2 -name memory.stat > | xargs cat" takes only 8ms. > > Any thoughts, particularly on what I should compare between the good > and bad machines to narrow down the cause, or even better, how to > prevent it happening? > > Thanks > Bruce > -- > Bruce Merry > Senior Science Processing Developer > SKA South Africa
Re: [PATCH] drivers: fpga: fix two trivial spelling mistakes
On Tue, Jul 17, 2018 at 10:21:38AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trival fix to two spellling mistakes
Thank you very much for this fixing. Only one minor thing here.
s/Trival/Trivial/
s/spellling/spelling/
Thanks
Hao
> "execeeded" -> "exceeded"
> "Invaild" -> "Invalid"
>
> Signed-off-by: Colin Ian King
> ---
> drivers/fpga/dfl-afu-dma-region.c | 2 +-
> drivers/fpga/dfl-fme-mgr.c| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/dfl-afu-dma-region.c
> b/drivers/fpga/dfl-afu-dma-region.c
> index 0e81d33af856..025aba3ea76c 100644
> --- a/drivers/fpga/dfl-afu-dma-region.c
> +++ b/drivers/fpga/dfl-afu-dma-region.c
> @@ -70,7 +70,7 @@ static int afu_dma_adjust_locked_vm(struct device *dev,
> long npages, bool incr)
> dev_dbg(dev, "[%d] RLIMIT_MEMLOCK %c%ld %ld/%ld%s\n", current->pid,
> incr ? '+' : '-', npages << PAGE_SHIFT,
> current->mm->locked_vm << PAGE_SHIFT, rlimit(RLIMIT_MEMLOCK),
> - ret ? "- execeeded" : "");
> + ret ? "- exceeded" : "");
>
> up_write(>mm->mmap_sem);
>
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index b5ef405b6d88..9f045d058cfd 100644
> --- a/drivers/fpga/dfl-fme-mgr.c
> +++ b/drivers/fpga/dfl-fme-mgr.c
> @@ -201,7 +201,7 @@ static int fme_mgr_write(struct fpga_manager *mgr,
> }
>
> if (count < 4) {
> - dev_err(dev, "Invaild PR bitstream size\n");
> + dev_err(dev, "Invalid PR bitstream size\n");
> return -EINVAL;
> }
>
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Showing /sys/fs/cgroup/memory/memory.stat very slow on some machines
(cc linux-mm) On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote: > Hi > > I've run into an odd performance issue in the kernel, and not being a > kernel dev or knowing terribly much about cgroups, am looking for > advice on diagnosing the problem further (I discovered this while > trying to pin down high CPU load in cadvisor). > > On some machines in our production system, cat > /sys/fs/cgroup/memory/memory.stat is extremely slow (500ms on one > machine), while on other nominally identical machines it is fast > (2ms). > > One other thing I've noticed is that the affected machines generally > have much larger values for SUnreclaim in /proc/memstat (up to several > GB), and slabtop reports >1GB of dentry. > > Before I tracked the original problem (high CPU usage in cadvisor) > down to this, I rebooted one of the machines and the original problem > went away, so it seems to be cleared by a reboot; I'm reluctant to > reboot more machines to confirm since I don't have a sure-fire way to > reproduce the problem again to debug it. > > The machines are running Ubuntu 16.04 with kernel 4.13.0-41-generic. > They're running Docker, which creates a bunch of cgroups, but not an > excessive number: there are 106 memory.stat files in > /sys/fs/cgroup/memory. > > Digging a bit further, cat > /sys/fs/cgroup/memory/system.slice/memory.stat also takes ~500ms, but > "find /sys/fs/cgroup/memory/system.slice -mindepth 2 -name memory.stat > | xargs cat" takes only 8ms. > > Any thoughts, particularly on what I should compare between the good > and bad machines to narrow down the cause, or even better, how to > prevent it happening? > > Thanks > Bruce > -- > Bruce Merry > Senior Science Processing Developer > SKA South Africa
Re: [PATCH -next] ipc/sem: prevent queue.status tearing in semop
Hello Davidlohr,
On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
What is the background of the above rule?
sma->use_global_lock is sometimes used with smp_load_acquire(),
sometimes without.
So far, I assumed that this is safe.
The same applies for nf_conntrack_locks_all, in nf_conntrack_all_lock()
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 6cbbf34a44ac..ccab4e51d351 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2125,7 +2125,7 @@ static long do_semtimedop(int semid, struct sembuf __user
*tsops,
}
do {
- queue.status = -EINTR;
+ WRITE_ONCE(queue.status, -EINTR);
queue.sleeper = current;
__set_current_state(TASK_INTERRUPTIBLE);
Re: [PATCH -next] ipc/sem: prevent queue.status tearing in semop
Hello Davidlohr,
On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
What is the background of the above rule?
sma->use_global_lock is sometimes used with smp_load_acquire(),
sometimes without.
So far, I assumed that this is safe.
The same applies for nf_conntrack_locks_all, in nf_conntrack_all_lock()
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 6cbbf34a44ac..ccab4e51d351 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -2125,7 +2125,7 @@ static long do_semtimedop(int semid, struct sembuf __user
*tsops,
}
do {
- queue.status = -EINTR;
+ WRITE_ONCE(queue.status, -EINTR);
queue.sleeper = current;
__set_current_state(TASK_INTERRUPTIBLE);
Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray wrote: > This patch introduces the Generic Counter interface for supporting > counter devices. > +EXPORT_SYMBOL(count_direction_str); +EXPORT_SYMBOL(count_mode_str); +EXPORT_SYMBOL(counter_signal_enum_read); +EXPORT_SYMBOL(counter_signal_enum_write); +EXPORT_SYMBOL(counter_signal_enum_available_read); +EXPORT_SYMBOL(counter_count_enum_read); +EXPORT_SYMBOL(counter_count_enum_write); +EXPORT_SYMBOL(counter_count_enum_available_read); +EXPORT_SYMBOL(counter_device_enum_read); +EXPORT_SYMBOL(counter_device_enum_write); +EXPORT_SYMBOL(counter_device_enum_available_read); +EXPORT_SYMBOL(signal_read_value_set); +EXPORT_SYMBOL(count_read_value_set); +EXPORT_SYMBOL(count_write_value_get); +EXPORT_SYMBOL(counter_register); +EXPORT_SYMBOL(counter_unregister); +EXPORT_SYMBOL(devm_counter_register); +EXPORT_SYMBOL(devm_counter_unregister); The naming is a bit chaotic. Most of the symbols start with counter_, which is good. But a handful do not. Also, symbols called signal_* make my head spin - Linux already has a firmly ingrained notion of what a signal is, and this ain't it ;) Although the kernel tends to use sig_ for signals-as-an-IPC-thing. Also, many many drivers deal with signals-as-an-electrical-thing - is it appropriate for this particular driver to take that namespace?
Re: [PATCH v7 01/10] counter: Introduce the Generic Counter interface
On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray wrote: > This patch introduces the Generic Counter interface for supporting > counter devices. > +EXPORT_SYMBOL(count_direction_str); +EXPORT_SYMBOL(count_mode_str); +EXPORT_SYMBOL(counter_signal_enum_read); +EXPORT_SYMBOL(counter_signal_enum_write); +EXPORT_SYMBOL(counter_signal_enum_available_read); +EXPORT_SYMBOL(counter_count_enum_read); +EXPORT_SYMBOL(counter_count_enum_write); +EXPORT_SYMBOL(counter_count_enum_available_read); +EXPORT_SYMBOL(counter_device_enum_read); +EXPORT_SYMBOL(counter_device_enum_write); +EXPORT_SYMBOL(counter_device_enum_available_read); +EXPORT_SYMBOL(signal_read_value_set); +EXPORT_SYMBOL(count_read_value_set); +EXPORT_SYMBOL(count_write_value_get); +EXPORT_SYMBOL(counter_register); +EXPORT_SYMBOL(counter_unregister); +EXPORT_SYMBOL(devm_counter_register); +EXPORT_SYMBOL(devm_counter_unregister); The naming is a bit chaotic. Most of the symbols start with counter_, which is good. But a handful do not. Also, symbols called signal_* make my head spin - Linux already has a firmly ingrained notion of what a signal is, and this ain't it ;) Although the kernel tends to use sig_ for signals-as-an-IPC-thing. Also, many many drivers deal with signals-as-an-electrical-thing - is it appropriate for this particular driver to take that namespace?
Re: [PATCH] net/9p/trans_virtio.c: fix some spell mistakes in comments
piaojun wrote on Wed, Jul 18, 2018: > Fix spelling mistake in comments of p9_virtio_zc_request(). > > Signed-off-by: Jun Piao Thanks, queued it. > --- > net/9p/trans_virtio.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c > index c9f2717..86077f7 100644 > --- a/net/9p/trans_virtio.c > +++ b/net/9p/trans_virtio.c > @@ -384,8 +384,8 @@ static int p9_get_mapped_pages(struct virtio_chan *chan, > * p9_virtio_zc_request - issue a zero copy request > * @client: client instance issuing the request > * @req: request to be issued > - * @uidata: user bffer that should be ued for zero copy read > - * @uodata: user buffer that shoud be user for zero copy write > + * @uidata: user buffer that should be used for zero copy read > + * @uodata: user buffer that should be used for zero copy write > * @inlen: read buffer size > * @outlen: write buffer size > * @in_hdr_len: reader header size, This is the size of response protocol > data -- Dominique Martinet
Re: [PATCH] net/9p/trans_virtio.c: fix some spell mistakes in comments
piaojun wrote on Wed, Jul 18, 2018: > Fix spelling mistake in comments of p9_virtio_zc_request(). > > Signed-off-by: Jun Piao Thanks, queued it. > --- > net/9p/trans_virtio.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c > index c9f2717..86077f7 100644 > --- a/net/9p/trans_virtio.c > +++ b/net/9p/trans_virtio.c > @@ -384,8 +384,8 @@ static int p9_get_mapped_pages(struct virtio_chan *chan, > * p9_virtio_zc_request - issue a zero copy request > * @client: client instance issuing the request > * @req: request to be issued > - * @uidata: user bffer that should be ued for zero copy read > - * @uodata: user buffer that shoud be user for zero copy write > + * @uidata: user buffer that should be used for zero copy read > + * @uodata: user buffer that should be used for zero copy write > * @inlen: read buffer size > * @outlen: write buffer size > * @in_hdr_len: reader header size, This is the size of response protocol > data -- Dominique Martinet
[PATCH] net/9p/trans_virtio.c: fix some spell mistakes in comments
Fix spelling mistake in comments of p9_virtio_zc_request(). Signed-off-by: Jun Piao --- net/9p/trans_virtio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index c9f2717..86077f7 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -384,8 +384,8 @@ static int p9_get_mapped_pages(struct virtio_chan *chan, * p9_virtio_zc_request - issue a zero copy request * @client: client instance issuing the request * @req: request to be issued - * @uidata: user bffer that should be ued for zero copy read - * @uodata: user buffer that shoud be user for zero copy write + * @uidata: user buffer that should be used for zero copy read + * @uodata: user buffer that should be used for zero copy write * @inlen: read buffer size * @outlen: write buffer size * @in_hdr_len: reader header size, This is the size of response protocol data --
[PATCH] net/9p/trans_virtio.c: fix some spell mistakes in comments
Fix spelling mistake in comments of p9_virtio_zc_request(). Signed-off-by: Jun Piao --- net/9p/trans_virtio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c index c9f2717..86077f7 100644 --- a/net/9p/trans_virtio.c +++ b/net/9p/trans_virtio.c @@ -384,8 +384,8 @@ static int p9_get_mapped_pages(struct virtio_chan *chan, * p9_virtio_zc_request - issue a zero copy request * @client: client instance issuing the request * @req: request to be issued - * @uidata: user bffer that should be ued for zero copy read - * @uodata: user buffer that shoud be user for zero copy write + * @uidata: user buffer that should be used for zero copy read + * @uodata: user buffer that should be used for zero copy write * @inlen: read buffer size * @outlen: write buffer size * @in_hdr_len: reader header size, This is the size of response protocol data --
Re: [PATCH v7 2/7] thermal: tsens: Add support to split up register address space into two
On Wed, Jul 18, 2018 at 4:59 AM Matthias Kaehlcke wrote:
>
> On Thu, Jul 12, 2018 at 02:09:03PM +0530, Amit Kucheria wrote:
> > There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
> > SoCs these were contiguous, leading to DTs mapping them as one register
> > address space of size 0x2000. In newer SoCs, these two banks are not
> > contiguous anymore.
> >
> > Add logic to init_common() to differentiate between old and new DTs and
> > adjust associated offsets for the TM register bank so that the old DTs will
> > continue to function correctly.
> >
> > Signed-off-by: Amit Kucheria
> > Reviewed-by: Bjorn Andersson
> > Tested-by: Matthias Kaehlcke
> > ---
> > drivers/thermal/qcom/tsens-8996.c | 4 ++--
> > drivers/thermal/qcom/tsens-common.c | 12
> > drivers/thermal/qcom/tsens.h| 1 +
> > 3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-8996.c
> > b/drivers/thermal/qcom/tsens-8996.c
> > index e1f7781..3e60cec 100644
> > --- a/drivers/thermal/qcom/tsens-8996.c
> > +++ b/drivers/thermal/qcom/tsens-8996.c
> > @@ -16,7 +16,7 @@
> > #include
> > #include "tsens.h"
> >
> > -#define STATUS_OFFSET0x10a0
> > +#define STATUS_OFFSET0xa0
> > #define LAST_TEMP_MASK 0xfff
> > #define STATUS_VALID_BIT BIT(21)
> > #define CODE_SIGN_BITBIT(11)
> > @@ -28,7 +28,7 @@ static int get_temp_8996(struct tsens_device *tmdev, int
> > id, int *temp)
> > unsigned int sensor_addr;
> > int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> >
> > - sensor_addr = STATUS_OFFSET + s->hw_id * 4;
> > + sensor_addr = tmdev->tm_offset + STATUS_OFFSET + s->hw_id * 4;
> > ret = regmap_read(tmdev->map, sensor_addr, );
> > if (ret)
> > return ret;
> > diff --git a/drivers/thermal/qcom/tsens-common.c
> > b/drivers/thermal/qcom/tsens-common.c
> > index b1449ad..c22dc18 100644
> > --- a/drivers/thermal/qcom/tsens-common.c
> > +++ b/drivers/thermal/qcom/tsens-common.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "tsens.h"
> > @@ -126,11 +127,22 @@ static const struct regmap_config tsens_config = {
> > int __init init_common(struct tsens_device *tmdev)
> > {
> > void __iomem *base;
> > + struct platform_device *op =
> > of_find_device_by_node(tmdev->dev->of_node);
> >
> > + if (!op)
> > + return -EINVAL;
> > base = of_iomap(tmdev->dev->of_node, 0);
> > if (!base)
> > return -EINVAL;
> >
> > + /* The driver only uses the TM register address space for now */
> > + if (op->num_resources > 1) {
> > + tmdev->tm_offset = 0;
> > + } else {
> > + /* old DTs where SROT and TM were in a contiguous 2K block */
> > + tmdev->tm_offset = 0x1000;
> > + }
>
> nit: no curly braces for conditionals with a single statement. There
> is probably no need to respin just for this though.
Yeah, that was leftover from refactoring because I have an upcoming
patch that adds SROT mapping inside those braces. I'm about to post it
soon.
> Reviewed-by: Matthias Kaehlcke
Re: [PATCH v7 2/7] thermal: tsens: Add support to split up register address space into two
On Wed, Jul 18, 2018 at 4:59 AM Matthias Kaehlcke wrote:
>
> On Thu, Jul 12, 2018 at 02:09:03PM +0530, Amit Kucheria wrote:
> > There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
> > SoCs these were contiguous, leading to DTs mapping them as one register
> > address space of size 0x2000. In newer SoCs, these two banks are not
> > contiguous anymore.
> >
> > Add logic to init_common() to differentiate between old and new DTs and
> > adjust associated offsets for the TM register bank so that the old DTs will
> > continue to function correctly.
> >
> > Signed-off-by: Amit Kucheria
> > Reviewed-by: Bjorn Andersson
> > Tested-by: Matthias Kaehlcke
> > ---
> > drivers/thermal/qcom/tsens-8996.c | 4 ++--
> > drivers/thermal/qcom/tsens-common.c | 12
> > drivers/thermal/qcom/tsens.h| 1 +
> > 3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-8996.c
> > b/drivers/thermal/qcom/tsens-8996.c
> > index e1f7781..3e60cec 100644
> > --- a/drivers/thermal/qcom/tsens-8996.c
> > +++ b/drivers/thermal/qcom/tsens-8996.c
> > @@ -16,7 +16,7 @@
> > #include
> > #include "tsens.h"
> >
> > -#define STATUS_OFFSET0x10a0
> > +#define STATUS_OFFSET0xa0
> > #define LAST_TEMP_MASK 0xfff
> > #define STATUS_VALID_BIT BIT(21)
> > #define CODE_SIGN_BITBIT(11)
> > @@ -28,7 +28,7 @@ static int get_temp_8996(struct tsens_device *tmdev, int
> > id, int *temp)
> > unsigned int sensor_addr;
> > int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> >
> > - sensor_addr = STATUS_OFFSET + s->hw_id * 4;
> > + sensor_addr = tmdev->tm_offset + STATUS_OFFSET + s->hw_id * 4;
> > ret = regmap_read(tmdev->map, sensor_addr, );
> > if (ret)
> > return ret;
> > diff --git a/drivers/thermal/qcom/tsens-common.c
> > b/drivers/thermal/qcom/tsens-common.c
> > index b1449ad..c22dc18 100644
> > --- a/drivers/thermal/qcom/tsens-common.c
> > +++ b/drivers/thermal/qcom/tsens-common.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include "tsens.h"
> > @@ -126,11 +127,22 @@ static const struct regmap_config tsens_config = {
> > int __init init_common(struct tsens_device *tmdev)
> > {
> > void __iomem *base;
> > + struct platform_device *op =
> > of_find_device_by_node(tmdev->dev->of_node);
> >
> > + if (!op)
> > + return -EINVAL;
> > base = of_iomap(tmdev->dev->of_node, 0);
> > if (!base)
> > return -EINVAL;
> >
> > + /* The driver only uses the TM register address space for now */
> > + if (op->num_resources > 1) {
> > + tmdev->tm_offset = 0;
> > + } else {
> > + /* old DTs where SROT and TM were in a contiguous 2K block */
> > + tmdev->tm_offset = 0x1000;
> > + }
>
> nit: no curly braces for conditionals with a single statement. There
> is probably no need to respin just for this though.
Yeah, that was leftover from refactoring because I have an upcoming
patch that adds SROT mapping inside those braces. I'm about to post it
soon.
> Reviewed-by: Matthias Kaehlcke
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, Jul 17, 2018 at 08:27:53PM -0700, Andrew Morton wrote: > On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote: > > > > > --- a/fs/proc/kcore.c > > > > +++ b/fs/proc/kcore.c > > > > @@ -59,8 +59,8 @@ struct memelfnote > > > > }; > > > > > > > > static LIST_HEAD(kclist_head); > > > > -static DEFINE_RWLOCK(kclist_lock); > > > > -static int kcore_need_update = 1; > > > > +static DECLARE_RWSEM(kclist_lock); > > > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > > > > > It's unclear why kcore_need_update was changed to atomic_t - it's still > > > updated under kclist_lock? > > > > Not in the hotplug notifier (kcore_callback()) anymore, so I need the > > atomic_cmpxchg() in __kcore_update_ram(). > > Well that's just > > kcore_need_update = 1; > > and turning that into an atomic_set doesn't change anything(?). > > It's not a harmful change of course, but a bit ... odd. The change from read, ..., write to cmpxchg in __kcore_update_ram() is the important part, not the change from = to atomic_set(). I needed to change that because now kcore_need_update could potentially be set again by the hotplug notifier while we're in __kcore_update_ram(). But I'll just put all of this in the commit message in v3 :) > > That could use a mention in the commit message. > > That never hurts ;)
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, Jul 17, 2018 at 08:27:53PM -0700, Andrew Morton wrote: > On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote: > > > > > --- a/fs/proc/kcore.c > > > > +++ b/fs/proc/kcore.c > > > > @@ -59,8 +59,8 @@ struct memelfnote > > > > }; > > > > > > > > static LIST_HEAD(kclist_head); > > > > -static DEFINE_RWLOCK(kclist_lock); > > > > -static int kcore_need_update = 1; > > > > +static DECLARE_RWSEM(kclist_lock); > > > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > > > > > It's unclear why kcore_need_update was changed to atomic_t - it's still > > > updated under kclist_lock? > > > > Not in the hotplug notifier (kcore_callback()) anymore, so I need the > > atomic_cmpxchg() in __kcore_update_ram(). > > Well that's just > > kcore_need_update = 1; > > and turning that into an atomic_set doesn't change anything(?). > > It's not a harmful change of course, but a bit ... odd. The change from read, ..., write to cmpxchg in __kcore_update_ram() is the important part, not the change from = to atomic_set(). I needed to change that because now kcore_need_update could potentially be set again by the hotplug notifier while we're in __kcore_update_ram(). But I'll just put all of this in the commit message in v3 :) > > That could use a mention in the commit message. > > That never hurts ;)
Re: vfs / overlayfs conflict resolution for linux-next
Hi Al, On Wed, 18 Jul 2018 03:56:37 +0100 Al Viro wrote: > > ... and now it even builds. Said that, I would really like to hear something > from you - I can duplicate the entire overlayfs-next and merge it into > my #for-next and ask Steven to use that instead of your tree, but I very > much dislike going over your head like that. > > I realize that you'd been away for a while and probably are digging yourself > from under the piles of mail, but it's getting late in the cycle and I want > to get #for-next into reasonably sane shape. Please, look through that > thing and respond. Almost everything has been removed from the overlayfs tree in linux-next today. The only commit there currently is: 67810693077a ovl: fix wrong use of impure dir cache in ovl_iterate() -- Cheers, Stephen Rothwell pgpEJKdnBgr7t.pgp Description: OpenPGP digital signature
Re: vfs / overlayfs conflict resolution for linux-next
Hi Al, On Wed, 18 Jul 2018 03:56:37 +0100 Al Viro wrote: > > ... and now it even builds. Said that, I would really like to hear something > from you - I can duplicate the entire overlayfs-next and merge it into > my #for-next and ask Steven to use that instead of your tree, but I very > much dislike going over your head like that. > > I realize that you'd been away for a while and probably are digging yourself > from under the piles of mail, but it's getting late in the cycle and I want > to get #for-next into reasonably sane shape. Please, look through that > thing and respond. Almost everything has been removed from the overlayfs tree in linux-next today. The only commit there currently is: 67810693077a ovl: fix wrong use of impure dir cache in ovl_iterate() -- Cheers, Stephen Rothwell pgpEJKdnBgr7t.pgp Description: OpenPGP digital signature
Re: [PATCH v2 7/7] proc/kcore: add vmcoreinfo note to /proc/kcore
On Tue, Jul 17, 2018 at 07:44:21PM -0700, Andrew Morton wrote: > On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote: > > > From: Omar Sandoval > > > > The vmcoreinfo information is useful for runtime debugging tools, not > > just for crash dumps. A lot of this information can be determined by > > other means, but this is much more convenient. > > > > What effect does this have upon the overall size of the dump file? About 2 kB on my machine, and no more than one page + the few bytes of extra headers.
[PATCH net-next v2 2/2] docs: networking: Convert bridge.txt to rst
The kernel documentation is now restructured text. Convert the Ethernet
Bridge documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Add license identifier.
Signed-off-by: Tobin C. Harding
---
Documentation/networking/{bridge.txt => bridge.rst} | 6 ++
Documentation/networking/index.rst | 1 +
2 files changed, 7 insertions(+)
rename Documentation/networking/{bridge.txt => bridge.rst} (85%)
diff --git a/Documentation/networking/bridge.txt
b/Documentation/networking/bridge.rst
similarity index 85%
rename from Documentation/networking/bridge.txt
rename to Documentation/networking/bridge.rst
index a27cb6214ed7..4aef9cddde2f 100644
--- a/Documentation/networking/bridge.txt
+++ b/Documentation/networking/bridge.rst
@@ -1,3 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Ethernet Bridging
+=
+
In order to use the Ethernet bridging functionality, you'll need the
userspace tools.
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 65502f2031a8..d75da2ff25c7 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -18,6 +18,7 @@ Contents:
failover
net_failover
alias
+ bridge
.. only:: subproject
--
2.17.1
[PATCH net-next v2 1/2] docs: networking: Convert alias.txt to rst
The kernel documentation is now restructured text. Convert the IP aliasing documentation and include it in the toplevel kernel documentation. - Fix heading adornments. - Correctly indent code snippets. - Limit line length to 72 characters inline with kernel documentation standards. - Add license identifier. Signed-off-by: Tobin C. Harding --- Documentation/networking/00-INDEX | 2 -- Documentation/networking/alias.rst | 49 ++ Documentation/networking/alias.txt | 40 Documentation/networking/index.rst | 1 + 4 files changed, 50 insertions(+), 42 deletions(-) create mode 100644 Documentation/networking/alias.rst delete mode 100644 Documentation/networking/alias.txt diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 2b89d91b376f..1e5153ed8990 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -18,8 +18,6 @@ README.ipw2200 - README for the Intel PRO/Wireless 2915ABG and 2200BG driver. README.sb1000 - info on General Instrument/NextLevel SURFboard1000 cable modem. -alias.txt - - info on using alias network devices. altera_tse.txt - Altera Triple-Speed Ethernet controller. arcnet-hardware.txt diff --git a/Documentation/networking/alias.rst b/Documentation/networking/alias.rst new file mode 100644 index ..af7c5ee92014 --- /dev/null +++ b/Documentation/networking/alias.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +IP-Aliasing +=== + +IP-aliases are an obsolete way to manage multiple IP-addresses/masks +per interface. Newer tools such as iproute2 support multiple +address/prefixes per interface, but aliases are still supported +for backwards compatibility. + +An alias is formed by adding a colon and a string when running ifconfig. +This string is usually numeric, but this is not a must. + + +Alias creation +== + +Alias creation is done by 'magic' interface naming: eg. to create a +200.1.1.1 alias for eth0 ... +:: + + # ifconfig eth0:0 200.1.1.1 etc,etc + ~~ -> request alias #0 creation (if not yet exists) for eth0 + +The corresponding route is also set up by this command. Please note: +The route always points to the base interface. + + +Alias deletion +== + +The alias is removed by shutting the alias down:: + + # ifconfig eth0:0 down + ~~ -> will delete alias + + +Alias (re-)configuring +== + +Aliases are not real devices, but programs should be able to configure +and refer to them as usual (ifconfig, route, etc). + + +Relationship with main device += + +If the base device is shut down the added aliases will be deleted too. diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt deleted file mode 100644 index 85046f53fcfc.. --- a/Documentation/networking/alias.txt +++ /dev/null @@ -1,40 +0,0 @@ - -IP-Aliasing: - - -IP-aliases are an obsolete way to manage multiple IP-addresses/masks -per interface. Newer tools such as iproute2 support multiple -address/prefixes per interface, but aliases are still supported -for backwards compatibility. - -An alias is formed by adding a colon and a string when running ifconfig. -This string is usually numeric, but this is not a must. - -o Alias creation. - Alias creation is done by 'magic' interface naming: eg. to create a - 200.1.1.1 alias for eth0 ... - -# ifconfig eth0:0 200.1.1.1 etc,etc - ~~ -> request alias #0 creation (if not yet exists) for eth0 - -The corresponding route is also set up by this command. -Please note: The route always points to the base interface. - - -o Alias deletion. - The alias is removed by shutting the alias down: - -# ifconfig eth0:0 down - ~~ -> will delete alias - - -o Alias (re-)configuring - - Aliases are not real devices, but programs should be able to configure and - refer to them as usual (ifconfig, route, etc). - - -o Relationship with main device - - If the base device is shut down the added aliases will be deleted - too. diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index a4bbde70bcb9..65502f2031a8 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -17,6 +17,7 @@ Contents: msg_zerocopy failover net_failover + alias .. only:: subproject -- 2.17.1
Re: [PATCH v2 7/7] proc/kcore: add vmcoreinfo note to /proc/kcore
On Tue, Jul 17, 2018 at 07:44:21PM -0700, Andrew Morton wrote: > On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote: > > > From: Omar Sandoval > > > > The vmcoreinfo information is useful for runtime debugging tools, not > > just for crash dumps. A lot of this information can be determined by > > other means, but this is much more convenient. > > > > What effect does this have upon the overall size of the dump file? About 2 kB on my machine, and no more than one page + the few bytes of extra headers.
[PATCH net-next v2 2/2] docs: networking: Convert bridge.txt to rst
The kernel documentation is now restructured text. Convert the Ethernet
Bridge documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Add license identifier.
Signed-off-by: Tobin C. Harding
---
Documentation/networking/{bridge.txt => bridge.rst} | 6 ++
Documentation/networking/index.rst | 1 +
2 files changed, 7 insertions(+)
rename Documentation/networking/{bridge.txt => bridge.rst} (85%)
diff --git a/Documentation/networking/bridge.txt
b/Documentation/networking/bridge.rst
similarity index 85%
rename from Documentation/networking/bridge.txt
rename to Documentation/networking/bridge.rst
index a27cb6214ed7..4aef9cddde2f 100644
--- a/Documentation/networking/bridge.txt
+++ b/Documentation/networking/bridge.rst
@@ -1,3 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Ethernet Bridging
+=
+
In order to use the Ethernet bridging functionality, you'll need the
userspace tools.
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 65502f2031a8..d75da2ff25c7 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -18,6 +18,7 @@ Contents:
failover
net_failover
alias
+ bridge
.. only:: subproject
--
2.17.1
[PATCH net-next v2 1/2] docs: networking: Convert alias.txt to rst
The kernel documentation is now restructured text. Convert the IP aliasing documentation and include it in the toplevel kernel documentation. - Fix heading adornments. - Correctly indent code snippets. - Limit line length to 72 characters inline with kernel documentation standards. - Add license identifier. Signed-off-by: Tobin C. Harding --- Documentation/networking/00-INDEX | 2 -- Documentation/networking/alias.rst | 49 ++ Documentation/networking/alias.txt | 40 Documentation/networking/index.rst | 1 + 4 files changed, 50 insertions(+), 42 deletions(-) create mode 100644 Documentation/networking/alias.rst delete mode 100644 Documentation/networking/alias.txt diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 2b89d91b376f..1e5153ed8990 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -18,8 +18,6 @@ README.ipw2200 - README for the Intel PRO/Wireless 2915ABG and 2200BG driver. README.sb1000 - info on General Instrument/NextLevel SURFboard1000 cable modem. -alias.txt - - info on using alias network devices. altera_tse.txt - Altera Triple-Speed Ethernet controller. arcnet-hardware.txt diff --git a/Documentation/networking/alias.rst b/Documentation/networking/alias.rst new file mode 100644 index ..af7c5ee92014 --- /dev/null +++ b/Documentation/networking/alias.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +IP-Aliasing +=== + +IP-aliases are an obsolete way to manage multiple IP-addresses/masks +per interface. Newer tools such as iproute2 support multiple +address/prefixes per interface, but aliases are still supported +for backwards compatibility. + +An alias is formed by adding a colon and a string when running ifconfig. +This string is usually numeric, but this is not a must. + + +Alias creation +== + +Alias creation is done by 'magic' interface naming: eg. to create a +200.1.1.1 alias for eth0 ... +:: + + # ifconfig eth0:0 200.1.1.1 etc,etc + ~~ -> request alias #0 creation (if not yet exists) for eth0 + +The corresponding route is also set up by this command. Please note: +The route always points to the base interface. + + +Alias deletion +== + +The alias is removed by shutting the alias down:: + + # ifconfig eth0:0 down + ~~ -> will delete alias + + +Alias (re-)configuring +== + +Aliases are not real devices, but programs should be able to configure +and refer to them as usual (ifconfig, route, etc). + + +Relationship with main device += + +If the base device is shut down the added aliases will be deleted too. diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt deleted file mode 100644 index 85046f53fcfc.. --- a/Documentation/networking/alias.txt +++ /dev/null @@ -1,40 +0,0 @@ - -IP-Aliasing: - - -IP-aliases are an obsolete way to manage multiple IP-addresses/masks -per interface. Newer tools such as iproute2 support multiple -address/prefixes per interface, but aliases are still supported -for backwards compatibility. - -An alias is formed by adding a colon and a string when running ifconfig. -This string is usually numeric, but this is not a must. - -o Alias creation. - Alias creation is done by 'magic' interface naming: eg. to create a - 200.1.1.1 alias for eth0 ... - -# ifconfig eth0:0 200.1.1.1 etc,etc - ~~ -> request alias #0 creation (if not yet exists) for eth0 - -The corresponding route is also set up by this command. -Please note: The route always points to the base interface. - - -o Alias deletion. - The alias is removed by shutting the alias down: - -# ifconfig eth0:0 down - ~~ -> will delete alias - - -o Alias (re-)configuring - - Aliases are not real devices, but programs should be able to configure and - refer to them as usual (ifconfig, route, etc). - - -o Relationship with main device - - If the base device is shut down the added aliases will be deleted - too. diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index a4bbde70bcb9..65502f2031a8 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -17,6 +17,7 @@ Contents: msg_zerocopy failover net_failover + alias .. only:: subproject -- 2.17.1
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote: > > > --- a/fs/proc/kcore.c > > > +++ b/fs/proc/kcore.c > > > @@ -59,8 +59,8 @@ struct memelfnote > > > }; > > > > > > static LIST_HEAD(kclist_head); > > > -static DEFINE_RWLOCK(kclist_lock); > > > -static int kcore_need_update = 1; > > > +static DECLARE_RWSEM(kclist_lock); > > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > > > It's unclear why kcore_need_update was changed to atomic_t - it's still > > updated under kclist_lock? > > Not in the hotplug notifier (kcore_callback()) anymore, so I need the > atomic_cmpxchg() in __kcore_update_ram(). Well that's just kcore_need_update = 1; and turning that into an atomic_set doesn't change anything(?). It's not a harmful change of course, but a bit ... odd. > That could use a mention in the commit message. That never hurts ;)
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote: > > > --- a/fs/proc/kcore.c > > > +++ b/fs/proc/kcore.c > > > @@ -59,8 +59,8 @@ struct memelfnote > > > }; > > > > > > static LIST_HEAD(kclist_head); > > > -static DEFINE_RWLOCK(kclist_lock); > > > -static int kcore_need_update = 1; > > > +static DECLARE_RWSEM(kclist_lock); > > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > > > It's unclear why kcore_need_update was changed to atomic_t - it's still > > updated under kclist_lock? > > Not in the hotplug notifier (kcore_callback()) anymore, so I need the > atomic_cmpxchg() in __kcore_update_ram(). Well that's just kcore_need_update = 1; and turning that into an atomic_set doesn't change anything(?). It's not a harmful change of course, but a bit ... odd. > That could use a mention in the commit message. That never hurts ;)
Re: [PATCH v2 2/7] mm/swapfile.c: Replace some #ifdef with IS_ENABLED()
Dave Hansen writes:
>> @@ -878,6 +877,11 @@ static int swap_alloc_cluster(struct swap_info_struct
>> *si, swp_entry_t *slot)
>> unsigned long offset, i;
>> unsigned char *map;
>>
>> +if (!IS_ENABLED(CONFIG_THP_SWAP)) {
>> +VM_WARN_ON_ONCE(1);
>> +return 0;
>> +}
>
> I see you seized the opportunity to keep this code gloriously
> unencumbered by pesky comments. This seems like a time when you might
> have slipped up and been temped to add a comment or two. Guess not. :)
>
> Seriously, though, does it hurt us to add a comment or two to say
> something like:
>
> /*
>* Should not even be attempting cluster allocations when
>* huge page swap is disabled. Warn and fail the allocation.
>*/
> if (!IS_ENABLED(CONFIG_THP_SWAP)) {
> VM_WARN_ON_ONCE(1);
> return 0;
> }
I totally agree with you that we should add more comments for THP swap
to improve the code readability. As for this specific case,
VM_WARN_ON_ONCE() here is just to capture some programming error during
development. Do we really need comments here?
I will try to add more comments for other places in code regardless this
one.
Best Regards,
Huang, Ying
Re: [PATCH v2 2/7] mm/swapfile.c: Replace some #ifdef with IS_ENABLED()
Dave Hansen writes:
>> @@ -878,6 +877,11 @@ static int swap_alloc_cluster(struct swap_info_struct
>> *si, swp_entry_t *slot)
>> unsigned long offset, i;
>> unsigned char *map;
>>
>> +if (!IS_ENABLED(CONFIG_THP_SWAP)) {
>> +VM_WARN_ON_ONCE(1);
>> +return 0;
>> +}
>
> I see you seized the opportunity to keep this code gloriously
> unencumbered by pesky comments. This seems like a time when you might
> have slipped up and been temped to add a comment or two. Guess not. :)
>
> Seriously, though, does it hurt us to add a comment or two to say
> something like:
>
> /*
>* Should not even be attempting cluster allocations when
>* huge page swap is disabled. Warn and fail the allocation.
>*/
> if (!IS_ENABLED(CONFIG_THP_SWAP)) {
> VM_WARN_ON_ONCE(1);
> return 0;
> }
I totally agree with you that we should add more comments for THP swap
to improve the code readability. As for this specific case,
VM_WARN_ON_ONCE() here is just to capture some programming error during
development. Do we really need comments here?
I will try to add more comments for other places in code regardless this
one.
Best Regards,
Huang, Ying
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, Jul 17, 2018 at 07:38:41PM -0700, Andrew Morton wrote: > On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote: > > > From: Omar Sandoval > > > > Now we only need kclist_lock from user context and at fs init time, and > > the following changes need to sleep while holding the kclist_lock. > > > > ... > > > > --- a/fs/proc/kcore.c > > +++ b/fs/proc/kcore.c > > @@ -59,8 +59,8 @@ struct memelfnote > > }; > > > > static LIST_HEAD(kclist_head); > > -static DEFINE_RWLOCK(kclist_lock); > > -static int kcore_need_update = 1; > > +static DECLARE_RWSEM(kclist_lock); > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > It's unclear why kcore_need_update was changed to atomic_t - it's still > updated under kclist_lock? Not in the hotplug notifier (kcore_callback()) anymore, so I need the atomic_cmpxchg() in __kcore_update_ram(). That could use a mention in the commit message. > Maybe it's for a later patch. > >
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Tue, Jul 17, 2018 at 07:38:41PM -0700, Andrew Morton wrote: > On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote: > > > From: Omar Sandoval > > > > Now we only need kclist_lock from user context and at fs init time, and > > the following changes need to sleep while holding the kclist_lock. > > > > ... > > > > --- a/fs/proc/kcore.c > > +++ b/fs/proc/kcore.c > > @@ -59,8 +59,8 @@ struct memelfnote > > }; > > > > static LIST_HEAD(kclist_head); > > -static DEFINE_RWLOCK(kclist_lock); > > -static int kcore_need_update = 1; > > +static DECLARE_RWSEM(kclist_lock); > > +static atomic_t kcore_need_update = ATOMIC_INIT(1); > > It's unclear why kcore_need_update was changed to atomic_t - it's still > updated under kclist_lock? Not in the hotplug notifier (kcore_callback()) anymore, so I need the atomic_cmpxchg() in __kcore_update_ram(). That could use a mention in the commit message. > Maybe it's for a later patch. > >
Re: [PATCH v2 1/7] proc/kcore: don't grab lock for kclist_add()
On Tue, Jul 17, 2018 at 07:35:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > kclist_add() is only called at init time, so there's no point in
> > grabbing any locks. We're also going to replace the rwlock with a rwsem,
> > which we don't want to try grabbing during early boot.
> >
> > ...
> >
> > --- a/fs/proc/kcore.c
> > +++ b/fs/proc/kcore.c
> > @@ -62,6 +62,7 @@ static LIST_HEAD(kclist_head);
> > static DEFINE_RWLOCK(kclist_lock);
> > static int kcore_need_update = 1;
> >
> > +/* This doesn't grab kclist_lock, so it should only be used at init time.
> > */
> > void
> > kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
> > {
> > @@ -69,9 +70,7 @@ kclist_add(struct kcore_list *new, void *addr, size_t
> > size, int type)
> > new->size = size;
> > new->type = type;
> >
> > - write_lock(_lock);
> > list_add_tail(>list, _head);
> > - write_unlock(_lock);
> > }
>
> So we can mark kclist_add() as __init, yes?
Yes, thanks, I'll add that in v2.
> That way we save a scrap of ram and if someone starts calling
> kclist_add() from non-__init code we get a build-time warning.
>
> --- a/fs/proc/kcore.c~proc-kcore-dont-grab-lock-for-kclist_add-fix
> +++ a/fs/proc/kcore.c
> @@ -63,7 +63,7 @@ static DEFINE_RWLOCK(kclist_lock);
> static int kcore_need_update = 1;
>
> /* This doesn't grab kclist_lock, so it should only be used at init time. */
> -void
> +void __init
> kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
> {
> new->addr = (unsigned long)addr;
> --- a/include/linux/kcore.h~proc-kcore-dont-grab-lock-for-kclist_add-fix
> +++ a/include/linux/kcore.h
> @@ -35,7 +35,7 @@ struct vmcoredd_node {
> };
>
> #ifdef CONFIG_PROC_KCORE
> -extern void kclist_add(struct kcore_list *, void *, size_t, int type);
> +extern void __init kclist_add(struct kcore_list *, void *, size_t, int type);
> #else
> static inline
> void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
>
>
Re: [PATCH v2 1/7] proc/kcore: don't grab lock for kclist_add()
On Tue, Jul 17, 2018 at 07:35:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > kclist_add() is only called at init time, so there's no point in
> > grabbing any locks. We're also going to replace the rwlock with a rwsem,
> > which we don't want to try grabbing during early boot.
> >
> > ...
> >
> > --- a/fs/proc/kcore.c
> > +++ b/fs/proc/kcore.c
> > @@ -62,6 +62,7 @@ static LIST_HEAD(kclist_head);
> > static DEFINE_RWLOCK(kclist_lock);
> > static int kcore_need_update = 1;
> >
> > +/* This doesn't grab kclist_lock, so it should only be used at init time.
> > */
> > void
> > kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
> > {
> > @@ -69,9 +70,7 @@ kclist_add(struct kcore_list *new, void *addr, size_t
> > size, int type)
> > new->size = size;
> > new->type = type;
> >
> > - write_lock(_lock);
> > list_add_tail(>list, _head);
> > - write_unlock(_lock);
> > }
>
> So we can mark kclist_add() as __init, yes?
Yes, thanks, I'll add that in v2.
> That way we save a scrap of ram and if someone starts calling
> kclist_add() from non-__init code we get a build-time warning.
>
> --- a/fs/proc/kcore.c~proc-kcore-dont-grab-lock-for-kclist_add-fix
> +++ a/fs/proc/kcore.c
> @@ -63,7 +63,7 @@ static DEFINE_RWLOCK(kclist_lock);
> static int kcore_need_update = 1;
>
> /* This doesn't grab kclist_lock, so it should only be used at init time. */
> -void
> +void __init
> kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
> {
> new->addr = (unsigned long)addr;
> --- a/include/linux/kcore.h~proc-kcore-dont-grab-lock-for-kclist_add-fix
> +++ a/include/linux/kcore.h
> @@ -35,7 +35,7 @@ struct vmcoredd_node {
> };
>
> #ifdef CONFIG_PROC_KCORE
> -extern void kclist_add(struct kcore_list *, void *, size_t, int type);
> +extern void __init kclist_add(struct kcore_list *, void *, size_t, int type);
> #else
> static inline
> void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
>
>
Re: [PATCH 0/3] use unicode for vt mouse paste
On Wed, 18 Jul 2018, Adam Borowski wrote: > Hi! > Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters > that have been copy+pasted via mouse selection. The uniscr array holds > their original identity even if they got mangled by glyph conversion. > The glyph conversion lossily turns similar-looking characters into a > representation, and everyone else into a replacement character. > > There's no proper handling for CJK (yet?) but anything of wcwidth()==1 will > work fine. > > The whole thing doesn't get enabled until something reads from /dev/vcsu for > that console, but let's test this code first before enabling it widely. Glad to see this. For the whole set you may add: Acked-by: Nicolas Pitre > Diffstat: > drivers/tty/vt/selection.c | 48 > +--- > drivers/tty/vt/vt.c| 10 ++ > include/linux/selection.h | 1 + > 3 files changed, 40 insertions(+), 19 deletions(-) > > > -- > // If you believe in so-called "intellectual property", please immediately > // cease using counterfeit alphabets. Instead, contact the nearest temple > // of Amon, whose priests will provide you with scribal services for all > // your writing needs, for Reasonable And Non-Discriminatory prices. > -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] use unicode for vt mouse paste
On Wed, 18 Jul 2018, Adam Borowski wrote: > Hi! > Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters > that have been copy+pasted via mouse selection. The uniscr array holds > their original identity even if they got mangled by glyph conversion. > The glyph conversion lossily turns similar-looking characters into a > representation, and everyone else into a replacement character. > > There's no proper handling for CJK (yet?) but anything of wcwidth()==1 will > work fine. > > The whole thing doesn't get enabled until something reads from /dev/vcsu for > that console, but let's test this code first before enabling it widely. Glad to see this. For the whole set you may add: Acked-by: Nicolas Pitre > Diffstat: > drivers/tty/vt/selection.c | 48 > +--- > drivers/tty/vt/vt.c| 10 ++ > include/linux/selection.h | 1 + > 3 files changed, 40 insertions(+), 19 deletions(-) > > > -- > // If you believe in so-called "intellectual property", please immediately > // cease using counterfeit alphabets. Instead, contact the nearest temple > // of Amon, whose priests will provide you with scribal services for all > // your writing needs, for Reasonable And Non-Discriminatory prices. > -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] swap: Add comments to lock_cluster_or_swap_info()
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> +/*
>> + * For non-HDD swap devices, the fine grained cluster lock is used to
>> + * protect si->swap_map. But cluster and cluster locks isn't
>> + * available for HDD, so coarse grained si->lock will be used instead
>> + * for that.
>> + */
>> static inline struct swap_cluster_info *lock_cluster_or_swap_info(
>> struct swap_info_struct *si,
>> unsigned long offset)
>
> This nomenclature is not consistent with the rest of the file. We call
> a "non-HDD" device an "ssd" absolutely everywhere else in the file. Why
> are you calling it a non-HDD here? (fwiw, HDD _barely_ hits my acronym
> cache anyway).
>
> How about this?
>
> /*
> * Determine the locking method in use for this device. Return
> * swap_cluster_info if SSD-style cluster-based locking is in place.
> */
> static inline struct swap_cluster_info *lock_cluster_or_swap_info(
> struct swap_info_struct *si,
> unsigned long offset)
> {
> struct swap_cluster_info *ci;
>
> /* Try to use fine-grained SSD-style locking if available: */
> ci = lock_cluster(si, offset);
>
> /* Otherwise, fall back to traditional, coarse locking: */
> if (!ci)
> spin_lock(>lock);
>
> return ci;
> }
This is better than my one, will use this. Thanks!
> Which reminds me? Why do we even bother having two locking models?
Because si->cluster_info is NULL for non-SSD, so we cannot use cluster
lock.
About why not use struct swap_cluster_info for non-SSD? Per my
understanding, struct swap_cluster_info is optimized for SSD.
Especially it assumes seeking is cheap. So different free swap slot
scanning policy is used for SSD and non-SSD.
Best Regards,
Huang, Ying
Re: [PATCH v2 1/7] swap: Add comments to lock_cluster_or_swap_info()
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> +/*
>> + * For non-HDD swap devices, the fine grained cluster lock is used to
>> + * protect si->swap_map. But cluster and cluster locks isn't
>> + * available for HDD, so coarse grained si->lock will be used instead
>> + * for that.
>> + */
>> static inline struct swap_cluster_info *lock_cluster_or_swap_info(
>> struct swap_info_struct *si,
>> unsigned long offset)
>
> This nomenclature is not consistent with the rest of the file. We call
> a "non-HDD" device an "ssd" absolutely everywhere else in the file. Why
> are you calling it a non-HDD here? (fwiw, HDD _barely_ hits my acronym
> cache anyway).
>
> How about this?
>
> /*
> * Determine the locking method in use for this device. Return
> * swap_cluster_info if SSD-style cluster-based locking is in place.
> */
> static inline struct swap_cluster_info *lock_cluster_or_swap_info(
> struct swap_info_struct *si,
> unsigned long offset)
> {
> struct swap_cluster_info *ci;
>
> /* Try to use fine-grained SSD-style locking if available: */
> ci = lock_cluster(si, offset);
>
> /* Otherwise, fall back to traditional, coarse locking: */
> if (!ci)
> spin_lock(>lock);
>
> return ci;
> }
This is better than my one, will use this. Thanks!
> Which reminds me? Why do we even bother having two locking models?
Because si->cluster_info is NULL for non-SSD, so we cannot use cluster
lock.
About why not use struct swap_cluster_info for non-SSD? Per my
understanding, struct swap_cluster_info is optimized for SSD.
Especially it assumes seeking is cheap. So different free swap slot
scanning policy is used for SSD and non-SSD.
Best Regards,
Huang, Ying
[PATCH 3/6] vt: let \e[100m use bright background if unblinking
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 45057bbf6f74..4096093c8cd2 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1709,6 +1709,8 @@ static void csi_m(struct vc_data *vc)
if (vc->vc_par[i] >= 90 && vc->vc_par[i] <= 107) {
if (vc->vc_par[i] < 100)
vc->vc_intensity = 2;
+ else if (vc->vc_unblinking)
+ vc->vc_blink = 1;
vc->vc_par[i] -= 60;
}
if (vc->vc_par[i] >= 30 && vc->vc_par[i] <= 37)
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] vt: let \e[100m use bright background if unblinking
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 45057bbf6f74..4096093c8cd2 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1709,6 +1709,8 @@ static void csi_m(struct vc_data *vc)
if (vc->vc_par[i] >= 90 && vc->vc_par[i] <= 107) {
if (vc->vc_par[i] < 100)
vc->vc_intensity = 2;
+ else if (vc->vc_unblinking)
+ vc->vc_blink = 1;
vc->vc_par[i] -= 60;
}
if (vc->vc_par[i] >= 30 && vc->vc_par[i] <= 37)
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] vt: drop unused struct vt_struct
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -17,7 +17,6 @@
#include
#include
-struct vt_struct;
struct uni_pagedir;
struct uni_screen;
@@ -150,7 +149,7 @@ struct vc {
struct vc_data *d;
struct work_struct SAK_work;
- /* might add scrmem, vt_struct, kbd at some time,
+ /* might add scrmem, kbd at some time,
to have everything in one place - the disadvantage
would be that vc_cons etc can no longer be static */
};
--
2.18.0
[PATCH 2/6] vt: add console flag "unblinking"
Marks consoles that interpret the blink bit by showing bright background
instead. Doesn't matter if the console can't do either.
For now, turn it on for fbcon when in color mode. Vgacon can also do so
but requires setting appropriate VGA register (bit 3 of AMCR). I don't
know other consoles: newport looks like it shows bright bg, sti can't do
either, mda appears to blink, etc -- but confirmation would be needed.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
include/linux/console_struct.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 846dfedb657d..45057bbf6f74 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -998,6 +998,7 @@ static void visual_init(struct vc_data *vc, int num, int
init)
vc->vc_hi_font_mask = 0;
vc->vc_complement_mask = 0;
vc->vc_can_do_color = 0;
+ vc->vc_unblinking = 0;
vc->vc_panic_force_write = false;
vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
vc->vc_sw->con_init(vc, init);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c910e74d46ff..4c67254f1ec4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1092,6 +1092,7 @@ static void fbcon_init(struct vc_data *vc, int init)
vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
vc->vc_can_do_color = (fb_get_color_depth(>var, >fix)!=1);
+ vc->vc_unblinking = vc->vc_can_do_color;
vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
if (charcnt == 256) {
vc->vc_hi_font_mask = 0;
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index fea64f2692a0..f94b28a6bd2d 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -122,6 +122,7 @@ struct vc_data {
unsigned intvc_ques : 1;
unsigned intvc_need_wrap: 1;
unsigned intvc_can_do_color : 1;
+ unsigned intvc_unblinking : 1;/* shows bright bg for blink */
unsigned intvc_report_mouse : 2;
unsigned char vc_utf : 1;/* Unicode UTF-8 encoding */
unsigned char vc_utf_count;
--
2.18.0
[PATCH 5/6] vt: compensate for brightening the 256-color palette
The algorithm for 256-to-16 conversion was designed with wrong input
palette but actually tuned on mainstream GUI terminals. This resulted in
something that works well only for data we convert ourselves (ie, 256 not
24-bit).
As the change is non-linear, I did not bother replicating it exactly, thus
there are some differences, among others:
* values very close to black go to 0 (black) rather than 8 (dark grey)
* grayscale ramp is more even
A comparison of the old vs new vs FreeBSD's teken is at:
https://github.com/kilobyte/colorkernel
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8c61caafdf3c..c777f4c91df0 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1559,17 +1559,17 @@ static void rgb_foreground(struct vc_data *vc, const
struct rgb *c)
{
u8 hue = 0, max = max3(c->r, c->g, c->b);
- if (c->r > max / 2)
+ if (c->r > max / 2 + 32)
hue |= 4;
- if (c->g > max / 2)
+ if (c->g > max / 2 + 32)
hue |= 2;
- if (c->b > max / 2)
+ if (c->b > max / 2 + 32)
hue |= 1;
- if (hue == 7 && max <= 0x55) {
+ if (hue == 7 && max <= 0x70) {
hue = 0;
vc->vc_intensity = 2;
- } else if (max > 0xaa)
+ } else if (max > 0xc0)
vc->vc_intensity = 2;
else
vc->vc_intensity = 1;
--
2.18.0
[PATCH 4/6] vt: change 256-color palette to match all(?) modern terminals
Turns out that osso-xterm which I based upon uses something a lot different
from apparently any other terminal -- they all use identical shades, much
brighter than what I copied:
Old: 00 2a 55 7f aa d4
New: 00 5f 87 af d7 ff
This did hardly matter as we immediately shoehorn the colors into only 16
values, but recently 24-bit codes turned from an oddity to something
widespread, thus it's better to handle 256 vs 24-bit consistently.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 4096093c8cd2..8c61caafdf3c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1545,9 +1545,12 @@ static void rgb_from_256(int i, struct rgb *c)
c->g = i&2 ? 0xff : 0x55;
c->b = i&4 ? 0xff : 0x55;
} else if (i < 232) { /* 6x6x6 colour cube. */
- c->r = (i - 16) / 36 * 85 / 2;
- c->g = (i - 16) / 6 % 6 * 85 / 2;
- c->b = (i - 16) % 6 * 85 / 2;
+ int r = (i - 16) / 36;
+ int g = (i - 16) / 6 % 6;
+ int b = (i - 16) % 6;
+ c->r = r ? r * 0x28 + 0x37 : 0;
+ c->g = g ? g * 0x28 + 0x37 : 0;
+ c->b = b ? b * 0x28 + 0x37 : 0;
} else /* Grayscale ramp. */
c->r = c->g = c->b = i * 10 - 2312;
}
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] vt: support bright backgrounds for \e[48m if unblinking
This improves schemes used by fancy new programs. For example, it lets
bright powerline segments match, and fixes images shown by catimg being
striped to the point of unreadability.
Handling of 8-color backgrounds uses stripped 16-color value instead of a
dedicated formula; this works worse for dark and better for bright inputs.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c777f4c91df0..7fcb0ff2dccf 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1555,7 +1555,7 @@ static void rgb_from_256(int i, struct rgb *c)
c->r = c->g = c->b = i * 10 - 2312;
}
-static void rgb_foreground(struct vc_data *vc, const struct rgb *c)
+static u8 rgb_to_16(const struct rgb *c)
{
u8 hue = 0, max = max3(c->r, c->g, c->b);
@@ -1566,22 +1566,12 @@ static void rgb_foreground(struct vc_data *vc, const
struct rgb *c)
if (c->b > max / 2 + 32)
hue |= 1;
- if (hue == 7 && max <= 0x70) {
- hue = 0;
- vc->vc_intensity = 2;
- } else if (max > 0xc0)
- vc->vc_intensity = 2;
+ if (hue == 7 && max <= 0x70)
+ return 8;
+ if (max > 0xc0)
+ return hue | 8;
else
- vc->vc_intensity = 1;
-
- vc->vc_color = (vc->vc_color & 0xf0) | hue;
-}
-
-static void rgb_background(struct vc_data *vc, const struct rgb *c)
-{
- /* For backgrounds, err on the dark side. */
- vc->vc_color = (vc->vc_color & 0x0f)
- | (c->r&0x80) >> 1 | (c->g&0x80) >> 2 | (c->b&0x80) >> 3;
+ return hue;
}
/*
@@ -1593,10 +1583,10 @@ static void rgb_background(struct vc_data *vc, const
struct rgb *c)
* Subcommands 3 (CMY) and 4 (CMYK) are so insane there's no point in
* supporting them.
*/
-static int vc_t416_color(struct vc_data *vc, int i,
- void(*set_color)(struct vc_data *vc, const struct rgb *c))
+static int vc_t416_color(struct vc_data *vc, int i, int bgshift)
{
struct rgb c;
+ u8 v;
i++;
if (i > vc->vc_npar)
@@ -1615,7 +1605,13 @@ static int vc_t416_color(struct vc_data *vc, int i,
} else
return i;
- set_color(vc, );
+ v = rgb_to_16();
+
+ vc->vc_color = (vc->vc_color & (0xf0 >> bgshift)) | v << bgshift;
+ if (!bgshift)
+ vc->vc_intensity = (v & 8 >> 4) + 1;
+ else if (vc->vc_unblinking)
+ vc->vc_blink = v & 8 >> 4;
return i;
}
@@ -1695,10 +1691,10 @@ static void csi_m(struct vc_data *vc)
vc->vc_reverse = 0;
break;
case 38:
- i = vc_t416_color(vc, i, rgb_foreground);
+ i = vc_t416_color(vc, i, 0);
break;
case 48:
- i = vc_t416_color(vc, i, rgb_background);
+ i = vc_t416_color(vc, i, 4);
break;
case 39:
vc->vc_color = (vc->vc_def_color & 0x0f) |
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] vt: drop unused struct vt_struct
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -17,7 +17,6 @@
#include
#include
-struct vt_struct;
struct uni_pagedir;
struct uni_screen;
@@ -150,7 +149,7 @@ struct vc {
struct vc_data *d;
struct work_struct SAK_work;
- /* might add scrmem, vt_struct, kbd at some time,
+ /* might add scrmem, kbd at some time,
to have everything in one place - the disadvantage
would be that vc_cons etc can no longer be static */
};
--
2.18.0
[PATCH 2/6] vt: add console flag "unblinking"
Marks consoles that interpret the blink bit by showing bright background
instead. Doesn't matter if the console can't do either.
For now, turn it on for fbcon when in color mode. Vgacon can also do so
but requires setting appropriate VGA register (bit 3 of AMCR). I don't
know other consoles: newport looks like it shows bright bg, sti can't do
either, mda appears to blink, etc -- but confirmation would be needed.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 1 +
drivers/video/fbdev/core/fbcon.c | 1 +
include/linux/console_struct.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 846dfedb657d..45057bbf6f74 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -998,6 +998,7 @@ static void visual_init(struct vc_data *vc, int num, int
init)
vc->vc_hi_font_mask = 0;
vc->vc_complement_mask = 0;
vc->vc_can_do_color = 0;
+ vc->vc_unblinking = 0;
vc->vc_panic_force_write = false;
vc->vc_cur_blink_ms = DEFAULT_CURSOR_BLINK_MS;
vc->vc_sw->con_init(vc, init);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c910e74d46ff..4c67254f1ec4 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1092,6 +1092,7 @@ static void fbcon_init(struct vc_data *vc, int init)
vc->vc_panic_force_write = !!(info->flags & FBINFO_CAN_FORCE_OUTPUT);
vc->vc_can_do_color = (fb_get_color_depth(>var, >fix)!=1);
+ vc->vc_unblinking = vc->vc_can_do_color;
vc->vc_complement_mask = vc->vc_can_do_color ? 0x7700 : 0x0800;
if (charcnt == 256) {
vc->vc_hi_font_mask = 0;
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index fea64f2692a0..f94b28a6bd2d 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -122,6 +122,7 @@ struct vc_data {
unsigned intvc_ques : 1;
unsigned intvc_need_wrap: 1;
unsigned intvc_can_do_color : 1;
+ unsigned intvc_unblinking : 1;/* shows bright bg for blink */
unsigned intvc_report_mouse : 2;
unsigned char vc_utf : 1;/* Unicode UTF-8 encoding */
unsigned char vc_utf_count;
--
2.18.0
[PATCH 5/6] vt: compensate for brightening the 256-color palette
The algorithm for 256-to-16 conversion was designed with wrong input
palette but actually tuned on mainstream GUI terminals. This resulted in
something that works well only for data we convert ourselves (ie, 256 not
24-bit).
As the change is non-linear, I did not bother replicating it exactly, thus
there are some differences, among others:
* values very close to black go to 0 (black) rather than 8 (dark grey)
* grayscale ramp is more even
A comparison of the old vs new vs FreeBSD's teken is at:
https://github.com/kilobyte/colorkernel
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 8c61caafdf3c..c777f4c91df0 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1559,17 +1559,17 @@ static void rgb_foreground(struct vc_data *vc, const
struct rgb *c)
{
u8 hue = 0, max = max3(c->r, c->g, c->b);
- if (c->r > max / 2)
+ if (c->r > max / 2 + 32)
hue |= 4;
- if (c->g > max / 2)
+ if (c->g > max / 2 + 32)
hue |= 2;
- if (c->b > max / 2)
+ if (c->b > max / 2 + 32)
hue |= 1;
- if (hue == 7 && max <= 0x55) {
+ if (hue == 7 && max <= 0x70) {
hue = 0;
vc->vc_intensity = 2;
- } else if (max > 0xaa)
+ } else if (max > 0xc0)
vc->vc_intensity = 2;
else
vc->vc_intensity = 1;
--
2.18.0
[PATCH 4/6] vt: change 256-color palette to match all(?) modern terminals
Turns out that osso-xterm which I based upon uses something a lot different
from apparently any other terminal -- they all use identical shades, much
brighter than what I copied:
Old: 00 2a 55 7f aa d4
New: 00 5f 87 af d7 ff
This did hardly matter as we immediately shoehorn the colors into only 16
values, but recently 24-bit codes turned from an oddity to something
widespread, thus it's better to handle 256 vs 24-bit consistently.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 4096093c8cd2..8c61caafdf3c 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1545,9 +1545,12 @@ static void rgb_from_256(int i, struct rgb *c)
c->g = i&2 ? 0xff : 0x55;
c->b = i&4 ? 0xff : 0x55;
} else if (i < 232) { /* 6x6x6 colour cube. */
- c->r = (i - 16) / 36 * 85 / 2;
- c->g = (i - 16) / 6 % 6 * 85 / 2;
- c->b = (i - 16) % 6 * 85 / 2;
+ int r = (i - 16) / 36;
+ int g = (i - 16) / 6 % 6;
+ int b = (i - 16) % 6;
+ c->r = r ? r * 0x28 + 0x37 : 0;
+ c->g = g ? g * 0x28 + 0x37 : 0;
+ c->b = b ? b * 0x28 + 0x37 : 0;
} else /* Grayscale ramp. */
c->r = c->g = c->b = i * 10 - 2312;
}
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] vt: support bright backgrounds for \e[48m if unblinking
This improves schemes used by fancy new programs. For example, it lets
bright powerline segments match, and fixes images shown by catimg being
striped to the point of unreadability.
Handling of 8-color backgrounds uses stripped 16-color value instead of a
dedicated formula; this works worse for dark and better for bright inputs.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 38 +-
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index c777f4c91df0..7fcb0ff2dccf 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1555,7 +1555,7 @@ static void rgb_from_256(int i, struct rgb *c)
c->r = c->g = c->b = i * 10 - 2312;
}
-static void rgb_foreground(struct vc_data *vc, const struct rgb *c)
+static u8 rgb_to_16(const struct rgb *c)
{
u8 hue = 0, max = max3(c->r, c->g, c->b);
@@ -1566,22 +1566,12 @@ static void rgb_foreground(struct vc_data *vc, const
struct rgb *c)
if (c->b > max / 2 + 32)
hue |= 1;
- if (hue == 7 && max <= 0x70) {
- hue = 0;
- vc->vc_intensity = 2;
- } else if (max > 0xc0)
- vc->vc_intensity = 2;
+ if (hue == 7 && max <= 0x70)
+ return 8;
+ if (max > 0xc0)
+ return hue | 8;
else
- vc->vc_intensity = 1;
-
- vc->vc_color = (vc->vc_color & 0xf0) | hue;
-}
-
-static void rgb_background(struct vc_data *vc, const struct rgb *c)
-{
- /* For backgrounds, err on the dark side. */
- vc->vc_color = (vc->vc_color & 0x0f)
- | (c->r&0x80) >> 1 | (c->g&0x80) >> 2 | (c->b&0x80) >> 3;
+ return hue;
}
/*
@@ -1593,10 +1583,10 @@ static void rgb_background(struct vc_data *vc, const
struct rgb *c)
* Subcommands 3 (CMY) and 4 (CMYK) are so insane there's no point in
* supporting them.
*/
-static int vc_t416_color(struct vc_data *vc, int i,
- void(*set_color)(struct vc_data *vc, const struct rgb *c))
+static int vc_t416_color(struct vc_data *vc, int i, int bgshift)
{
struct rgb c;
+ u8 v;
i++;
if (i > vc->vc_npar)
@@ -1615,7 +1605,13 @@ static int vc_t416_color(struct vc_data *vc, int i,
} else
return i;
- set_color(vc, );
+ v = rgb_to_16();
+
+ vc->vc_color = (vc->vc_color & (0xf0 >> bgshift)) | v << bgshift;
+ if (!bgshift)
+ vc->vc_intensity = (v & 8 >> 4) + 1;
+ else if (vc->vc_unblinking)
+ vc->vc_blink = v & 8 >> 4;
return i;
}
@@ -1695,10 +1691,10 @@ static void csi_m(struct vc_data *vc)
vc->vc_reverse = 0;
break;
case 38:
- i = vc_t416_color(vc, i, rgb_foreground);
+ i = vc_t416_color(vc, i, 0);
break;
case 48:
- i = vc_t416_color(vc, i, rgb_background);
+ i = vc_t416_color(vc, i, 4);
break;
case 39:
vc->vc_color = (vc->vc_def_color & 0x0f) |
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
Hi! Here's a patchset with two entangled improvements: * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) allows disabling it, rendering such characters with a bright background instead. * due to my error, 256-color mode uses a much darker palette for conversion, resulting in behaving inconsistently with 24-bit mode. The new code uses bright backgrounds when possible, enabled with \e[100m or \e[48;m. Despite the whole idea following a VGA capability, this patchset doesn't change vgacon yet, just fbcon. The reason being: ~80% of x86 users have an nVidia chip, which means nouveau or nvidia-proprietary. Nouveau implies fbcon, nvidia-proprietary fails to properly restore text flags (as evidenced by 512 glyph mode turning to 256 on switch from graphics). You don't care about the proprietary driver, but let's not break it pointlessly, and as both nVidia cards I own work only with nouveau, I don't want to touch what I can't test. Thus, let's enable unblinking on fbcon for now. We can flip that bit (in register 0x10) later. This fixes the display of catimg and similar tools. Diffstat: drivers/tty/vt/vt.c | 56 +--- drivers/video/fbdev/core/fbcon.c | 1 + include/linux/console_struct.h | 4 ++-- 3 files changed, 32 insertions(+), 29 deletions(-) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
[PATCH 0/6] vt: no blinking on console, 256/24-bit color improvements
Hi! Here's a patchset with two entangled improvements: * it'd be good to get rid of blinking where possible. Even CGA (thus VGA) allows disabling it, rendering such characters with a bright background instead. * due to my error, 256-color mode uses a much darker palette for conversion, resulting in behaving inconsistently with 24-bit mode. The new code uses bright backgrounds when possible, enabled with \e[100m or \e[48;m. Despite the whole idea following a VGA capability, this patchset doesn't change vgacon yet, just fbcon. The reason being: ~80% of x86 users have an nVidia chip, which means nouveau or nvidia-proprietary. Nouveau implies fbcon, nvidia-proprietary fails to properly restore text flags (as evidenced by 512 glyph mode turning to 256 on switch from graphics). You don't care about the proprietary driver, but let's not break it pointlessly, and as both nVidia cards I own work only with nouveau, I don't want to touch what I can't test. Thus, let's enable unblinking on fbcon for now. We can flip that bit (in register 0x10) later. This fixes the display of catimg and similar tools. Diffstat: drivers/tty/vt/vt.c | 56 +--- drivers/video/fbdev/core/fbcon.c | 1 + include/linux/console_struct.h | 4 ++-- 3 files changed, 32 insertions(+), 29 deletions(-) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Re: [PATCH v3 0/6] KVM: X86: Implement PV IPIs support
Gentle ping, hope this series can catch up with the next merge window. :) On Tue, 3 Jul 2018 at 14:21, Wanpeng Li wrote: > > Using hypercall to send IPIs by one vmexit instead of one by one for > xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster > mode. Intel guest can enter x2apic cluster mode when interrupt remmaping > is enabled in qemu, however, latest AMD EPYC still just supports xapic > mode which can get great improvement by PV IPIs. This patchset supports > PV IPIs for maximal 128 vCPUs VM, it is big enough for cloud environment > currently, supporting more vCPUs needs to introduce more complex logic, > in the future this might be extended if needed. > > Hardware: Xeon Skylake 2.5GHz, 2 sockets, 40 cores, 80 threads, the VM > is 80 vCPUs, IPI microbenchmark(https://lkml.org/lkml/2017/12/19/141): > > x2apic cluster mode, vanilla > > Dry-run: 0,2392199 ns > Self-IPI: 6907514, 15027589 ns > Normal IPI: 223910476, 251301666 ns > Broadcast IPI: 0, 9282161150 ns > Broadcast lock: 0, 8812934104 ns > > x2apic cluster mode, pv-ipi > > Dry-run: 0,2449341 ns > Self-IPI: 6720360, 15028732 ns > Normal IPI: 228643307, 255708477 ns > Broadcast IPI: 0, 7572293590 ns => 22% > performance boost > Broadcast lock: 0, 8316124651 ns > > x2apic physical mode, vanilla > > Dry-run: 0,3135933 ns > Self-IPI: 8572670, 17901757 ns > Normal IPI: 226444334, 255421709 ns > Broadcast IPI: 0,19845070887 ns > Broadcast lock: 0,19827383656 ns > > x2apic physical mode, pv-ipi > > Dry-run: 0,2446381 ns > Self-IPI: 6788217, 15021056 ns > Normal IPI: 219454441, 249583458 ns > Broadcast IPI: 0, 7806540019 ns => 154% > performance boost > Broadcast lock: 0, 9143618799 ns > > v2 -> v3: > * rename ipi_mask_done to irq_restore_exit, __send_ipi_mask return int >instead of bool > * fix build errors reported by 0day > * split patches, nothing change > > v1 -> v2: > * sparse apic id > 128, or any other errors, fallback to original apic hooks > * have two bitmask arguments so that one hypercall handles 128 vCPUs > * fix KVM_FEATURE_PV_SEND_IPI doc > * document hypercall > * fix NMI selftest fails > * fix build errors reported by 0day > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Vitaly Kuznetsov > > Wanpeng Li (6): > KVM: X86: Add kvm hypervisor init time platform setup callback > KVM: X86: Implement PV IPIs in linux guest > KVM: X86: Fallback to original apic hooks when bad happens > KVM: X86: Implement PV IPIs send hypercall > KVM: X86: Add NMI support to PV IPIs > KVM: X86: Expose PV_SEND_IPI CPUID feature bit to guest > > Documentation/virtual/kvm/cpuid.txt | 4 ++ > Documentation/virtual/kvm/hypercalls.txt | 6 ++ > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kernel/kvm.c| 101 > +++ > arch/x86/kvm/cpuid.c | 3 +- > arch/x86/kvm/x86.c | 42 + > include/uapi/linux/kvm_para.h| 1 + > 7 files changed, 157 insertions(+), 1 deletion(-) > > -- > 2.7.4 >
Re: [PATCH v3 0/6] KVM: X86: Implement PV IPIs support
Gentle ping, hope this series can catch up with the next merge window. :) On Tue, 3 Jul 2018 at 14:21, Wanpeng Li wrote: > > Using hypercall to send IPIs by one vmexit instead of one by one for > xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster > mode. Intel guest can enter x2apic cluster mode when interrupt remmaping > is enabled in qemu, however, latest AMD EPYC still just supports xapic > mode which can get great improvement by PV IPIs. This patchset supports > PV IPIs for maximal 128 vCPUs VM, it is big enough for cloud environment > currently, supporting more vCPUs needs to introduce more complex logic, > in the future this might be extended if needed. > > Hardware: Xeon Skylake 2.5GHz, 2 sockets, 40 cores, 80 threads, the VM > is 80 vCPUs, IPI microbenchmark(https://lkml.org/lkml/2017/12/19/141): > > x2apic cluster mode, vanilla > > Dry-run: 0,2392199 ns > Self-IPI: 6907514, 15027589 ns > Normal IPI: 223910476, 251301666 ns > Broadcast IPI: 0, 9282161150 ns > Broadcast lock: 0, 8812934104 ns > > x2apic cluster mode, pv-ipi > > Dry-run: 0,2449341 ns > Self-IPI: 6720360, 15028732 ns > Normal IPI: 228643307, 255708477 ns > Broadcast IPI: 0, 7572293590 ns => 22% > performance boost > Broadcast lock: 0, 8316124651 ns > > x2apic physical mode, vanilla > > Dry-run: 0,3135933 ns > Self-IPI: 8572670, 17901757 ns > Normal IPI: 226444334, 255421709 ns > Broadcast IPI: 0,19845070887 ns > Broadcast lock: 0,19827383656 ns > > x2apic physical mode, pv-ipi > > Dry-run: 0,2446381 ns > Self-IPI: 6788217, 15021056 ns > Normal IPI: 219454441, 249583458 ns > Broadcast IPI: 0, 7806540019 ns => 154% > performance boost > Broadcast lock: 0, 9143618799 ns > > v2 -> v3: > * rename ipi_mask_done to irq_restore_exit, __send_ipi_mask return int >instead of bool > * fix build errors reported by 0day > * split patches, nothing change > > v1 -> v2: > * sparse apic id > 128, or any other errors, fallback to original apic hooks > * have two bitmask arguments so that one hypercall handles 128 vCPUs > * fix KVM_FEATURE_PV_SEND_IPI doc > * document hypercall > * fix NMI selftest fails > * fix build errors reported by 0day > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Cc: Vitaly Kuznetsov > > Wanpeng Li (6): > KVM: X86: Add kvm hypervisor init time platform setup callback > KVM: X86: Implement PV IPIs in linux guest > KVM: X86: Fallback to original apic hooks when bad happens > KVM: X86: Implement PV IPIs send hypercall > KVM: X86: Add NMI support to PV IPIs > KVM: X86: Expose PV_SEND_IPI CPUID feature bit to guest > > Documentation/virtual/kvm/cpuid.txt | 4 ++ > Documentation/virtual/kvm/hypercalls.txt | 6 ++ > arch/x86/include/uapi/asm/kvm_para.h | 1 + > arch/x86/kernel/kvm.c| 101 > +++ > arch/x86/kvm/cpuid.c | 3 +- > arch/x86/kvm/x86.c | 42 + > include/uapi/linux/kvm_para.h| 1 + > 7 files changed, 157 insertions(+), 1 deletion(-) > > -- > 2.7.4 >
Re: [PATCH v2 0/7] swap: THP optimizing refactoring
Daniel Jordan writes: > On Tue, Jul 17, 2018 at 08:55:49AM +0800, Huang, Ying wrote: >> This patchset is based on 2018-07-13 head of mmotm tree. > > Looks good. > > Still think patch 7 would be easier to review if split into two logical > changes. Either way, though. > > For the series, > Reviewed-by: Daniel Jordan Thanks a lot for your review! Best Regards, Huang, Ying
Re: [PATCH v2 0/7] swap: THP optimizing refactoring
Daniel Jordan writes: > On Tue, Jul 17, 2018 at 08:55:49AM +0800, Huang, Ying wrote: >> This patchset is based on 2018-07-13 head of mmotm tree. > > Looks good. > > Still think patch 7 would be easier to review if split into two logical > changes. Either way, though. > > For the series, > Reviewed-by: Daniel Jordan Thanks a lot for your review! Best Regards, Huang, Ying
Re: [PATCH v2 7/7] swap, put_swap_page: Share more between huge/normal code path
Dave Hansen writes: > On 07/16/2018 05:55 PM, Huang, Ying wrote: >> text data bss dec hex filename >> base: 24215 2028 340 2658367d7 mm/swapfile.o >> unified: 245772028 340 269456941 mm/swapfile.o > > That's a bit more than I'd expect looking at the rest of the diff. Make > me wonder if we missed an #ifdef somewhere or the compiler is getting > otherwise confused. > > Might be worth a 10-minute look at the disassembly. Dig one step deeper via 'size -A mm/swapfile.o' and diff between base and unified, --- b.s 2018-07-18 09:42:07.872501680 +0800 +++ h.s 2018-07-18 09:50:37.984499168 +0800 @@ -1,6 +1,6 @@ mm/swapfile.o : section size addr -.text17815 0 +.text17927 0 .data 1288 0 .bss 340 0 ___ksymtab_gpl+nr_swap_pages 8 0 @@ -26,8 +26,8 @@ .data.once 1 0 .comment35 0 .note.GNU-stack 0 0 -.orc_unwind_ip1380 0 -.orc_unwind 2070 0 -Total26810 +.orc_unwind_ip1480 0 +.orc_unwind 2220 0 +Total27172 The total difference is same: 27172 - 26810 = 362 = 24577 - 24215. The text section difference is small: 17927 - 17815 = 112. The additional size change comes from unwinder information: (1480 + 2220) - (1380 + 2070) = 250. If the frame pointer unwinder is chosen, this cost nothing, but if the ORC unwinder is chosen, this is the real difference. For 112 text section difference, use 'objdump -t' to get symbol size and compare, --- b.od2018-07-18 10:45:05.768483075 +0800 +++ h.od2018-07-18 10:44:39.556483204 +0800 @@ -30,9 +30,9 @@ 00a3 cluster_list_add_tail 001e __kunmap_atomic.isra.34 018c swap_count_continued -00ac __swap_entry_free 000f put_swap_device.isra.35 00b4 inc_cluster_info_page +006f __swap_entry_free_locked 004a _enable_swap_info 0046 wait_on_page_writeback 002e inode_to_bdi @@ -53,8 +53,8 @@ 0012 __x64_sys_swapon 0011 __ia32_sys_swapon 007a get_swap_device -0032 swap_free -0035 put_swap_page +006e swap_free +0078 put_swap_page 0267 swapcache_free_entries 0058 page_swapcount 003a __swap_count @@ -64,7 +64,7 @@ 011a try_to_free_swap 01fb get_swap_pages 0098 get_swap_page_of_type -01b8 free_swap_and_cache +01e6 free_swap_and_cache 0543 try_to_unuse 000e __x64_sys_swapoff 000d __ia32_sys_swapoff The size of put_swap_page() change is small: 0x78 - 0x35 = 67. But __swap_entry_free() is inlined by compiler, which cause some code dilating. Best Regards, Huang, Ying
Re: vfs / overlayfs conflict resolution for linux-next
On Thu, Jul 12, 2018 at 04:53:37PM +0100, Al Viro wrote: > On Thu, Jul 12, 2018 at 08:05:26AM -0700, Linus Torvalds wrote: > > On Thu, Jul 12, 2018 at 5:43 AM Al Viro wrote: > > > > > > A question regarding the customs in such situations - are previous > > > Reviewed-by/Acked-by normally kept across rebases like that? > > > > Yeah, unless there were big changes, keep the reviewed/acked-by lines. > > > > Otherwise you'd never be able to handle different people giving > > slightly different feedback about separate issues. > > OK... Miklos, I've pushed #ovl-candidate, with equivalent of the beginning > of your branch. I'm *not* saying that I've no remaining issues > with your series - this is just how I'd prefer to resolve that group > of conflicts. > > Everything past "vfs: simplify dentry_open()" could live on top of that > one, or its equivalent. > > I'm going to put #work-open3 into -next, let's figure out what to do with > the conflicts; what I can promise is never-rebased status for #for-ovl > (the beginning of #work-open3 merged into #ovl-candidate). ... and now it even builds. Said that, I would really like to hear something from you - I can duplicate the entire overlayfs-next and merge it into my #for-next and ask Steven to use that instead of your tree, but I very much dislike going over your head like that. I realize that you'd been away for a while and probably are digging yourself from under the piles of mail, but it's getting late in the cycle and I want to get #for-next into reasonably sane shape. Please, look through that thing and respond.
Re: [PATCH v2 7/7] swap, put_swap_page: Share more between huge/normal code path
Dave Hansen writes: > On 07/16/2018 05:55 PM, Huang, Ying wrote: >> text data bss dec hex filename >> base: 24215 2028 340 2658367d7 mm/swapfile.o >> unified: 245772028 340 269456941 mm/swapfile.o > > That's a bit more than I'd expect looking at the rest of the diff. Make > me wonder if we missed an #ifdef somewhere or the compiler is getting > otherwise confused. > > Might be worth a 10-minute look at the disassembly. Dig one step deeper via 'size -A mm/swapfile.o' and diff between base and unified, --- b.s 2018-07-18 09:42:07.872501680 +0800 +++ h.s 2018-07-18 09:50:37.984499168 +0800 @@ -1,6 +1,6 @@ mm/swapfile.o : section size addr -.text17815 0 +.text17927 0 .data 1288 0 .bss 340 0 ___ksymtab_gpl+nr_swap_pages 8 0 @@ -26,8 +26,8 @@ .data.once 1 0 .comment35 0 .note.GNU-stack 0 0 -.orc_unwind_ip1380 0 -.orc_unwind 2070 0 -Total26810 +.orc_unwind_ip1480 0 +.orc_unwind 2220 0 +Total27172 The total difference is same: 27172 - 26810 = 362 = 24577 - 24215. The text section difference is small: 17927 - 17815 = 112. The additional size change comes from unwinder information: (1480 + 2220) - (1380 + 2070) = 250. If the frame pointer unwinder is chosen, this cost nothing, but if the ORC unwinder is chosen, this is the real difference. For 112 text section difference, use 'objdump -t' to get symbol size and compare, --- b.od2018-07-18 10:45:05.768483075 +0800 +++ h.od2018-07-18 10:44:39.556483204 +0800 @@ -30,9 +30,9 @@ 00a3 cluster_list_add_tail 001e __kunmap_atomic.isra.34 018c swap_count_continued -00ac __swap_entry_free 000f put_swap_device.isra.35 00b4 inc_cluster_info_page +006f __swap_entry_free_locked 004a _enable_swap_info 0046 wait_on_page_writeback 002e inode_to_bdi @@ -53,8 +53,8 @@ 0012 __x64_sys_swapon 0011 __ia32_sys_swapon 007a get_swap_device -0032 swap_free -0035 put_swap_page +006e swap_free +0078 put_swap_page 0267 swapcache_free_entries 0058 page_swapcount 003a __swap_count @@ -64,7 +64,7 @@ 011a try_to_free_swap 01fb get_swap_pages 0098 get_swap_page_of_type -01b8 free_swap_and_cache +01e6 free_swap_and_cache 0543 try_to_unuse 000e __x64_sys_swapoff 000d __ia32_sys_swapoff The size of put_swap_page() change is small: 0x78 - 0x35 = 67. But __swap_entry_free() is inlined by compiler, which cause some code dilating. Best Regards, Huang, Ying
Re: vfs / overlayfs conflict resolution for linux-next
On Thu, Jul 12, 2018 at 04:53:37PM +0100, Al Viro wrote: > On Thu, Jul 12, 2018 at 08:05:26AM -0700, Linus Torvalds wrote: > > On Thu, Jul 12, 2018 at 5:43 AM Al Viro wrote: > > > > > > A question regarding the customs in such situations - are previous > > > Reviewed-by/Acked-by normally kept across rebases like that? > > > > Yeah, unless there were big changes, keep the reviewed/acked-by lines. > > > > Otherwise you'd never be able to handle different people giving > > slightly different feedback about separate issues. > > OK... Miklos, I've pushed #ovl-candidate, with equivalent of the beginning > of your branch. I'm *not* saying that I've no remaining issues > with your series - this is just how I'd prefer to resolve that group > of conflicts. > > Everything past "vfs: simplify dentry_open()" could live on top of that > one, or its equivalent. > > I'm going to put #work-open3 into -next, let's figure out what to do with > the conflicts; what I can promise is never-rebased status for #for-ovl > (the beginning of #work-open3 merged into #ovl-candidate). ... and now it even builds. Said that, I would really like to hear something from you - I can duplicate the entire overlayfs-next and merge it into my #for-next and ask Steven to use that instead of your tree, but I very much dislike going over your head like that. I realize that you'd been away for a while and probably are digging yourself from under the piles of mail, but it's getting late in the cycle and I want to get #for-next into reasonably sane shape. Please, look through that thing and respond.
Re: [PATCH 1/3] vt: avoid a VLA in the unicode screen scroll function
On Wed, 18 Jul 2018, Adam Borowski wrote:
> On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> > The nr argument is typically small: most often nr == 1. However this
> > could be abused with a very large explicit scroll in a resized screen.
> > Make the code scroll lines one at a time in all cases to avoid the VLA.
> > Anything smarter is most likely not warranted here.
>
> Even though nr can be 32767 at most, your new version is O(nr*nr) for no
> reason. Instead of O(n) memory or O(n²) time, a variant of the original
> that copies values one at a time would be shorter and faster.
Well... even though nr _can_ be up to 32766 to be precise, it is most
likely to be just 1 in 99.9% of the cases. So in that case, you'll
execute the loop only once and the code is currently optimal with O(n).
If nr > 1 then the current cost is O(n*nr) where n is the height of the
scroll window i.e. relatively small in practice (typically between 25
and 60). There is no point optimizing for 32767 rows as that is rather
silly. If we had then the best solution would be a linked list rather
than an array.
But still, if nr > 2 that means you need a temporary storage because the
destination memory has to be preserved before the source memory can be
moved there, and that destination memory content cannot be stored in the
vacated source memory until the source content is moved. Copying values
one at a time cannot work because the destination memory, the source
memory, and the area where the previous content from the destination
memory will end up don't overlap most of the time.
That temporary storage was that VLA. We don't want VLAs. So how do we
efficiently allocate and deallocate memory for, say, 25 words? Maybe
that doesn't have to be efficient because that doesn't happen very often
as we said, at which point we can just do it in a loop with a one-line
increment instead, as this patch does.
If you still have a more clever way of doing this then please propose it
in code form (I'm genuinely curious of what you have in mind). But let's
get the baseline working in an obvious "correct" way first.
> > Requested-by: Kees Cook
> > Signed-off-by: Nicolas Pitre
> > ---
> > drivers/tty/vt/vt.c | 18 ++
> > 1 file changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 2d14bb195d..03e79f7787 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -433,20 +433,22 @@ static void vc_uniscr_scroll(struct vc_data *vc,
> > unsigned int t, unsigned int b,
> >
> > if (uniscr) {
> > unsigned int s, d, rescue, clear;
> > - char32_t *save[nr];
> >
> > s = clear = t;
> > - d = t + nr;
> > - rescue = b - nr;
> > + d = t + 1;
> > + rescue = b - 1;
> > if (dir == SM_UP) {
> > swap(s, d);
> > swap(clear, rescue);
> > }
> > - memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
> > - memmove(uniscr->lines + d, uniscr->lines + s,
> > - (b - t - nr) * sizeof(*uniscr->lines));
> > - memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
> > - vc_uniscr_clear_lines(vc, clear, nr);
> > + while (nr--) {
> > + char32_t *tmp;
> > + tmp = uniscr->lines[rescue];
> > + memmove(uniscr->lines + d, uniscr->lines + s,
> > + (b - t - 1) * sizeof(*uniscr->lines));
> > + uniscr->lines[clear] = tmp;
> > + vc_uniscr_clear_lines(vc, clear, 1);
> > + }
> > }
> > }
>
> What the function does is rotating an array (slice [t..b) here), by nr if
> SM_DOWN or by -nr ie (b - t - nr) if SM_UP. A nice problem that almost every
> "code interview questions" book includes :)
>
> Please say if you don't have time for such games, I've just refreshed what's
> a good answer. :þ
>
>
> Meow.
> --
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets. Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.
>
Re: [PATCH 1/3] vt: avoid a VLA in the unicode screen scroll function
On Wed, 18 Jul 2018, Adam Borowski wrote:
> On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> > The nr argument is typically small: most often nr == 1. However this
> > could be abused with a very large explicit scroll in a resized screen.
> > Make the code scroll lines one at a time in all cases to avoid the VLA.
> > Anything smarter is most likely not warranted here.
>
> Even though nr can be 32767 at most, your new version is O(nr*nr) for no
> reason. Instead of O(n) memory or O(n²) time, a variant of the original
> that copies values one at a time would be shorter and faster.
Well... even though nr _can_ be up to 32766 to be precise, it is most
likely to be just 1 in 99.9% of the cases. So in that case, you'll
execute the loop only once and the code is currently optimal with O(n).
If nr > 1 then the current cost is O(n*nr) where n is the height of the
scroll window i.e. relatively small in practice (typically between 25
and 60). There is no point optimizing for 32767 rows as that is rather
silly. If we had then the best solution would be a linked list rather
than an array.
But still, if nr > 2 that means you need a temporary storage because the
destination memory has to be preserved before the source memory can be
moved there, and that destination memory content cannot be stored in the
vacated source memory until the source content is moved. Copying values
one at a time cannot work because the destination memory, the source
memory, and the area where the previous content from the destination
memory will end up don't overlap most of the time.
That temporary storage was that VLA. We don't want VLAs. So how do we
efficiently allocate and deallocate memory for, say, 25 words? Maybe
that doesn't have to be efficient because that doesn't happen very often
as we said, at which point we can just do it in a loop with a one-line
increment instead, as this patch does.
If you still have a more clever way of doing this then please propose it
in code form (I'm genuinely curious of what you have in mind). But let's
get the baseline working in an obvious "correct" way first.
> > Requested-by: Kees Cook
> > Signed-off-by: Nicolas Pitre
> > ---
> > drivers/tty/vt/vt.c | 18 ++
> > 1 file changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 2d14bb195d..03e79f7787 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -433,20 +433,22 @@ static void vc_uniscr_scroll(struct vc_data *vc,
> > unsigned int t, unsigned int b,
> >
> > if (uniscr) {
> > unsigned int s, d, rescue, clear;
> > - char32_t *save[nr];
> >
> > s = clear = t;
> > - d = t + nr;
> > - rescue = b - nr;
> > + d = t + 1;
> > + rescue = b - 1;
> > if (dir == SM_UP) {
> > swap(s, d);
> > swap(clear, rescue);
> > }
> > - memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
> > - memmove(uniscr->lines + d, uniscr->lines + s,
> > - (b - t - nr) * sizeof(*uniscr->lines));
> > - memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
> > - vc_uniscr_clear_lines(vc, clear, nr);
> > + while (nr--) {
> > + char32_t *tmp;
> > + tmp = uniscr->lines[rescue];
> > + memmove(uniscr->lines + d, uniscr->lines + s,
> > + (b - t - 1) * sizeof(*uniscr->lines));
> > + uniscr->lines[clear] = tmp;
> > + vc_uniscr_clear_lines(vc, clear, 1);
> > + }
> > }
> > }
>
> What the function does is rotating an array (slice [t..b) here), by nr if
> SM_DOWN or by -nr ie (b - t - nr) if SM_UP. A nice problem that almost every
> "code interview questions" book includes :)
>
> Please say if you don't have time for such games, I've just refreshed what's
> a good answer. :þ
>
>
> Meow.
> --
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets. Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.
>
Re: [PATCH v2 7/7] proc/kcore: add vmcoreinfo note to /proc/kcore
On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote: > From: Omar Sandoval > > The vmcoreinfo information is useful for runtime debugging tools, not > just for crash dumps. A lot of this information can be determined by > other means, but this is much more convenient. > What effect does this have upon the overall size of the dump file?
Re: [PATCH v2 7/7] proc/kcore: add vmcoreinfo note to /proc/kcore
On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote: > From: Omar Sandoval > > The vmcoreinfo information is useful for runtime debugging tools, not > just for crash dumps. A lot of this information can be determined by > other means, but this is much more convenient. > What effect does this have upon the overall size of the dump file?
Re: [PATCH] tpm: Add module parameter for hwrng quality.
On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard wrote: > On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild wrote: >> As a point of clarification (and correct me if I'm wrong), the TPM is >> always ready used to seed the rng. It just doesn't update the entropy >> pool estimate. > > Good point. > >> >> So, perhaps the default value for the TPM hwrng quality should be >> non-zero (in addition to the module param that lets users override >> it)? > > That makes sense to me, however I can imagine that some users would > prefer to not have the TPM enabled as an ongoing source of entropy by > default. Fair enough. > Following on from your previous point - perhaps we can just make a > small change to how the initial seeding is done: maybe we can replace > the call to crng_slow_load (via add_early_randomness and > add_device_randomness) with a call (indirectly) to crng_fast_load. (We > might also need to increase the amount of data read at this point.) > > This would update crng_init_cnt and crng_init, and calls to getrandom > [without GRND_RANDOM] would not block. Interesting. add_hwgenereator_randomness() will call crng_fast_load(), regardless of entropy estimate/quality, if crng_init is 0. So initializing crng_init from the hwrng, regardless of quality, is already the intent. But hw_random only calls add_hwgenerator_randomness() if current_quality > 0, via the hwrng_fillfn() kthread. All that to say, I agree. add_early_randomness() should (indirectly) call crng_fast_load(), like add_hwgenerator_randomness() does. > This obviously doesn't solve the issue if there are blocking calls on > boot that are querying random rather than urandom; I don't believe > that would be a problem for our use case though. > It wouldn't be a problem for our use case either. Best, David
Re: [PATCH] tpm: Add module parameter for hwrng quality.
On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard wrote: > On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild wrote: >> As a point of clarification (and correct me if I'm wrong), the TPM is >> always ready used to seed the rng. It just doesn't update the entropy >> pool estimate. > > Good point. > >> >> So, perhaps the default value for the TPM hwrng quality should be >> non-zero (in addition to the module param that lets users override >> it)? > > That makes sense to me, however I can imagine that some users would > prefer to not have the TPM enabled as an ongoing source of entropy by > default. Fair enough. > Following on from your previous point - perhaps we can just make a > small change to how the initial seeding is done: maybe we can replace > the call to crng_slow_load (via add_early_randomness and > add_device_randomness) with a call (indirectly) to crng_fast_load. (We > might also need to increase the amount of data read at this point.) > > This would update crng_init_cnt and crng_init, and calls to getrandom > [without GRND_RANDOM] would not block. Interesting. add_hwgenereator_randomness() will call crng_fast_load(), regardless of entropy estimate/quality, if crng_init is 0. So initializing crng_init from the hwrng, regardless of quality, is already the intent. But hw_random only calls add_hwgenerator_randomness() if current_quality > 0, via the hwrng_fillfn() kthread. All that to say, I agree. add_early_randomness() should (indirectly) call crng_fast_load(), like add_hwgenerator_randomness() does. > This obviously doesn't solve the issue if there are blocking calls on > boot that are querying random rather than urandom; I don't believe > that would be a problem for our use case though. > It wouldn't be a problem for our use case either. Best, David
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote: > From: Omar Sandoval > > Now we only need kclist_lock from user context and at fs init time, and > the following changes need to sleep while holding the kclist_lock. > > ... > > --- a/fs/proc/kcore.c > +++ b/fs/proc/kcore.c > @@ -59,8 +59,8 @@ struct memelfnote > }; > > static LIST_HEAD(kclist_head); > -static DEFINE_RWLOCK(kclist_lock); > -static int kcore_need_update = 1; > +static DECLARE_RWSEM(kclist_lock); > +static atomic_t kcore_need_update = ATOMIC_INIT(1); It's unclear why kcore_need_update was changed to atomic_t - it's still updated under kclist_lock? Maybe it's for a later patch.
Re: [PATCH v2 2/7] proc/kcore: replace kclist_lock rwlock with rwsem
On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote: > From: Omar Sandoval > > Now we only need kclist_lock from user context and at fs init time, and > the following changes need to sleep while holding the kclist_lock. > > ... > > --- a/fs/proc/kcore.c > +++ b/fs/proc/kcore.c > @@ -59,8 +59,8 @@ struct memelfnote > }; > > static LIST_HEAD(kclist_head); > -static DEFINE_RWLOCK(kclist_lock); > -static int kcore_need_update = 1; > +static DECLARE_RWSEM(kclist_lock); > +static atomic_t kcore_need_update = ATOMIC_INIT(1); It's unclear why kcore_need_update was changed to atomic_t - it's still updated under kclist_lock? Maybe it's for a later patch.
