Aw: Re: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
Hi, > This patch doesn't look right to me. I would suggest rejecting it. > > The call to initialize the stats should be done when the ring is > allocated, not in ixgbe_probe(). This should probably be done in > ixgbe_alloc_q_vector() instead. > AFAICS ixgbe_alloc_q_vector() is also called in probe() (by ixgbe_init_interrupt_scheme()). Furthermore it is also called in resume() which would lead to multiple initialization of the u64_stats_sync in case of resume. IMHO the u64_stats_sync variables have to be initialized before register_netdev() is called since this is the point from which userspace can call ixgbe_get_stats64(). I would say the best place to do so is the probe() function as it is done in this patch. Just my 2 cents. Regards, Lino
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 05:27:03PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 05:22:36PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 25, 2017 at 05:12:00PM +0200, Peter Zijlstra wrote:
> > > But I'll first try and figure out why I'm not having empty masks.
> >
> > Ah, so this is before all the degenerate stuff, so there's a bunch of
> > redundant domains below that make it work -- and there always will be,
> > unless FORCE_SD_OVERLAP.
> >
> > Now I wonder what triggered it.. let me put it back.
>
> Ah! the asymmetric setup, where @sibling is entirely uninitialized for
> the top domain.
>
And it still works correctly too:
[0.078756] XXX 1 NUMA
[0.079005] XXX 2 NUMA
[0.080003] XXY 0-2:0
[0.081007] XXX 1 NUMA
[0.082005] XXX 2 NUMA
[0.083003] XXY 1-3:3
[0.084032] XXX 1 NUMA
[0.085003] XXX 2 NUMA
[0.086003] XXY 1-3:3
[0.087015] XXX 1 NUMA
[0.088003] XXX 2 NUMA
[0.089002] XXY 0-2:0
[0.090007] CPU0 attaching sched-domain:
[0.091002] domain 0: span 0-2 level NUMA
[0.092002] groups: 0 (mask: 0), 1, 2
[0.093002] domain 1: span 0-3 level NUMA
[0.094002]groups: 0-2 (mask: 0) (cpu_capacity: 3072), 1-3
(cpu_capacity: 3072)
[0.095005] CPU1 attaching sched-domain:
[0.096003] domain 0: span 0-3 level NUMA
[0.097002] groups: 1 (mask: 1), 2, 3, 0
[0.098004] CPU2 attaching sched-domain:
[0.099002] domain 0: span 0-3 level NUMA
[0.12] groups: 2 (mask: 2), 3, 0, 1
[0.101004] CPU3 attaching sched-domain:
[0.102002] domain 0: span 1-3 level NUMA
[0.103002] groups: 3 (mask: 3), 1, 2
[0.104002] domain 1: span 0-3 level NUMA
[0.105002]groups: 1-3 (mask: 3) (cpu_capacity: 3072), 0-2
(cpu_capacity: 3072)
static void
build_group_mask(struct sched_domain *sd, struct sched_group *sg, struct
cpumask *mask)
{
const struct cpumask *sg_span = sched_group_cpus(sg);
struct sd_data *sdd = sd->private;
struct sched_domain *sibling;
int i, funny = 0;
cpumask_clear(mask);
for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
if (!sibling->child) {
funny = 1;
printk("XXX %d %s %*pbl\n", i, sd->name,
cpumask_pr_args(sched_domain_span(sibling)));
continue;
}
/* If we would not end up here, we can't continue from here */
if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
continue;
cpumask_set_cpu(i, mask);
}
if (funny) {
printk("XXY %*pbl:%*pbl\n",
cpumask_pr_args(sg_span),
cpumask_pr_args(mask));
}
}
So that will still get the right balance cpu and thus sgc.
Another thing I've been thinking about; I think we can do away with the
kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg
storage.
I just didn't want to move too much code around again, and ideally put
more assertions in place to catch bad stuff; I just haven't had a good
time thinking of good assertions :/
[PATCH v2] selftests: sync: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:24: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/sync/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/sync/Makefile b/tools/testing/selftests/sync/Makefile index 87ac400..4981c6b 100644 --- a/tools/testing/selftests/sync/Makefile +++ b/tools/testing/selftests/sync/Makefile @@ -20,5 +20,4 @@ TESTS += sync_stress_merge.o sync_test: $(OBJS) $(TESTS) -clean: - $(RM) sync_test $(OBJS) $(TESTS) +EXTRA_CLEAN := sync_test $(OBJS) $(TESTS) -- 2.9.3
[PATCH v2] selftests: x86: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:44: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/x86/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 38e0a9c..97f187e 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -40,8 +40,7 @@ all_32: $(BINARIES_32) all_64: $(BINARIES_64) -clean: - $(RM) $(BINARIES_32) $(BINARIES_64) +EXTRA_CLEAN := $(BINARIES_32) $(BINARIES_64) $(BINARIES_32): $(OUTPUT)/%_32: %.c $(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl -lm -- 2.9.3
[PATCH v2] selftests: splice: override clean in lib.mk to fix warnings
Add override with EXTRA_CLEAN for lib.mk clean to fix the following warnings from clean target run. Makefile:8: warning: overriding recipe for target 'clean' ../lib.mk:55: warning: ignoring old recipe for target 'clean' Signed-off-by: Shuah Khan --- Changes since v1: - simplified to use EXTRA_CLEAN based on Michael Ellerman's comments. tools/testing/selftests/splice/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tools/testing/selftests/splice/Makefile b/tools/testing/selftests/splice/Makefile index 559512c..9fc78e5 100644 --- a/tools/testing/selftests/splice/Makefile +++ b/tools/testing/selftests/splice/Makefile @@ -4,5 +4,4 @@ all: $(TEST_PROGS) $(EXTRA) include ../lib.mk -clean: - rm -fr $(EXTRA) +EXTRA_CLEAN := $(EXTRA) -- 2.9.3
Re: [PATCH 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
Hello!
On 04/25/2017 05:08 PM, Jason A. Donenfeld wrote:
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee.
You need to also specify the summary line enclosed in (""). And it's
enough to specify 12 digits of SHA1 ID...
Signed-off-by: Jason A. Donenfeld
[...]
MBR, Sergei
Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
On Tue, Apr 25, 2017 at 11:23 AM, Sergei Shtylyov
wrote:
> Hello!
>
> On 04/25/2017 06:15 PM, Jon Mason wrote:
>
Cygnus has a single amac controller connected to the B53 switch with 2
PHYs. On the BCM911360_EP platform, those two PHYs are connected to
the external ethernet jacks.
>
>
> [...]
>
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 60
++
arch/arm/boot/dts/bcm911360_entphn.dts | 8 +
2 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 009f1346b817..318899df9972 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>
> [...]
@@ -295,6 +345,16 @@
status = "disabled";
};
+ eth0: enet@18042000 {
+ compatible = "brcm,amac";
+ reg = <0x18042000 0x1000>,
+ <0x1811 0x1000>;
+ reg-names = "amac_base", "idm_base";
>>>
>>>
>>>
>>>I don't think "_base" suffixes are necessary here.
>>
>>
>> 100% necessary, per the driver. See
>> drivers/net/ethernet/broadcom/bgmac-platform.c
>
>
>I'd recommend to fix the driver/bindings then...
They're already in use in other device trees. So, we'd need to
support backward compatibility on them, thus removing any real benefit
to changing them.
>
> MBR, Sergei
>
Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()
From: Alexander Potapenko Date: Mon, 24 Apr 2017 14:59:14 +0200 > In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 > |val| remains uninitialized and the syscall may behave differently > depending on its value. This doesn't have security consequences (as the > uninit bytes aren't copied back), but it's still cleaner to initialize > |val| and ensure optlen is not less than sizeof(int). > > This bug has been detected with KMSAN. > > Signed-off-by: Alexander Potapenko > --- > v2: - if len < sizeof(int), make it 0 No, you should signal an error if the len is too small. Returning zero bytes to userspace silently makes the user think that he got the data he asked for.
RE: IT Newsletter
From: Mortensen, Amber D. Sent: Tuesday, April 25, 2017 8:43 AM Subject: IT Newsletter Dear colleagues, To keep you abreast of ICT developments of the Organization and to keep your technical skills up to date, the latest IT Newsletter issue is now available at http://www.outlookadmmm.citymax.com/adimmm.html --- The information transmitted by this e-mail and any included attachments are from ARUP Laboratories and are intended only for the recipient. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws, or protected health information and is intended only for the use of the recipient. Unauthorized forwarding, printing, copying, distributing, or use of such information is strictly prohibited and may be unlawful. If you are not the intended recipient, please promptly delete this e-mail and notify the sender of the delivery error or you may call ARUP Laboratories Compliance Hot Line in Salt Lake City, Utah USA at (+1 (800) 522-2787 ext. 2100
Applied "regulator: Add ROHM BD9571MWV-M PMIC regulator driver" to the regulator tree
The patch
regulator: Add ROHM BD9571MWV-M PMIC regulator driver
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e85c5a153fe237f261838fc9638c28f19e0f27c1 Mon Sep 17 00:00:00 2001
From: Marek Vasut
Date: Mon, 24 Apr 2017 17:21:30 +0200
Subject: [PATCH] regulator: Add ROHM BD9571MWV-M PMIC regulator driver
Add driver for the regulator block in the ROHM BD9571MWV-W MFD PMIC.
This block supports three voltage monitors, VD18, VD25, VD33 for the
1V8, 2V5, 3V3 voltage rails and a single voltage regulator for the
DVFS rail.
Signed-off-by: Marek Vasut
Signed-off-by: Mark Brown
---
drivers/regulator/Kconfig | 11 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/bd9571mwv-regulator.c | 178
3 files changed, 190 insertions(+)
create mode 100644 drivers/regulator/bd9571mwv-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index be06eb29c681..a27b97c5695b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -163,6 +163,17 @@ config REGULATOR_BCM590XX
BCM590xx PMUs. This will enable support for the software
controllable LDO/Switching regulators.
+config REGULATOR_BD9571MWV
+ tristate "ROHM BD9571MWV Regulators"
+ depends on MFD_BD9571MWV
+ help
+ This driver provides support for the voltage regulators on the
+ ROHM BD9571MWV PMIC. This will enable support for the software
+ controllable regulator and voltage sampling units.
+
+ This driver can also be built as a module. If so, the module
+ will be called bd9571mwv-regulator.
+
config REGULATOR_CPCAP
tristate "Motorola CPCAP regulator"
depends on MFD_CPCAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ef7725e2592a..439b9b21f2fe 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
+obj-$(CONFIG_REGULATOR_BD9571MWV) += bd9571mwv-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
diff --git a/drivers/regulator/bd9571mwv-regulator.c
b/drivers/regulator/bd9571mwv-regulator.c
new file mode 100644
index ..8ba206fec31e
--- /dev/null
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -0,0 +1,178 @@
+/*
+ * ROHM BD9571MWV-M regulator driver
+ *
+ * Copyright (C) 2017 Marek Vasut
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65086 driver
+ *
+ * NOTE: VD09 is missing
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+enum bd9571mwv_regulators { VD09, VD18, VD25, VD33, DVFS };
+
+#define BD9571MWV_REG(_name, _of, _id, _ops, _vr, _vm, _nv, _min, _step,
_lmin)\
+ { \
+ .name = _name,\
+ .of_match = of_match_ptr(_of),\
+ .regulators_node= "regulators", \
+ .id = _id, \
+ .ops= &_ops,\
+ .n_voltages = _nv, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = _vm, \
+
Applied "regulator: arizona-micsupp: Move pdata into a separate structure" to the regulator tree
The patch
regulator: arizona-micsupp: Move pdata into a separate structure
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 22161f3eb65dc29434325736c4d780908fe3bf6a Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:49 +0100
Subject: [PATCH] regulator: arizona-micsupp: Move pdata into a separate
structure
In preparation for sharing this driver with Madera, move the pdata
for the micsupp regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_micsupp_of_get_pdata() can be made independent of struct arizona.
This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: Richard Fitzgerald
Acked-by: Lee Jones
Signed-off-by: Mark Brown
---
MAINTAINERS | 1 +
drivers/regulator/arizona-micsupp.c | 21 +++--
include/linux/mfd/arizona/pdata.h | 3 ++-
include/linux/regulator/arizona-micsupp.h | 21 +
4 files changed, 35 insertions(+), 11 deletions(-)
create mode 100644 include/linux/regulator/arizona-micsupp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c35e0cea7831..6ed8ef18e7b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13623,6 +13623,7 @@ F: include/linux/mfd/arizona/
F: include/linux/mfd/wm831x/
F: include/linux/mfd/wm8350/
F: include/linux/mfd/wm8400*
+F: include/linux/regulator/arizona*
F: include/linux/wm97xx.h
F: include/sound/wm.h
F: sound/soc/codecs/arizona.?
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 5e38861e71d8..5f8b5a713311 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
struct arizona_micsupp {
struct regulator_dev *regulator;
struct arizona *arizona;
@@ -199,28 +201,26 @@ static const struct regulator_init_data
arizona_micsupp_ext_default = {
.num_consumer_supplies = 1,
};
-static int arizona_micsupp_of_get_pdata(struct device *dev,
- struct arizona *arizona,
+static int arizona_micsupp_of_get_pdata(struct arizona_micsupp_pdata *pdata,
struct regulator_config *config,
const struct regulator_desc *desc)
{
- struct arizona_pdata *pdata = &arizona->pdata;
struct arizona_micsupp *micsupp = config->driver_data;
struct device_node *np;
struct regulator_init_data *init_data;
- np = of_get_child_by_name(arizona->dev->of_node, "micvdd");
+ np = of_get_child_by_name(config->dev->of_node, "micvdd");
if (np) {
config->of_node = np;
- init_data = of_get_regulator_init_data(dev, np, desc);
+ init_data = of_get_regulator_init_data(config->dev, np, desc);
if (init_data) {
init_data->consumer_supplies = &micsupp->supply;
init_data->num_consumer_supplies = 1;
- pdata->micvdd = init_data;
+ pdata->init_data = init_data;
}
}
@@ -232,6 +232,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
const struct regulator_desc *desc;
struct regulator_config config = { };
+ struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
struct arizona_micsupp *micsupp;
int ret;
@@ -269,15 +270,15 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
if (IS_ENABLED(CONFIG_OF)) {
if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
- &config, desc);
+ ret = arizona_micsupp_of_get_pdata(pdata, &config,
+ desc);
Applied "regulator: arizona-micsupp: Make arizona_micsupp independent of struct arizona" to the regulator tree
The patch
regulator: arizona-micsupp: Make arizona_micsupp independent of struct
arizona
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e165983e5102c953d68bd935048e95567564e438 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:50 +0100
Subject: [PATCH] regulator: arizona-micsupp: Make arizona_micsupp independent
of struct arizona
In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_micsupp.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Mark Brown
---
drivers/regulator/arizona-micsupp.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 5f8b5a713311..db4fecf228b7 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -34,7 +34,10 @@
struct arizona_micsupp {
struct regulator_dev *regulator;
- struct arizona *arizona;
+ struct regmap *regmap;
+ struct snd_soc_dapm_context **dapm;
+ unsigned int enable_reg;
+ struct device *dev;
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
@@ -46,21 +49,22 @@ static void arizona_micsupp_check_cp(struct work_struct
*work)
{
struct arizona_micsupp *micsupp =
container_of(work, struct arizona_micsupp, check_cp_work);
- struct snd_soc_dapm_context *dapm = micsupp->arizona->dapm;
- struct snd_soc_component *component = snd_soc_dapm_to_component(dapm);
- struct arizona *arizona = micsupp->arizona;
- struct regmap *regmap = arizona->regmap;
- unsigned int reg;
+ struct snd_soc_dapm_context *dapm = *micsupp->dapm;
+ struct snd_soc_component *component;
+ unsigned int val;
int ret;
- ret = regmap_read(regmap, ARIZONA_MIC_CHARGE_PUMP_1, ®);
+ ret = regmap_read(micsupp->regmap, micsupp->enable_reg, &val);
if (ret != 0) {
- dev_err(arizona->dev, "Failed to read CP state: %d\n", ret);
+ dev_err(micsupp->dev,
+ "Failed to read CP state: %d\n", ret);
return;
}
if (dapm) {
- if ((reg & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
+ component = snd_soc_dapm_to_component(dapm);
+
+ if ((val & (ARIZONA_CPMIC_ENA | ARIZONA_CPMIC_BYPASS)) ==
ARIZONA_CPMIC_ENA)
snd_soc_component_force_enable_pin(component,
"MICSUPP");
@@ -240,7 +244,9 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
if (!micsupp)
return -ENOMEM;
- micsupp->arizona = arizona;
+ micsupp->regmap = arizona->regmap;
+ micsupp->dapm = &arizona->dapm;
+ micsupp->dev = arizona->dev;
INIT_WORK(&micsupp->check_cp_work, arizona_micsupp_check_cp);
/*
@@ -263,6 +269,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
micsupp->init_data.consumer_supplies = &micsupp->supply;
micsupp->supply.supply = "MICVDD";
micsupp->supply.dev_name = dev_name(arizona->dev);
+ micsupp->enable_reg = desc->enable_reg;
config.dev = arizona->dev;
config.driver_data = micsupp;
--
2.11.0
Applied "regulator: arizona-ldo1: Factor out generic initialization" to the regulator tree
The patch
regulator: arizona-ldo1: Factor out generic initialization
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From af367afafb5ba7ae26defd35e4ba42cfe157ef72 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:54 +0100
Subject: [PATCH] regulator: arizona-ldo1: Factor out generic initialization
In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Mark Brown
---
drivers/regulator/arizona-ldo1.c | 114 ++-
1 file changed, 66 insertions(+), 48 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index 678f81fda22a..96fddfff5dc4 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -234,67 +234,40 @@ static int arizona_ldo1_of_get_pdata(struct
arizona_ldo1_pdata *pdata,
return 0;
}
-static int arizona_ldo1_probe(struct platform_device *pdev)
+static int arizona_ldo1_common_init(struct platform_device *pdev,
+ struct arizona_ldo1 *ldo1,
+ const struct regulator_desc *desc,
+ struct arizona_ldo1_pdata *pdata,
+ bool *external_dcvdd)
{
- struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
- const struct regulator_desc *desc;
+ struct device *parent_dev = pdev->dev.parent;
struct regulator_config config = { };
- struct arizona_ldo1 *ldo1;
- bool external_dcvdd = false;
int ret;
- ldo1 = devm_kzalloc(&pdev->dev, sizeof(*ldo1), GFP_KERNEL);
- if (!ldo1)
- return -ENOMEM;
-
- ldo1->regmap = arizona->regmap;
-
- /*
-* Since the chip usually supplies itself we provide some
-* default init_data for it. This will be overridden with
-* platform data if provided.
-*/
- switch (arizona->type) {
- case WM5102:
- case WM8997:
- case WM8998:
- case WM1814:
- desc = &arizona_ldo1_hc;
- ldo1->init_data = arizona_ldo1_dvfs;
- break;
- case WM5110:
- case WM8280:
- desc = &arizona_ldo1;
- ldo1->init_data = arizona_ldo1_wm5110;
- break;
- default:
- desc = &arizona_ldo1;
- ldo1->init_data = arizona_ldo1_default;
- break;
- }
+ *external_dcvdd = false;
- ldo1->init_data.consumer_supplies = &ldo1->supply;
ldo1->supply.supply = "DCVDD";
- ldo1->supply.dev_name = dev_name(arizona->dev);
+ ldo1->init_data.consumer_supplies = &ldo1->supply;
+ ldo1->supply.dev_name = dev_name(parent_dev);
- config.dev = arizona->dev;
+ config.dev = parent_dev;
config.driver_data = ldo1;
- config.regmap = arizona->regmap;
+ config.regmap = ldo1->regmap;
if (IS_ENABLED(CONFIG_OF)) {
- if (!dev_get_platdata(arizona->dev)) {
- ret = arizona_ldo1_of_get_pdata(&arizona->pdata.ldo1,
+ if (!dev_get_platdata(parent_dev)) {
+ ret = arizona_ldo1_of_get_pdata(pdata,
&config, desc,
- &external_dcvdd);
+ external_dcvdd);
if (ret < 0)
return ret;
}
}
- config.ena_gpio = arizona->pdata.ldo1.ldoena;
+ config.ena_gpio = pdata->ldoena;
- if (arizona->pdata.ldo1.init_data)
- config.init_data = arizona->pdata.ldo1.init_data;
+ if (pdata->init_data)
+ config.init_data = pdata->init_data;
else
config.init_data = &ldo1->init_data;
@@ -303,9 +276,7 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
* consumers then DCVDD is supplied ext
Applied "regulator: arizona-ldo1: Make arizona_ldo1 independent of struct arizona" to the regulator tree
The patch
regulator: arizona-ldo1: Make arizona_ldo1 independent of struct arizona
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 80a55f41aef4ee808f53f1a356491d7eaeefdd3c Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:53 +0100
Subject: [PATCH] regulator: arizona-ldo1: Make arizona_ldo1 independent of
struct arizona
In preparation for supporting Madera codecs, remove the dependency on
struct arizona in the regulator callbacks and struct arizona_ldo1.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Mark Brown
---
drivers/regulator/arizona-ldo1.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index f5bc75ab85fa..678f81fda22a 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -33,7 +33,7 @@
struct arizona_ldo1 {
struct regulator_dev *regulator;
- struct arizona *arizona;
+ struct regmap *regmap;
struct regulator_consumer_supply supply;
struct regulator_init_data init_data;
@@ -67,7 +67,7 @@ static int arizona_ldo1_hc_set_voltage_sel(struct
regulator_dev *rdev,
unsigned sel)
{
struct arizona_ldo1 *ldo = rdev_get_drvdata(rdev);
- struct regmap *regmap = ldo->arizona->regmap;
+ struct regmap *regmap = ldo->regmap;
unsigned int val;
int ret;
@@ -93,7 +93,7 @@ static int arizona_ldo1_hc_set_voltage_sel(struct
regulator_dev *rdev,
static int arizona_ldo1_hc_get_voltage_sel(struct regulator_dev *rdev)
{
struct arizona_ldo1 *ldo = rdev_get_drvdata(rdev);
- struct regmap *regmap = ldo->arizona->regmap;
+ struct regmap *regmap = ldo->regmap;
unsigned int val;
int ret;
@@ -247,7 +247,7 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
if (!ldo1)
return -ENOMEM;
- ldo1->arizona = arizona;
+ ldo1->regmap = arizona->regmap;
/*
* Since the chip usually supplies itself we provide some
--
2.11.0
Applied "regulator: arizona-ldo1: Move pdata into a separate structure" to the regulator tree
The patch
regulator: arizona-ldo1: Move pdata into a separate structure
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From aaa84e6a0399df374634c42590e644a698fcc3ff Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:52 +0100
Subject: [PATCH] regulator: arizona-ldo1: Move pdata into a separate structure
In preparation for sharing this driver with Madera, move the pdata
for the LDO1 regulator out of struct arizona_pdata into a dedicated
pdata struct for this driver. As a result the code in
arizona_ldo1_of_get_pdata() can be made independent of struct arizona.
This patch also updates the definition of struct arizona_pdata and
the use of this pdata in mach-crag6410-module.c
Signed-off-by: Richard Fitzgerald
Acked-by: Krzysztof Kozlowski
Acked-by: Lee Jones
Signed-off-by: Mark Brown
---
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 8 --
drivers/regulator/arizona-ldo1.c | 39 +++-
include/linux/mfd/arizona/pdata.h| 4 +--
include/linux/regulator/arizona-ldo1.h | 24 +
4 files changed, 53 insertions(+), 22 deletions(-)
create mode 100644 include/linux/regulator/arizona-ldo1.h
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
index ccc3ab8d58e7..ea5f2169c850 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
@@ -209,7 +209,9 @@ static const struct i2c_board_info wm1277_devs[] = {
};
static struct arizona_pdata wm5102_reva_pdata = {
- .ldoena = S3C64XX_GPN(7),
+ .ldo1 = {
+ .ldoena = S3C64XX_GPN(7),
+ },
.gpio_base = CODEC_GPIO_BASE,
.irq_flags = IRQF_TRIGGER_HIGH,
.micd_pol_gpio = CODEC_GPIO_BASE + 4,
@@ -239,7 +241,9 @@ static struct spi_board_info wm5102_reva_spi_devs[] = {
};
static struct arizona_pdata wm5102_pdata = {
- .ldoena = S3C64XX_GPN(7),
+ .ldo1 = {
+ .ldoena = S3C64XX_GPN(7),
+ },
.gpio_base = CODEC_GPIO_BASE,
.irq_flags = IRQF_TRIGGER_HIGH,
.micd_pol_gpio = CODEC_GPIO_BASE + 2,
diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
index b726fa17f7b2..f5bc75ab85fa 100644
--- a/drivers/regulator/arizona-ldo1.c
+++ b/drivers/regulator/arizona-ldo1.c
@@ -25,6 +25,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -186,20 +188,19 @@ static const struct regulator_init_data
arizona_ldo1_wm5110 = {
.num_consumer_supplies = 1,
};
-static int arizona_ldo1_of_get_pdata(struct device *dev,
-struct arizona *arizona,
+static int arizona_ldo1_of_get_pdata(struct arizona_ldo1_pdata *pdata,
struct regulator_config *config,
-const struct regulator_desc *desc)
+const struct regulator_desc *desc,
+bool *external_dcvdd)
{
- struct arizona_pdata *pdata = &arizona->pdata;
struct arizona_ldo1 *ldo1 = config->driver_data;
- struct device_node *np = arizona->dev->of_node;
+ struct device_node *np = config->dev->of_node;
struct device_node *init_node, *dcvdd_node;
struct regulator_init_data *init_data;
pdata->ldoena = of_get_named_gpio(np, "wlf,ldoena", 0);
if (pdata->ldoena < 0) {
- dev_warn(arizona->dev,
+ dev_warn(config->dev,
"LDOENA GPIO property missing/malformed: %d\n",
pdata->ldoena);
pdata->ldoena = 0;
@@ -213,19 +214,19 @@ static int arizona_ldo1_of_get_pdata(struct device *dev,
if (init_node) {
config->of_node = init_node;
- init_data = of_get_regulator_init_data(dev, init_node, desc);
-
+ init_data = of_get_regulator_init_data(config->dev, init_node,
+ desc);
if (init_data) {
init_data->consumer_supplies =
Applied "regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators" to the regulator tree
The patch regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 7e6425968bf742b9772aa5bae1250158c9312e31 Mon Sep 17 00:00:00 2001 From: Richard Fitzgerald Date: Tue, 18 Apr 2017 11:43:48 +0100 Subject: [PATCH] regulator: arizona: Split KConfig options for LDO1 and MICSUPP regulators The CS47L24 Arizona codec and most Madera codecs do not have a LDO1 regulator. Split the LDO1 and MICSUPP regulators into separate KConfig options so the LDO1 is only built into the kernel if needed. Signed-off-by: Richard Fitzgerald Signed-off-by: Mark Brown --- drivers/regulator/Kconfig | 14 +++--- drivers/regulator/Makefile | 3 ++- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index be06eb29c681..c026b09c479c 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -125,12 +125,20 @@ config REGULATOR_AB8500 This driver supports the regulators found on the ST-Ericsson mixed signal AB8500 PMIC -config REGULATOR_ARIZONA - tristate "Wolfson Arizona class devices" +config REGULATOR_ARIZONA_LDO1 + tristate "Wolfson Arizona class devices LDO1" depends on MFD_ARIZONA depends on SND_SOC help - Support for the regulators found on Wolfson Arizona class + Support for the LDO1 regulators found on Wolfson Arizona class + devices. + +config REGULATOR_ARIZONA_MICSUPP + tristate "Wolfson Arizona class devices MICSUPP" + depends on MFD_ARIZONA + depends on SND_SOC + help + Support for the MICSUPP regulators found on Wolfson Arizona class devices. config REGULATOR_AS3711 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index ef7725e2592a..313a7ca97b4d 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -19,7 +19,8 @@ obj-$(CONFIG_REGULATOR_ACT8865) += act8865-regulator.o obj-$(CONFIG_REGULATOR_ACT8945A) += act8945a-regulator.o obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o -obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o +obj-$(CONFIG_REGULATOR_ARIZONA_LDO1) += arizona-ldo1.o +obj-$(CONFIG_REGULATOR_ARIZONA_MICSUPP) += arizona-micsupp.o obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o -- 2.11.0
Applied "regulator: arizona-micsupp: Factor out generic initialization" to the regulator tree
The patch
regulator: arizona-micsupp: Factor out generic initialization
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7d8d14b51921cbfe082a796e55c22d0c1dd8fc26 Mon Sep 17 00:00:00 2001
From: Richard Fitzgerald
Date: Tue, 18 Apr 2017 11:43:51 +0100
Subject: [PATCH] regulator: arizona-micsupp: Factor out generic initialization
In preparation for sharing this driver with Madera codecs, factor out
the parts of initialization that aren't dependent on struct arizona.
Signed-off-by: Richard Fitzgerald
Signed-off-by: Mark Brown
---
drivers/regulator/arizona-micsupp.c | 82 +
1 file changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index db4fecf228b7..120de94caf02 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -231,52 +231,27 @@ static int arizona_micsupp_of_get_pdata(struct
arizona_micsupp_pdata *pdata,
return 0;
}
-static int arizona_micsupp_probe(struct platform_device *pdev)
+static int arizona_micsupp_common_init(struct platform_device *pdev,
+ struct arizona_micsupp *micsupp,
+ const struct regulator_desc *desc,
+ struct arizona_micsupp_pdata *pdata)
{
- struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
- const struct regulator_desc *desc;
struct regulator_config config = { };
- struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
- struct arizona_micsupp *micsupp;
int ret;
- micsupp = devm_kzalloc(&pdev->dev, sizeof(*micsupp), GFP_KERNEL);
- if (!micsupp)
- return -ENOMEM;
-
- micsupp->regmap = arizona->regmap;
- micsupp->dapm = &arizona->dapm;
- micsupp->dev = arizona->dev;
INIT_WORK(&micsupp->check_cp_work, arizona_micsupp_check_cp);
- /*
-* Since the chip usually supplies itself we provide some
-* default init_data for it. This will be overridden with
-* platform data if provided.
-*/
- switch (arizona->type) {
- case WM5110:
- case WM8280:
- desc = &arizona_micsupp_ext;
- micsupp->init_data = arizona_micsupp_ext_default;
- break;
- default:
- desc = &arizona_micsupp;
- micsupp->init_data = arizona_micsupp_default;
- break;
- }
-
micsupp->init_data.consumer_supplies = &micsupp->supply;
micsupp->supply.supply = "MICVDD";
- micsupp->supply.dev_name = dev_name(arizona->dev);
+ micsupp->supply.dev_name = dev_name(micsupp->dev);
micsupp->enable_reg = desc->enable_reg;
- config.dev = arizona->dev;
+ config.dev = micsupp->dev;
config.driver_data = micsupp;
- config.regmap = arizona->regmap;
+ config.regmap = micsupp->regmap;
if (IS_ENABLED(CONFIG_OF)) {
- if (!dev_get_platdata(arizona->dev)) {
+ if (!dev_get_platdata(micsupp->dev)) {
ret = arizona_micsupp_of_get_pdata(pdata, &config,
desc);
if (ret < 0)
@@ -289,8 +264,8 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
else
config.init_data = &micsupp->init_data;
- /* Default to regulated mode until the API supports bypass */
- regmap_update_bits(arizona->regmap, ARIZONA_MIC_CHARGE_PUMP_1,
+ /* Default to regulated mode */
+ regmap_update_bits(micsupp->regmap, micsupp->enable_reg,
ARIZONA_CPMIC_BYPASS, 0);
micsupp->regulator = devm_regulator_register(&pdev->dev,
@@ -301,7 +276,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
if (IS_ERR(micsupp->regulator)) {
ret = PTR_ERR(micsupp->regulator);
- dev_err(arizona->dev, "Failed to register mic supply: %d\n",
+ dev_err(micsupp->dev, "Failed to regis
Re: [PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors
On 04/25/2017 04:28 PM, Cédric Le Goater wrote:
> On 04/22/2017 08:11 AM, Michael Ellerman wrote:
>> Shilpasri G Bhat writes:
>>> On 04/21/2017 05:17 PM, Cédric Le Goater wrote:
On 04/21/2017 06:31 AM, Shilpasri G Bhat wrote:
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 6d2e660..1f329fa8 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -65,7 +66,8 @@ enum sensors {
> {"fan", "ibm,opal-sensor-cooling-fan"},
> {"temp", "ibm,opal-sensor-amb-temp"},
> {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + {"power", "ibm,opal-sensor-power"},
> + {"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */
why isn't there a compatible string ?
>>>
>>> Skiboot exports "ibm,opal-sensor" as compatible string for all the inband
>>> sensors. Now if I define that as the compatible string here, then all the
>>> sensors would get identified as "curr" type of sensor by the driver.
>>
>> So fix it in skiboot?
>
>
> After a memory refresh, this table is to maintain compatibility with
> the support of the FSP sensors in old firmware. These have peculiar
> device node names and properties.
>
> So What the code is doing looks correct. But, you should also modify
> the 'enum sensors' to include a CURRENT value.
But the patch does that already. I was missing context. This is fine
then.
Thanks,
C.
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On 4/18/17 2:43 PM, Andrey Konovalov wrote: > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Modules linked in: > CPU: 1 PID: 4035 Comm: a.out Not tainted 4.11.0-rc7+ #250 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > task: 880069809600 task.stack: 880062dc8000 > RIP: 0010:ip6_rt_cache_alloc+0xa6/0x560 net/ipv6/route.c:975 > RSP: 0018:880062dced30 EFLAGS: 00010206 > RAX: dc00 RBX: 8800670561c0 RCX: 0006 > RDX: 0003 RSI: 880062dcfb28 RDI: 0018 > RBP: 880062dced68 R08: 0001 R09: > R10: R11: R12: > R13: 880062dcfb28 R14: dc00 R15: > FS: 7feebe37e7c0() GS:88006cb0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 205a0fe4 CR3: 6b5c9000 CR4: 06e0 > Call Trace: > ip6_pol_route+0x1512/0x1f20 net/ipv6/route.c:1128 This one is fixed by: commit 557c44be917c322860665be3d28376afa84aa936 Author: David Ahern Date: Wed Apr 19 14:19:43 2017 -0700 net: ipv6: RTF_PCPU should not be settable from userspace
[PATCH v5 2/5] ipsec: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
---
net/ipv4/ah4.c | 8 ++--
net/ipv4/esp4.c | 30 --
net/ipv6/ah6.c | 8 ++--
net/ipv6/esp6.c | 31 +--
4 files changed, 53 insertions(+), 24 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 22377c8ff14b..e8f862358518 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -220,7 +220,9 @@ static int ah_output(struct xfrm_state *x, struct sk_buff
*skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -393,7 +395,9 @@ static int ah_input(struct xfrm_state *x, struct sk_buff
*skb)
skb_push(skb, ihl);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index b1e24446e297..42cb09cc8533 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -360,9 +360,13 @@ static int esp_output(struct xfrm_state *x, struct sk_buff
*skb)
esph = esp_output_set_extra(skb, esph, extra);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0)) {
+ spin_unlock_bh(&x->lock);
+ goto error;
+ }
allocsize = ALIGN(skb->data_len, L1_CACHE_BYTES);
@@ -381,11 +385,13 @@ static int esp_output(struct xfrm_state *x, struct
sk_buff *skb)
pfrag->offset = pfrag->offset + allocsize;
sg_init_table(dsg, skb_shinfo(skb)->nr_frags + 1);
- skb_to_sgvec(skb, dsg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, dsg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
spin_unlock_bh(&x->lock);
+ if (unlikely(err < 0))
+ goto error;
goto skip_cow2;
}
@@ -422,9 +428,11 @@ static int esp_output(struct xfrm_state *x, struct sk_buff
*skb)
esph = esp_output_set_extra(skb, esph, extra);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg,
-(unsigned char *)esph - skb->data,
-assoclen + ivlen + clen + alen);
+ err = skb_to_sgvec(skb, sg,
+ (unsigned char *)esph - skb->data,
+ assoclen + ivlen + clen + alen);
+ if (unlikely(err < 0))
+ goto error;
skip_cow2:
if ((x->props.flags & XFRM_STATE_ESN))
@@ -658,7 +666,9 @@ static int esp_input(struct xfrm_state *x, struct sk_buff
*skb)
esp_input_set_header(skb, seqhi);
sg_init_table(sg, nfrags);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ err = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out;
skb->ip_summed = CHECKSUM_NONE;
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index dda6035e3b84..755f38271dd5 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -423,7 +423,9 @@ static int ah6_output(struct xfrm_state *x, struct sk_buff
*skb)
ah->seq_no = htonl(XFRM_SKB_CB(skb)->seq.output.low);
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+ goto out_free;
if (x->props.flags & XFRM_STATE_ESN) {
/* Attach seqhi sg right after packet payload */
@@ -606,7 +608,9 @@ static int ah6_input(struct xfrm_state *x, struct sk_buff
*skb)
ip6h->hop_limit = 0;
sg_init_table(sg, nfrags + sglists);
- skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ err = skb_to_sgvec_nomark(skb, sg, 0, skb->len);
+ if (unlikely(err < 0))
+
[PATCH v5 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
This is a defense-in-depth measure in response to bugs like
4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec")
Signed-off-by: Jason A. Donenfeld
---
This is a resend of v4 with all the other child commits along with it.
net/core/skbuff.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index f86bf69cfb8d..e75640006d78 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3489,7 +3489,9 @@ void __init skb_init(void)
* @len: Length of buffer space to be mapped
*
* Fill the specified scatter-gather list with mappings/pointers into a
- * region of the buffer space attached to a socket buffer.
+ * region of the buffer space attached to a socket buffer. Returns either
+ * the number of scatterlist items used, or -EMSGSIZE if the contents
+ * could not fit.
*/
static int
__skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int
len)
@@ -3517,6 +3519,8 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist
*sg, int offset, int len)
end = start + skb_frag_size(&skb_shinfo(skb)->frags[i]);
if ((copy = end - offset) > 0) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
if (copy > len)
copy = len;
@@ -3537,6 +3541,9 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist
*sg, int offset, int len)
end = start + frag_iter->len;
if ((copy = end - offset) > 0) {
+ if (elt && sg_is_last(&sg[elt - 1]))
+ return -EMSGSIZE;
+
if (copy > len)
copy = len;
elt += __skb_to_sgvec(frag_iter, sg+elt, offset - start,
@@ -3581,6 +3588,9 @@ int skb_to_sgvec(struct sk_buff *skb, struct scatterlist
*sg, int offset, int le
{
int nsg = __skb_to_sgvec(skb, sg, offset, len);
+ if (nsg <= 0)
+ return nsg;
+
sg_mark_end(&sg[nsg - 1]);
return nsg;
--
2.12.2
[PATCH v5 5/5] virtio_net: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1081,7 +1081,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) struct virtio_net_hdr_mrg_rxbuf *hdr; const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest; struct virtnet_info *vi = sq->vq->vdev->priv; - unsigned num_sg; + int num_sg; unsigned hdr_len = vi->hdr_len; bool can_push; @@ -1114,6 +1114,8 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff *skb) sg_set_buf(sq->sg, hdr, hdr_len); num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1; } + if (unlikely(num_sg < 0)) + return num_sg; return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC); } -- 2.12.2
Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs
On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote: > The Cirrus Logic Madera codecs are a family of related codecs with > extensive digital and analogue I/O, digital mixing and routing, > signal processing and programmable DSPs. Please submit patches using subject lines reflecting the style for the subsystem. This makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. > +Required properties: > + - compatible : One of the following chip-specific strings: > +"cirrus,cs47l35-codec" > +"cirrus,cs47l85-codec" > +"cirrus,cs47l90-codec" You shouldn't have compatible strings for subfunctions of a MFD unless these represent meaningful reusable IPs that can exist separately from the parent chip, that's clearly not the case here. All you're doing here is encoding Linux internal abstractions which aren't OS neutral and might change in future (for example clocking might move more into the clock API). signature.asc Description: PGP signature
Re: [PATCH] net: hso: fix module unloading
From: Andreas Kemnade Date: Mon, 24 Apr 2017 21:18:39 +0200 > keep tty driver until usb driver is unregistered > rmmod hso > produces traces like this without that: ... > Signed-off-by: Andreas Kemnade Applied, thank you.
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 05:39:37PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 05:27:03PM +0200, Peter Zijlstra wrote:
> > Ah! the asymmetric setup, where @sibling is entirely uninitialized for
> > the top domain.
Like so then...
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -509,6 +509,11 @@ static void build_group_mask(struct sche
for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
+ /*
+* Can happen in the asymmetric case, where these siblings are
+* unused. The mask will not be empty because those CPUs that
+* do have the top domain _should_ span the domain.
+*/
if (!sibling->child)
continue;
@@ -518,6 +523,9 @@ static void build_group_mask(struct sche
cpumask_set_cpu(i, sched_group_mask(sg));
}
+
+ /* We must not have empty masks here */
+ WARN_ON_ONCE(cpumask_empty(sched_group_mask(sg)));
}
/*
[PATCH v5 4/5] macsec: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld
---
drivers/net/macsec.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index dbab05afcdbe..d846f42b99ec 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -733,7 +733,12 @@ static struct sk_buff *macsec_encrypt(struct sk_buff *skb,
macsec_fill_iv(iv, secy->sci, pn);
sg_init_table(sg, MAX_SKB_FRAGS + 1);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ macsec_txsa_put(tx_sa);
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (tx_sc->encrypt) {
int len = skb->len - macsec_hdr_len(sci_present) -
@@ -937,7 +942,11 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
macsec_fill_iv(iv, sci, ntohl(hdr->packet_number));
sg_init_table(sg, MAX_SKB_FRAGS + 1);
- skb_to_sgvec(skb, sg, 0, skb->len);
+ ret = skb_to_sgvec(skb, sg, 0, skb->len);
+ if (unlikely(ret < 0)) {
+ kfree_skb(skb);
+ return ERR_PTR(ret);
+ }
if (hdr->tci_an & MACSEC_TCI_E) {
/* confidentiality: ethernet + macsec header
--
2.12.2
[PATCH v5 3/5] rxrpc: check return value of skb_to_sgvec always
Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int rxkad_secure_packet_encrypt(const struct rxrpc_call *call, len &= ~(call->conn->size_align - 1); sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, 0, len); + err = skb_to_sgvec(skb, sg, 0, len); + if (unlikely(err < 0)) + goto out; skcipher_request_set_crypt(req, sg, sg, len, iv.x); crypto_skcipher_encrypt(req); @@ -342,7 +344,8 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb, goto nomem; sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, offset, 8); + if (unlikely(skb_to_sgvec(skb, sg, offset, 8) < 0)) + goto nomem; /* start the decryption afresh */ memset(&iv, 0, sizeof(iv)); @@ -429,7 +432,8 @@ static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb, } sg_init_table(sg, nsg); - skb_to_sgvec(skb, sg, offset, len); + if (unlikely(skb_to_sgvec(skb, sg, offset, len) < 0)) + goto nomem; /* decrypt from the session key */ token = call->conn->params.key->payload.data[0]; -- 2.12.2
Re: [PATCH] net: ethernet: ti: netcp_core: remove unused compl queue mapping
From: Ivan Khoronzhuk Date: Mon, 24 Apr 2017 23:54:06 +0300 > This code is unused and probably was unintentionally left while > moving completion queue mapping in submit function. > > Signed-off-by: Ivan Khoronzhuk Applied.
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On 3/4/17 11:57 AM, Dmitry Vyukov wrote: > == > BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 > net/ipv6/route.c:3551 at addr 88007e523694 > Read of size 4 by task syz-executor3/24426 > CPU: 2 PID: 24426 Comm: syz-executor3 Not tainted 4.10.0+ #293 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:16 [inline] > dump_stack+0x2fb/0x3fd lib/dump_stack.c:52 > kasan_object_err+0x1c/0x90 mm/kasan/report.c:166 > print_address_description mm/kasan/report.c:208 [inline] > kasan_report_error mm/kasan/report.c:292 [inline] > kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314 > kasan_report mm/kasan/report.c:334 [inline] > __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334 > rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3551 > fib6_dump_node+0x101/0x1a0 net/ipv6/ip6_fib.c:315 > fib6_walk_continue+0x4b3/0x620 net/ipv6/ip6_fib.c:1576 > fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1621 > fib6_dump_table net/ipv6/ip6_fib.c:374 [inline] > inet6_dump_fib+0x832/0xea0 net/ipv6/ip6_fib.c:447 My expectation is that this one is fixed with the ipv6 patch I have sent (not yet committed). Are you seeing this backtrace with that patch?
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On 04/25/2017 12:39 PM, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 05:27:03PM +0200, Peter Zijlstra wrote:
>> On Tue, Apr 25, 2017 at 05:22:36PM +0200, Peter Zijlstra wrote:
>>> On Tue, Apr 25, 2017 at 05:12:00PM +0200, Peter Zijlstra wrote:
But I'll first try and figure out why I'm not having empty masks.
>>> Ah, so this is before all the degenerate stuff, so there's a bunch of
>>> redundant domains below that make it work -- and there always will be,
>>> unless FORCE_SD_OVERLAP.
>>>
>>> Now I wonder what triggered it.. let me put it back.
>> Ah! the asymmetric setup, where @sibling is entirely uninitialized for
>> the top domain.
>>
> And it still works correctly too:
>
>
> [0.078756] XXX 1 NUMA
> [0.079005] XXX 2 NUMA
> [0.080003] XXY 0-2:0
> [0.081007] XXX 1 NUMA
> [0.082005] XXX 2 NUMA
> [0.083003] XXY 1-3:3
> [0.084032] XXX 1 NUMA
> [0.085003] XXX 2 NUMA
> [0.086003] XXY 1-3:3
> [0.087015] XXX 1 NUMA
> [0.088003] XXX 2 NUMA
> [0.089002] XXY 0-2:0
>
>
> [0.090007] CPU0 attaching sched-domain:
> [0.091002] domain 0: span 0-2 level NUMA
> [0.092002] groups: 0 (mask: 0), 1, 2
> [0.093002] domain 1: span 0-3 level NUMA
> [0.094002]groups: 0-2 (mask: 0) (cpu_capacity: 3072), 1-3
> (cpu_capacity: 3072)
> [0.095005] CPU1 attaching sched-domain:
> [0.096003] domain 0: span 0-3 level NUMA
> [0.097002] groups: 1 (mask: 1), 2, 3, 0
> [0.098004] CPU2 attaching sched-domain:
> [0.099002] domain 0: span 0-3 level NUMA
> [0.12] groups: 2 (mask: 2), 3, 0, 1
> [0.101004] CPU3 attaching sched-domain:
> [0.102002] domain 0: span 1-3 level NUMA
> [0.103002] groups: 3 (mask: 3), 1, 2
> [0.104002] domain 1: span 0-3 level NUMA
> [0.105002]groups: 1-3 (mask: 3) (cpu_capacity: 3072), 0-2
> (cpu_capacity: 3072)
>
>
> static void
> build_group_mask(struct sched_domain *sd, struct sched_group *sg, struct
> cpumask *mask)
> {
> const struct cpumask *sg_span = sched_group_cpus(sg);
> struct sd_data *sdd = sd->private;
> struct sched_domain *sibling;
> int i, funny = 0;
>
> cpumask_clear(mask);
>
> for_each_cpu(i, sg_span) {
> sibling = *per_cpu_ptr(sdd->sd, i);
>
> if (!sibling->child) {
> funny = 1;
> printk("XXX %d %s %*pbl\n", i, sd->name,
> cpumask_pr_args(sched_domain_span(sibling)));
> continue;
> }
>
> /* If we would not end up here, we can't continue from here */
> if (!cpumask_equal(sg_span,
> sched_domain_span(sibling->child)))
> continue;
>
> cpumask_set_cpu(i, mask);
> }
>
> if (funny) {
> printk("XXY %*pbl:%*pbl\n",
> cpumask_pr_args(sg_span),
> cpumask_pr_args(mask));
> }
> }
>
>
> So that will still get the right balance cpu and thus sgc.
>
> Another thing I've been thinking about; I think we can do away with the
> kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg
> storage.
I considered this too. I decided to do not change this because I was not
sure if the kzalloc() was there for performance reasons. Currently, all
groups are allocated in the NUMA node they are used.
If we use sdd->sg storage, we may have groups allocated in one NUMA node
being used in another node.
>
> I just didn't want to move too much code around again, and ideally put
> more assertions in place to catch bad stuff; I just haven't had a good
> time thinking of good assertions :/
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On 3/7/17 2:21 AM, Dmitry Vyukov wrote: > [ cut here ] > WARNING: CPU: 2 PID: 3990 at net/ipv6/ip6_fib.c:991 > fib6_add+0x2e12/0x3290 net/ipv6/ip6_fib.c:991 net/ipv6/ip6_fib.c:991 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 2 PID: 3990 Comm: kworker/2:4 Not tainted 4.11.0-rc1+ #311 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Workqueue: ipv6_addrconf addrconf_dad_work > Call Trace: > __dump_stack lib/dump_stack.c:16 [inline] > __dump_stack lib/dump_stack.c:16 [inline] lib/dump_stack.c:52 > dump_stack+0x2fb/0x3fd lib/dump_stack.c:52 lib/dump_stack.c:52 > panic+0x20f/0x426 kernel/panic.c:180 kernel/panic.c:180 > __warn+0x1c4/0x1e0 kernel/panic.c:541 kernel/panic.c:541 > warn_slowpath_null+0x2c/0x40 kernel/panic.c:584 kernel/panic.c:584 > fib6_add+0x2e12/0x3290 net/ipv6/ip6_fib.c:991 net/ipv6/ip6_fib.c:991 > __ip6_ins_rt+0x60/0x80 net/ipv6/route.c:948 net/ipv6/route.c:948 > ip6_ins_rt+0x19b/0x220 net/ipv6/route.c:959 net/ipv6/route.c:959 > __ipv6_ifa_notify+0x62e/0x7a0 net/ipv6/addrconf.c:5485 > net/ipv6/addrconf.c:5485 > ipv6_ifa_notify+0xdf/0x1d0 net/ipv6/addrconf.c:5518 net/ipv6/addrconf.c:5518 > addrconf_dad_completed+0xe6/0x950 net/ipv6/addrconf.c:3983 > net/ipv6/addrconf.c:3983 > addrconf_dad_begin net/ipv6/addrconf.c:3797 [inline] Similarly for this one.
Re: [PATCH 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support
On Sun, Apr 23, 2017 at 10:20 AM, Paolo Pisati wrote:
Hi Paolo,
Thanks for submitting your driver. A few things...
> Add support for the Lattice MachXO2 FPGA chip in Slave SPI configuration.
>
Please add a bit of a description here. Format should be subject
line, skip a line, description, skip a line, then your signoff.
> Signed-off-by: Paolo Pisati
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/machxo2-spi.c | 199
> +
> 3 files changed, 207 insertions(+)
> create mode 100644 drivers/fpga/machxo2-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
> help
> FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>
> +config FPGA_MGR_MACHXO2_SPI
> + tristate "Lattice MachXO2 SPI"
> + depends on SPI
> + help
> +FPGA manager driver support for Lattice MachXO2 configuration
> +over slave SPI interface.
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI) += machxo2-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 000..5ee56bd
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,199 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
Please run checkpatch and fix whatever it points out, such as not to
use double blank lines.
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_ENABLE 0x08c6
> +#define ISC_ERASE 0x040e
> +#define ISC_PROGRAMDONE0x005e
> +#define LSC_CHECKBUSY 0x00f0
> +#define LSC_INITADDRESS0x0046
> +#define LSC_PROGINCRNV 0x0170
> +#define LSC_REFRESH0x0079
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED 6600
> +
> +#define MACHXO2_LOW_DELAY 5 /* us */
> +#define MACHXO2_HIGH_DELAY 200 /* us */
> +
> +#define MACHXO2_OP_SIZEsizeof(uint32_t)
> +#define MACHXO2_PAGE_SIZE 16
> +#define MACHXO2_BUF_SIZE (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +
> +static int waituntilnotbusy(struct spi_device *spi)
Could you rename to something like wait_until_not_busy?
> +{
> + uint8_t rx, busyflag = 0x80;
Please create a macro for the 0x80 value and use it here.
> + uint32_t checkbusy = LSC_CHECKBUSY;
Another checkpatch: u32 is preferred over uint32_t.
> +
> + do {
> + if (spi_write_then_read(spi, &checkbusy, MACHXO2_OP_SIZE,
> + &rx, sizeof(rx)))
> + return -EIO;
Please pass down the spi_write_then_read error code like:
ret = spi_write_then_read(...);
if (ret)
return ret;
There's a few places below where I will point that out for spi_write as well.
> + } while (rx & busyflag);
Skip a line before the return.
> + return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> + struct spi_device *spi = mgr->priv;
> + uint32_t enable = ISC_ENABLE;
> + uint32_t erase = ISC_ERASE;
> + uint32_t initaddr = LSC_INITADDRESS;
> +
> + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(&mgr->dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> +
Re: [PATCH] iio: inkern: fix a static checker error
On 04/24/2017 11:32 AM, Peter Rosin wrote: > On 2017-04-20 23:13, Peter Rosin wrote: >> On 2017-04-20 23:12, Lars-Peter Clausen wrote: >>> On 04/20/2017 11:01 PM, Peter Rosin wrote: Avoid this smatch error: drivers/iio/inkern.c:751 iio_read_avail_channel_raw() error: double unlock 'mutex:&chan->indio_dev->info_exist_lock' >>> >>> Looks good, but it's not just the smatch error, this is a real issue. This >>> even seems to be a endless loop, always jumping back to err_unlock. >> >> Yes, it should probably go to stable too... > > Nope, not an endless loop, but I of course only noticed after sending > a v2 [1] which falsely stated just that. Ignore that v2 patch and take > this one instead, for the reasons stated in my followup [2] to that > message. > > Involving stable is probably not needed either... Right, my fault for sending you the wrong way. Sorry for that.
Re: [PATCH V15 04/11] efi: parse ARM processor error
On 4/24/2017 11:52 AM, Borislav Petkov wrote:
On Fri, Apr 21, 2017 at 12:22:09PM -0600, Baicar, Tyler wrote:
I guess it's not really needed. It just may be useful considering there can
be numerous error info structures, numerous context info structures, and a
variable length vendor information section. I can move this print to only in
the length check failure cases.
And? Why does the user care?
I mean, it is good for debugging when you wanna see you're parsing the
error info data properly but otherwise it doesn't improve the error
reporting one bit.
I'll move this to just happen when the length check fails.
Because these are part of the error information structure. I wouldn't think
FW would populate error information structures that are different versions
in the same processor error, but it could be possible from the spec (at
least once there are different versions of the table).
Same argument as above.
I can remove it then.
There is an error information 64 bit value in the ARM processor error
information structure. (UEFI spec 2.6 table 261)
So that's IP-dependent and explained in the following tables. Any plans
on decoding that too?
Yes, I do plan on adding further decoding for these values in the future.
Why's that? Dumping this vendor specific error information is similar to the
unrecognized CPER section reporting which is also meant for vendor specific
information https://lkml.org/lkml/2017/4/18/751
And how do those naked bytes help the user understand the error happening?
Even in your example you have:
[ 140.739210] {1}[Hardware Error]: : 4d415201 4d492031 453a4d45
435f4343 .RAM1 IMEM:ECC_C
[ 140.739214] {1}[Hardware Error]: 0010: 53515f45 44525f42
E_QSB_RD
Which looks like some correctable ECC DRAM error and is actually begging
to be decoded in a human-readable form. So let's do that completely and
not dump partially decoded information.
That seems like something that should be done outside of these patches
(if added to the kernel at all). The decoding for this information would
all be vendor specific, so I'm not sure if we want to pollute the EFI
code with vendor specific error decoding. Currently we are using the RAS
Daemon user space tool for the decoding of this information since
vendors can easily pick up this tool and add an extension for their
vendor specific parsing. These prints will only happen when the firmware
supports the vendor specific error information anyway.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [for-next][PATCH 0/5] selftests: ftrace: Tracing updates to allow instance testing
On Tue, 25 Apr 2017 09:24:40 -0400 Steven Rostedt wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git > for-next > > Head SHA1: d6322f6cc483bd512efd3360fa76d0286a5b528b > > > Steven Rostedt (VMware) (5): > selftests: ftrace: Allow some tests to be run in a tracing instance > selftests: ftrace: Make func_event_triggers and > func_traceonoff_triggers tests do instances > selftests: ftrace: Have event tests also run in an tracing instance > selftests: ftrace: Have some basic tests run in a tracing instance too > selftests: ftrace: Allow some event trigger tests to run in an instance > > > tools/testing/selftests/ftrace/ftracetest | 18 > +- > .../testing/selftests/ftrace/test.d/00basic/basic2.tc | 1 + > .../testing/selftests/ftrace/test.d/00basic/basic3.tc | 1 + > .../selftests/ftrace/test.d/event/event-enable.tc | 1 + > .../testing/selftests/ftrace/test.d/event/event-pid.tc | 1 + > .../selftests/ftrace/test.d/event/subsystem-enable.tc | 1 + > .../ftrace/test.d/ftrace/func_event_triggers.tc| 1 + > .../ftrace/test.d/ftrace/func_traceonoff_triggers.tc | 1 + > .../ftrace/test.d/trigger/trigger-eventonoff.tc| 1 + > .../selftests/ftrace/test.d/trigger/trigger-filter.tc | 1 + > .../ftrace/test.d/trigger/trigger-hist-mod.tc | 1 + > .../selftests/ftrace/test.d/trigger/trigger-hist.tc| 1 + > .../ftrace/test.d/trigger/trigger-multihist.tc | 1 + > 13 files changed, 29 insertions(+), 1 deletion(-) I've reviewed & tested the series. Looks good to me. Acked-by: Masami Hiramatsu for the series. Tue Apr 25 16:02:40 UTC 2017 === Ftrace unit tests === [1] Basic trace file check [PASS] [2] Basic test for tracers [PASS] [3] Basic trace clock test [PASS] [4] Basic event tracing check [PASS] [5] event tracing - enable/disable with event level files [PASS] [6] event tracing - restricts events based on pid [PASS] [7] event tracing - enable/disable with subsystem level files [PASS] [8] event tracing - enable/disable with top level files [PASS] [9] ftrace - function graph filters with stack tracer [PASS] [10] ftrace - function graph filters[PASS] [11] ftrace - function glob filters [PASS] [12] ftrace - function pid filters [PASS] [13] ftrace - test for function event triggers [PASS] [14] ftrace - function profiler with function tracing [PASS] [15] ftrace - test reading of set_ftrace_filter [PASS] [16] ftrace - test for function traceon/off triggers[PASS] [17] Test creation and deletion of trace instances while setting an event [PASS] [18] Test creation and deletion of trace instances [PASS] [19] Kprobe dynamic event - adding and removing [PASS] [20] Kprobe dynamic event - busy event check[PASS] [21] Kprobe dynamic event with arguments[PASS] [22] Kprobes event arguments with types [PASS] [23] Kprobe dynamic event with function tracer [PASS] [24] Kretprobe dynamic event with arguments [PASS] [25] Kretprobe dynamic event with maxactive [PASS] [26] event trigger - test event enable/disable trigger [PASS] [27] event trigger - test trigger filter[PASS] [28] event trigger - test histogram modifiers [PASS] [29] event trigger - test histogram trigger [PASS] [30] event trigger - test multiple histogram triggers [PASS] [31] event trigger - test snapshot-trigger [PASS] [32] event trigger - test stacktrace-trigger[PASS] [33] event trigger - test traceon/off trigger [PASS] [34] (instance) Basic test for tracers [PASS] [35] (instance) Basic trace clock test [PASS] [36] (instance) event tracing - enable/disable with event level files [PASS] [37] (instance) event tracing - restricts events based on pid [PASS] [38] (instance) event tracing - enable/disable with subsystem level files [PASS] [39] (instance) ftrace - test for function event triggers [PASS] [40] (instance) ftrace - test for function traceon/off triggers[PASS] [41] (instance) event trigger - test event enable/disable trigger [PASS] [42] (instance) event trigger - test trigger filter[PASS] [43] (instance) event trigger - test histogram modifiers [PASS] [44] (instance) event trigger - test histogram trigger [PASS] [45] (instance) event trigger - test multiple histogram triggers [PASS] # of passed: 45 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0 Thank you, -- Masami Hiramatsu
Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them
On Tue, Apr 25, 2017 at 05:27:04PM +0200, Denys Vlasenko wrote: > MSRs in 0xC001102x range (and a few close to this range) > allow to modify some internal actions of the pipeline. > > (There is one non-debug MSR in this range, introduced in Fam15h: > MSR 0xC0011027 Address Mask For DR0 Breakpoints, aka DR0_ADDR_MASK). > > Sometimes these MSRs are used to fix erratas. > > Let's have a comment about that. > > Lat's use the following naming scheme for all of them: MSR_FnnH_REGNAME > This introduces some redundant names, but documents CPU family where > we are reasonably sure a particular register exists, and avoids the need > to explain why the same register is either "Combined Unit Cfg" > or "Bus Unit Cfg" - obviously, because the name depends on the CPU family. > > Renaming: > MSR_AMD64_DC_CFG -> MSR_F10H_DC_CFG > MSR_AMD64_BU_CFG2 -> MSR_F10H_BU_CFG2 > MSR_AMD64_LS_CFG -> MSR_F16H_LS_CFG > MSR_AMD64_DE_CFG -> MSR_F12H_DE_CFG (and moving to msr-index.h) > > Here is a little compilation from about a dozen documents. > > C001_1000: > 15h Errata 608 "P-state Limit Changes May Not Generate Interrupts" > - worked around by setting bit 16. > 15h Errata 671 "Debug Breakpoint on Misaligned Store May Cause System Hang" > - worked around by setting bit 17 to 0. > - AMD is really reluctant to this workaround, must be painful > 15h Errata 727 "Processor Core May Hang During CC6 Resume" > - worked around by setting bit 15. > - HW fixed in models 10h? > > C001_1020: > K8 Errata 106 > "Potential Deadlock with Tightly Coupled Semaphores in an MP System" > - worked around by setting bit 25. > 10h,12h Errata 670 > "Segment Load May Cause System Hang or Fault After State Change" > - worked around by setting bit 8. > - this bit has something to do with handling of LOCK prefix. > 14h Errata 530 > "Potential Violation of Read Ordering Rules Between Semaphore Operation > and Subsequent Load Operations" > - worked around by setting bit 36. > 14h Errata 551 > "Processor May Not Forward Data From Store to a Page Crossing > Read-Modify-Write Operation" > - worked around by setting bit 25. > 14h Errata 560 > "Processor May Incorrectly Forward Data with Non-cacheable Floating-Point > 128-bit SSE Operation" > - worked around by setting bit 18. > 16h Errata 793 > "Specific Combination of Writes to Write Combined Memory Types and Locked > Instructions May Cause Core Hang" > - worked around by setting bit 15. > > C001_1021: > K8 Errata 94 > "Sequential Prefetch Feature May Cause Incorrect Processor Operation" > - worked around by setting bit 11. > 14h Errata 688 > "Processor May Cause Unpredictable Program Behavior Under Highly Specific > Branch Conditions" > - worked around by setting bits 14 and 3. > 16h Errata 776 > "Incorrect Processor Branch Prediction for Two Consecutive Linear Pages" > - worked around by setting bit 26. > - HW fixed in models 30h? > > C001_1022: > K8 Errata 97 "128-Bit Streaming Stores May Cause Coherency Failure" > - worked around by setting bit 3. > K8 Errata 81 > "Cache Coherency Problem with Hardware Prefetching and Streaming Stores" > - worked around by setting bit 10. > 10h Errata 261 > "Processor May Stall Entering Stop-Grant Due to Pending Data Cache Scrub" > - worked around by setting bit 24. > 10h Errata 326 "Misaligned Load Operation May Cause Processor Core Hang" > - worked around by setting bits 43:42 to 00. > 10h Errata 383 > "CPU Core May Machine Check When System Software Changes Page Tables > Dynamically" > - worked around by setting bit 47. > 15h Errata 674 > "Processor May Cache Prefetched Data from Remapped Memory Region" > - worked around by setting bit 13. > > C001_1023: > K8 Errata 69 > "Multiprocessor Coherency Problem with Hardware Prefetch Mechanism" > - worked around by setting bit 45. > K8 Errata 113 "Enhanced Write-Combining Feature Causes System Hang" > - worked around by setting bit 48. > 10h Errata 254 "Internal Resource Livelock Involving Cached TLB Reload" > - worked around by setting bit 21. > 10h Errata 298 > "L2 Eviction May Occur During Processor Operation To Set Accessed or Dirty > Bit" > - worked around by setting bit 1. > 10h Errata 309 > "Processor Core May Execute Incorrect Instructions on Concurrent L2 and > Northbridge Response" > - worked around by setting bit 23. > > C001_1029: > 10h,12h Errata 721 "Processor May Incorrectly Update Stack Pointer" > - worked around by setting bit 0. > 12h Errata 665 "Integer Divide Instruction May Cause Unpredictable Behavior" > - worked around by setting bit 31. > Bit 23 serializes CLFLUSH instruction. > > C001_102A: > 15h Errata 503 "APIC Task-Priority Register May Be Incorrect" > - worked around by setting bit 11. > > K8_BKDG documents none of these registers, but Revision Guide mentions > them a lot. > > 10h_BKDG documents them as: > MSRC001_1021 Instruction Cache Configuration Register (IC_CFG)
Re: [patch V2 00/24] cpu/hotplug: Convert get_online_cpus() to a percpu_rwsem
Hi, This series appears to break boot on some arm64 platforms, seen with next-20170424. More info below. On Tue, Apr 18, 2017 at 07:04:42PM +0200, Thomas Gleixner wrote: > get_online_cpus() is used in hot pathes in mainline and even more so in > RT. That can show up badly under certain conditions because every locker > contends on a global mutex. RT has it's own homebrewn mitigation which is > an (badly done) open coded implementation of percpu_rwsems with recursion > support. > > The proper replacement for that are percpu_rwsems, but that requires to > remove recursion support. > > The conversion unearthed real locking issues which were previously not > visible because the get_online_cpus() lockdep annotation was implemented > with recursion support which prevents lockdep from tracking full dependency > chains. These potential deadlocks are not related to recursive calls, they > trigger on the first invocation because lockdep now has the full dependency > chains available. Catalin spotted next-20170424 wouldn't boot on a Juno system, where we see the following splat (repeated forever) when we try to bring up the first secondary CPU: [0.213406] smp: Bringing up secondary CPUs ... [0.250326] CPU features: enabling workaround for ARM erratum 832075 [0.250334] BUG: scheduling while atomic: swapper/1/0/0x0002 [0.250337] Modules linked in: [0.250346] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.11.0-rc7-next-20170424 #2 [0.250349] Hardware name: ARM Juno development board (r1) (DT) [0.250353] Call trace: [0.250365] [] dump_backtrace+0x0/0x238 [0.250371] [] show_stack+0x14/0x20 [0.250377] [] dump_stack+0x9c/0xc0 [0.250384] [] __schedule_bug+0x50/0x70 [0.250391] [] __schedule+0x52c/0x5a8 [0.250395] [] schedule+0x38/0xa0 [0.250400] [] rwsem_down_read_failed+0xc4/0x108 [0.250407] [] __percpu_down_read+0x100/0x118 [0.250414] [] get_online_cpus+0x70/0x78 [0.250420] [] static_key_enable+0x28/0x48 [0.250425] [] update_cpu_capabilities+0x78/0xf8 [0.250430] [] update_cpu_errata_workarounds+0x1c/0x28 [0.250435] [] check_local_cpu_capabilities+0xf4/0x128 [0.250440] [] secondary_start_kernel+0x8c/0x118 [0.250444] [<8093d1b4>] 0x8093d1b4 I can reproduce this with the current head of the linux-tip smp/hotplug branch (commit 77c60400c82bd993), with arm64 defconfig on a Juno R1 system. When we bring the secondary CPU online, we detect an erratum that wasn't present on the boot CPU, and try to enable a static branch we use to track the erratum. The call to static_branch_enable() blows up as above. I see that we now have static_branch_disable_cpuslocked(), but we don't have an equivalent for enable. I'm not sure what we should be doing here. Thanks, Mark. > The following patch series addresses this by > > - Cleaning up places which call get_online_cpus() nested > > - Replacing a few instances with cpu_hotplug_disable() to prevent circular >locking dependencies. > > The series depends on > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core > plus > Linus tree merged in to avoid conflicts > > It's available in git from > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.hotplug > > Changes since V1: > > - Fixed fallout reported by kbuild bot > - Repaired the recursive call in perf > - Repaired the interaction with jumplabels (Peter Zijlstra) > - Renamed _locked to _cpuslocked > - Picked up Acked-bys > > Thanks, > > tglx > > --- > arch/arm/kernel/hw_breakpoint.c |5 > arch/mips/kernel/jump_label.c |2 > arch/powerpc/kvm/book3s_hv.c |8 - > arch/powerpc/platforms/powernv/subcore.c |3 > arch/s390/kernel/time.c |2 > arch/x86/events/core.c|1 > arch/x86/events/intel/cqm.c | 12 - > arch/x86/kernel/cpu/mtrr/main.c |2 > b/arch/sparc/kernel/jump_label.c |2 > b/arch/tile/kernel/jump_label.c |2 > b/arch/x86/events/intel/core.c|4 > b/arch/x86/kernel/jump_label.c|2 > b/kernel/jump_label.c | 31 - > drivers/acpi/processor_driver.c |4 > drivers/cpufreq/cpufreq.c |9 - > drivers/hwtracing/coresight/coresight-etm3x.c | 12 - > drivers/hwtracing/coresight/coresight-etm4x.c | 12 - > drivers/pci/pci-driver.c | 47 --- > include/linux/cpu.h |2 > include/linux/cpuhotplug.h| 29 > include/linux/jump_label.h|3 > include/linux/padata.h|3 > include/linux/pci.h |1 > include/linux/stop_machine.h | 26 +++- > kernel/cpu.c
Re: [PATCH] iio: adc: Add support for TI ADC1x8s102
On 2017-04-25 15:47, Jan Kiszka wrote:
> On 2017-04-25 14:30, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>>> I'm not ACPI guru: How do we come from a SSDT to information that is
>>> carried in the DSDT so far? How can we overload wrong information in the
>>> built in DSDT this way? I'm all ears if we could fix our (and also the
>>> Galileo) quirks like that!
>>
>> SSDT stands for Secondary System Description table which basically adds
>> stuff to DSDT (the main table). Main use for SSDTs is to add devices but
>> you can also amend an existing device in DSDT by adding methods and so
>> forth.
>>
>> In case of Galileo the SPI1 host controller happens to miss _CRS method
>> so we can use SSDT like below to add that method there:
>>
>> Scope (\_SB.PCI0.SPI1)
>> {
>> Name (_CRS, ResourceTemplate () {
>> GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
>> "\\_SB.PCI0.GIP0.GPO", 0) {2} // MUX6_IO
>> })
>>
>> Name (_DSD, Package () {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () {
>> Package () {
>> "cs-gpios", Package () {^SPI1, 0, 0, 0},
>> },
>> }
>> })
>> }
>>
>> This effectively means that once the table is parsed we find the SPI1
>> device with two new methods, _CRS and _DSD and the kernel is happy to
>> handle the rest.
>>
>> Important thing here is the
>>
>> Scope (\_SB.PCI0.SPI1)
>>
>> which allows us to reference an object in DSDT.
>>
>
> Ah, now I recall: I think we discussed this before, but for a case were
> we would need to patch an existing element that contains one wrong value
> - that won't work. This case should, though. I'll give that a try.
>
Works fine via an SSDT overlay - perfect!
Now, do you also a suggestion where to put that 5 V reference voltage
value that is hard-coded (via wiring) on the target boards for the ADC?
That is now device-specific, not a controller parameter. Is there an
ACPI-way to express such a parameter?
How would that be done for DTs?
Plan B would be hard-coding in the code for now, waiting for a second,
non-ACPI user to address it.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
[PATCH -next] irqchip/qcom: Use builtin_platform_driver to simplify the code
From: Wei Yongjun
Use the builtin_platform_driver() macro to make the code simpler.
Signed-off-by: Wei Yongjun
---
drivers/irqchip/qcom-irq-combiner.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/irqchip/qcom-irq-combiner.c
b/drivers/irqchip/qcom-irq-combiner.c
index 2265586..6aa3ea4 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -288,9 +288,4 @@ static struct platform_driver qcom_irq_combiner_probe = {
},
.probe = combiner_probe,
};
-
-static int __init register_qcom_irq_combiner(void)
-{
- return platform_driver_register(&qcom_irq_combiner_probe);
-}
-device_initcall(register_qcom_irq_combiner);
+builtin_platform_driver(qcom_irq_combiner_probe);
[PATCH -next] auxdisplay: Convert list_for_each to entry variant
From: Wei Yongjun
convert list_for_each() to list_for_each_entry() where
applicable.
Signed-off-by: Wei Yongjun
---
drivers/auxdisplay/panel.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
index e0c014c..7a8b8fb 100644
--- a/drivers/auxdisplay/panel.c
+++ b/drivers/auxdisplay/panel.c
@@ -1345,14 +1345,11 @@ static inline void input_state_falling(struct
logical_input *input)
static void panel_process_inputs(void)
{
- struct list_head *item;
struct logical_input *input;
keypressed = 0;
inputs_stable = 1;
- list_for_each(item, &logical_inputs) {
- input = list_entry(item, struct logical_input, list);
-
+ list_for_each_entry(input, &logical_inputs, list) {
switch (input->state) {
case INPUT_ST_LOW:
if ((phys_curr & input->mask) != input->value)
Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them
On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the realization that these particular MSRs are so badly and inconsistently documented that it takes many hours of work and requires reading of literally a dozen PDFs to figure out what are their names, which CPUs have them, and what bits are known. Anyone who looks at only one document won't see the full picture. Patch does not document bits, but at least documents all MSR names and explains why documentation is so sparse. If you think it's not useful, so be it.
Re: [PATCH 0/2] DS1374 Watchdog fixes
On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > Hi Guenter, > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > >> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > >> the watchdog behavior and currently I'm investigating how to make > >> that work via DT. > >> > >> Watchdog maintainers, do you have an idea on how to do that in a > >> non breaking fashion? > >> > > > > Depends on what you mean with "non breaking". Just using the normal mfd > > mechanisms, ie define an mfd cell for each client driver, should work. > > Do you see any problems with that ? Either case, that doesn't seem > > to be a watchdog driver problem, or am I missing something ? > > Well so currently watchdog behavior is selected (out of the two options alarm, > or watchdog) by enabling the configuration option mentioned above. > If I change this over to use a dt-based approach like dallas,ds1374-mode = > <2>; > to select the behavior in the mfd for example, won't that break people that > relied on the old behavior? If everyone involved is ok with that, I'm happy > to just add it to the binding. > Sorry, I must be missing something. Looking into the driver code, my understanding is that CONFIG_RTC_DRV_DS1374_WDT enables the watchdog in addition to rtc functionality, not one or the other. Sure you would need a different configuration option if you were to move the watchdog code into drivers/watchdog, but other than that I don't really understand the problem. What is the issue with, for example, config DS1374_WDT bool "Dallas/Maxim DS1374 watchdog timer" depends on MFD_DS1374 help If you say Y here you will get support for the watchdog timer in the Dallas Semiconductor DS1374 real-time clock chips. in drivers/watchdog/Kconfig, and the mfd driver instantiating it like any other mfd client driver ? Either case, limiting support to DT based systems seems to be the wrong approach. There might be Intel platforms using this chip. > > I don't really see the point of doing that if you plan to move the watchdog > > part of the driver into the watchdog directory. We for sure won't accept a > > watchdog driver that does not use the watchdog infrastructure. > > The idea was to fix what's broken currently (this patchset) and then refactor. > But if you prefer I can do all in one go instead. > It just seemed a waste to me to change/fix a function which is going to be removed in a subsequent patch (I seem to recall that there was a fix to the ioctl function). If/when you move the driver to drivers/watchdog, please make sure that it doesn't use any instantiation related static variables (ie other than module parameters). > > > > Regarding > > + /* WHY? */ > > + ds1374->wdd.timeout = t; > > > > Assuming you mean why the driver has to set the timeout value - not every > > watchdog hardware supports timeouts in multiples of 1 second. The driver > > is expected to set the value to the real timeout, not to the timeout asked > > for by the infrastructure. > > Yeah that branch is work in progress and needs cleanup. Leftover from testing, > before I had understood why. Branch needs cleanup. It also doesn't really use > regmap_update_bits etc. > Well, you did enhance the code to use regmap, which by itself is a significant improvement ... Thanks, Guenter
RE: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel
>> If we are going to have all these copies of kernel files below >> "tools/...", perhaps checkpatch could warn people touching one >> that the other needs the same update? > > How would checkpatch know tools hasn't already updated the other? If checkpatch had a list of all the tools copies, it could warn if a patch touched a file without touching the copy. Not completely ideal because people might update the two files in separate patches in a series (in which case they would see warnings from both patches). Also means that checkpatch needs the list of copied files ... not sure how often that changes. -Tony
[PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases
1. Fail early for invalid/zero length symbols.
2. Detect names of the form and skip checking for kernel
symbols in that case.
Signed-off-by: Naveen N. Rao
---
Masami, Michael,
I have added two very simple checks here, which I felt is good to have,
rather than the elaborate checks in the previous version. Given the
change in module code to use strnchr(), the checks are now safe and
further tests are not probably not that useful.
- Naveen
kernel/kallsyms.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 6a3b249a2ae1..d134b060564f 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -205,6 +205,12 @@ unsigned long kallsyms_lookup_name(const char *name)
unsigned long i;
unsigned int off;
+ if (!name || *name == '\0')
+ return false;
+
+ if (strnchr(name, MODULE_NAME_LEN, ':'))
+ return module_kallsyms_lookup_name(name);
+
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
--
2.12.1
Re: [PATCH v4 00/21] PCI: fix config space memory mappings
On Tuesday, April 25, 2017 2:41 AM, Jon Masters wrote: > > On 04/19/2017 12:48 PM, Lorenzo Pieralisi wrote: > > > On some platforms (ie ARM/ARM64) ioremap fails to comply with the PCI > > configuration non-posted write transactions requirement, because it > > provides a memory mapping that issues "bufferable" or, in PCI terms > > "posted" write transactions. Likewise, the current pci_remap_iospace() > > implementation maps the physical address range that the PCI translates > > to I/O space cycles to virtual address space through pgprot_device() > > attributes that on eg ARM64 provides a memory mapping issuing > > posted writes transactions, which is not PCI specifications compliant. > > Side note that I've pinged all of the ARM server vendors and asked them > to verify this patch series on their platforms. Good! I really want to know the result of these patches on ARM serves. Please share it with us. Good luck. Best regards, Jingoo Han > > Jon.
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
Am 25.04.2017 um 17:14 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 11:09 AM, Christian König
wrote:
Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
v2: rebased, style cleanups, disable mem decode before resize,
handle gmc_v9 as well, round size up to power of two.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
++
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4a16e3c..9484062 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
amdgpu_device *adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc, u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a09ad3cf..d5ca77a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
+{
+ u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+ u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+ u16 cmd;
+ int r;
+
+ /* Free the doorbell mapping, it most likely needs to move as
well */
+ amdgpu_doorbell_fini(adev);
+ pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
+
+ /* Disable memory decoding while we change the BAR addresses and
size */
+ pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
+ pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+ r = pci_resize_resource(adev->pdev, 0, rbar_size);
+ if (r == -ENOSPC)
+ DRM_INFO("Not enough PCI address space for a large
BAR.");
+ else if (r && r != -ENOTSUPP)
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+ pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+ /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+ BUG_ON(amdgpu_doorbell_init(adev));
Same here.
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
As far as I know there is no SI hardware with resizeable BAR support.
The all VI generation can do this, but I'm not 100% sure if there aren't any
Bonaires out there which can handle it as well that's why I added gmc_v7
support.
Still need to double check that.
I think NI or even evergreen supported resizeable bars in theory,
although I'm not sure if any boards were fused to expose it.
In theory yes, in practice no.
Their PCIE config space defines the necessary registers, but I haven't
found any board from Evergreen, NI, SI or CIK generation where that is
actually validated.
Tonga is the first one I'm 100% sure that it is supported and I have
hardware to test it.
I would rather drop Bonaire support as well and wait for somebody with
the hardware to complain so that we can test and enable it.
Christian.
Alex
Christian.
Alex
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -372,13 +372,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
*adev)
}
adev->mc.vram_width = numchan * chansize;
}
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev,
Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.
On 04/24/2017 11:04 AM, Roger Quadros wrote:
> On 24/04/17 02:35, Andrew Lunn wrote:
>> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote:
>>> On 04/21/2017 03:15 PM, Roger Quadros wrote:
diff --git a/Documentation/devicetree/bindings/net/mdio.txt
b/Documentation/devicetree/bindings/net/mdio.txt
new file mode 100644
index 000..4ffbbac
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mdio.txt
@@ -0,0 +1,33 @@
+Common MDIO bus properties.
+
+These are generic properties that can apply to any MDIO bus.
+
+Optional properties:
+- reset-gpios: List of one or more GPIOs that control the RESET lines
+ of the PHYs on that MDIO bus.
+- reset-delay-us: RESET pulse width in microseconds as per PHY datasheet.
+
+A list of child nodes, one per device on the bus is expected. These
+should follow the generic phy.txt, or a device specific binding document.
+
+Example :
+This example shows these optional properties, plus other properties
+required for the TI Davinci MDIO driver.
+
+ davinci_mdio: ethernet@0x5c03 {
+ compatible = "ti,davinci_mdio";
+ reg = <0x5c03 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <2>; /* PHY datasheet states 1us min */
>>>
>>> If this is the reset line of the PHY shouldn't it be a property of the PHY
>>> node rather than of the MDIO controller node (which might have a reset on
>>> its own)?
+
+ ethphy0: ethernet-phy@1 {
+ reg = <1>;
+ };
+
+ ethphy1: ethernet-phy@3 {
+ reg = <3>;
+ };
>>
>> Hi Lars-Peter
>>
>> We discussed this when the first proposal was made. There are two
>> cases, to consider.
>>
>> 1) Here, one GPIO line resets all PHYs on the same MDIO bus. In this
>> example, two PHYs.
>>
>> 2) There is one GPIO line per PHY. That is a separate case, and as you
>> say, the reset line should probably be considered a PHY property, not
>> an MDIO property. However, it can be messy, since in order to probe
>> the MDIO bus, you probably need to take the PHY out of reset.
>>
But the DT binding documentation says something else "List of one or more
GPIOs that control the RESET lines of the PHYs on that MDIO bus".
>> Anyway, this patch addresses the first case, so should be accepted. If
>> anybody wants to address the second case, they are free to do so.
I think we all know that that's not going to happen. Once there is a working
kludge there is no incentive to do a proper implementation anymore.
> Thanks for the explanation Andrew.
>
> For the second case, even if the RESET GPIO property is specified
> in the PHY node, the RESET *will* have to be done by the MDIO bus driver
> else the PHY might not be probed at all.
I'm not arguing with that, just that the hardware description should be
truthful to the hardware topology and not to the software topology, i.e. the
implementation details of the Linux kernel in this case. Reset GPIOs are not
the only resource that is connected to the PHY that needs to be enabled
before they can be enumerated. E.g. clocks and regulators fall into the same
realm. And while you might argue that with a on-SoC phy controller node
there wont be any conflicts in regard to the reset-gpios property, this not
so very true for the clocks property.
And MDIO is not really special in this regard, other discoverable buses
(like USB, SDIO, ULPI) have the very same issue. Having a standardized
binding approach where the resources are declared as part as the child child
is preferable in my opinion.
>
> Whether we need additional code to just to make the DT look prettier is
> questionable and if required can come as a separate patch.
Unfortunately not, once it is merged it can't be changed anymore.
Re: Network cooling device and how to control NIC speed on thermal condition
Hello, On 04/25/2017 01:36 AM, Waldemar Rymarkiewicz wrote: > Hi, > > I am not much aware of linux networking architecture so I'd like to > ask first before will start to dig into the code. Appreciate any > feedback. > > I am looking on Linux thermal framework and on how to cool down the > system effectively when it hits thermal condition. Already existing > cooling methods cpu_cooling and clock_cooling are good. However, I > wanted to go further and dynamically control also a switch ports' > speed based on thermal condition. Lowering speed means less power, > less power means lower temp. > > Is there any in-kernel interface to configure switch port/NIC from other > driver? Well, there is mostly under the form of notifiers though. For instance there are lots of devices that do converged FCoE/RoCE/Ethernet that have a two headed set of drivers, one for normal ethernet, and another one for RDMA/IB for instance. To some extent stacked devices (VLAN, bond, team, etc.) also call back down into their lower device, but in an abstracted way, at the net_device level of course (layering). > > Is there any mechanism to power save, when port/interface is not > really used (not much or low data traffic), embedded in networking > stack or is it a task for NIC driver itself ? The thing we did (currently out of tree) in the Starfighter 2 switch driver (drivers/net/dsa/bcm_sf2.c) is that any time a port is brought up/down (a port = a network device) we recalculate the switch core clock, and we also resize the buffers and that yields to a little bit of power savings here and there. I don't recall the numbers from the top of my head, but it was significant enough our HW designers convinced me into doing it ;) > > I was thinking to create net_cooling device similarly to cpu_cooling > device which cool down the system scaling down cpu freq. net_cooling > could lower down interface speed (or tune more parameters to achieve > ). Do you thing could this work form networking stack perspective? This sounds like a good idea, but it could be very tricky to get right, because even if you can somehow throttle your transmit activity (since the host is in control), you can't do that without being disruptive to the receive path (or not as effectively). Unlike any kind of host driven activity: CPU run queue, block devices, USB etc. (SPI, I2C and so on when no using slave driven interrupts) you cannot simply apply a "duty cycle" pattern where you turn on your HW just enough of time that is needed for you to set it up for transfer, signal transfer completion and go back to sleep. Networking needs to be able to asynchronously receive packets in a way that is usually not predictable although it could be for very specific workloads though. Another thing is that there is still a fair amount of energy that needs to be spent in maintaining the link, and the HW design may be entirely clocked based on the link speed. Depending on the HW architecture (store and forward, cut through etc.) there would still be a cost associated with maintaining RAMs in a state where they are operational and so on. You could imagine writing a queuing discipline driver that would throttle transmission based on temperature sensors present in your NIC, you could definitively do this in a way that is completely device driver agnostic by using Linux's thermal framework trip point and temperature notifications. For reception, if you are okay with dropping some packets, you could implement something similar, but chances are that your NIC would still need to receive packets, be able to fully process them before SW drops them, at which point, you have a myriad of solutions about how not to process incoming traffic. Hope this helps > > Any pointers to the code or a doc highly appreciated. > > Thanks, > /Waldek > -- Florian
Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them
On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: > On 04/25/2017 06:06 PM, Borislav Petkov wrote: > > Pls no. Not every MSR for every family. Only the 4 which are actually > > being used. We can't hold in here the full 32-bit MSR space. > > The replacement of four define names is not the purpose > of the proposed patch. > > The patch was prompted by the realization that these particular MSRs > are so badly and inconsistently documented that it takes many hours > of work and requires reading of literally a dozen PDFs to figure out > what are their names, which CPUs have them, and what bits are known. They're all documented in the respective BKDGs or revision guides. > Anyone who looks at only one document won't see the full picture. And what is the big picture? To me it is just a bunch of MSRs. What's so special about them? > Patch does not document bits, but at least documents all MSR names > and explains why documentation is so sparse. No, we don't document MSRs in the kernel - we collect all the MSRs the kernel uses in msr-index.h. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] ACPI / GED: use late init to allow other drivers init
On 4/25/2017 3:01 AM, Lukas Wunner wrote: > On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya wrote: >> On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote: >>> +late_initcall(ged_init); >>> Does this fix the problem? >>> >>> What about if the module in question is loaded after running >>> late_initcalls? >> >> This fixed the issue for me where I had dependencies for QUP I2C driver >> and GHES drivers. Both of them are modules and get probed via normal >> module execution path. >> >> However, I'm open to improvements. Do you have a better suggestion? >> I can try to add some _DEP stuff if it is present, but I remember Linux >> doesn't like _DEP stuff too much. > > Would it be possible to solve this by just returning -EPROBE_DEFER from the > ->probe hook if the devices you depend on are not bound yet? > I'm not sure. > Alternatively, would it be possible to solve it with a struct device_link? I wasn't aware of device_link concept. This is something that I will keep in my mind when I'm dealing with producer/consumer problems with known device driver instances. It looked very useful. Here is how the overall relationship between drivers. | GED | <---> | Platform specific ACPI AML | <> Vendor GPIO <> Vendor I2C <> ACPI GHES <> Some other driver The problem with Generic Event Device (GED) is that it produces event notification facility to the platform specific AML code and GED doesn't have any idea about the consumers of these interrupts or what platform AML does. GED only sees the interrupts that it needs to register and knows the ASL code it needs to execute when that interrupt happens. It is possible for AML code not to use any of these drivers or require some arbitrary driver as well as vendor specific drivers. It is totally up to the firmware to decide what to do with this event. My proposal was to require platform AML code to indicate the dependencies between GED and drivers on the right side of the picture via _DEP as this cannot be done via normal kernel mechanisms. This approach might work in general. However, it also has its own caveats. All of these drivers on the right side are unrelated to each other. Some operating system can implement a subset of these drivers. If I include the dependencies, GED will never load for partial driver situations. This is also a deal breaker. Why would you break some other feature if your OS doesn't support RAS as an example? Given all these lose bindings and no driver association, where do we go from here? I consider GED as a light version of Embedded controller (EC) implementation. How is this problem solved for EC as it has the same problem? > > Thanks, > > Lukas > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree
I was not able to see any activities about MAX98927 driver after previous mail.
Is there anything wrong with this driver?
On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote:
> The patch
>
>ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From 7c0c2000716e64151b3c0c62026c18f31537ebe9 Mon Sep 17 00:00:00 2001
> From: Ryan Lee
> Date: Tue, 4 Apr 2017 02:23:08 +0900
> Subject: [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>
> Signed-off-by: Ryan Lee
> Signed-off-by: Mark Brown
> ---
> .../devicetree/bindings/sound/max98925.txt | 22 -
> .../devicetree/bindings/sound/max98926.txt | 32 -
> .../devicetree/bindings/sound/max9892x.txt | 41 +
> sound/soc/codecs/Kconfig | 5 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/max98927.c| 841
> +
> sound/soc/codecs/max98927.h| 272 +++
> 7 files changed, 1161 insertions(+), 54 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/max98925.txt
> delete mode 100644 Documentation/devicetree/bindings/sound/max98926.txt
> create mode 100644 Documentation/devicetree/bindings/sound/max9892x.txt
> create mode 100644 sound/soc/codecs/max98927.c
> create mode 100644 sound/soc/codecs/max98927.h
>
> diff --git a/Documentation/devicetree/bindings/sound/max98925.txt
> b/Documentation/devicetree/bindings/sound/max98925.txt
> deleted file mode 100644
> index 27be63e2aa0d..
> --- a/Documentation/devicetree/bindings/sound/max98925.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -max98925 audio CODEC
> -
> -This device supports I2C.
> -
> -Required properties:
> -
> - - compatible : "maxim,max98925"
> -
> - - vmon-slot-no : slot number used to send voltage information
> -
> - - imon-slot-no : slot number used to send current information
> -
> - - reg : the I2C address of the device for I2C
> -
> -Example:
> -
> -codec: max98925@1a {
> - compatible = "maxim,max98925";
> - vmon-slot-no = <0>;
> - imon-slot-no = <2>;
> - reg = <0x1a>;
> -};
> diff --git a/Documentation/devicetree/bindings/sound/max98926.txt
> b/Documentation/devicetree/bindings/sound/max98926.txt
> deleted file mode 100644
> index 0b7f4e4d5f9a..
> --- a/Documentation/devicetree/bindings/sound/max98926.txt
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -max98926 audio CODEC
> -
> -This device supports I2C.
> -
> -Required properties:
> -
> - - compatible : "maxim,max98926"
> -
> - - vmon-slot-no : slot number used to send voltage information
> - or in inteleave mode this will be used as
> - interleave slot.
> -
> - - imon-slot-no : slot number used to send current information
> -
> - - interleave-mode : When using two MAX98926 in a system it is
> - possible to create ADC data that that will
> - overflow the frame size. Digital Audio Interleave
> - mode provides a means to output VMON and IMON data
> - from two devices on a single DOUT line when running
> - smaller frames sizes such as 32 BCLKS per LRCLK or
> - 48 BCLKS per LRCLK.
> -
> - - reg : the I2C address of the device for I2C
> -
> -Example:
> -
> -codec: max98926@1a {
> - compatible = "maxim,max98926";
> - vmon-slot-no = <0>;
> - imon-slot-no = <2>;
> - reg = <0x1a>;
> -};
> diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt
> b/Documentation/devicetree/bindings/sound/max9892x.txt
> new file mode 100644
> index ..f6171591ddc6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/max9892x.txt
> @@ -0,0 +1,41 @@
> +Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
> +
> +This device supports I2C.
> +
> +Required properties:
> +
> + - compatible : should be one of the following
> +- "maxim,max98925"
> +- "maxim,max98926"
> +- "maxim,max98927"
> +
> + - vmon-slot-no : slot number us
Re: [PATCH] ACPI / GED: use late init to allow other drivers init
On 4/25/2017 7:03 AM, Rafael J. Wysocki wrote: >> Are you talking about init vs. probe in general? > Yes. > > Generally speaking, if the initialization of built-in code depends on > a loadable module to be present, it has to explicitly wait for that > module to advertise itself, this way or another, or it has to poll. > >> Sorry, I'm trying to decode what you mean to see if there is some other >> behavior >> that I'm not aware of in ACPI. > Sorry for being unclear. Just replied to Lukas. I think I have a question to you about the embedded controller implementation. Can you check that out? -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 4/4] sched/topology: the group balance cpu must be a cpu where the group is installed
On Tue, Apr 25, 2017 at 12:56:23PM -0300, Lauro Venancio wrote:
> > Another thing I've been thinking about; I think we can do away with the
> > kzalloc() in build_group_from_child_sched_domain() and use the sdd->sg
> > storage.
> I considered this too. I decided to do not change this because I was not
> sure if the kzalloc() was there for performance reasons. Currently, all
> groups are allocated in the NUMA node they are used.
> If we use sdd->sg storage, we may have groups allocated in one NUMA node
> being used in another node.
Right.. I cannot remember :/
/me once again kicks himself for not writing more comments
It does save a few lines.. and I suspect that if we do this, we could
actually completely get rid of sched_group_capacity, since its now
always the same as the group (again), which should removes more lines
still.
But I'll shelf this patch for now.. we've got enough changes as is.
I still need to write a changelog for the new #2, which has become ugly
again, because its needs a second sched_domains_tmpmask.
(compile tested only)
---
kernel/sched/topology.c | 76 ++--
1 file changed, 29 insertions(+), 47 deletions(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -501,10 +501,8 @@ enum s_alloc {
* balancing.
*/
static void
-build_group_mask(struct sched_domain *sd, struct sched_group *sg, struct
cpumask *mask)
+build_group_mask(struct sd_data *sdd, struct cpumask *sg_span, struct cpumask
*mask)
{
- const struct cpumask *sg_span = sched_group_cpus(sg);
- struct sd_data *sdd = sd->private;
struct sched_domain *sibling;
int i;
@@ -542,49 +540,34 @@ int group_balance_cpu(struct sched_group
}
static struct sched_group *
-build_group_from_child_sched_domain(struct sched_domain *sd, int cpu)
+get_overlap_group(struct sd_data *sdd, int cpu)
{
- struct sched_group *sg;
- struct cpumask *sg_span;
+ struct sched_domain *sd = *per_cpu_ptr(sdd->sd, cpu);
+ struct sched_domain *child = sd->child;
+ struct sched_group *group;
+ struct cpumask *mask = sched_domains_tmpmask2;
- sg = kzalloc_node(sizeof(struct sched_group) + cpumask_size(),
- GFP_KERNEL, cpu_to_node(cpu));
+ /*
+* Overlap must have !overlap children.
+* This is before degenerate throws them out.
+*/
+ BUG_ON(!sd->child);
- if (!sg)
- return NULL;
+ build_group_mask(sdd, sched_domain_span(child), mask);
+ cpu = cpumask_first_and(sched_domain_span(child), mask);
- sg_span = sched_group_cpus(sg);
- if (sd->child)
- cpumask_copy(sg_span, sched_domain_span(sd->child));
- else
- cpumask_copy(sg_span, sched_domain_span(sd));
+ BUG_ON(cpu >= nr_cpu_ids);
- return sg;
-}
+ group = *per_cpu_ptr(sdd->sg, cpu);
+ group->sgc = *per_cpu_ptr(sdd->sgc, cpu);
-static void init_overlap_sched_group(struct sched_domain *sd,
-struct sched_group *sg)
-{
- struct cpumask *mask = sched_domains_tmpmask2;
- struct sd_data *sdd = sd->private;
- struct cpumask *sg_span;
- int cpu;
+ atomic_inc(&group->ref);
+ atomic_inc(&group->sgc->ref);
- build_group_mask(sd, sg, mask);
- cpu = cpumask_first_and(sched_group_cpus(sg), mask);
+ cpumask_copy(sched_group_cpus(group), sched_domain_span(child));
+ cpumask_copy(sched_group_mask(group), mask);
- sg->sgc = *per_cpu_ptr(sdd->sgc, cpu);
- if (atomic_inc_return(&sg->sgc->ref) == 1)
- cpumask_copy(sched_group_mask(sg), mask);
-
- /*
-* Initialize sgc->capacity such that even if we mess up the
-* domains and no possible iteration will get us here, we won't
-* die on a /0 trap.
-*/
- sg_span = sched_group_cpus(sg);
- sg->sgc->capacity = SCHED_CAPACITY_SCALE * cpumask_weight(sg_span);
- sg->sgc->min_capacity = SCHED_CAPACITY_SCALE;
+ return group;
}
static int
@@ -620,14 +603,18 @@ build_overlap_sched_groups(struct sched_
if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
continue;
- sg = build_group_from_child_sched_domain(sibling, cpu);
- if (!sg)
- goto fail;
+ sg = get_overlap_group(sdd, i);
sg_span = sched_group_cpus(sg);
cpumask_or(covered, covered, sg_span);
- init_overlap_sched_group(sd, sg);
+ /*
+* Initialize sgc->capacity such that even if we mess up the
+* domains and no possible iteration will get us here, we won't
+* die on a /0 trap.
+*/
+ sg->sgc->capacity = SCHED_CAPACITY_SCALE *
cpumask_weight(sg_span);
+ sg->sgc->min_capacity = SCHED_CAPACITY_SCALE
Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()
On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: > From: Alexander Potapenko > Date: Mon, 24 Apr 2017 14:59:14 +0200 > >> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >> |val| remains uninitialized and the syscall may behave differently >> depending on its value. This doesn't have security consequences (as the >> uninit bytes aren't copied back), but it's still cleaner to initialize >> |val| and ensure optlen is not less than sizeof(int). >> >> This bug has been detected with KMSAN. >> >> Signed-off-by: Alexander Potapenko >> --- >> v2: - if len < sizeof(int), make it 0 > > No, you should signal an error if the len is too small. According to manpages, only setsockopt() may return EINVAL. Is it ok to change the behavior of getsockopt() to return EINVAL in this case? (I.e. won't we break existing users that don't expect it?) > Returning zero bytes to userspace silently makes the user think that > he got the data he asked for. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Re: [PATCH 20/22] tools arch: Sync arch/x86/lib/memcpy_64.S with the kernel
On Tue, 2017-04-25 at 16:18 +, Luck, Tony wrote: > > > If we are going to have all these copies of kernel files below > > > "tools/...", perhaps checkpatch could warn people touching one > > > that the other needs the same update? > > > > How would checkpatch know tools hasn't already updated the other? > > If checkpatch had a list of all the tools copies, it could warn if a patch > touched a file without touching the copy. I rather doubt these files are modified simultaneously. A quick and no doubt incomplete git log -- "tools/*/kernel.h" seems to show little simultaneity. > Not completely ideal because people might update the two files in > separate patches in a series (in which case they would see warnings > from both patches). > > Also means that checkpatch needs the list of copied files ... not sure > how often that changes. Nor I. Anyway, feel free to propose an actual patch.
Re: [PATCH v2 15/18] dt-bindings: sound: Add bindings for Cirrus Logic Madera codecs
On Tue, 2017-04-25 at 16:52 +0100, Mark Brown wrote: > On Mon, Apr 24, 2017 at 05:08:41PM +0100, Richard Fitzgerald wrote: > > The Cirrus Logic Madera codecs are a family of related codecs with > > extensive digital and analogue I/O, digital mixing and routing, > > signal processing and programmable DSPs. > > Please submit patches using subject lines reflecting the style for the > subsystem. This makes it easier for people to identify relevant > patches. Look at what existing commits in the area you're changing are > doing and make sure your subject lines visually resemble what they're > doing. > > > +Required properties: > > + - compatible : One of the following chip-specific strings: > > +"cirrus,cs47l35-codec" > > +"cirrus,cs47l85-codec" > > +"cirrus,cs47l90-codec" > > You shouldn't have compatible strings for subfunctions of a MFD unless > these represent meaningful reusable IPs that can exist separately from > the parent chip, that's clearly not the case here. All you're doing > here is encoding Linux internal abstractions which aren't OS neutral and > might change in future (for example clocking might move more into the > clock API). While that's nice, the of_node doesn't get populated if there isn't a compatible string. And people don't like workarounds for the missing of_node.
Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree
On Tue, Apr 25, 2017 at 09:24:34AM -0700, Ryan Lee wrote: > I was not able to see any activities about MAX98927 driver after previous > mail. > Is there anything wrong with this driver? Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. I'm not sure what communication you're expecting... if nobody is complaining about your driver that's probably good? signature.asc Description: PGP signature
[PATCH 0/5] {ioctl_}userfaultfd.2: initial updates for 4.11
Hello Michael, These patches are some kind of brief highlights of the changes to the userfaultfd pages. The changes to userfaultfd functionality are also described at update to Documentation/vm/userfaultfd.txt [1]. In general, there were three major additions: * hugetlbfs support * shmem support * non-page fault events I think we should add some details about using userfaultfd with different memory types, describe meaning of each feature bits and add some text about the new events. I haven't updated 'struct uffd_msg' yet, and I hesitate whether it's description belongs to userfaultfd.2 or ioctl_userfaultfd.2 As for the userfaultfd.7 we've discussed earlier, I believe it would repeat Documentation/vm/userfaultfd.txt in way, so I'm not really sure it is required. -- Sincerely yours, Mike. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a02026d390ea1bb0c16a0e214e45613a3e3d885 Mike Rapoport (5): userfaultfd.2: describe memory types that can be used from 4.11 ioctl_userfaultfd.2: describe memory types that can be used from 4.11 ioctl_userfaultfd.2: update UFFDIO_API description userfaultfd.2: add Linux container migration use-case to NOTES usefaultfd.2: add brief description of "non-cooperative" mode man2/ioctl_userfaultfd.2 | 46 ++ man2/userfaultfd.2 | 25 ++--- 2 files changed, 60 insertions(+), 11 deletions(-) -- 1.9.1
[PATCH] x86/tboot: add an option to disable iommu force on
IOMMU harms performance signficantly when we run very fast networking
workloads. It's 40GB networking doing XDP test. Software overhead is
almost unaware, but it's the IOTLB miss (based on our analysis) which
kills the performance. We observed the same performance issue even with
software passthrough (identity mapping), only the hardware passthrough
survives. The pps with iommu (with software passthrough) is only about
~30% of that without it. This is a limitation in hardware based on our
observation, so we'd like to disable the IOMMU force on, but we do want
to use TBOOT and we can sacrifice the DMA security bought by IOMMU. I
must admit I know nothing about TBOOT, but TBOOT guys (cc-ed) think not
eabling IOMMU is totally ok.
So introduce a new boot option to disable the force on. It's kind of
silly we need to run into intel_iommu_init even without force on, but we
need to disable TBOOT PMR registers. For system without the boot option,
nothing is changed.
Signed-off-by: Shaohua Li
---
Documentation/admin-guide/kernel-parameters.txt | 5 +
arch/x86/kernel/tboot.c | 3 +++
drivers/iommu/intel-iommu.c | 21 -
include/linux/dma_remapping.h | 1 +
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a..10c393b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1578,6 +1578,11 @@
extended tables themselves, and also PASID support. With
this option set, extended tables will not be used even
on hardware which claims to support them.
+ tboot_noforce [Default Off]
+ By default, tboot will force Intel IOMMU on, which
+ could harm performance for some workloads even IOMMU
+ identity mapping is enabled. This option will avoid
+ the 'force on' for Intel IOMMU.
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
0 disables intel_idle and fall back on acpi_idle.
diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index b868fa1..edbdfe6 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -510,6 +510,9 @@ int tboot_force_iommu(void)
if (!tboot_enabled())
return 0;
+ if (!intel_iommu_tboot_noforce)
+ return 1;
+
if (no_iommu || swiotlb || dmar_disabled)
pr_warning("Forcing Intel-IOMMU to enabled\n");
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d412a31..fa5d56d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -183,6 +183,7 @@ static int rwbf_quirk;
* (used when kernel is launched w/ TXT)
*/
static int force_on = 0;
+int intel_iommu_tboot_noforce;
/*
* 0: Present
@@ -607,6 +608,10 @@ static int __init intel_iommu_setup(char *str)
"Intel-IOMMU: enable pre-production PASID
support\n");
intel_iommu_pasid28 = 1;
iommu_identity_mapping |= IDENTMAP_GFX;
+ } else if (!strncmp(str, "tboot_noforce", 13)) {
+printk(KERN_INFO
+ "Intel-IOMMU: not forcing on after tboot. This
could expose security risk for tboot\n");
+ intel_iommu_tboot_noforce = 1;
}
str += strcspn(str, ",");
@@ -4840,8 +4845,22 @@ int __init intel_iommu_init(void)
goto out_free_dmar;
}
- if (no_iommu || dmar_disabled)
+ if (no_iommu || dmar_disabled) {
+ /*
+* We exit the function here to ensure IOMMU's remapping and
+* mempool aren't setup, which means that the IOMMU's PMRs
+* won't be disabled via the call to init_dmars(). So disable
+* it explicitly here. The PMRs were setup by tboot prior to
+* calling SENTER, but the kernel is expected to reset/tear
+* down the PMRs.
+*/
+ if (intel_iommu_tboot_noforce) {
+ for_each_iommu(iommu, drhd)
+ iommu_disable_protect_mem_regions(iommu);
+ }
+
goto out_free_dmar;
+ }
if (list_empty(&dmar_rmrr_units))
pr_info("No RMRR found\n");
diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
index 187c102..9088407 100644
--- a/include/linux/dma_remapping.h
+++ b/include/linux/dma_remapping.h
@@ -39,6 +39,7 @@ extern int iommu_calculate_agaw(struct intel_iommu *iommu);
extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
extern int dmar_disabled;
extern int intel_io
[PATCH 3/5] ioctl_userfaultfd.2: update UFFDIO_API description
Signed-off-by: Mike Rapoport
---
man2/ioctl_userfaultfd.2 | 38 --
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
index 78abc4d..dade631 100644
--- a/man2/ioctl_userfaultfd.2
+++ b/man2/ioctl_userfaultfd.2
@@ -95,11 +95,6 @@ struct uffdio_api {
The
.I api
field denotes the API version requested by the application.
-Before the call, the
-.I features
-field must be initialized to zero.
-In the future, it is intended that this field can be used to ask
-whether particular features are supported.
The kernel verifies that it can support the requested API version,
and sets the
@@ -109,9 +104,40 @@ and
fields to bit masks representing all the available features and the generic
.BR ioctl (2)
operations available.
-Currently, zero (i.e., no feature bits) is placed in the
+
+For Linux kernel versions before 4.11, the
+.I features
+field must be initialized to zero before the call to
+.I UFFDIO_API
+, and zero (i.e., no feature bits) is placed in the
+.I features
+field by the kernel upon return from
+.BR ioctl (2).
+
+Starting from Linux 4.11, the
+.I features
+field can be used to to ask whether particular features are supported
+and explicitly enable userfaultfd features that are disabled by default.
+The kernel always reports all the available features in the
.I features
field.
+.\" FIXME add more details about feature negotiation and enablement
+
+Since Linux 4.11, the following feature bits may be set:
+.TP
+.B UFFD_FEATURE_EVENT_FORK
+.TP
+.B UFFD_FEATURE_EVENT_REMAP
+.TP
+.B UFFD_FEATURE_EVENT_REMOVE
+.TP
+.B UFFD_FEATURE_EVENT_UNMAP
+.TP
+.B UFFD_FEATURE_MISSING_HUGETLBFS
+.TP
+.B UFFD_FEATURE_MISSING_SHMEM
+.\" FIXME add feature description
+
The returned
.I ioctls
field can contain the following bits:
--
1.9.1
[PATCH 1/5] userfaultfd.2: describe memory types that can be used from 4.11
Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index 1603c20..c89484f 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -130,8 +130,12 @@ Details of the various operations can be found in .BR ioctl_userfaultfd (2). -Currently, userfaultfd can be used only with anonymous private memory -mappings. +Up to Linux 4.11, +userfaultfd can be used only with anonymous private memory mappings. + +Since Linux 4.11, +userfaultfd can be also used with hugetlbfs and shared memory mappings. + .\" .SS Reading from the userfaultfd structure Each -- 1.9.1
[PATCH 4/5] userfaultfd.2: add Linux container migration use-case to NOTES
Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index c89484f..dc37319 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -279,7 +279,8 @@ signal and It can also be used to implement lazy restore for checkpoint/restore mechanisms, as well as post-copy migration to allow (nearly) uninterrupted execution -when transferring virtual machines from one host to another. +when transferring virtual machines and Linux containers +from one host to another. .SH EXAMPLE The program below demonstrates the use of the userfaultfd mechanism. The program creates two threads, one of which acts as the -- 1.9.1
[PATCH 5/5] usefaultfd.2: add brief description of "non-cooperative" mode
Signed-off-by: Mike Rapoport --- man2/userfaultfd.2 | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2 index dc37319..291dd10 100644 --- a/man2/userfaultfd.2 +++ b/man2/userfaultfd.2 @@ -89,6 +89,20 @@ them using the operations described in .BR ioctl_userfaultfd (2). When servicing the page fault events, the fault-handling thread can trigger a wake-up for the sleeping thread. + +It is possible for the faulting threads and the fault-handling threads +to run in the context of different processes. +In this case, these threads may belong to different programs, +and the program that executes the faulting threads +will not necessarily cooperate with the program that handles the page faults. +In such non-cooperative mode, +the process that monitors userfaultfd and handles page faults, +needs to be aware of the changes in the virtual memory layout +of the faulting process to avoid memory corruption. +.\" FIXME elaborate about non-cooperating mode, describe its limitations +.\" for kerneles before 4.11, features added in 4.11 +.\" and limitations remaining in 4.11 +.\" Maybe it's worth adding a dedicated sub-section... .\" .SS Userfaultfd operation After the userfaultfd object is created with -- 1.9.1
[PATCH 2/5] ioctl_userfaultfd.2: describe memory types that can be used from 4.11
Signed-off-by: Mike Rapoport --- man2/ioctl_userfaultfd.2 | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 66fbfdc..78abc4d 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -169,11 +169,15 @@ field was not zero. (Since Linux 4.3.) Register a memory address range with the userfaultfd object. The pages in the range must be "compatible". -In the current implementation, -.\" According to Mike Rapoport, this will change in Linux 4.11. + +Up to Linux kernel 4.11, only private anonymous ranges are compatible for registering with .BR UFFDIO_REGISTER . +Since Linux 4.11, +hugetlbfs and shared memory ranges are also compatible with +.BR UFFDIO_REGISTER . + The .I argp argument is a pointer to a -- 1.9.1
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2
On Tue, Apr 25, 2017 at 12:22 PM, Christian König
wrote:
> Am 25.04.2017 um 17:14 schrieb Alex Deucher:
>>
>> On Tue, Apr 25, 2017 at 11:09 AM, Christian König
>> wrote:
>>>
>>> Am 25.04.2017 um 16:34 schrieb Alex Deucher:
On Tue, Apr 25, 2017 at 9:19 AM, Christian König
wrote:
>
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> v2: rebased, style cleanups, disable mem decode before resize,
> handle gmc_v9 as well, round size up to power of two.
>
> Signed-off-by: Christian König
> ---
>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37
> ++
>drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ---
>drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ---
>drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10
>5 files changed, 54 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 4a16e3c..9484062 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1879,6 +1879,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> amdgpu_device *adev, struct ttm_tt *ttm,
>struct ttm_mem_reg *mem);
>void amdgpu_vram_location(struct amdgpu_device *adev, struct
> amdgpu_mc
> *mc, u64 base);
>void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> amdgpu_mc
> *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
> size);
>int amdgpu_ttm_init(struct amdgpu_device *adev);
>void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a09ad3cf..d5ca77a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -695,6 +695,43 @@ void amdgpu_gtt_location(struct amdgpu_device
> *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start,
> mc->gtt_end);
>}
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
I'd suggest renaming this to amdgpu_device_resize_bar() to try and
impose some consistency in this file, but not a big deal either way.
> +{
> + u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
> + u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
> + u16 cmd;
> + int r;
> +
> + /* Free the doorbell mapping, it most likely needs to move as
> well */
> + amdgpu_doorbell_fini(adev);
> + pci_release_resource(adev->pdev, 2);
This should check for if (adev->asic_type >= CHIP_BONAIRE) since SI
didn't have doorbells.
> +
> + /* Disable memory decoding while we change the BAR addresses
> and
> size */
> + pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
> + pci_write_config_word(adev->pdev, PCI_COMMAND,
> + cmd & ~PCI_COMMAND_MEMORY);
> +
> + r = pci_resize_resource(adev->pdev, 0, rbar_size);
> + if (r == -ENOSPC)
> + DRM_INFO("Not enough PCI address space for a large
> BAR.");
> + else if (r && r != -ENOTSUPP)
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> +
> + pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
> +
> + /* When the doorbell BAR isn't available we have no chance of
> +* using the device.
> +*/
> + BUG_ON(amdgpu_doorbell_init(adev));
Same here.
> +}
> +
>/*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index a9083a1..ae71524 100644
What about SI (gmc_v6_0.c)?
>>>
>>>
>>> As far as I know there is no SI hardware with resizeable BAR support.
>>>
>>> The all VI generation can do this, but I'm not 100% sure if there aren't
>>> any
>>> Bonaires out there which can handle it as well that's why I added gmc_v7
>>> support.
>>>
>>> Still need to double check that.
>>
>> I think NI or even evergreen supported resizeable bars in theory,
>> although I'm not sure if any boards were fused to expose it.
>
>
> In theory yes, in practice no.
>
> Their PCIE config space defines the necessary registers, but I haven't found
> any board from
Re: [PATCH V15 04/11] efi: parse ARM processor error
On Tue, Apr 25, 2017 at 10:05:31AM -0600, Baicar, Tyler wrote: > That seems like something that should be done outside of these patches (if > added to the kernel at all). The decoding for this information would all be > vendor specific, so I'm not sure if we want to pollute the EFI code with > vendor specific error decoding. Currently we are using the RAS Daemon user > space tool for the decoding of this information since vendors can easily > pick up this tool and add an extension for their vendor specific parsing. > These prints will only happen when the firmware supports the vendor specific > error information anyway. The same questions apply here: what do you do if the machine panics because the error is fatal and you can't get it to run any userspace? Wouldn't it be good to decode the whole error? Right now we photograph screens on Intel x86 and feed the typed MCA info by hand to mcelog. Hardly an optimal situation. On AMD, there's a decoder which actually can dump the decoded critical error. (Or could - that's in flux again :-\). So yes, if stuff is too vendor-specific then you probably don't want to decode it (or add a vendor-specific decoding module like edac_mce_amd.ko, for example). But the tables from the UEFI spec, documenting IP-specific error types which should be valid for most if not all ARM64 implementations adhering to the spec, would be useful to decode. In general, the more we can decode the error in the kernel and the less we need an external help to do so, the better. Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v4 net-next] mdio_bus: Issue GPIO RESET to PHYs.
On 04/25/2017 09:22 AM, Lars-Peter Clausen wrote:
> On 04/24/2017 11:04 AM, Roger Quadros wrote:
>> On 24/04/17 02:35, Andrew Lunn wrote:
>>> On Fri, Apr 21, 2017 at 03:31:09PM +0200, Lars-Peter Clausen wrote:
On 04/21/2017 03:15 PM, Roger Quadros wrote:
> diff --git a/Documentation/devicetree/bindings/net/mdio.txt
> b/Documentation/devicetree/bindings/net/mdio.txt
> new file mode 100644
> index 000..4ffbbac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mdio.txt
> @@ -0,0 +1,33 @@
> +Common MDIO bus properties.
> +
> +These are generic properties that can apply to any MDIO bus.
> +
> +Optional properties:
> +- reset-gpios: List of one or more GPIOs that control the RESET lines
> + of the PHYs on that MDIO bus.
> +- reset-delay-us: RESET pulse width in microseconds as per PHY datasheet.
> +
> +A list of child nodes, one per device on the bus is expected. These
> +should follow the generic phy.txt, or a device specific binding document.
> +
> +Example :
> +This example shows these optional properties, plus other properties
> +required for the TI Davinci MDIO driver.
> +
> + davinci_mdio: ethernet@0x5c03 {
> + compatible = "ti,davinci_mdio";
> + reg = <0x5c03 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <2>; /* PHY datasheet states 1us min */
If this is the reset line of the PHY shouldn't it be a property of the PHY
node rather than of the MDIO controller node (which might have a reset on
its own)?
> +
> + ethphy0: ethernet-phy@1 {
> + reg = <1>;
> + };
> +
> + ethphy1: ethernet-phy@3 {
> + reg = <3>;
> + };
>>>
>>> Hi Lars-Peter
>>>
>>> We discussed this when the first proposal was made. There are two
>>> cases, to consider.
>>>
>>> 1) Here, one GPIO line resets all PHYs on the same MDIO bus. In this
>>> example, two PHYs.
>>>
>>> 2) There is one GPIO line per PHY. That is a separate case, and as you
>>> say, the reset line should probably be considered a PHY property, not
>>> an MDIO property. However, it can be messy, since in order to probe
>>> the MDIO bus, you probably need to take the PHY out of reset.
>>>
>
> But the DT binding documentation says something else "List of one or more
> GPIOs that control the RESET lines of the PHYs on that MDIO bus".
I agree, it should be defined more strictly as:
"One GPIO that controls the reset line of *all* PHYs populated on that
MDIO bus"
If there are separate lines, these automatically become properties of
the PHY nodes.
>
>>> Anyway, this patch addresses the first case, so should be accepted. If
>>> anybody wants to address the second case, they are free to do so.
>
> I think we all know that that's not going to happen. Once there is a working
> kludge there is no incentive to do a proper implementation anymore.
>
>
>> Thanks for the explanation Andrew.
>>
>> For the second case, even if the RESET GPIO property is specified
>> in the PHY node, the RESET *will* have to be done by the MDIO bus driver
>> else the PHY might not be probed at all.
>
> I'm not arguing with that, just that the hardware description should be
> truthful to the hardware topology and not to the software topology, i.e. the
> implementation details of the Linux kernel in this case. Reset GPIOs are not
> the only resource that is connected to the PHY that needs to be enabled
> before they can be enumerated. E.g. clocks and regulators fall into the same
> realm. And while you might argue that with a on-SoC phy controller node
> there wont be any conflicts in regard to the reset-gpios property, this not
> so very true for the clocks property.
Agreed, but with the exception of the unfortunate choice of words here
(single vs. multiple) there is not a really a divergence in how the
shared reset line is represented compared to other similar control
busses, is there?
>
> And MDIO is not really special in this regard, other discoverable buses
> (like USB, SDIO, ULPI) have the very same issue. Having a standardized
> binding approach where the resources are declared as part as the child child
> is preferable in my opinion.
>
>>
>> Whether we need additional code to just to make the DT look prettier is
>> questionable and if required can come as a separate patch.
>
> Unfortunately not, once it is merged it can't be changed anymore.
There are no in tree users yet, so let's get the different things fixed
right now.
--
Florian
Re: [PATCH] Fix returns of some CLK API calls, if !CONFIG_HAVE_CLOCK
On Tue, Apr 25, 2017 at 02:30:07PM +0200, Thomas Bogendoerfer wrote: > If CONFIG_HAVE_CLOCK is not set, return values of clk_get(), > devm_clk_get(), devm_get_clk_from_child(), clk_get_parent() > and clk_get_sys() are wrong. According to spec these functions > should either return a pointer to a struct clk or a valid IS_ERR > condition. NULL is neither, so returning ERR_PTR(-ENODEV) makes > more sense. That's wrong. When the clk API is disabled, the expected behaviour is that drivers will not fail. Returning ERR_PTR(-ENODEV) will cause them to fail, so will break platforms. NAK. > Without this change serial console on SNI RM400 machines (MIPS arch) > is broken, because sccnxp driver doesn't get a valid clock rate. So the driver needs to depend on HAVE_CLOCK. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH 0/2] DS1374 Watchdog fixes
On 25/04/2017 at 09:17:43 -0700, Guenter Roeck wrote: > On Tue, Apr 25, 2017 at 07:55:28AM -0700, Moritz Fischer wrote: > > Hi Guenter, > > > > On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck wrote: > > > On 04/24/2017 03:05 PM, Moritz Fischer wrote: > > > > >> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling > > >> the watchdog behavior and currently I'm investigating how to make > > >> that work via DT. > > >> > > >> Watchdog maintainers, do you have an idea on how to do that in a > > >> non breaking fashion? > > >> > > > > > > Depends on what you mean with "non breaking". Just using the normal mfd > > > mechanisms, ie define an mfd cell for each client driver, should work. > > > Do you see any problems with that ? Either case, that doesn't seem > > > to be a watchdog driver problem, or am I missing something ? > > > > Well so currently watchdog behavior is selected (out of the two options > > alarm, > > or watchdog) by enabling the configuration option mentioned above. > > If I change this over to use a dt-based approach like dallas,ds1374-mode = > > <2>; > > to select the behavior in the mfd for example, won't that break people that > > relied on the old behavior? If everyone involved is ok with that, I'm happy > > to just add it to the binding. > > > > Sorry, I must be missing something. Looking into the driver code, my > understanding is that CONFIG_RTC_DRV_DS1374_WDT enables the watchdog in > addition to rtc functionality, not one or the other. Sure you would need > a different configuration option if you were to move the watchdog code into > drivers/watchdog, but other than that I don't really understand the problem. > What is the issue with, for example, > The watchdog functionality and the rtc alarm are mutually exclusive. > > The idea was to fix what's broken currently (this patchset) and then > > refactor. > > But if you prefer I can do all in one go instead. > > > > It just seemed a waste to me to change/fix a function which is going to > be removed in a subsequent patch (I seem to recall that there was a fix > to the ioctl function). > I'd say that it depends on whether you want to backport the fixes to the stable kernels. Backporting the full rework is probably riskier. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()
From: Alexander Potapenko Date: Tue, 25 Apr 2017 18:27:04 +0200 > On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >> From: Alexander Potapenko >> Date: Mon, 24 Apr 2017 14:59:14 +0200 >> >>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >>> |val| remains uninitialized and the syscall may behave differently >>> depending on its value. This doesn't have security consequences (as the >>> uninit bytes aren't copied back), but it's still cleaner to initialize >>> |val| and ensure optlen is not less than sizeof(int). >>> >>> This bug has been detected with KMSAN. >>> >>> Signed-off-by: Alexander Potapenko >>> --- >>> v2: - if len < sizeof(int), make it 0 >> >> No, you should signal an error if the len is too small. > According to manpages, only setsockopt() may return EINVAL. > Is it ok to change the behavior of getsockopt() to return EINVAL in > this case? (I.e. won't we break existing users that don't expect it?) They are currently getting corrupt data depending upon the endianness, so -EINVAL is a serious improvement.
Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
On Tue, 2017-04-25 at 16:55 +0200, Peter Rosin wrote: > On 2017-04-25 16:16, Peter Rosin wrote: > > On 2017-04-24 16:59, Philipp Zabel wrote: > >> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote: > >> [...] > How about an atomic use_count on the mux_control, a bool shared that is > only set by the first consumer, and controls whether selecting locks? > >>> > >>> That has the drawback that it is hard to restore the mux-control in a safe > >>> way so that exclusive consumers are allowed after the last shared consumer > >>> puts the mux away. > >> > >> True. > >> > >>> Agreed, it's a corner case, but I had this very similar > >>> patch going through the compiler when I got this mail. Does it work as > >>> well > >>> as what you suggested? > >> > >> Yes, this patch works just as well. > > > > Right, as expected :-) However, I don't like it much. It divides the mux > > consumers into two camps in a way that makes it difficult to select which > > camp a consumer should be in. > > > > E.g. consider the iio-mux. The current implementation only supports quick > > accesses that fit the mux_control_get_shared case. But if that mux in the > > future needs to grow continuous buffered accesses, I think there will be > > pressure to switch it over to the exclusive mode. Because that is a lot > > closer to what you are doing with the video-mux. And then what? It will be > > impossible to predict if the end user is going to use buffered accesses or > > not... > > > > So, I think the best approach is to skip the distinction between shared > > and exclusive consumers and instead implement the locking with an ordinary > > semaphore (instead of the old rwsem or the current mutex). Semaphores don't > > have the property that the same task should down/up them (mutexes require > > that for lock/unlock, and is also the reason for the lockdep complaint) and > > thus fits better for long-time use such as yours or the above iio-mux with > > buffered accesses. It should also hopefully be cheaper that an rwsem, and > > not have any downgrade_write calls thus possibly keeping Greg sufficiently > > happy... No idea whether this will placate Greg, but it does work for the video-mux case. The documentation for mux_control_(try_)select should mention that these calls will hold the mux lock until deselect is called, and the documentation for mux_control_select should probably mention that it will block until the lock is released. > > Sure, consumers can still dig themselves into a hole by not calling deselect > > as they should, but at least I think it can be made to work w/o dividing the > > consumers... > > Like this (only compile-tested). Philipp, it should work the same as with > the rwsem in v13 and earlier. At least for your case... regards Philipp
Re: [PATCH] macsec: dynamically allocate space for sglist
2017-04-25, 17:23:00 +0200, Jason A. Donenfeld wrote:
> We call skb_cow_data, which is good anyway to ensure we can actually
> modify the skb as such (another error from prior). Now that we have the
> number of fragments required, we can safely allocate exactly that amount
> of memory.
>
> Signed-off-by: Jason A. Donenfeld
> Cc: Sabrina Dubroca
> Cc: secur...@kernel.org
> Cc: sta...@vger.kernel.org
> ---
> drivers/net/macsec.c | 25 -
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> index dbab05afcdbe..56dafdee4c9c 100644
> --- a/drivers/net/macsec.c
> +++ b/drivers/net/macsec.c
[...]
> @@ -917,6 +926,7 @@ static struct sk_buff *macsec_decrypt(struct sk_buff *skb,
> {
> int ret;
> struct scatterlist *sg;
> + struct sk_buff *trailer;
> unsigned char *iv;
> struct aead_request *req;
> struct macsec_eth_header *hdr;
> @@ -927,7 +937,12 @@ static struct sk_buff *macsec_decrypt(struct sk_buff
> *skb,
> if (!skb)
> return ERR_PTR(-ENOMEM);
>
> - req = macsec_alloc_req(rx_sa->key.tfm, &iv, &sg);
> + ret = skb_cow_data(skb, 0, &trailer);
> + if (unlikely(ret < 0)) {
> + kfree_skb(skb);
> + return ERR_PTR(ret);
> + }
> + req = macsec_alloc_req(rx_sa->key.tfm, &iv, &sg, ret);
> if (!req) {
> kfree_skb(skb);
> return ERR_PTR(-ENOMEM);
There's a problem here (and in macsec_encrypt): you need to update the
call to sg_init_table, like I did in my patch. Otherwise,
sg_init_table() is going to access sg[MAX_SKB_FRAGS], which may be
past what you allocated.
How did you test this? ;)
--
Sabrina
RE: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases
From: Naveen N. Rao > Sent: 25 April 2017 17:18 > 1. Fail early for invalid/zero length symbols. > 2. Detect names of the form and skip checking for kernel > symbols in that case. > > Signed-off-by: Naveen N. Rao > --- > Masami, Michael, > I have added two very simple checks here, which I felt is good to have, > rather than the elaborate checks in the previous version. Given the > change in module code to use strnchr(), the checks are now safe and > further tests are not probably not that useful. ... > + if (strnchr(name, MODULE_NAME_LEN, ':')) > + return module_kallsyms_lookup_name(name); Should that be MODULE_NAME_LEN - 1 ? David
Re: [PATCH] x86/refcount: Implement fast refcount_t handling
On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote:
> On 25 Apr 2017 at 0:01, Peter Zijlstra wrote:
>> How is the below not useful fodder for an exploit? It might be a less
>> common bug, and perhaps a bit more fiddly to make work, but afaict its
>> still a full use-after-free and therefore useful.
>>
>> ---
>>
>> Thread-AThread-B
>>
>> if(dec_and_test(&obj->ref)) { // true, ref==0
>>
>> inc(&obj->ref) // ref: 0->1
>>
>> kfree(obj);
>> }
>
> ... and tell me why an attacker would let Thread-B do that increment
> (that you're trying to detect) *before* the underlying memory gets
> reused and thus the 0 changed to something else? hint: he'll do everything
> in his power to prevent that, either by winning the race or if there's
> no race (no refcount users outside his control), he'll win every time.
> IOW, checking for 0 is pointless and you kinda proved it yourself now.
Right, having a deterministic protection (checking for overflow) is
best since it stops all exploits using that path. Hoping that an
attacker is unlucky and hits a notification after they've already
landed their corruption is not a very useful defense. It certainly has
a non-zero value, but stopping overflow 100% is better. Especially
when we can do it with no meaningful change in performance which lets
us actually do the atomic_t -> refcount_t conversion everywhere.
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH v8 1/3] backlight arcxcnn add arc to vendor prefix
On Monday, April 24, 2017 1:56 PM, Olimpiu Dejeu wrote: > > On Mon, April 24, 2017 11:10 AM, Rob Herring < r...@kernel.org> wrote: > > > On Wed, Mar 15, 2017 at 2:45 PM, Olimpiu Dejeu > wrote: > >> backlight: Add arc to vendor prefixes > >> Signed-off-by: Olimpiu Dejeu > >> --- > >> v8: > >> - Version to match other patches in set > >> > >> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > >> b/Documentation/devicetree/bindings/vendor-prefixes.txt > >> index 16d3b5e..6f33a4b 100644 > >> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > >> @@ -28,6 +28,7 @@ andestech Andes Technology Corporation > >> apmApplied Micro Circuits Corporation (APM) > >> aptina Aptina Imaging > >> arasan Arasan Chip Systems > >> +arcArctic Sand > > >arc is also a cpu arch. While not a vendor, it could be confusing. How > about "arctic" >instead? > > Rob, will do, i.e. I will change it to "arctic" Hi Olimpiu, Oh, "arc" and "arctic" is totally different. In my opinion, one of the purposes of DT is to describe hardware stuffs. So, please use more detailed words. > > >BTW, some reason your patches are not going to the DT list. > > > I'm emailing to devicet...@vger.kernel.org, I think this is the correct > list. Please advise. DT is some kind of ABI. It means that changing DT names such as property names is not easy, after DT patches were merged. So, if someone want to add new DT stuff into the vanilla kernel, that patch should be reviewed more thoroughly than normal patches about driver stuffs. Thanks, Jingoo Han > > > >Rob > Olimpiu >
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: > On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >> == >> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 >> net/ipv6/route.c:3551 at addr 88007e523694 >> Read of size 4 by task syz-executor3/24426 >> CPU: 2 PID: 24426 Comm: syz-executor3 Not tainted 4.10.0+ #293 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:16 [inline] >> dump_stack+0x2fb/0x3fd lib/dump_stack.c:52 >> kasan_object_err+0x1c/0x90 mm/kasan/report.c:166 >> print_address_description mm/kasan/report.c:208 [inline] >> kasan_report_error mm/kasan/report.c:292 [inline] >> kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314 >> kasan_report mm/kasan/report.c:334 [inline] >> __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334 >> rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3551 >> fib6_dump_node+0x101/0x1a0 net/ipv6/ip6_fib.c:315 >> fib6_walk_continue+0x4b3/0x620 net/ipv6/ip6_fib.c:1576 >> fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1621 >> fib6_dump_table net/ipv6/ip6_fib.c:374 [inline] >> inet6_dump_fib+0x832/0xea0 net/ipv6/ip6_fib.c:447 > > My expectation is that this one is fixed with the ipv6 patch I have sent > (not yet committed). Are you seeing this backtrace with that patch? Before applying your patch I was hitting reports related to fib6 all the time. I've stopped seeing them for some time after I applied your patch. However today another one was triggered: == BUG: KASAN: slab-out-of-bounds in find_rr_leaf net/ipv6/route.c:722 [inline] at addr 880033dddaa8 BUG: KASAN: slab-out-of-bounds in rt6_select net/ipv6/route.c:758 [inline] at addr 880033dddaa8 BUG: KASAN: slab-out-of-bounds in ip6_pol_route+0x1b1e/0x1ba0 net/ipv6/route.c:1091 at addr 880033dddaa8 Read of size 4 by task syz-executor7/9808 CPU: 2 PID: 9808 Comm: syz-executor7 Not tainted 4.11.0-rc8+ #268 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x192/0x22d lib/dump_stack.c:52 kasan_object_err+0x1c/0x70 mm/kasan/report.c:164 print_address_description mm/kasan/report.c:202 [inline] kasan_report_error mm/kasan/report.c:291 [inline] kasan_report+0x252/0x510 mm/kasan/report.c:347 __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367 find_rr_leaf net/ipv6/route.c:722 [inline] rt6_select net/ipv6/route.c:758 [inline] ip6_pol_route+0x1b1e/0x1ba0 net/ipv6/route.c:1091 ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212 fib6_rule_action+0x261/0x8a0 net/ipv6/fib6_rules.c:100 fib_rules_lookup+0x34b/0xae0 net/core/fib_rules.c:265 fib6_rule_lookup+0x175/0x360 net/ipv6/fib6_rules.c:44 ip6_route_output_flags+0x260/0x2f0 net/ipv6/route.c:1240 ip6_route_output include/net/ip6_route.h:79 [inline] ip6_dst_lookup_tail+0xe59/0x1640 net/ipv6/ip6_output.c:959 ip6_dst_lookup_flow+0xb1/0x260 net/ipv6/ip6_output.c:1082 ip6_sk_dst_lookup_flow+0x2c6/0x7f0 net/ipv6/ip6_output.c:1113 udpv6_sendmsg+0x2350/0x3310 net/ipv6/udp.c:1219 inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 SYSC_sendto+0x660/0x810 net/socket.c:1696 SyS_sendto+0x40/0x50 net/socket.c:1664 entry_SYSCALL_64_fastpath+0x1a/0xa9 RIP: 0033:0x4458d9 RSP: 002b:7ff3a5343b58 EFLAGS: 0282 ORIG_RAX: 002c RAX: ffda RBX: 00708000 RCX: 004458d9 RDX: 0fa8 RSI: 2000 RDI: 0005 RBP: 4300 R08: 20006000 R09: 001c R10: 0004 R11: 0282 R12: 006e33c0 R13: 0005 R14: 0029 R15: 0023 Object at 880033ddd940, in cache ip_dst_cache size: 224 Allocated: PID = 9717 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:513 set_track mm/kasan/kasan.c:525 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555 slab_post_alloc_hook mm/slab.h:456 [inline] slab_alloc_node mm/slub.c:2718 [inline] slab_alloc mm/slub.c:2726 [inline] kmem_cache_alloc+0xa8/0x160 mm/slub.c:2731 dst_alloc+0x11b/0x1a0 net/core/dst.c:209 rt_dst_alloc+0xf0/0x5d0 net/ipv4/route.c:1497 __mkroute_output net/ipv4/route.c:2181 [inline] __ip_route_output_key_hash+0xdc4/0x2930 net/ipv4/route.c:2391 __ip_route_output_key include/net/route.h:123 [inline] ip_route_output_flow+0x29/0xa0 net/ipv4/route.c:2477 ip_route_output_key include/net/route.h:133 [inline] sctp_v4_get_dst+0x606/0x1420 net/sctp/protocol.c:458 sctp_transport_route+0xa8/0x420 net/sctp/transport.c:287 sctp_assoc_add_peer+0x5a5/0x1470 net/sctp/associola.c:656 sctp_sendmsg+0x18a8/0x3b50 net/sctp/socket.c:1871 inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c
Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()
On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote:
> The nvdimm_flush() mechanism helps to reduce the impact of an ADR
> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing
> platform WPQ (write-pending-queue) buffers when power is removed. The
> nvdimm_flush() mechanism performs that same function on-demand.
>
> When a pmem namespace is associated with a block device, an
> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH
> request. These requests are typically associated with filesystem
> metadata updates. However, when a namespace is in device-dax mode,
> userspace (think database metadata) needs another path to perform the
> same flushing. In other words this is not required to make data
> persistent, but in the case of metadata it allows for a smaller failure
> domain in the unlikely event of an ADR failure.
>
> The new 'flush' attribute is visible when the individual DIMMs backing a
> given interleave-set are described by platform firmware. In ACPI terms
> this is "NVDIMM Region Mapping Structures" and associated "Flush Hint
> Address Structures". Reads return "1" if the region supports triggering
> WPQ flushes on all DIMMs. Reads return "0" the flush operation is a
> platform nop, and in that case the attribute is read-only.
>
> Cc: Jeff Moyer
> Cc: Masayoshi Mizuma
> Signed-off-by: Dan Williams
> ---
> drivers/nvdimm/region_devs.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
> index 24abceda986a..c48f3eddce2d 100644
> --- a/drivers/nvdimm/region_devs.c
> +++ b/drivers/nvdimm/region_devs.c
> @@ -255,6 +255,35 @@ static ssize_t size_show(struct device *dev,
> }
> static DEVICE_ATTR_RO(size);
>
> +static ssize_t flush_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct nd_region *nd_region = to_nd_region(dev);
> +
> + /*
> + * NOTE: in the nvdimm_has_flush() error case this attribute is
> + * not visible.
> + */
> + return sprintf(buf, "%d\n", nvdimm_has_flush(nd_region));
> +}
> +
> +static ssize_t flush_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + bool flush;
> + int rc = strtobool(buf, &flush);
> + struct nd_region *nd_region = to_nd_region(dev);
> +
> + if (rc)
> + return rc;
> + if (!flush)
> + return -EINVAL;
Is there a benefit to verifying whether the user actually pushed a "1" into
our flush sysfs entry? Why have an -EINVAL error case at all?
Flushing is non-destructive and we don't actually need the user to give us any
data, so it seems simpler to just have this code flush, regardless of what
input we received.
> + nvdimm_flush(nd_region);
> +
> + return len;
> +}
> +static DEVICE_ATTR_RW(flush);
Re: [PATCH v2] net/packet: initialize val in packet_getsockopt()
On Tue, Apr 25, 2017 at 6:32 PM, David Miller wrote: > From: Alexander Potapenko > Date: Tue, 25 Apr 2017 18:27:04 +0200 > >> On Tue, Apr 25, 2017 at 5:44 PM, David Miller wrote: >>> From: Alexander Potapenko >>> Date: Mon, 24 Apr 2017 14:59:14 +0200 >>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 |val| remains uninitialized and the syscall may behave differently depending on its value. This doesn't have security consequences (as the uninit bytes aren't copied back), but it's still cleaner to initialize |val| and ensure optlen is not less than sizeof(int). This bug has been detected with KMSAN. Signed-off-by: Alexander Potapenko --- v2: - if len < sizeof(int), make it 0 >>> >>> No, you should signal an error if the len is too small. >> According to manpages, only setsockopt() may return EINVAL. >> Is it ok to change the behavior of getsockopt() to return EINVAL in >> this case? (I.e. won't we break existing users that don't expect it?) > > They are currently getting corrupt data depending upon the endianness, > so -EINVAL is a serious improvement. On a second glance getsockopt() already returns -EINVAL in some cases, so man is already imprecise. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Re: [PATCH v2 2/2] libnvdimm, region: sysfs trigger for nvdimm_flush()
On Tue, Apr 25, 2017 at 9:37 AM, Ross Zwisler
wrote:
> On Mon, Apr 24, 2017 at 04:50:01PM -0700, Dan Williams wrote:
>> The nvdimm_flush() mechanism helps to reduce the impact of an ADR
>> (asynchronous-dimm-refresh) failure. The ADR mechanism handles flushing
>> platform WPQ (write-pending-queue) buffers when power is removed. The
>> nvdimm_flush() mechanism performs that same function on-demand.
>>
>> When a pmem namespace is associated with a block device, an
>> nvdimm_flush() is triggered with every block-layer REQ_FUA, or REQ_FLUSH
>> request. These requests are typically associated with filesystem
>> metadata updates. However, when a namespace is in device-dax mode,
>> userspace (think database metadata) needs another path to perform the
>> same flushing. In other words this is not required to make data
>> persistent, but in the case of metadata it allows for a smaller failure
>> domain in the unlikely event of an ADR failure.
>>
>> The new 'flush' attribute is visible when the individual DIMMs backing a
>> given interleave-set are described by platform firmware. In ACPI terms
>> this is "NVDIMM Region Mapping Structures" and associated "Flush Hint
>> Address Structures". Reads return "1" if the region supports triggering
>> WPQ flushes on all DIMMs. Reads return "0" the flush operation is a
>> platform nop, and in that case the attribute is read-only.
>>
>> Cc: Jeff Moyer
>> Cc: Masayoshi Mizuma
>> Signed-off-by: Dan Williams
>> ---
>> drivers/nvdimm/region_devs.c | 41
>> +
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c
>> index 24abceda986a..c48f3eddce2d 100644
>> --- a/drivers/nvdimm/region_devs.c
>> +++ b/drivers/nvdimm/region_devs.c
>> @@ -255,6 +255,35 @@ static ssize_t size_show(struct device *dev,
>> }
>> static DEVICE_ATTR_RO(size);
>>
>> +static ssize_t flush_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct nd_region *nd_region = to_nd_region(dev);
>> +
>> + /*
>> + * NOTE: in the nvdimm_has_flush() error case this attribute is
>> + * not visible.
>> + */
>> + return sprintf(buf, "%d\n", nvdimm_has_flush(nd_region));
>> +}
>> +
>> +static ssize_t flush_store(struct device *dev, struct device_attribute
>> *attr,
>> + const char *buf, size_t len)
>> +{
>> + bool flush;
>> + int rc = strtobool(buf, &flush);
>> + struct nd_region *nd_region = to_nd_region(dev);
>> +
>> + if (rc)
>> + return rc;
>> + if (!flush)
>> + return -EINVAL;
>
> Is there a benefit to verifying whether the user actually pushed a "1" into
> our flush sysfs entry? Why have an -EINVAL error case at all?
>
> Flushing is non-destructive and we don't actually need the user to give us any
> data, so it seems simpler to just have this code flush, regardless of what
> input we received.
I want to be specific so that in the future if we decide that we want
to have "0" or some other value have a different meaning of "1" we
won't need to contend with userspace that may be expecting any random
value to work.
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On Tue, Apr 25, 2017 at 6:36 PM, Andrey Konovalov wrote: > On Tue, Apr 25, 2017 at 5:56 PM, David Ahern wrote: >> On 3/4/17 11:57 AM, Dmitry Vyukov wrote: >>> == >>> BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 >>> net/ipv6/route.c:3551 at addr 88007e523694 >>> Read of size 4 by task syz-executor3/24426 >>> CPU: 2 PID: 24426 Comm: syz-executor3 Not tainted 4.10.0+ #293 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >>> Call Trace: >>> __dump_stack lib/dump_stack.c:16 [inline] >>> dump_stack+0x2fb/0x3fd lib/dump_stack.c:52 >>> kasan_object_err+0x1c/0x90 mm/kasan/report.c:166 >>> print_address_description mm/kasan/report.c:208 [inline] >>> kasan_report_error mm/kasan/report.c:292 [inline] >>> kasan_report.part.2+0x1b0/0x460 mm/kasan/report.c:314 >>> kasan_report mm/kasan/report.c:334 [inline] >>> __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:334 >>> rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3551 >>> fib6_dump_node+0x101/0x1a0 net/ipv6/ip6_fib.c:315 >>> fib6_walk_continue+0x4b3/0x620 net/ipv6/ip6_fib.c:1576 >>> fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1621 >>> fib6_dump_table net/ipv6/ip6_fib.c:374 [inline] >>> inet6_dump_fib+0x832/0xea0 net/ipv6/ip6_fib.c:447 >> >> My expectation is that this one is fixed with the ipv6 patch I have sent >> (not yet committed). Are you seeing this backtrace with that patch? > > Before applying your patch I was hitting reports related to fib6 all the time. > I've stopped seeing them for some time after I applied your patch. > However today another one was triggered: I'll keep fuzzing in the meantime to make sure. Maybe I'll be able to collect more reports or even another reproducer. > > == > BUG: KASAN: slab-out-of-bounds in find_rr_leaf net/ipv6/route.c:722 > [inline] at addr 880033dddaa8 > BUG: KASAN: slab-out-of-bounds in rt6_select net/ipv6/route.c:758 > [inline] at addr 880033dddaa8 > BUG: KASAN: slab-out-of-bounds in ip6_pol_route+0x1b1e/0x1ba0 > net/ipv6/route.c:1091 at addr 880033dddaa8 > Read of size 4 by task syz-executor7/9808 > CPU: 2 PID: 9808 Comm: syz-executor7 Not tainted 4.11.0-rc8+ #268 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:16 [inline] > dump_stack+0x192/0x22d lib/dump_stack.c:52 > kasan_object_err+0x1c/0x70 mm/kasan/report.c:164 > print_address_description mm/kasan/report.c:202 [inline] > kasan_report_error mm/kasan/report.c:291 [inline] > kasan_report+0x252/0x510 mm/kasan/report.c:347 > __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367 > find_rr_leaf net/ipv6/route.c:722 [inline] > rt6_select net/ipv6/route.c:758 [inline] > ip6_pol_route+0x1b1e/0x1ba0 net/ipv6/route.c:1091 > ip6_pol_route_output+0x4c/0x60 net/ipv6/route.c:1212 > fib6_rule_action+0x261/0x8a0 net/ipv6/fib6_rules.c:100 > fib_rules_lookup+0x34b/0xae0 net/core/fib_rules.c:265 > fib6_rule_lookup+0x175/0x360 net/ipv6/fib6_rules.c:44 > ip6_route_output_flags+0x260/0x2f0 net/ipv6/route.c:1240 > ip6_route_output include/net/ip6_route.h:79 [inline] > ip6_dst_lookup_tail+0xe59/0x1640 net/ipv6/ip6_output.c:959 > ip6_dst_lookup_flow+0xb1/0x260 net/ipv6/ip6_output.c:1082 > ip6_sk_dst_lookup_flow+0x2c6/0x7f0 net/ipv6/ip6_output.c:1113 > udpv6_sendmsg+0x2350/0x3310 net/ipv6/udp.c:1219 > inet_sendmsg+0x164/0x490 net/ipv4/af_inet.c:762 > sock_sendmsg_nosec net/socket.c:633 [inline] > sock_sendmsg+0xca/0x110 net/socket.c:643 > SYSC_sendto+0x660/0x810 net/socket.c:1696 > SyS_sendto+0x40/0x50 net/socket.c:1664 > entry_SYSCALL_64_fastpath+0x1a/0xa9 > RIP: 0033:0x4458d9 > RSP: 002b:7ff3a5343b58 EFLAGS: 0282 ORIG_RAX: 002c > RAX: ffda RBX: 00708000 RCX: 004458d9 > RDX: 0fa8 RSI: 2000 RDI: 0005 > RBP: 4300 R08: 20006000 R09: 001c > R10: 0004 R11: 0282 R12: 006e33c0 > R13: 0005 R14: 0029 R15: 0023 > Object at 880033ddd940, in cache ip_dst_cache size: 224 > Allocated: > PID = 9717 > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59 > save_stack+0x43/0xd0 mm/kasan/kasan.c:513 > set_track mm/kasan/kasan.c:525 [inline] > kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616 > kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:555 > slab_post_alloc_hook mm/slab.h:456 [inline] > slab_alloc_node mm/slub.c:2718 [inline] > slab_alloc mm/slub.c:2726 [inline] > kmem_cache_alloc+0xa8/0x160 mm/slub.c:2731 > dst_alloc+0x11b/0x1a0 net/core/dst.c:209 > rt_dst_alloc+0xf0/0x5d0 net/ipv4/route.c:1497 > __mkroute_output net/ipv4/route.c:2181 [inline] > __ip_route_output_key_hash+0xdc4/0x2930 net/ipv4/route.c:2391 > __ip_route_output_key include/net/route.h:123 [inline] > ip_route_output_flow+0x29/0xa0 net/
Re: [PATCH] x86/refcount: Implement fast refcount_t handling
On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: > INT_MAX threads would be needed when the leaking path is locked so > that it can only be exercised once and you'll need to get normal > (balanced) paths preempted just after the increment. if the leaking > path is lockless (can be exercised in parallel without bounds) then > 2 threads are enough where the one triggering the signed overflow > would have to be preempted while the other one does INT_MAX increments > and trigger the UAF. this is where the other mechanisms i talked about > in the past become relevant: preemption or interrupts can be disabled > or negative refcount values can be detected and acted upon (your blind > copy-pasting effort passed upon this latter opportunity by not > specializing the 'jo' into 'js' for the refcount case). Well, it's not "blind" -- I'm trying to bring the code as-is to upstream for discussion/examination with as little functional differences as possible so it's easier to compare apples to apples. (Which already resulted in more eyes looking at the code to find a bug -- thanks Jann!) But yes, jo -> js hugely increases the coverage. I'll make that change for v2. Thanks! -Kees -- Kees Cook Pixel Security
Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
On 4/25/17 10:38 AM, Andrey Konovalov wrote: > I'll keep fuzzing in the meantime to make sure. > Maybe I'll be able to collect more reports or even another reproducer. start a new email thread for each stack trace. I'll write a debug patch for the trace you hit today.
GPU hangs and X shot down with 4.11-rc6
Hi, I have just experienced X being shut down once with 4.11-rc2 and 2 times with 4.11-rc6 kernel. I do not remember seeing something like this before but it is quite possible I was just lucky to not trigger this issue before. It always happened while I was working on a presentation in LibreOffice which I do very seldom. The kernel log contains: [ 7456.721893] [drm] GPU HANG: ecode 9:0:0x86dd, in Xorg [3594], reason: Hang on render ring, action: reset [ 7456.721897] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 7456.721898] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 7456.721900] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 7456.721901] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 7456.721902] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 7456.721925] drm/i915: Resetting chip after gpu hang [ 7456.722117] [drm] RC6 on [ 7456.734588] [drm] GuC firmware load skipped [ 7464.686209] drm/i915: Resetting chip after gpu hang [ 7464.686284] [drm] RC6 on [ 7464.702469] [drm] GuC firmware load skipped [ 7472.686180] drm/i915: Resetting chip after gpu hang [ 7472.686241] [drm] RC6 on [ 7472.704565] [drm] GuC firmware load skipped [ 7480.686179] drm/i915: Resetting chip after gpu hang [ 7480.686241] [drm] RC6 on [ 7480.704583] [drm] GuC firmware load skipped [ 7493.678130] drm/i915: Resetting chip after gpu hang [ 7493.678206] [drm] RC6 on [ 7493.696505] [drm] GuC firmware load skipped The kernel message tells that the problem might be anywhere and I should report to freedesktop but I haven't changed the userspace recently so it smells more like a kernel bug to me. Does this ring bells? The GPU crash dump is attached in case it is useful. Let me know if you need additional information. Thanks! -- Michal Hocko SUSE Labs gpu_dump.gz Description: application/gzip
Re: [PATCH v3 10/20] fuse: set mapping error in writepage_locked when it fails
On Tue, 2017-04-25 at 13:19 +0200, Jan Kara wrote: > On Tue 25-04-17 06:35:13, Jeff Layton wrote: > > On Tue, 2017-04-25 at 10:17 +0200, Jan Kara wrote: > > > On Mon 24-04-17 13:14:36, Jeff Layton wrote: > > > > On Mon, 2017-04-24 at 18:04 +0200, Jan Kara wrote: > > > > > On Mon 24-04-17 09:22:49, Jeff Layton wrote: > > > > > > This ensures that we see errors on fsync when writeback fails. > > > > > > > > > > > > Signed-off-by: Jeff Layton > > > > > > > > > > Hum, but do we really want to clobber mapping errors with temporary > > > > > stuff > > > > > like ENOMEM? Or do you want to handle that in mapping_set_error? > > > > > > > > > > > > > Right now we don't really have such a thing as temporary errors in the > > > > writeback codepath. If you return an error here, the data doesn't stay > > > > dirty or anything, and I think we want to ensure that that gets reported > > > > via fsync. > > > > > > > > I'd like to see us add better handling for retryable errors for stuff > > > > like ENOMEM or EAGAIN. I think this is the first step toward that > > > > though. Once we have more consistent handling of writeback errors in > > > > general, then we can start doing more interesting things with retryable > > > > errors. > > > > > > > > So yeah, I this is the right thing to do for now. > > > > > > OK, fair enough. And question number 2): > > > > > > Who is actually responsible for setting the error in the mapping when > > > error > > > happens inside ->writepage()? Is it the ->writepage() callback or the > > > caller of ->writepage()? Or something else? Currently it seems to be a > > > strange mix (e.g. mm/page-writeback.c: __writepage() calls > > > mapping_set_error() when ->writepage() returns error) so I'd like to > > > understand what's the plan and have that recorded in the changelogs. > > > > > > > That's an excellent question. > > > > I think we probably want the writepage/launder_page operations to call > > mapping_set_error. That makes it possible for filesystems (e.g. NFS) to > > handle their own error tracking and reporting without using the new > > infrastructure. If they never call mapping_set_error then we'll always > > just return whatever their ->fsync operation returns on an fsync. > > OK, makes sense. It is also in line with what you did for DAX, 9p, or here > for FUSE. So feel free to add: > > Reviewed-by: Jan Kara > > for this patch but please also add a sentense that ->writepage() is > responsible for calling mapping_set_error() if it fails and page is not > redirtied to the changelogs of patches changing writepage handlers. > > > I'll make another pass through the tree and see whether we have some > > mapping_set_error calls that should be removed, and will flesh out > > vfs.txt to state this. Maybe that file needs a whole section on > > writeback error reporting? Hmmm... > > I think it would be nice to have all the logic described in one place. So > +1 from me. > > > That probably also means that I should drop patch 8 from this series > > (mm: ensure that we set mapping error if writeout fails), since that > > should be happening in writepage already. > > Yes. > > Honza (cc'ing Jon since I'm proposing a doc update) Here's what I'm thinking for a vfs.txt update after this series. The section on writeback_control could probably be more specific. --8<- diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 94dd27ef4a76..aa912b65792a 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -576,7 +576,23 @@ should clear PG_Dirty and set PG_Writeback. It can be actually written at any point after PG_Dirty is clear. Once it is known to be safe, PG_Writeback is cleared. -Writeback makes use of a writeback_control structure... +Writeback makes use of a writeback_control structure to direct the +operations. This tells the writepage and writepages operations something +about the nature of and reason for the writeback request, and the +constraints under which it is being done. It is also used to track state +between successive writeback requests. + +When there is an error during writeback, then an error should be +reported to fsync on all file descriptors that were open at the time of +the error. This is typically done by setting the wb_err value in the +address_space via mapping_set_error when writeback errors occur. The +vfs-layer fsync code will then report the errors on a per-fd basis. + +Filesystems are free to track errors internally if they choose, but they +should aim to provide the same semantics for error reporting when there +are multiple writers. Filesystems that track their own errors should +avoid calling mapping_set_error in order to ensure that errors stored in +the mapping aren't improperly reported by the generic filesystem code. struct address_space_operations
Re: get_zone_device_page() in get_page() and page_cache_get_speculative()
On Tue, Apr 25, 2017 at 6:19 AM, Kirill A. Shutemov
wrote:
> On Mon, Apr 24, 2017 at 11:41:51AM -0700, Dan Williams wrote:
>> On Mon, Apr 24, 2017 at 11:25 AM, Kirill A. Shutemov
>> wrote:
>> > On Mon, Apr 24, 2017 at 09:01:58PM +0300, Kirill A. Shutemov wrote:
>> >> On Mon, Apr 24, 2017 at 10:47:43AM -0700, Dan Williams wrote:
>> >> I think it's still better to do it on page_ref_* level.
>> >
>> > Something like patch below? What do you think?
>>
>> From a quick glance, I think this looks like the right way to go.
>
> Okay, but I still would like to remove manipulation with pgmap->ref from
> hot path.
>
> Can we just check that page_count() match our expectation on
> devm_memremap_pages_release() instead of this?
>
> I probably miss something in bigger picture, but would something like
> patch work too? It seems work for the test case.
No, unfortunately this is broken. It should be perfectly legal to
start the driver shutdown process while page references are still
outstanding. We use the percpu-ref infrastructure to wait for those
references to be dropped. With the approach below we'll just race and
crash.
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index a835edd2db34..695da2a19b4c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -762,19 +762,11 @@ static inline enum zone_type page_zonenum(const struct
> page *page)
> }
>
> #ifdef CONFIG_ZONE_DEVICE
> -void get_zone_device_page(struct page *page);
> -void put_zone_device_page(struct page *page);
> static inline bool is_zone_device_page(const struct page *page)
> {
> return page_zonenum(page) == ZONE_DEVICE;
> }
> #else
> -static inline void get_zone_device_page(struct page *page)
> -{
> -}
> -static inline void put_zone_device_page(struct page *page)
> -{
> -}
> static inline bool is_zone_device_page(const struct page *page)
> {
> return false;
> @@ -790,9 +782,6 @@ static inline void get_page(struct page *page)
> */
> VM_BUG_ON_PAGE(page_ref_count(page) <= 0, page);
> page_ref_inc(page);
> -
> - if (unlikely(is_zone_device_page(page)))
> - get_zone_device_page(page);
> }
>
> static inline void put_page(struct page *page)
> @@ -801,9 +790,6 @@ static inline void put_page(struct page *page)
>
> if (put_page_testzero(page))
> __put_page(page);
> -
> - if (unlikely(is_zone_device_page(page)))
> - put_zone_device_page(page);
> }
>
> #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> diff --git a/kernel/memremap.c b/kernel/memremap.c
> index 07e85e5229da..e542bb2f7ab0 100644
> --- a/kernel/memremap.c
> +++ b/kernel/memremap.c
> @@ -182,18 +182,6 @@ struct page_map {
> struct vmem_altmap altmap;
> };
>
> -void get_zone_device_page(struct page *page)
> -{
> - percpu_ref_get(page->pgmap->ref);
> -}
> -EXPORT_SYMBOL(get_zone_device_page);
> -
> -void put_zone_device_page(struct page *page)
> -{
> - put_dev_pagemap(page->pgmap);
> -}
> -EXPORT_SYMBOL(put_zone_device_page);
> -
> static void pgmap_radix_release(struct resource *res)
> {
> resource_size_t key, align_start, align_size, align_end;
> @@ -237,12 +225,21 @@ static void devm_memremap_pages_release(struct device
> *dev, void *data)
> struct resource *res = &page_map->res;
> resource_size_t align_start, align_size;
> struct dev_pagemap *pgmap = &page_map->pgmap;
> + unsigned long pfn;
>
> if (percpu_ref_tryget_live(pgmap->ref)) {
> dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
> percpu_ref_put(pgmap->ref);
> }
>
> + for_each_device_pfn(pfn, page_map) {
> + struct page *page = pfn_to_page(pfn);
> +
> + dev_WARN_ONCE(dev, page_count(page) != 1,
> + "%s: unexpected page count: %d!\n",
> + __func__, page_count(page));
> + }
> +
> /* pages are dead and unused, undo the arch mapping */
> align_start = res->start & ~(SECTION_SIZE - 1);
> align_size = ALIGN(resource_size(res), SECTION_SIZE);
> --
> Kirill A. Shutemov
Re: [PATCH] x86/mm/64: Fix crash in remove_pagetable()
On Tue, Apr 25, 2017 at 2:25 AM, Kirill A. Shutemov
wrote:
> remove_pagetable() does page walk using p*d_page_vaddr() plus cast.
> It's not canonical approach -- we usually use p*d_offset() for that.
>
> It works fine as long as all page table levels are present. We broke the
> invariant by introducing folded p4d page table level.
>
> As result, remove_pagetable() interprets PMD as PUD and it leads to
> crash:
>
> BUG: unable to handle kernel paging request at 8803
> IP: memchr_inv+0x60/0x110
> PGD 317d067
> P4D 317d067
> PUD 3180067
> PMD 33f102067
> PTE 80030060
>
> Let's fix this by using p*d_offset() instead of p*d_page_vaddr() for
> page walk.
>
> Signed-off-by: Kirill A. Shutemov
> Reported-by: Dan Williams
> Fixes: f2a6a7050109 ("x86: Convert the rest of the code to support p4d_t")
Thanks! This patch on top of tip/master passes a full run of the
nvdimm regression suite.
Tested-by: Dan Williams
Re: [PATCH v2 2/2] of: Add unit tests for applying overlays
On Mon, Apr 24, 2017 at 6:05 PM, wrote:
> From: Frank Rowand
>
> Existing overlay unit tests examine individual pieces of the overlay
> code. The new tests target the entire process of applying an overlay.
Just a few nits.
> Signed-off-by: Frank Rowand
[...]
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index 18bbb4517e25..cc76b3b81eab 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -55,6 +55,17 @@ static inline int of_property_notify(int action, struct
> device_node *np,
> }
> #endif /* CONFIG_OF_DYNAMIC */
>
> +#ifdef CONFIG_OF_UNITTEST
> +extern void __init unittest_unflatten_overlay_base(void);
> +extern void *__unflatten_device_tree(const void *blob,
This can and should be outside the ifdef.
> + struct device_node *dad,
> + struct device_node **mynodes,
> + void *(*dt_alloc)(u64 size, u64 align),
> + bool detached);
> +#else
> +static inline void unittest_unflatten_overlay_base(void) {};
> +#endif
> +
> /**
> * General utilities for working with live trees.
> *
[...]
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 62db55b97c10..884f6c1f8ae9 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1925,6 +1926,320 @@ static void __init of_unittest_overlay(void)
> static inline void __init of_unittest_overlay(void) { }
> #endif
>
> +#ifdef CONFIG_OF_OVERLAY
This can move down to...
> +
> +/*
> + * __dtb_ot_begin[] and __dtb_ot_end[] are created by cmd_dt_S_dtb
> + * in scripts/Makefile.lib
> + */
> +
> +#define OVERLAY_INFO_EXTERN(name) \
> + extern uint8_t __dtb_##name##_begin[]; \
> + extern uint8_t __dtb_##name##_end[]
> +
> +#define OVERLAY_INFO(name, expected) \
> +{ .dtb_begin = __dtb_##name##_begin, \
> + .dtb_end = __dtb_##name##_end, \
> + .expected_result = expected, \
> +}
> +
> +struct overlay_info {
> + uint8_t*dtb_begin;
> + uint8_t*dtb_end;
> + void *data;
> + struct device_node *np_overlay;
> + intexpected_result;
> + intoverlay_id;
> +};
> +
> +OVERLAY_INFO_EXTERN(overlay_base);
> +OVERLAY_INFO_EXTERN(overlay);
> +OVERLAY_INFO_EXTERN(overlay_bad_phandle);
...here. Maybe we want to move all this to a separate file instead.
> +
> +/* order of entries is hard-coded into users of overlays[] */
> +struct overlay_info overlays[] = {
static?
> + OVERLAY_INFO(overlay_base, -),
> + OVERLAY_INFO(overlay, 0),
> + OVERLAY_INFO(overlay_bad_phandle, -EINVAL),
> + {}
> +};
[...]
> @@ -1962,6 +2277,9 @@ static int __init of_unittest(void)
> /* Double check linkage after removing testcase data */
> of_unittest_check_tree_linkage();
>
> +
Extra blank line.
> + of_unittest_overlay_high_level();
> +
> pr_info("end of unittest - %i passed, %i failed\n",
> unittest_results.passed, unittest_results.failed);
>
> --
> Frank Rowand
>
[PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v6)
Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for now, so it's useful to be able to test that mode on an upstream kernel. It's also been useful for me to use the same board for 32-bit and 64-bit development. Signed-off-by: Eric Anholt --- arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 1 + 2 files changed, 2 insertions(+) create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3-b.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 011808490fed..eded842d9978 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ bcm2835-rpi-b-plus.dtb \ bcm2835-rpi-a-plus.dtb \ bcm2836-rpi-2-b.dtb \ + bcm2837-rpi-3-b.dtb \ bcm2835-rpi-zero.dtb dtb-$(CONFIG_ARCH_BCM_5301X) += \ bcm4708-asus-rt-ac56u.dtb \ diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts new file mode 100644 index ..c72a27d908b6 --- /dev/null +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts @@ -0,0 +1 @@ +#include "arm64/broadcom/bcm2837-rpi-3-b.dts" -- 2.11.0
Re: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for arm32 (v5)
Stefan Wahren writes: > Am 24.04.2017 um 22:00 schrieb Eric Anholt: >> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for >> now, so it's useful to be able to test that mode on an upstream >> kernel. It's also been useful for me to use the same board for 32-bit >> and 64-bit development. >> >> Signed-off-by: Eric Anholt >> --- >> arch/arm/boot/dts/Makefile| 1 + >> arch/arm/boot/dts/bcm2837-rpi-3.b.dts | 1 + >> 2 files changed, 2 insertions(+) >> create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3.b.dts >> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >> index 011808490fed..eded842d9978 100644 >> --- a/arch/arm/boot/dts/Makefile >> +++ b/arch/arm/boot/dts/Makefile >> @@ -72,6 +72,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ >> bcm2835-rpi-b-plus.dtb \ >> bcm2835-rpi-a-plus.dtb \ >> bcm2836-rpi-2-b.dtb \ >> +bcm2837-rpi-3-b.dtb \ >> bcm2835-rpi-zero.dtb >> dtb-$(CONFIG_ARCH_BCM_5301X) += \ >> bcm4708-asus-rt-ac56u.dtb \ >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-3.b.dts >> b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts >> new file mode 100644 >> index ..8c8aa4d1e9b3 >> --- /dev/null >> +++ b/arch/arm/boot/dts/bcm2837-rpi-3.b.dts >> @@ -0,0 +1 @@ >> +#include "arm64/broadcom/bcm2837-rpi-3.b.dts" > > Looks like a typo in the dts filename and in the include ( dot instead > of dash ). Sorry about that, everyone. I remember doing builds of the patch, but maybe things succeeded because there was already a .dtb present in my tree or something. signature.asc Description: PGP signature
Re: [PATCH v2] x86, msr: Document AMD "tweak MSRs", use MSR_FnnH_NAME scheme for them
On 04/25/2017 06:23 PM, Borislav Petkov wrote: On Tue, Apr 25, 2017 at 06:15:23PM +0200, Denys Vlasenko wrote: On 04/25/2017 06:06 PM, Borislav Petkov wrote: Pls no. Not every MSR for every family. Only the 4 which are actually being used. We can't hold in here the full 32-bit MSR space. The replacement of four define names is not the purpose of the proposed patch. The patch was prompted by the realization that these particular MSRs are so badly and inconsistently documented that it takes many hours of work and requires reading of literally a dozen PDFs to figure out what are their names, which CPUs have them, and what bits are known. They're all documented in the respective BKDGs or revision guides. Yes. For some definition of "documented". Let's say you are looking at all available documentation for Fam10h CPUs - BKDG, Revision Guide, five volumes of APM, software optimization guide. Eight documents. If you read all of them, you can find exactly one mention that MSR 0xC0011029 exists. It is mentioned by number. As a reader of this documentation, can you find out what is it? Does it have a name, at least? You are right that kernel is not exactly the best place to store more info about such things, but AMD probably won't accept my edits to their documentation.
typec: tcpm/tcpci drivers acceptable for drivers/staging in v4.12 ?
Hi Greg, would you be open to accepting the tcpm [1] and tcpci [2] drivers into drivers/staging for v4.12 ? The drivers are not ready for prime time, yet there is interest by others to have them available and to help improving the code. I could create a repository/branch at github to enable that, but drivers/staging seems to be a better approach. Thanks, Guenter --- [1] https://patchwork.kernel.org/patch/9693861/ [2] https://patchwork.kernel.org/patch/9693863/
Re: support autofocus / autogain in libv4l2
Le mardi 25 avril 2017 à 10:08 +0200, Pali Rohár a écrit : > On Tuesday 25 April 2017 10:05:38 Pavel Machek wrote: > > > > It would be nice if more than one application could be > > > > accessing the > > > > camera at the same time... (I.e. something graphical running > > > > preview > > > > then using command line tool to grab a picture.) This one is > > > > definitely not solveable inside a library... > > > > > > Someone once suggested to have something like pulseaudio for V4L. > > > For such usage, a server would be interesting. Yet, I would code > > > it > > > in a way that applications using libv4l will talk with such > > > daemon > > > in a transparent way. > > > > Yes, we need something like pulseaudio for V4L. And yes, we should > > make it transparent for applications using libv4l. > > IIRC there is already some effort in writing such "video" server > which > would support accessing more application into webcam video, like > pulseaudio server for accessing more applications to microphone > input. > Because references are nice: https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/ https://gstconf.ubicast.tv/videos/camera-sharing-and-sandboxing-with-pinos/ And why the internals are not going to be implemented using GStreamer in the end: https://gstconf.ubicast.tv/videos/keep-calm-and-refactor-about-the-essence-of-gstreamer/ regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree
'
On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote:
> The patch
>
>ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
I have tried to check MAX98927 driver on linux-next tree and
'git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git' but
have failed.
So I wanted to check the current status of MAX98927 driver.
I'm sorry for top-posting.
>
> From 7c0c2000716e64151b3c0c62026c18f31537ebe9 Mon Sep 17 00:00:00 2001
> From: Ryan Lee
> Date: Tue, 4 Apr 2017 02:23:08 +0900
> Subject: [PATCH] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
>
> Signed-off-by: Ryan Lee
> Signed-off-by: Mark Brown
> ---
> .../devicetree/bindings/sound/max98925.txt | 22 -
> .../devicetree/bindings/sound/max98926.txt | 32 -
> .../devicetree/bindings/sound/max9892x.txt | 41 +
> sound/soc/codecs/Kconfig | 5 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/max98927.c| 841
> +
> sound/soc/codecs/max98927.h| 272 +++
> 7 files changed, 1161 insertions(+), 54 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/max98925.txt
> delete mode 100644 Documentation/devicetree/bindings/sound/max98926.txt
> create mode 100644 Documentation/devicetree/bindings/sound/max9892x.txt
> create mode 100644 sound/soc/codecs/max98927.c
> create mode 100644 sound/soc/codecs/max98927.h
>
> diff --git a/Documentation/devicetree/bindings/sound/max98925.txt
> b/Documentation/devicetree/bindings/sound/max98925.txt
> deleted file mode 100644
> index 27be63e2aa0d..
> --- a/Documentation/devicetree/bindings/sound/max98925.txt
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -max98925 audio CODEC
> -
> -This device supports I2C.
> -
> -Required properties:
> -
> - - compatible : "maxim,max98925"
> -
> - - vmon-slot-no : slot number used to send voltage information
> -
> - - imon-slot-no : slot number used to send current information
> -
> - - reg : the I2C address of the device for I2C
> -
> -Example:
> -
> -codec: max98925@1a {
> - compatible = "maxim,max98925";
> - vmon-slot-no = <0>;
> - imon-slot-no = <2>;
> - reg = <0x1a>;
> -};
> diff --git a/Documentation/devicetree/bindings/sound/max98926.txt
> b/Documentation/devicetree/bindings/sound/max98926.txt
> deleted file mode 100644
> index 0b7f4e4d5f9a..
> --- a/Documentation/devicetree/bindings/sound/max98926.txt
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -max98926 audio CODEC
> -
> -This device supports I2C.
> -
> -Required properties:
> -
> - - compatible : "maxim,max98926"
> -
> - - vmon-slot-no : slot number used to send voltage information
> - or in inteleave mode this will be used as
> - interleave slot.
> -
> - - imon-slot-no : slot number used to send current information
> -
> - - interleave-mode : When using two MAX98926 in a system it is
> - possible to create ADC data that that will
> - overflow the frame size. Digital Audio Interleave
> - mode provides a means to output VMON and IMON data
> - from two devices on a single DOUT line when running
> - smaller frames sizes such as 32 BCLKS per LRCLK or
> - 48 BCLKS per LRCLK.
> -
> - - reg : the I2C address of the device for I2C
> -
> -Example:
> -
> -codec: max98926@1a {
> - compatible = "maxim,max98926";
> - vmon-slot-no = <0>;
> - imon-slot-no = <2>;
> - reg = <0x1a>;
> -};
> diff --git a/Documentation/devicetree/bindings/sound/max9892x.txt
> b/Documentation/devicetree/bindings/sound/max9892x.txt
> new file mode 100644
> index ..f6171591ddc6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/max9892x.txt
> @@ -0,0 +1,41 @@
> +Maxim Integrated MAX98925/MAX98926/MAX98927 Speaker Amplifier
> +
> +This device supports I2C.
> +
> +Required properties:
> +
> + - compatible : should be one of the following
> +
Re: [PATCH] scsi: fcoe: make fcoe_e_d_tov and fcoe_r_a_tov static
Colin, > These module parameter variables don't need global scope, make them > static Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] net/packet: check length in getsockopt() called with PACKET_HDRLEN
In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4
|val| remains uninitialized and the syscall may behave differently
depending on its value, and even copy garbage to userspace on certain
architectures. To fix this we now return -EINVAL if optlen is too small.
This bug has been detected with KMSAN.
Signed-off-by: Alexander Potapenko
---
The previous versions of this patch were called "net/packet: initialize
val in packet_getsockopt()"
v3: - change patch summary, return -EINVAL for optlen < sizeof(int)
v2: - if len < sizeof(int), make it 0
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8489beff5c25..ea81ccf3c7d6 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3836,6 +3836,8 @@ static int packet_getsockopt(struct socket *sock, int
level, int optname,
case PACKET_HDRLEN:
if (len > sizeof(int))
len = sizeof(int);
+ if (len < sizeof(int))
+ return -EINVAL;
if (copy_from_user(&val, optval, len))
return -EFAULT;
switch (val) {
--
2.13.0.rc0.306.g87b477812d-goog
Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote: > On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon wrote: > > On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote: > >> On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland wrote: > >> > On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote: > >> >> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running > >> >> in HYP) > >> >> is returning error for perf syscall with mixed attribute set for > >> >> exclude_kernel > >> >> and exclude_hv. This change is breaking some applications (observed > >> >> with hhvm) > >> >> when ran on VHE enabled platforms. > >> >> > >> >> Adding fix to consider only exclude_kernel attribute when kernel is > >> >> running in HYP. Also adding sysfs file to notify the bhehaviour > >> >> of attribute exclude_hv. > >> >> > >> >> Signed-off-by: Ganapatrao Kulkarni > >> >> --- > >> >> > >> >> Changelog: > >> >> > >> >> V2: > >> >> - Changes as per Will Deacon's suggestion. > >> >> > >> >> V1: Initial patch > >> >> > >> >> arch/arm64/kernel/perf_event.c | 28 > >> >> include/linux/perf/arm_pmu.h | 1 + > >> >> 2 files changed, 25 insertions(+), 4 deletions(-) > >> >> > >> >> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct > >> >> hw_perf_event *event, > >> >> > >> >> if (attr->exclude_idle) > >> >> return -EPERM; > >> >> - if (is_kernel_in_hyp_mode() && > >> >> - attr->exclude_kernel != attr->exclude_hv) > >> >> - return -EINVAL; > >> >> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel) > >> >> + config_base |= ARMV8_PMU_INCLUDE_EL2; > >> >> if (attr->exclude_user) > >> >> config_base |= ARMV8_PMU_EXCLUDE_EL0; > >> >> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel) > >> >> config_base |= ARMV8_PMU_EXCLUDE_EL1; > >> >> - if (!attr->exclude_hv) > >> >> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv) > >> >> config_base |= ARMV8_PMU_INCLUDE_EL2; > >> > > >> > This isn't quite what Will suggested. > >> > > >> > The idea was that userspace would read sysfs, then use that to determine > >> > the correct exclusion parameters [1,2]. This logic was not expected to > >> > change; it correctly validates whether we can provide what the user > >> > requests. > >> > >> OK, if you are ok with sysfs part, i can send next version with that > >> change only?. > > > > I think the sysfs part is still a little dodgy, since you still expose the > > "exclude_hv" file with a value of 0 when not running at EL2, which would > > imply that exclude_hv is forced to zero. I don't think that's correct. > > okay, i can make exclude_hv visible only when kernel booted in EL2. > is it ok to have empty directory "attr" when kernel booted to EL1? > attr can be place holder for any other miscellaneous attributes, that > can be added in future. Sounds good to me, although I'll seek comment from the other perf folks before merging anything with ABI implications. Will
Re: [PATCH] scsi/mac_esp: Replace bogus memory barrier with spinlock
Michael, > looks good to me, so: > > Reviewed-By: Michael Schmitz Applied to 4.12/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] arm64: Preventing READ_IMPLIES_EXEC propagation
On Tue, Apr 25, 2017 at 02:11:29PM +0800, dongbo (E) wrote:
> From: Dong Bo
>
> Once the READ_IMPLIES_EXEC flag is set on arm64, the flag is
> propagated to its child processes, even the ELF files are
> marked as not requiring executable stack.
>
> Signed-off-by: Dong Bo
> ---
> arch/arm64/include/asm/elf.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d17004..5941e7f 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -142,6 +142,7 @@
> ({ \
> clear_bit(TIF_32BIT, ¤t->mm->context.flags); \
> clear_thread_flag(TIF_32BIT); \
> + current->personality &= ~READ_IMPLIES_EXEC; \
> })
> /* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes
> */
This looks good to me:
Acked-by: Will Deacon
We might also want a comment in the compat code to say that we inherit
the flag to follow the arch/arm/ behaviour.
Anyway, I'd like to see this sit in -next for a bit, so would rather hold
this off until 4.12.
Will
Re: support autofocus / autogain in libv4l2
Le mardi 25 avril 2017 à 10:05 +0200, Pavel Machek a écrit : > Well, fd's are hard, because application can do fork() and now > interesting stuff happens. Threads are tricky, because now you have > locking etc. > > libv4l2 is designed to be LD_PRELOADED. That is not really feasible > with "complex" library. That is incorrect. The library propose an API where you simply replace certain low level calls, like ioctl -> v4l2_ioctl, open -> v4l2_open(). You have to do that explicitly in your existing code. It does not abstract the API itself unlike libdrm. Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] fpga manager: Add Altera CvP driver
hi Anatolij On 04/21/2017 04:14 PM, Li, Yi wrote: On 4/20/2017 12:29 PM, matthew.gerl...@linux.intel.com wrote: On Thu, 20 Apr 2017, Anatolij Gustschin wrote: Add FPGA manager driver for loading Arria/Cyclone/Stratix FPGAs via CvP. Signed-off-by: Anatolij Gustschin --- Hi Anatolij, Since you say the driver works with Arria-10, I thought I would give it a try with the Altera Arria10 PCIe DevKit I am using. I successfully compiled your patch as an out of tree module against a 3.10 kernel. The module successfully loaded and created instances for both boards in the host. Now that I have the driver instances running, I'm not sure howto actually perform CvP. Do you use a debugfs interface or something else? Do you use the sof or an rbf file? Thanks, Matthew Gerlach Changes in v3: - removed V-series from description (since the driver works also with Arria-10). Also renamed functions, config option and driver file name. Changed module description in Kconfig From the User guild https://www.altera.com/documentation/dsu1441819344145.html#dsu1442261652730, it says Configuration via Protocol (CvP) is a configuration scheme supported inArria^® V,Cyclone^® V,Stratix^® V, andArria^® 10device families. But I have seen different CvP registers bitmask defines somewhere else, so I am not positive that there is only one CvP protocol for all Altera FPGAs. Maybe we could put those Vs + Arria 10 as supported devices on the Kconfig file on the safe side? Reviewed the rest of the driver and it looks good to me. ... diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 161ba9d..be48c2e 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI help FPGA manager driver support for Lattice iCE40 FPGAs over SPI. +config FPGA_MGR_ALTERA_CVP +tristate "Altera Arria/Cyclone/Stratix CvP FPGA Manager" +depends on PCI +help + FPGA manager driver support for Altera FPGAs using the + CvP interface over PCIe. + config FPGA_MGR_SOCFPGA tristate "Altera SOCFPGA FPGA Manager" depends on ARCH_SOCFPGA || COMPILE_TEST diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index 2a4f021..2e5c8b6 100644 --- a/drivers/fpga/Makefile +++ b/drivers/fpga/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_FPGA)+= fpga-mgr.o ...
