Re: [PATCH 1/2] power: reset: at91: add sama5d3 reset function
Hi Guenter, On 09/07/2015 at 20:14:38 -0700, Guenter Roeck wrote : > > This patch introduces a new compatible string: "atmel,sama5d3-rstc" for the > > reset driver of sama5d3 and later chips. > > As in sama5d3 or later chips, we don't have to shutdown the DDR controller > > before reset. Shutdown the DDR controller before reset is a workaround to > > avoid DDR signal driving the bus, but since sama5d3 and later chips there is > > no such a conflict. > > That means: > > 1. the sama5d3 reset function only need to write the rstc register and > > return. > > 2. for sama5d3, we can remove the code related with DDR controller as we > > don't use it at all. > > > Sorry, I don't get it. Doesn't that mean there are two distinct logical > changes, which would ask for two separate patches ? I would agree with Josh and I think that only one patch is needed. There is only one change, the removal of the workaround for sama5d3 and later. As the workaround is using a table of compatibles to remap the ram controller and the one for sama5d3 is not used because it is not needed, I think it makes sense to remove it in that same patch. The logical change here is the removal of the workaround. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/iio/accel/bma180.c | 1 -
drivers/iio/accel/st_accel_i2c.c | 1 -
drivers/iio/adc/mcp3422.c | 1 -
drivers/iio/adc/ti-adc081c.c | 1 -
drivers/iio/dac/ad5064.c | 1 -
drivers/iio/dac/ad5380.c | 1 -
drivers/iio/dac/ad5446.c | 1 -
drivers/iio/dac/max5821.c | 1 -
drivers/iio/gyro/itg3200_core.c| 1 -
drivers/iio/gyro/st_gyro_i2c.c | 1 -
drivers/iio/humidity/si7005.c | 1 -
drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 1 -
drivers/iio/light/apds9300.c | 1 -
drivers/iio/light/bh1750.c | 1 -
drivers/iio/light/cm32181.c| 1 -
drivers/iio/light/cm3232.c | 1 -
drivers/iio/light/cm36651.c| 1 -
drivers/iio/light/gp2ap020a00f.c | 1 -
drivers/iio/light/isl29125.c | 1 -
drivers/iio/light/jsa1212.c| 1 -
drivers/iio/light/ltr501.c | 1 -
drivers/iio/light/tcs3414.c| 1 -
drivers/iio/light/tcs3472.c| 1 -
drivers/iio/light/tsl4531.c| 1 -
drivers/iio/light/vcnl4000.c | 1 -
drivers/iio/magnetometer/st_magn_i2c.c | 1 -
drivers/iio/pressure/ms5611_i2c.c | 1 -
drivers/iio/pressure/st_pressure_i2c.c | 1 -
drivers/iio/temperature/mlx90614.c | 1 -
drivers/iio/temperature/tmp006.c | 1 -
30 files changed, 30 deletions(-)
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
index 75c6d2103e07..f04b88406995 100644
--- a/drivers/iio/accel/bma180.c
+++ b/drivers/iio/accel/bma180.c
@@ -846,7 +846,6 @@ MODULE_DEVICE_TABLE(i2c, bma180_ids);
static struct i2c_driver bma180_driver = {
.driver = {
.name = "bma180",
- .owner = THIS_MODULE,
.pm = BMA180_PM_OPS,
},
.probe = bma180_probe,
diff --git a/drivers/iio/accel/st_accel_i2c.c b/drivers/iio/accel/st_accel_i2c.c
index d4ad72ca4a3d..a2f1c20319eb 100644
--- a/drivers/iio/accel/st_accel_i2c.c
+++ b/drivers/iio/accel/st_accel_i2c.c
@@ -122,7 +122,6 @@ MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
static struct i2c_driver st_accel_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = "st-accel-i2c",
.of_match_table = of_match_ptr(st_accel_of_match),
},
diff --git a/drivers/iio/adc/mcp3422.c b/drivers/iio/adc/mcp3422.c
index b96c636470ef..3555122008b4 100644
--- a/drivers/iio/adc/mcp3422.c
+++ b/drivers/iio/adc/mcp3422.c
@@ -404,7 +404,6 @@ MODULE_DEVICE_TABLE(of, mcp3422_of_match);
static struct i2c_driver mcp3422_driver = {
.driver = {
.name = "mcp3422",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(mcp3422_of_match),
},
.probe = mcp3422_probe,
diff --git a/drivers/iio/adc/ti-adc081c.c b/drivers/iio/adc/ti-adc081c.c
index b3a82b4d1a75..2c8374f86252 100644
--- a/drivers/iio/adc/ti-adc081c.c
+++ b/drivers/iio/adc/ti-adc081c.c
@@ -140,7 +140,6 @@ MODULE_DEVICE_TABLE(of, adc081c_of_match);
static struct i2c_driver adc081c_driver = {
.driver = {
.name = "adc081c",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(adc081c_of_match),
},
.probe = adc081c_probe,
diff --git a/drivers/iio/dac/ad5064.c b/drivers/iio/dac/ad5064.c
index f03b92fd3803..c067e6821496 100644
--- a/drivers/iio/dac/ad5064.c
+++ b/drivers/iio/dac/ad5064.c
@@ -630,7 +630,6 @@ MODULE_DEVICE_TABLE(i2c, ad5064_i2c_ids);
static struct i2c_driver ad5064_i2c_driver = {
.driver = {
.name = "ad5064",
- .owner = THIS_MODULE,
},
.probe = ad5064_i2c_probe,
.remove = ad5064_i2c_remove,
diff --git a/drivers/iio/dac/ad5380.c b/drivers/iio/dac/ad5380.c
index 9de4c4d38280..130de9b3e0bf 100644
--- a/drivers/iio/dac/ad5380.c
+++ b/drivers/iio/dac/ad5380.c
@@ -593,7 +593,6 @@ MODULE_DEVICE_TABLE(i2c, ad5380_i2c_ids);
static struct i2c_driver ad5380_i2c_driver = {
.driver = {
.name = "ad5380",
- .owner = THIS_MODULE,
},
.probe = ad5380_i2c_probe,
.remove = ad5380_i2c_remove,
diff --git a/drivers/iio/dac/ad5446.c b/drivers/iio/dac/ad5446.c
index 46bb62a5c1d4..07e17d72a3f3 100644
--- a/drivers/iio/dac/ad5446.c
+++ b/drivers/iio/dac/ad5446.c
@@ -569,7 +569,6 @@ MODULE_DEVICE_TABLE(i2c, ad5446_i2c_ids);
static struct i2c_driver ad5446_i2c_driver = {
.driver = {
.name = "ad5446",
- .owner = THIS_MODULE,
[PATCH] acpi-cpufreq: Fix an acpi perf unregister issue
As policy->cpu may not be same in acpi_cpufreq_cpu_init and
acpi_cpufreq_cpu_exit. There is a risk that we use different *cpu* to
un/register acpi performance. So acpi_processor_unregister_performance
may not be able to do the cleanup work. That causes a memory leak. And
if there will be another acpi_processor_register_performance call, it
may also fail thanks to the internal check of pr->performace.
So we add a field *perf_cpu* to fix this issue.
Signed-off-by: Pan Xinhui
---
drivers/cpufreq/acpi-cpufreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 314a19e..8cad583 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -69,6 +69,7 @@ struct acpi_cpufreq_data {
struct cpufreq_frequency_table *freq_table;
unsigned int resume;
unsigned int cpu_feature;
+ unsigned int acpi_perf_cpu;
cpumask_var_t freqdomain_cpus;
};
@@ -677,6 +678,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
}
data->acpi_data = per_cpu_ptr(acpi_perf_data, cpu);
+ data->acpi_perf_cpu = cpu;
policy->driver_data = data;
if (cpu_has(c, X86_FEATURE_CONSTANT_TSC))
@@ -861,7 +863,7 @@ static int acpi_cpufreq_cpu_exit(struct cpufreq_policy
*policy)
if (data) {
policy->driver_data = NULL;
acpi_processor_unregister_performance(data->acpi_data,
- policy->cpu);
+ data->acpi_perf_cpu);
free_cpumask_var(data->freqdomain_cpus);
kfree(data->freq_table);
kfree(data);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2c: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/i2c/i2c-slave-eeprom.c | 1 -
drivers/i2c/muxes/i2c-mux-pca9541.c | 1 -
drivers/i2c/muxes/i2c-mux-pca954x.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c
index 822374654609..aed3298ad6aa 100644
--- a/drivers/i2c/i2c-slave-eeprom.c
+++ b/drivers/i2c/i2c-slave-eeprom.c
@@ -163,7 +163,6 @@ MODULE_DEVICE_TABLE(i2c, i2c_slave_eeprom_id);
static struct i2c_driver i2c_slave_eeprom_driver = {
.driver = {
.name = "i2c-slave-eeprom",
- .owner = THIS_MODULE,
},
.probe = i2c_slave_eeprom_probe,
.remove = i2c_slave_eeprom_remove,
diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
b/drivers/i2c/muxes/i2c-mux-pca9541.c
index 0c8d4d2cbdaf..d0ba424adebc 100644
--- a/drivers/i2c/muxes/i2c-mux-pca9541.c
+++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
@@ -386,7 +386,6 @@ static int pca9541_remove(struct i2c_client *client)
static struct i2c_driver pca9541_driver = {
.driver = {
.name = "pca9541",
- .owner = THIS_MODULE,
},
.probe = pca9541_probe,
.remove = pca9541_remove,
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index ea4aa9dfcea9..acfcef3d4068 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -300,7 +300,6 @@ static struct i2c_driver pca954x_driver = {
.driver = {
.name = "pca954x",
.pm = _pm,
- .owner = THIS_MODULE,
},
.probe = pca954x_probe,
.remove = pca954x_remove,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
cpb is not needed. Add ifdef around it.
Signed-off-by: Pan Xinhui
---
drivers/cpufreq/acpi-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e7fcaa6..314a19e 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -884,7 +884,9 @@ static int acpi_cpufreq_resume(struct cpufreq_policy
*policy)
static struct freq_attr *acpi_cpufreq_attr[] = {
_freq_attr_scaling_available_freqs,
_cpus,
+#ifdef CONFIG_X86_ACPI_CPUFREQ_CPB
NULL, /* this is a placeholder for cpb, do not remove */
+#endif
NULL,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hwmon: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/hwmon/g762.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c
index 9b55e673b67c..3d845947f584 100644
--- a/drivers/hwmon/g762.c
+++ b/drivers/hwmon/g762.c
@@ -1112,7 +1112,6 @@ static int g762_remove(struct i2c_client *client)
static struct i2c_driver g762_driver = {
.driver = {
.name = DRVNAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(g762_dt_match),
},
.probe= g762_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/gpio/gpio-adnp.c | 1 -
drivers/gpio/gpio-max7300.c| 1 -
drivers/gpio/gpio-max732x.c| 1 -
drivers/gpio/gpio-mc9s08dz60.c | 1 -
drivers/gpio/gpio-mcp23s08.c | 1 -
drivers/gpio/gpio-pcf857x.c| 1 -
drivers/gpio/gpio-sx150x.c | 1 -
7 files changed, 7 deletions(-)
diff --git a/drivers/gpio/gpio-adnp.c b/drivers/gpio/gpio-adnp.c
index d3d0a90fe542..85223aac8c55 100644
--- a/drivers/gpio/gpio-adnp.c
+++ b/drivers/gpio/gpio-adnp.c
@@ -547,7 +547,6 @@ MODULE_DEVICE_TABLE(of, adnp_of_match);
static struct i2c_driver adnp_i2c_driver = {
.driver = {
.name = "gpio-adnp",
- .owner = THIS_MODULE,
.of_match_table = adnp_of_match,
},
.probe = adnp_i2c_probe,
diff --git a/drivers/gpio/gpio-max7300.c b/drivers/gpio/gpio-max7300.c
index 0cc2c279ab5c..1ae9ba851c9a 100644
--- a/drivers/gpio/gpio-max7300.c
+++ b/drivers/gpio/gpio-max7300.c
@@ -65,7 +65,6 @@ MODULE_DEVICE_TABLE(i2c, max7300_id);
static struct i2c_driver max7300_driver = {
.driver = {
.name = "max7300",
- .owner = THIS_MODULE,
},
.probe = max7300_probe,
.remove = max7300_remove,
diff --git a/drivers/gpio/gpio-max732x.c b/drivers/gpio/gpio-max732x.c
index aed4ca9338bc..4958b433bb0c 100644
--- a/drivers/gpio/gpio-max732x.c
+++ b/drivers/gpio/gpio-max732x.c
@@ -743,7 +743,6 @@ static int max732x_remove(struct i2c_client *client)
static struct i2c_driver max732x_driver = {
.driver = {
.name = "max732x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(max732x_of_table),
},
.probe = max732x_probe,
diff --git a/drivers/gpio/gpio-mc9s08dz60.c b/drivers/gpio/gpio-mc9s08dz60.c
index d62b4f8182bf..0a1505df3338 100644
--- a/drivers/gpio/gpio-mc9s08dz60.c
+++ b/drivers/gpio/gpio-mc9s08dz60.c
@@ -131,7 +131,6 @@ MODULE_DEVICE_TABLE(i2c, mc9s08dz60_id);
static struct i2c_driver mc9s08dz60_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = "mc9s08dz60",
},
.probe = mc9s08dz60_probe,
diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
index 2fc7ff852d16..822f1527a844 100644
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -852,7 +852,6 @@ MODULE_DEVICE_TABLE(i2c, mcp230xx_id);
static struct i2c_driver mcp230xx_driver = {
.driver = {
.name = "mcp230xx",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(mcp23s08_i2c_of_match),
},
.probe = mcp230xx_probe,
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 404f3c61ef9b..fd539c1f92b0 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -451,7 +451,6 @@ static int pcf857x_remove(struct i2c_client *client)
static struct i2c_driver pcf857x_driver = {
.driver = {
.name = "pcf857x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(pcf857x_of_table),
},
.probe = pcf857x_probe,
diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index 458d9d7952b8..ae248a5986d7 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -683,7 +683,6 @@ static int sx150x_remove(struct i2c_client *client)
static struct i2c_driver sx150x_driver = {
.driver = {
.name = "sx150x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(sx150x_of_match),
},
.probe= sx150x_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hid: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/hid/i2c-hid/i2c-hid.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index f77469d4edfb..dfd679647391 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1167,7 +1167,6 @@ MODULE_DEVICE_TABLE(i2c, i2c_hid_id_table);
static struct i2c_driver i2c_hid_driver = {
.driver = {
.name = "i2c_hid",
- .owner = THIS_MODULE,
.pm = _hid_pm,
.acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
.of_match_table = of_match_ptr(i2c_hid_of_match),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] extcon: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/extcon/extcon-rt8973a.c | 1 -
drivers/extcon/extcon-sm5502.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 92c939221a41..11592e980bc1 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -693,7 +693,6 @@ MODULE_DEVICE_TABLE(i2c, rt8973a_i2c_id);
static struct i2c_driver rt8973a_muic_i2c_driver = {
.driver = {
.name = "rt8973a",
- .owner = THIS_MODULE,
.pm = _muic_pm_ops,
.of_match_table = rt8973a_dt_match,
},
diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
index 817dece23b4c..0ffefefa2e26 100644
--- a/drivers/extcon/extcon-sm5502.c
+++ b/drivers/extcon/extcon-sm5502.c
@@ -685,7 +685,6 @@ MODULE_DEVICE_TABLE(i2c, sm5502_i2c_id);
static struct i2c_driver sm5502_muic_i2c_driver = {
.driver = {
.name = "sm5502",
- .owner = THIS_MODULE,
.pm = _muic_pm_ops,
.of_match_table = sm5502_dt_match,
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 10
Hi all, Changes since 20150709: The drm-intel tree gained conflicts against the drm-intel-fixes trees. Non-merge commits (relative to Linus' tree): 1420 1324 files changed, 75720 insertions(+), 21647 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 223 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (c4b5fd3fb205 Merge branch 'hpfs-patches' (patches from Mikulas Patocka)) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (9958084a5275 powerpc: Update MAINTAINERS to point at shared tree) Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog interrupt handler) Merging powerpc-merge-benh/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (fc5778ca3f3c Merge branch 'pktgen-races') Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (d1f15e06b2af ALSA: hda - Fix a wrong busy check in alt PCM open) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1) Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1) Merging usb.current/usb-linus (d4669bb1427c Merge tag 'fixes-for-v4.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (b2e2c94b878b usb: gadget: f_midi: fix error recovery path) Merging usb-serial-fixes/usb-linus (d23f47d4927f USB: serial: Destroy serial_minors IDR on module exit) Merging staging.current/staging-linus (cbe4f4434ded staging:lustre: remove irq.h from socklnd.h) Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1) Merging input-current/for-linus (539c4b88146c Input: elan_i2c - change the hover event from MT to ST) Merging crypto-current/master (030f4e968741 crypto: nx - Fix reentrancy bugs) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (758556bdc1c8 module: Fix load_module() error path) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b52b374eb348 drm/i915: avoid leaking DMA mappings) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_f
Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail
On Thu, Jul 9, 2015 at 7:48 PM, Yinghai Lu wrote:
> On Thu, Jul 9, 2015 at 7:30 PM, Wei Yang wrote:
>> If you could update your for-pci-v4.3-next branch, that would be more
>> convenient for me to do the test.
>
> Just updated that branch, please check it.
>
just updated the branch again.
If you don't want to re get it again, please apply attached patch.
---
drivers/pci/bus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/drivers/pci/bus.c
===
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -140,7 +140,7 @@ static int pci_bus_alloc_from_region(str
type_mask |= IORESOURCE_TYPE_BITS;
pci_bus_for_each_resource(bus, r, i) {
- if (!r)
+ if (!r || resource_disabled(r))
continue;
/* type_mask must match */
[PATCH] edac: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/edac/xgene_edac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
index 14636e4b6a08..ba06904af2e1 100644
--- a/drivers/edac/xgene_edac.c
+++ b/drivers/edac/xgene_edac.c
@@ -1168,7 +1168,6 @@ static struct platform_driver xgene_edac_driver = {
.remove = xgene_edac_remove,
.driver = {
.name = "xgene-edac",
- .owner = THIS_MODULE,
.of_match_table = xgene_edac_of_match,
},
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] clk: mediatek: Add MT8173 MMPLL change rate support
Hi Stephen,
On Wed, 2015-07-08 at 17:46 -0700, Stephen Boyd wrote:
> On 07/08/2015 01:37 AM, James Liao wrote:
> > diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> > index 68af518..622e7b6 100644
> > --- a/drivers/clk/mediatek/clk-pll.c
> > +++ b/drivers/clk/mediatek/clk-pll.c
> > @@ -138,16 +138,28 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > *pll, u32 *pcw, u32 *postdiv,
> > u32 freq, u32 fin)
> > {
> > unsigned long fmin = 1000 * MHZ;
> > + const struct mtk_pll_div_table *div_table = pll->data->div_table;
> > u64 _pcw;
> > u32 val;
> >
> > if (freq > pll->data->fmax)
> > freq = pll->data->fmax;
> >
> > - for (val = 0; val < 4; val++) {
> > + if (div_table) {
> > + if (freq > div_table[0].freq)
> > + freq = div_table[0].freq;
> > +
> > + for (val = 0; div_table[val + 1].freq != 0; val++) {
> > + if (freq > div_table[val + 1].freq)
> > + break;
> > + }
> > *postdiv = 1 << val;
> > - if (freq * *postdiv >= fmin)
> > - break;
> > + } else {
> > + for (val = 0; val < 5; val++) {
> > + *postdiv = 1 << val;
> > + if ((u64)freq * *postdiv >= fmin)
> >
>
> No mention of this cast in the commit text. Is this fixing a bug? If so,
> please mention it and/or split this bug fix off of this patch.
>
Yes, this is a fix to avoid u32 overflow. I'll split it in next patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/crypto/marvell/cesa.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 1c6f98dd88f4..0643e3366e33 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -533,7 +533,6 @@ static struct platform_driver marvell_cesa = {
.probe = mv_cesa_probe,
.remove = mv_cesa_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "marvell-cesa",
.of_match_table = mv_cesa_of_match_table,
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On (07/10/15 14:31), Minchan Kim wrote: > There is no reason to prevent select ZS_ALMOST_FULL as migration > source if we cannot find source from ZS_ALMOST_EMPTY. > > With this patch, zs_can_compact will return more exact result. > > * From v1 > * remove unnecessary found variable - Sergey > > Signed-off-by: Minchan Kim > Acked-by: Sergey Senozhatsky -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Add MT8173 MMPLL change rate support
Hi Stephen, On Wed, 2015-07-08 at 17:44 -0700, Stephen Boyd wrote: > On 07/08/2015 01:37 AM, James Liao wrote: > > MT8173 MMPLL frequency settings are different from common PLLs. > > It needs different post divider settings for some ranges of frequency. > > This patch add support for MT8173 MMPLL frequency setting, includes: > > > > 1. Add div-rate table for PLLs. > > 2. Increase the max ost divider setting from 3 (/8) to 4 (/16). > > 3. Write postdiv and pcw settings at the same time. > > > > James Liao (2): > > clk: mediatek: Fix PLL registers setting flow > > clk: mediatek: Add MT8173 MMPLL change rate support > > > > Are these fixing regressions in 4.2-rc1? I don't see any "Fixes:" tag so > it's not clear and makes me want to defer these until v4.3. Furthermore, > the subject starts with "Add" so it sounds like a new feature. This patchset is based on 4.1-rc1 but it had been tested on 4.2-rc1. I'll send a new patch which based on 4.2-rc1. This patchset contains some general PLL fixes and MMPLL set rate support. We can say the last one is also a fix because changing some specific rate on MMPLL may fail in current implementation. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] regulator: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/regulator/act8865-regulator.c | 1 -
drivers/regulator/da9210-regulator.c | 1 -
drivers/regulator/da9211-regulator.c | 1 -
drivers/regulator/isl6271a-regulator.c | 1 -
drivers/regulator/isl9305.c| 1 -
drivers/regulator/lp3971.c | 1 -
drivers/regulator/lp3972.c | 1 -
drivers/regulator/lp872x.c | 1 -
drivers/regulator/ltc3589.c| 1 -
drivers/regulator/max1586.c| 1 -
drivers/regulator/max8660.c| 1 -
drivers/regulator/max8973-regulator.c | 1 -
drivers/regulator/pfuze100-regulator.c | 1 -
drivers/regulator/tps51632-regulator.c | 1 -
drivers/regulator/tps62360-regulator.c | 1 -
drivers/regulator/tps65023-regulator.c | 1 -
16 files changed, 16 deletions(-)
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 2ff73d72ca34..896db168e4bd 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -530,7 +530,6 @@ MODULE_DEVICE_TABLE(i2c, act8865_ids);
static struct i2c_driver act8865_pmic_driver = {
.driver = {
.name = "act8865",
- .owner = THIS_MODULE,
},
.probe = act8865_pmic_probe,
.id_table = act8865_ids,
diff --git a/drivers/regulator/da9210-regulator.c
b/drivers/regulator/da9210-regulator.c
index 8e39f7457bc3..b3517830edb6 100644
--- a/drivers/regulator/da9210-regulator.c
+++ b/drivers/regulator/da9210-regulator.c
@@ -259,7 +259,6 @@ MODULE_DEVICE_TABLE(i2c, da9210_i2c_id);
static struct i2c_driver da9210_regulator_driver = {
.driver = {
.name = "da9210",
- .owner = THIS_MODULE,
},
.probe = da9210_i2c_probe,
.id_table = da9210_i2c_id,
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
index df79e4b1946e..ab8914f280c7 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -494,7 +494,6 @@ MODULE_DEVICE_TABLE(of, da9211_dt_ids);
static struct i2c_driver da9211_regulator_driver = {
.driver = {
.name = "da9211",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(da9211_dt_ids),
},
.probe = da9211_i2c_probe,
diff --git a/drivers/regulator/isl6271a-regulator.c
b/drivers/regulator/isl6271a-regulator.c
index 6e5da95fa025..4abd8e9c81e5 100644
--- a/drivers/regulator/isl6271a-regulator.c
+++ b/drivers/regulator/isl6271a-regulator.c
@@ -156,7 +156,6 @@ MODULE_DEVICE_TABLE(i2c, isl6271a_id);
static struct i2c_driver isl6271a_i2c_driver = {
.driver = {
.name = "isl6271a",
- .owner = THIS_MODULE,
},
.probe = isl6271a_probe,
.id_table = isl6271a_id,
diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index 6e3a15fe00f1..eae9d1ffe641 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -195,7 +195,6 @@ MODULE_DEVICE_TABLE(i2c, isl9305_i2c_id);
static struct i2c_driver isl9305_regulator_driver = {
.driver = {
.name = "isl9305",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(isl9305_dt_ids),
},
.probe = isl9305_i2c_probe,
diff --git a/drivers/regulator/lp3971.c b/drivers/regulator/lp3971.c
index 66fd2330dca0..15c25c622edf 100644
--- a/drivers/regulator/lp3971.c
+++ b/drivers/regulator/lp3971.c
@@ -452,7 +452,6 @@ MODULE_DEVICE_TABLE(i2c, lp3971_i2c_id);
static struct i2c_driver lp3971_i2c_driver = {
.driver = {
.name = "LP3971",
- .owner = THIS_MODULE,
},
.probe= lp3971_i2c_probe,
.id_table = lp3971_i2c_id,
diff --git a/drivers/regulator/lp3972.c b/drivers/regulator/lp3972.c
index aea485afcc1a..3a7e96e2c7b3 100644
--- a/drivers/regulator/lp3972.c
+++ b/drivers/regulator/lp3972.c
@@ -550,7 +550,6 @@ MODULE_DEVICE_TABLE(i2c, lp3972_i2c_id);
static struct i2c_driver lp3972_i2c_driver = {
.driver = {
.name = "lp3972",
- .owner = THIS_MODULE,
},
.probe= lp3972_i2c_probe,
.id_table = lp3972_i2c_id,
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 3de328ab41f3..171c7625dd67 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -955,7 +955,6 @@ MODULE_DEVICE_TABLE(i2c, lp872x_ids);
static struct i2c_driver lp872x_driver = {
.driver = {
.name = "lp872x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(lp872x_dt_ids),
},
.probe = lp872x_probe,
diff --git
[PATCH 2/2] regulator: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/regulator/da9062-regulator.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/regulator/da9062-regulator.c
b/drivers/regulator/da9062-regulator.c
index dd76da09b3c7..5638fe8d759d 100644
--- a/drivers/regulator/da9062-regulator.c
+++ b/drivers/regulator/da9062-regulator.c
@@ -818,7 +818,6 @@ static int da9062_regulator_probe(struct platform_device
*pdev)
static struct platform_driver da9062_regulator_driver = {
.driver = {
.name = "da9062-regulators",
- .owner = THIS_MODULE,
},
.probe = da9062_regulator_probe,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (2): regulator: Drop owner assignment from i2c_driver regulator: Drop owner assignment from platform_driver drivers/regulator/act8865-regulator.c | 1 - drivers/regulator/da9062-regulator.c | 1 - drivers/regulator/da9210-regulator.c | 1 - drivers/regulator/da9211-regulator.c | 1 - drivers/regulator/isl6271a-regulator.c | 1 - drivers/regulator/isl9305.c| 1 - drivers/regulator/lp3971.c | 1 - drivers/regulator/lp3972.c | 1 - drivers/regulator/lp872x.c | 1 - drivers/regulator/ltc3589.c| 1 - drivers/regulator/max1586.c| 1 - drivers/regulator/max8660.c| 1 - drivers/regulator/max8973-regulator.c | 1 - drivers/regulator/pfuze100-regulator.c | 1 - drivers/regulator/tps51632-regulator.c | 1 - drivers/regulator/tps62360-regulator.c | 1 - drivers/regulator/tps65023-regulator.c | 1 - 17 files changed, 17 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power_supply: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/power/bq24190_charger.c | 1 -
drivers/power/bq24735-charger.c | 1 -
drivers/power/pm2301_charger.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c
index 052db78c3736..703ebecaf38b 100644
--- a/drivers/power/bq24190_charger.c
+++ b/drivers/power/bq24190_charger.c
@@ -1534,7 +1534,6 @@ static struct i2c_driver bq24190_driver = {
.id_table = bq24190_i2c_ids,
.driver = {
.name = "bq24190-charger",
- .owner = THIS_MODULE,
.pm = _pm_ops,
.of_match_table = of_match_ptr(bq24190_of_match),
},
diff --git a/drivers/power/bq24735-charger.c b/drivers/power/bq24735-charger.c
index 961a18930027..b0174379713c 100644
--- a/drivers/power/bq24735-charger.c
+++ b/drivers/power/bq24735-charger.c
@@ -409,7 +409,6 @@ MODULE_DEVICE_TABLE(of, bq24735_match_ids);
static struct i2c_driver bq24735_charger_driver = {
.driver = {
.name = "bq24735-charger",
- .owner = THIS_MODULE,
.of_match_table = bq24735_match_ids,
},
.probe = bq24735_charger_probe,
diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index cc0893ffbf7e..3a45cc0c4dce 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -1244,7 +1244,6 @@ static struct i2c_driver pm2xxx_charger_driver = {
.remove = pm2xxx_wall_charger_remove,
.driver = {
.name = "pm2xxx-wall_charger",
- .owner = THIS_MODULE,
.pm = PM2XXX_PM_OPS,
},
.id_table = pm2xxx_id,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] phy: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/phy/phy-armada375-usb2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/phy-armada375-usb2.c b/drivers/phy/phy-armada375-usb2.c
index 8ccc3952c13d..39c7d21f12da 100644
--- a/drivers/phy/phy-armada375-usb2.c
+++ b/drivers/phy/phy-armada375-usb2.c
@@ -149,7 +149,6 @@ static struct platform_driver armada375_usb_phy_driver = {
.driver = {
.of_match_table = of_usb_cluster_table,
.name = "armada-375-usb-cluster",
- .owner = THIS_MODULE,
}
};
module_platform_driver(armada375_usb_phy_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/gpu/drm/bridge/ps8622.c | 1 -
drivers/gpu/drm/bridge/ptn3460.c| 1 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index 1a6607beb29f..be881e9fef8f 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
.remove = ps8622_remove,
.driver = {
.name = "ps8622",
- .owner = THIS_MODULE,
.of_match_table = ps8622_devices,
},
};
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 1b1bf2384815..0ffa3a6a206a 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
.remove = ptn3460_remove,
.driver = {
.name = "nxp,ptn3460",
- .owner = THIS_MODULE,
.of_match_table = ptn3460_match,
},
};
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 01b558fe3695..9a0c2911272a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -555,7 +555,6 @@ static struct platform_driver rockchip_drm_platform_driver
= {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
.pm = _drm_pm_ops,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (1): drm: Drop owner assignment from i2c_driver drivers/gpu/drm/bridge/ps8622.c | 1 - drivers/gpu/drm/bridge/ptn3460.c| 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 - 3 files changed, 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: sm750fb: ddk750_dvi.h: Fix brace coding style issue
On Thu, Jul 09, 2015 at 02:45:22PM +0200, anders.fridl...@gmail.com wrote: > From: Anders Fridlund same comment that I gave to your another patch. "No need to mention this From: here. Please fix your .gitconfig so that git send-email will put your name in the email From: header." regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On (07/10/15 14:21), Minchan Kim wrote: > > I mean I find your argument that some level of fragmentation > > can be of use to be valid, to some degree. > > The benefit I had in mind was to prevent failure of allocation. > Sure. I tested the patch. cat /sys/block/zram0/mm_stat 3122102272 2882639758 28903669760 2969432064 5579294 cat /sys/block/zram0/stat 7212057696 73 75132540 6010603252096 0 5210652113 Compaction stats: [14637.002961] compaction nr:89 (full:528 part:3027) ~= 0.148 Nothing `alarming'. > > I'm thinking now, does it make sense to try harder here? if we > > failed to alloc_zspage(), then may be we can try any of unused > > objects from a 'upper' (larger/next) class? there might be a > > plenty of them. > > I actually thought about that but I didn't have any report from > community and product division of my compamy until now. > But with auto-compaction, the chance would be higher than old > so let's keep an eye on it(I think users can find it easily because > swap layer emits "write write failure"). > > If it happens(ie, any report from someone), we could try to compact > and then if it fails, we could fall back to upper class as a last > resort. > OK. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/char/ipmi/ipmi_ssif.c | 1 -
drivers/char/tpm/st33zp24/i2c.c | 1 -
drivers/char/tpm/tpm_i2c_atmel.c| 1 -
drivers/char/tpm/tpm_i2c_infineon.c | 1 -
drivers/char/tpm/tpm_i2c_nuvoton.c | 1 -
5 files changed, 5 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index b043d8d45823..003a4ab3b660 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -1950,7 +1950,6 @@ MODULE_DEVICE_TABLE(i2c, ssif_id);
static struct i2c_driver ssif_i2c_driver = {
.class = I2C_CLASS_HWMON,
.driver = {
- .owner = THIS_MODULE,
.name = DEVICE_NAME
},
.probe = ssif_probe,
diff --git a/drivers/char/tpm/st33zp24/i2c.c b/drivers/char/tpm/st33zp24/i2c.c
index ad1ee180e0c2..309d2767c6a1 100644
--- a/drivers/char/tpm/st33zp24/i2c.c
+++ b/drivers/char/tpm/st33zp24/i2c.c
@@ -258,7 +258,6 @@ static SIMPLE_DEV_PM_OPS(st33zp24_i2c_ops,
st33zp24_pm_suspend,
static struct i2c_driver st33zp24_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = TPM_ST33_I2C,
.pm = _i2c_ops,
.of_match_table = of_match_ptr(of_st33zp24_i2c_match),
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index 7a0ca78ad3c6..8dfb88b9739c 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -217,7 +217,6 @@ static struct i2c_driver i2c_atmel_driver = {
.remove = i2c_atmel_remove,
.driver = {
.name = I2C_DRIVER_NAME,
- .owner = THIS_MODULE,
.pm = _atmel_pm_ops,
.of_match_table = of_match_ptr(i2c_atmel_of_match),
},
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
b/drivers/char/tpm/tpm_i2c_infineon.c
index 33c5f360ab01..63d5d22e9e60 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c
@@ -711,7 +711,6 @@ static struct i2c_driver tpm_tis_i2c_driver = {
.remove = tpm_tis_i2c_remove,
.driver = {
.name = "tpm_i2c_infineon",
- .owner = THIS_MODULE,
.pm = _tis_i2c_ops,
.of_match_table = of_match_ptr(tpm_tis_i2c_of_match),
},
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 9d42b7d78e50..847f1597fe9b 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -641,7 +641,6 @@ static struct i2c_driver i2c_nuvoton_driver = {
.remove = i2c_nuvoton_remove,
.driver = {
.name = I2C_DRIVER_NAME,
- .owner = THIS_MODULE,
.pm = _nuvoton_pm_ops,
.of_match_table = of_match_ptr(i2c_nuvoton_of_match),
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (1): char: Drop owner assignment from i2c_driver drivers/char/ipmi/ipmi_ssif.c | 1 - drivers/char/tpm/st33zp24/i2c.c | 1 - drivers/char/tpm/tpm_i2c_atmel.c| 1 - drivers/char/tpm/tpm_i2c_infineon.c | 1 - drivers/char/tpm/tpm_i2c_nuvoton.c | 1 - 5 files changed, 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] zsmalloc: consider ZS_ALMOST_FULL as migrate source
From: Minchan Kim
There is no reason to prevent select ZS_ALMOST_FULL as migration
source if we cannot find source from ZS_ALMOST_EMPTY.
With this patch, zs_can_compact will return more exact result.
* From v1
* remove unnecessary found variable - Sergey
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 8c78bcb..9012645 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1686,11 +1686,17 @@ static enum fullness_group putback_zspage(struct
zs_pool *pool,
static struct page *isolate_source_page(struct size_class *class)
{
- struct page *page;
+ int i;
+ struct page *page = NULL;
+
+ for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
+ page = class->fullness_list[i];
+ if (!page)
+ continue;
- page = class->fullness_list[ZS_ALMOST_EMPTY];
- if (page)
- remove_zspage(page, class, ZS_ALMOST_EMPTY);
+ remove_zspage(page, class, i);
+ break;
+ }
return page;
}
@@ -1706,9 +1712,6 @@ static unsigned long zs_can_compact(struct size_class
*class)
{
unsigned long obj_wasted;
- if (!zs_stat_get(class, CLASS_ALMOST_EMPTY))
- return 0;
-
obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (2): ASoC: Drop owner assignment from i2c_driver ASoC: Drop owner assignment from platform_driver sound/soc/codecs/adau1373.c | 1 - sound/soc/codecs/adau1701.c | 1 - sound/soc/codecs/adau1761-i2c.c | 1 - sound/soc/codecs/adau1781-i2c.c | 1 - sound/soc/codecs/adau1977-i2c.c | 1 - sound/soc/codecs/adav803.c| 1 - sound/soc/codecs/ak4535.c | 1 - sound/soc/codecs/ak4641.c | 1 - sound/soc/codecs/ak4642.c | 1 - sound/soc/codecs/ak4671.c | 1 - sound/soc/codecs/alc5623.c| 1 - sound/soc/codecs/alc5632.c| 1 - sound/soc/codecs/cs35l32.c| 1 - sound/soc/codecs/cs4265.c | 1 - sound/soc/codecs/cs4270.c | 1 - sound/soc/codecs/cs4271-i2c.c | 1 - sound/soc/codecs/cs42l51-i2c.c| 1 - sound/soc/codecs/cs42l52.c| 1 - sound/soc/codecs/cs42l56.c| 1 - sound/soc/codecs/cs42l73.c| 1 - sound/soc/codecs/cs42xx8-i2c.c| 1 - sound/soc/codecs/da7210.c | 1 - sound/soc/codecs/da7213.c | 1 - sound/soc/codecs/da732x.c | 1 - sound/soc/codecs/da9055.c | 1 - sound/soc/codecs/isabelle.c | 1 - sound/soc/codecs/lm4857.c | 1 - sound/soc/codecs/lm49453.c| 1 - sound/soc/codecs/max9768.c| 1 - sound/soc/codecs/max98088.c | 1 - sound/soc/codecs/max98090.c | 1 - sound/soc/codecs/max98095.c | 1 - sound/soc/codecs/max9850.c| 1 - sound/soc/codecs/max9877.c| 1 - sound/soc/codecs/max98925.c | 1 - sound/soc/codecs/ml26124.c| 1 - sound/soc/codecs/pcm1681.c| 1 - sound/soc/codecs/pcm512x-i2c.c| 1 - sound/soc/codecs/rt286.c | 1 - sound/soc/codecs/rt5631.c | 1 - sound/soc/codecs/rt5640.c | 1 - sound/soc/codecs/rt5645.c | 1 - sound/soc/codecs/rt5651.c | 1 - sound/soc/codecs/rt5670.c | 1 - sound/soc/codecs/rt5677.c | 1 - sound/soc/codecs/sgtl5000.c | 1 - sound/soc/codecs/ssm2518.c| 1 - sound/soc/codecs/ssm2602-i2c.c| 1 - sound/soc/codecs/ssm4567.c| 1 - sound/soc/codecs/sta32x.c | 1 - sound/soc/codecs/sta350.c | 1 - sound/soc/codecs/sta529.c | 1 - sound/soc/codecs/tas2552.c| 1 - sound/soc/codecs/tas5086.c| 1 - sound/soc/codecs/tfa9879.c| 1 - sound/soc/codecs/tlv320aic31xx.c | 1 - sound/soc/codecs/tlv320aic32x4.c | 1 - sound/soc/codecs/tlv320aic3x.c| 1 - sound/soc/codecs/tlv320dac33.c| 1 - sound/soc/codecs/tpa6130a2.c | 1 - sound/soc/codecs/ts3a227e.c | 1 - sound/soc/codecs/uda1380.c| 1 - sound/soc/codecs/wm1250-ev1.c | 1 - sound/soc/codecs/wm2000.c | 1 - sound/soc/codecs/wm2200.c | 1 - sound/soc/codecs/wm5100.c | 1 - sound/soc/codecs/wm8510.c | 1 - sound/soc/codecs/wm8523.c | 1 - sound/soc/codecs/wm8580.c | 1 - sound/soc/codecs/wm8711.c | 1 - sound/soc/codecs/wm8728.c | 1 - sound/soc/codecs/wm8731.c | 1 - sound/soc/codecs/wm8737.c | 1 - sound/soc/codecs/wm8741.c | 1 - sound/soc/codecs/wm8750.c | 1 - sound/soc/codecs/wm8753.c | 1 - sound/soc/codecs/wm8776.c | 1 - sound/soc/codecs/wm8804-i2c.c | 1 - sound/soc/codecs/wm8900.c | 1 - sound/soc/codecs/wm8903.c | 1 - sound/soc/codecs/wm8904.c | 1 - sound/soc/codecs/wm8940.c | 1 - sound/soc/codecs/wm8955.c | 1 - sound/soc/codecs/wm8960.c | 1 - sound/soc/codecs/wm8961.c | 1 - sound/soc/codecs/wm8962.c | 1 - sound/soc/codecs/wm8971.c | 1 - sound/soc/codecs/wm8974.c | 1 - sound/soc/codecs/wm8978.c | 1 - sound/soc/codecs/wm8983.c | 1 - sound/soc/codecs/wm8985.c | 1 -
[PATCH 2/2] ASoC: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
sound/soc/mediatek/mt8173-max98090.c | 1 -
sound/soc/mediatek/mt8173-rt5650-rt5676.c | 1 -
sound/soc/mediatek/mtk-afe-pcm.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/sound/soc/mediatek/mt8173-max98090.c
b/sound/soc/mediatek/mt8173-max98090.c
index 4d44b5803e55..6311f31fa669 100644
--- a/sound/soc/mediatek/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173-max98090.c
@@ -193,7 +193,6 @@ MODULE_DEVICE_TABLE(of, mt8173_max98090_dt_match);
static struct platform_driver mt8173_max98090_driver = {
.driver = {
.name = "mt8173-max98090",
- .owner = THIS_MODULE,
.of_match_table = mt8173_max98090_dt_match,
#ifdef CONFIG_PM
.pm = _soc_pm_ops,
diff --git a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
index 094055323059..4fd7dff15fe7 100644
--- a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
+++ b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
@@ -258,7 +258,6 @@ MODULE_DEVICE_TABLE(of, mt8173_rt5650_rt5676_dt_match);
static struct platform_driver mt8173_rt5650_rt5676_driver = {
.driver = {
.name = "mtk-rt5650-rt5676",
- .owner = THIS_MODULE,
.of_match_table = mt8173_rt5650_rt5676_dt_match,
#ifdef CONFIG_PM
.pm = _soc_pm_ops,
diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index 9863da73dfe0..de38d2e8ef91 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -1220,7 +1220,6 @@ static const struct dev_pm_ops mtk_afe_pm_ops = {
static struct platform_driver mtk_afe_pcm_driver = {
.driver = {
.name = "mtk-afe-pcm",
- .owner = THIS_MODULE,
.of_match_table = mtk_afe_pcm_dt_match,
.pm = _afe_pm_ops,
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ASoC: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
sound/soc/codecs/adau1373.c | 1 -
sound/soc/codecs/adau1701.c | 1 -
sound/soc/codecs/adau1761-i2c.c | 1 -
sound/soc/codecs/adau1781-i2c.c | 1 -
sound/soc/codecs/adau1977-i2c.c | 1 -
sound/soc/codecs/adav803.c | 1 -
sound/soc/codecs/ak4535.c| 1 -
sound/soc/codecs/ak4641.c| 1 -
sound/soc/codecs/ak4642.c| 1 -
sound/soc/codecs/ak4671.c| 1 -
sound/soc/codecs/alc5623.c | 1 -
sound/soc/codecs/alc5632.c | 1 -
sound/soc/codecs/cs35l32.c | 1 -
sound/soc/codecs/cs4265.c| 1 -
sound/soc/codecs/cs4270.c| 1 -
sound/soc/codecs/cs4271-i2c.c| 1 -
sound/soc/codecs/cs42l51-i2c.c | 1 -
sound/soc/codecs/cs42l52.c | 1 -
sound/soc/codecs/cs42l56.c | 1 -
sound/soc/codecs/cs42l73.c | 1 -
sound/soc/codecs/cs42xx8-i2c.c | 1 -
sound/soc/codecs/da7210.c| 1 -
sound/soc/codecs/da7213.c| 1 -
sound/soc/codecs/da732x.c| 1 -
sound/soc/codecs/da9055.c| 1 -
sound/soc/codecs/isabelle.c | 1 -
sound/soc/codecs/lm4857.c| 1 -
sound/soc/codecs/lm49453.c | 1 -
sound/soc/codecs/max9768.c | 1 -
sound/soc/codecs/max98088.c | 1 -
sound/soc/codecs/max98090.c | 1 -
sound/soc/codecs/max98095.c | 1 -
sound/soc/codecs/max9850.c | 1 -
sound/soc/codecs/max9877.c | 1 -
sound/soc/codecs/max98925.c | 1 -
sound/soc/codecs/ml26124.c | 1 -
sound/soc/codecs/pcm1681.c | 1 -
sound/soc/codecs/pcm512x-i2c.c | 1 -
sound/soc/codecs/rt286.c | 1 -
sound/soc/codecs/rt5631.c| 1 -
sound/soc/codecs/rt5640.c| 1 -
sound/soc/codecs/rt5645.c| 1 -
sound/soc/codecs/rt5651.c| 1 -
sound/soc/codecs/rt5670.c| 1 -
sound/soc/codecs/rt5677.c| 1 -
sound/soc/codecs/sgtl5000.c | 1 -
sound/soc/codecs/ssm2518.c | 1 -
sound/soc/codecs/ssm2602-i2c.c | 1 -
sound/soc/codecs/ssm4567.c | 1 -
sound/soc/codecs/sta32x.c| 1 -
sound/soc/codecs/sta350.c| 1 -
sound/soc/codecs/sta529.c| 1 -
sound/soc/codecs/tas2552.c | 1 -
sound/soc/codecs/tas5086.c | 1 -
sound/soc/codecs/tfa9879.c | 1 -
sound/soc/codecs/tlv320aic31xx.c | 1 -
sound/soc/codecs/tlv320aic32x4.c | 1 -
sound/soc/codecs/tlv320aic3x.c | 1 -
sound/soc/codecs/tlv320dac33.c | 1 -
sound/soc/codecs/tpa6130a2.c | 1 -
sound/soc/codecs/ts3a227e.c | 1 -
sound/soc/codecs/uda1380.c | 1 -
sound/soc/codecs/wm1250-ev1.c| 1 -
sound/soc/codecs/wm2000.c| 1 -
sound/soc/codecs/wm2200.c| 1 -
sound/soc/codecs/wm5100.c| 1 -
sound/soc/codecs/wm8510.c| 1 -
sound/soc/codecs/wm8523.c| 1 -
sound/soc/codecs/wm8580.c| 1 -
sound/soc/codecs/wm8711.c| 1 -
sound/soc/codecs/wm8728.c| 1 -
sound/soc/codecs/wm8731.c| 1 -
sound/soc/codecs/wm8737.c| 1 -
sound/soc/codecs/wm8741.c| 1 -
sound/soc/codecs/wm8750.c| 1 -
sound/soc/codecs/wm8753.c| 1 -
sound/soc/codecs/wm8776.c| 1 -
sound/soc/codecs/wm8804-i2c.c| 1 -
sound/soc/codecs/wm8900.c| 1 -
sound/soc/codecs/wm8903.c| 1 -
sound/soc/codecs/wm8904.c| 1 -
sound/soc/codecs/wm8940.c| 1 -
sound/soc/codecs/wm8955.c| 1 -
sound/soc/codecs/wm8960.c| 1 -
sound/soc/codecs/wm8961.c| 1 -
sound/soc/codecs/wm8962.c| 1 -
sound/soc/codecs/wm8971.c| 1 -
sound/soc/codecs/wm8974.c| 1 -
sound/soc/codecs/wm8978.c| 1 -
sound/soc/codecs/wm8983.c| 1 -
sound/soc/codecs/wm8985.c| 1 -
sound/soc/codecs/wm8988.c| 1 -
sound/soc/codecs/wm8990.c| 1 -
sound/soc/codecs/wm8991.c| 1 -
sound/soc/codecs/wm8993.c| 1 -
sound/soc/codecs/wm8995.c| 1 -
sound/soc/codecs/wm8996.c| 1 -
sound/soc/codecs/wm9081.c| 1 -
sound/soc/codecs/wm9090.c| 1 -
99 files changed, 99 deletions(-)
diff --git a/sound/soc/codecs/adau1373.c b/sound/soc/codecs/adau1373.c
index a43160254929..6c96860f46de 100644
--- a/sound/soc/codecs/adau1373.c
+++ b/sound/soc/codecs/adau1373.c
@@ -1534,7 +1534,6 @@ MODULE_DEVICE_TABLE(i2c, adau1373_i2c_id);
static struct i2c_driver adau1373_i2c_driver = {
.driver = {
.name = "adau1373",
- .owner = THIS_MODULE,
},
.probe = adau1373_i2c_probe,
.remove = adau1373_i2c_remove,
diff --git a/sound/soc/codecs/adau1701.c b/sound/soc/codecs/adau1701.c
index ff7f846e3b76..de53c0d7bf10 100644
--- a/sound/soc/codecs/adau1701.c
+++ b/sound/soc/codecs/adau1701.c
@@ -915,7 +915,6 @@ MODULE_DEVICE_TABLE(i2c, adau1701_i2c_id);
static struct i2c_driver
RE: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, July 10, 2015 6:20 AM
> To: Zhao Qiang-B45475
> Cc: lau...@codeaurora.org; linux-kernel@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; a...@linux-foundation.org; o...@lixom.net;
> catalin.mari...@arm.com; Xie Xiaobo-R63061
> Subject: Re: [RFC] genalloc:add an gen_pool_alloc_align func to genalloc
>
> On Thu, 2015-07-09 at 15:47 +0800, Zhao Qiang wrote:
> > @@ -541,13 +562,14 @@ EXPORT_SYMBOL(gen_pool_first_fit_order_align);
> > * which we can allocate the memory.
> > */
> > unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
> > - unsigned long start, unsigned int nr, void *data)
> > + unsigned long start, unsigned int nr,
> > + void *data, unsigned long align_mask)
> > {
> > unsigned long start_bit = size;
> > unsigned long len = size + 1;
> > unsigned long index;
> >
> > - index = bitmap_find_next_zero_area(map, size, start, nr, 0);
> > + index = bitmap_find_next_zero_area(map, size, start, nr,
> align_mask);
> >
> > while (index < size) {
> > int next_bit = find_next_bit(map, size, index + nr);
>
> What about the other call to bitmap_find_next_zero_area()?
All others will pass the align_mask to bitmap_find_next_zero_area.
>
> -Scott
[PATCH] staging: style fix for octeon/ethernet-tx.c
Broke line with greater than 80 characters into two lines and
improved logical operator readability in hardware checksum if statement.
Signed-off-by: Jacob Kiefer
---
drivers/staging/octeon/ethernet-tx.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/octeon/ethernet-tx.c
b/drivers/staging/octeon/ethernet-tx.c
index 7c1c1b0..e2df041 100644
--- a/drivers/staging/octeon/ethernet-tx.c
+++ b/drivers/staging/octeon/ethernet-tx.c
@@ -396,10 +396,12 @@ dont_put_skbuff_in_hw:
/* Check if we can use the hardware checksumming */
if ((skb->protocol == htons(ETH_P_IP)) &&
- (ip_hdr(skb)->version == 4) && (ip_hdr(skb)->ihl == 5) &&
- ((ip_hdr(skb)->frag_off == 0) || (ip_hdr(skb)->frag_off == htons(1
<< 14)))
- && ((ip_hdr(skb)->protocol == IPPROTO_TCP)
- || (ip_hdr(skb)->protocol == IPPROTO_UDP))) {
+ (ip_hdr(skb)->version == 4) &&
+ (ip_hdr(skb)->ihl == 5) &&
+ ((ip_hdr(skb)->frag_off == 0) ||
+(ip_hdr(skb)->frag_off == htons(1 << 14))) &&
+ ((ip_hdr(skb)->protocol == IPPROTO_TCP) ||
+(ip_hdr(skb)->protocol == IPPROTO_UDP))) {
/* Use hardware checksum calc */
pko_command.s.ipoffp1 = sizeof(struct ethhdr) + 1;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On Fri, Jul 10, 2015 at 01:19:29PM +0900, Sergey Senozhatsky wrote:
> On (07/10/15 11:29), Minchan Kim wrote:
> > Good question.
> >
> > My worry was failure of order-0 page allocation in zram-swap path
> > when memory presssure is really heavy but I didn't insist to you
> > from sometime. The reason I changed my mind was
> >
> > 1. It's almost dead system if there is no order-0 page
> > 2. If old might be working well, it's not our design, just luck.
>
> I mean I find your argument that some level of fragmentation
> can be of use to be valid, to some degree.
The benefit I had in mind was to prevent failure of allocation.
>
>
> hm... by the way,
>
> unsigned long zs_malloc(struct zs_pool *pool, size_t size)
> {
> ...
>size += ZS_HANDLE_SIZE;
>class = pool->size_class[get_size_class_index(size)];
> ...
>if (!first_page) {
> spin_unlock(>lock);
> first_page = alloc_zspage(class, pool->flags);
> if (unlikely(!first_page)) {
> free_handle(pool, handle);
> return 0;
> }
>...
>
> I'm thinking now, does it make sense to try harder here? if we
> failed to alloc_zspage(), then may be we can try any of unused
> objects from a 'upper' (larger/next) class? there might be a
> plenty of them.
I actually thought about that but I didn't have any report from
community and product division of my compamy until now.
But with auto-compaction, the chance would be higher than old
so let's keep an eye on it(I think users can find it easily because
swap layer emits "write write failure").
If it happens(ie, any report from someone), we could try to compact
and then if it fails, we could fall back to upper class as a last
resort.
Thanks.
>
> -ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: beef up wake_wide()
On Thu, 2015-07-09 at 15:26 +0200, Peter Zijlstra wrote:
> On Wed, Jul 08, 2015 at 08:13:46AM +0200, Mike Galbraith wrote:
> > static int wake_wide(struct task_struct *p)
> > {
> > + unsigned int waker_flips = current->wakee_flips;
> > + unsigned int wakee_flips = p->wakee_flips;
> > int factor = this_cpu_read(sd_llc_size);
> >
> > + if (waker_flips < wakee_flips)
> > + swap(waker_flips, wakee_flips);
>
> This makes the wakee/waker names useless, the end result is more like
> wakee_flips := client_flips, waker_flips := server_flips.
I settled on master/slave plus hopefully improved comment block.
> > + if (wakee_flips < factor || waker_flips < wakee_flips * factor)
> > + return 0;
>
> I don't get the first condition... why would the client ever flip? It
> only talks to that one server.
(tightening heuristic up a bit by one means or another would be good,
but "if it ain't broke, don't fix it" applies for this patchlet)
> > @@ -5021,14 +5015,17 @@ select_task_rq_fair(struct task_struct *
> > {
> > struct sched_domain *tmp, *affine_sd = NULL, *sd = NULL;
> > int cpu = smp_processor_id();
> > + int new_cpu = prev_cpu;
> > int want_affine = 0;
> > int sync = wake_flags & WF_SYNC;
> >
> > rcu_read_lock();
> > + if (sd_flag & SD_BALANCE_WAKE) {
> > + want_affine = !wake_wide(p) && cpumask_test_cpu(cpu,
> > tsk_cpus_allowed(p));
> > + if (!want_affine)
> > + goto select_idle;
> > + }
>
> So this preserves/makes worse the bug Morten spotted, even without
> want_affine we should still attempt SD_BALANCE_WAKE if set.
Fixed. wake_wide() may override want_affine as before, want_affine may
override other ->flags as before, but a surviving domain selection now
results in a full balance instead of a select_idle_sibling() call.
sched: beef up wake_wide()
Josef Bacik reported that Facebook sees better performance with their
1:N load (1 dispatch/node, N workers/node) when carrying an old patch
to try very hard to wake to an idle CPU. While looking at wake_wide(),
I noticed that it doesn't pay attention to the wakeup of a many partner
waker, returning 1 only when waking one of its many partners.
Correct that, letting explicit domain flags override the heuristic.
While at it, adjust task_struct bits, we don't need a 64bit counter.
Signed-off-by: Mike Galbraith
Tested-by: Josef Bacik
---
include/linux/sched.h |4 +--
kernel/sched/fair.c | 57 ++
2 files changed, 28 insertions(+), 33 deletions(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1351,9 +1351,9 @@ struct task_struct {
#ifdef CONFIG_SMP
struct llist_node wake_entry;
int on_cpu;
- struct task_struct *last_wakee;
- unsigned long wakee_flips;
+ unsigned int wakee_flips;
unsigned long wakee_flip_decay_ts;
+ struct task_struct *last_wakee;
int wake_cpu;
#endif
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4730,26 +4730,29 @@ static long effective_load(struct task_g
#endif
+/*
+ * Detect M:N waker/wakee relationships via a switching-frequency heuristic.
+ * A waker of many should wake a different task than the one last awakened
+ * at a frequency roughly N times higher than one of its wakees. In order
+ * to determine whether we should let the load spread vs consolodating to
+ * shared cache, we look for a minimum 'flip' frequency of llc_size in one
+ * partner, and a factor of lls_size higher frequency in the other. With
+ * both conditions met, we can be relatively sure that the relationship is
+ * non-monogamous, with partner count exceeding socket size. Waker/wakee
+ * being client/server, worker/dispatcher, interrupt source or whatever is
+ * irrelevant, spread criteria is apparent partner count exceeds socket size.
+ */
static int wake_wide(struct task_struct *p)
{
+ unsigned int master = current->wakee_flips;
+ unsigned int slave = p->wakee_flips;
int factor = this_cpu_read(sd_llc_size);
- /*
-* Yeah, it's the switching-frequency, could means many wakee or
-* rapidly switch, use factor here will just help to automatically
-* adjust the loose-degree, so bigger node will lead to more pull.
-*/
- if (p->wakee_flips > factor) {
- /*
-* wakee is somewhat hot, it needs certain amount of cpu
-* resource, so if waker is far more hot, prefer to leave
-* it alone.
-*/
- if (current->wakee_flips > (factor * p->wakee_flips))
- return 1;
- }
-
- return 0;
+ if (master < slave)
+ swap(master, slave);
+ if (slave < factor || master < slave * factor)
+ return 0;
+ return 1;
}
static int wake_affine(struct sched_domain *sd, struct task_struct *p, int
sync)
@@ -4761,13 +4764,6
[PATCH] arcmsr: Fix a potential data corruption issue
Resetting rqbuffer or wqbuffer must be done within a critial section in order to avoir potential data corruption. Signed-off-by: Christophe JAILLET --- This change is *untested* because I don't have the corresponding hardware. However, it should'nt have any evil side effect (just a few lines of code moved from outside to within a spin_lock) This just a "guess" based on the other uses of the 2 buffers within the code. It is also inspired on how things are done in arcmsr_hba.c (see line #2390) So please ignore if not relevant. --- drivers/scsi/arcmsr/arcmsr_attr.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c b/drivers/scsi/arcmsr/arcmsr_attr.c index 9c86481..2ad970d 100644 --- a/drivers/scsi/arcmsr/arcmsr_attr.c +++ b/drivers/scsi/arcmsr/arcmsr_attr.c @@ -171,22 +171,21 @@ static ssize_t arcmsr_sysfs_iop_message_clear(struct file *filp, return -EACCES; arcmsr_clear_iop2drv_rqueue_buffer(acb); - acb->acb_flags |= - (ACB_F_MESSAGE_WQBUFFER_CLEARED - | ACB_F_MESSAGE_RQBUFFER_CLEARED - | ACB_F_MESSAGE_WQBUFFER_READED); spin_lock_irqsave(>rqbuffer_lock, flags); + acb->acb_flags |= ACB_F_MESSAGE_RQBUFFER_CLEARED; acb->rqbuf_getIndex = 0; acb->rqbuf_putIndex = 0; + pQbuffer = acb->rqbuffer; + memset(pQbuffer, 0, sizeof (struct QBUFFER)); spin_unlock_irqrestore(>rqbuffer_lock, flags); spin_lock_irqsave(>wqbuffer_lock, flags); + acb->acb_flags |= (ACB_F_MESSAGE_WQBUFFER_CLEARED | + ACB_F_MESSAGE_WQBUFFER_READED); acb->wqbuf_getIndex = 0; acb->wqbuf_putIndex = 0; - spin_unlock_irqrestore(>wqbuffer_lock, flags); - pQbuffer = acb->rqbuffer; - memset(pQbuffer, 0, sizeof (struct QBUFFER)); pQbuffer = acb->wqbuffer; memset(pQbuffer, 0, sizeof (struct QBUFFER)); + spin_unlock_irqrestore(>wqbuffer_lock, flags); return 1; } -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] kexec: Make a pair of map and unmap reserved pages when kdump fails to start
For some arch, kexec shall map the reserved pages, then use them, when
we try to start the kdump service.
Now kexec will never unmap the reserved pages, once it fails to continue
starting the kdump service. So we make a pair of map/unmap reserved
pages whatever kexec fails or not in code path.
In order to make code readable, wrap a new function __kexec_load which
contains all of the logic to deal with the image loading.
Signed-off-by: Minfei Huang
---
v3:
- reconstruct the patch, wrap a new function to deal with the code logic, based
on Vivek and Michael's patch
v2:
- replace the "failure" label with "fail_unmap_pages"
v1:
- reconstruct the patch code
---
kernel/kexec.c | 112 -
1 file changed, 63 insertions(+), 49 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index a785c10..2232c90 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1247,10 +1247,71 @@ int kexec_load_disabled;
static DEFINE_MUTEX(kexec_mutex);
+static int __kexec_load(unsigned long entry, unsigned long nr_segments,
+ struct kexec_segment __user *segments,
+ unsigned long flags)
+{
+ int result = 0;
+ struct kimage **dest_image, *image;
+
+ dest_image = _image;
+
+ if (flags & KEXEC_ON_CRASH)
+ dest_image = _crash_image;
+
+ if (nr_segments == 0) {
+ /* Install the new kernel, and Uninstall the old */
+ image = xchg(dest_image, image);
+ kimage_free(image);
+ } else {
+ unsigned long i;
+
+ if (flags & KEXEC_ON_CRASH) {
+ /*
+* Loading another kernel to switch to if this one
+* crashes. Free any current crash dump kernel before
+* we corrupt it.
+*/
+ kimage_free(xchg(_crash_image, NULL));
+ }
+
+ result = kimage_alloc_init(, entry,
+ nr_segments, segments, flags);
+ if (result)
+ return result;
+
+ if (flags & KEXEC_ON_CRASH)
+ crash_map_reserved_pages();
+
+ if (flags & KEXEC_PRESERVE_CONTEXT)
+ image->preserve_context = 1;
+
+ result = machine_kexec_prepare(image);
+ if (result)
+ goto failure_unmap_mem;
+
+ for (i = 0; i < nr_segments; i++) {
+ result = kimage_load_segment(image, >segment[i]);
+ if (result)
+ goto failure_unmap_mem;
+ }
+
+ kimage_terminate(image);
+
+ /* Install the new kernel, and Uninstall the old */
+ image = xchg(dest_image, image);
+
+failure_unmap_mem:
+ if (flags & KEXEC_ON_CRASH)
+ crash_unmap_reserved_pages();
+ kimage_free(image);
+ }
+ return result;
+}
+
SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
struct kexec_segment __user *, segments, unsigned long, flags)
{
- struct kimage **dest_image, *image;
int result;
/* We only trust the superuser with rebooting the system. */
@@ -1275,9 +1336,6 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry,
unsigned long, nr_segments,
if (nr_segments > KEXEC_SEGMENT_MAX)
return -EINVAL;
- image = NULL;
- result = 0;
-
/* Because we write directly to the reserved memory
* region when loading crash kernels we need a mutex here to
* prevent multiple crash kernels from attempting to load
@@ -1289,53 +1347,9 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry,
unsigned long, nr_segments,
if (!mutex_trylock(_mutex))
return -EBUSY;
- dest_image = _image;
- if (flags & KEXEC_ON_CRASH)
- dest_image = _crash_image;
- if (nr_segments > 0) {
- unsigned long i;
-
- if (flags & KEXEC_ON_CRASH) {
- /*
-* Loading another kernel to switch to if this one
-* crashes. Free any current crash dump kernel before
-* we corrupt it.
-*/
+ result = __kexec_load(entry, nr_segments, segments, flags);
- kimage_free(xchg(_crash_image, NULL));
- result = kimage_alloc_init(, entry, nr_segments,
- segments, flags);
- crash_map_reserved_pages();
- } else {
- /* Loading another kernel to reboot into. */
-
- result = kimage_alloc_init(, entry, nr_segments,
-
[RFC PATCH] i2c: busses: i2c-omap: Increase timeout for i2c interrupt
When system is under load and there is an i2c transaction running following warning appears on the console: [ 730.003617] omap_i2c 4807.i2c: controller timed out [ 731.023643] omap_i2c 4807.i2c: controller timed out This is because, the completion() call, which is done in bottom half of the interrupt handler, happens after the timeout period(1s) has elapsed for the wait_for_completion_timeout() in omap_i2c_xfer_msg(). The interrupt is raised within a second but due to system load (or other interrupts), the bottom half does not get scheduled within a second. Hence even though the interrupt has happened within required time frame, due to delayed scheduling of bottom half, spurious timeout errors are reported on the console and i2c controller is reset. i2c timeout is a rare condition, hence increase timeout to 60s in order to avoid reporting false timeout events under load. Signed-off-by: Vignesh R --- I reproduced this while running i2cdump in a loop and reading from flash using dd command. drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index d1c22e3fdd14..fa7758f0302c 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -50,7 +50,7 @@ #define OMAP_I2C_REV_ON_4430_PLUS 0x5042 /* timeout waiting for the controller to respond */ -#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000)) +#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(60 * 1000)) /* timeout for pm runtime autosuspend */ #define OMAP_I2C_PM_TIMEOUT1000/* ms */ -- 2.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
On Wed, Jul 08, 2015 at 05:41:03PM +0800, Chunfeng Yun wrote:
> add a DT binding documentation of usb3.0 phy for MT65xx
> SoCs from Mediatek.
>
> Signed-off-by: Chunfeng Yun
> ---
> .../devicetree/bindings/usb/mt65xx-u3phy.txt | 34
> ++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/mt65xx-u3phy.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/mt65xx-u3phy.txt
> b/Documentation/devicetree/bindings/usb/mt65xx-u3phy.txt
> new file mode 100644
> index 000..056b2aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/mt65xx-u3phy.txt
> @@ -0,0 +1,34 @@
> +MT65xx U3PHY
> +
> +The device node for Mediatek SOC usb3.0 phy
> +
> +Required properties:
> + - compatible : Should be "mediatek,mt8173-u3phy"
> + - reg: Offset and length of registers, the first is for mac domain,
> + another for phy domain
> + - power-domains: to enable usb's mtcmos
> + - usb-wakeup-ctrl : to access usb wakeup control register
> + - wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup mode; others
> + means don't enable wakeup source of usb
> + - u2port-num : number of usb2.0 ports to support which should be 1 or 2
> + - clocks : must support all clocks that phy need
> + - clock-names: should be "wakeup_deb_p0", "wakeup_deb_p1" for wakeup
> + debounce control clocks, and "u3phya_ref" for u3phya reference clock.
> +
> +Example:
> +
> +u3phy: usb-phy@11271000 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x11271000 0 0x3000>,
> + <0 0x1128 0 0x2>;
0x11271000 is the register space the xhci controller takes. You should
not expose the same register space to two different drivers.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (1): mfd: Drop owner assignment from i2c_drivers drivers/mfd/88pm800.c | 1 - drivers/mfd/88pm805.c | 1 - drivers/mfd/88pm860x-core.c | 1 - drivers/mfd/aat2870-core.c| 1 - drivers/mfd/ab3100-core.c | 1 - drivers/mfd/adp5520.c | 1 - drivers/mfd/arizona-i2c.c | 1 - drivers/mfd/as3711.c | 1 - drivers/mfd/as3722.c | 1 - drivers/mfd/axp20x.c | 1 - drivers/mfd/bcm590xx.c| 1 - drivers/mfd/cros_ec_i2c.c | 1 - drivers/mfd/da903x.c | 1 - drivers/mfd/da9052-i2c.c | 1 - drivers/mfd/da9055-i2c.c | 1 - drivers/mfd/da9063-i2c.c | 1 - drivers/mfd/intel_soc_pmic_core.c | 1 - drivers/mfd/lm3533-core.c | 1 - drivers/mfd/lp3943.c | 1 - drivers/mfd/lp8788.c | 1 - drivers/mfd/max14577.c| 1 - drivers/mfd/max77686.c| 1 - drivers/mfd/max77693.c| 1 - drivers/mfd/max8907.c | 1 - drivers/mfd/max8925-i2c.c | 1 - drivers/mfd/max8997.c | 1 - drivers/mfd/max8998.c | 1 - drivers/mfd/mc13xxx-i2c.c | 1 - drivers/mfd/palmas.c | 1 - drivers/mfd/rc5t583.c | 1 - drivers/mfd/retu-mfd.c| 1 - drivers/mfd/sec-core.c| 1 - drivers/mfd/si476x-i2c.c | 1 - drivers/mfd/smsc-ece1099.c| 1 - drivers/mfd/stmpe-i2c.c | 1 - drivers/mfd/tc3589x.c | 1 - drivers/mfd/tps6507x.c| 1 - drivers/mfd/tps65090.c| 1 - drivers/mfd/tps65217.c| 1 - drivers/mfd/tps65218.c| 1 - drivers/mfd/tps6586x.c| 1 - drivers/mfd/tps65910.c| 1 - drivers/mfd/tps65912-i2c.c| 1 - drivers/mfd/tps80031.c| 1 - drivers/mfd/twl6040.c | 1 - drivers/mfd/wm831x-i2c.c | 1 - drivers/mfd/wm8350-i2c.c | 1 - drivers/mfd/wm8400-core.c | 1 - drivers/mfd/wm8994-core.c | 1 - 49 files changed, 49 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: Drop owner assignment from i2c_drivers
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/mfd/88pm800.c | 1 -
drivers/mfd/88pm805.c | 1 -
drivers/mfd/88pm860x-core.c | 1 -
drivers/mfd/aat2870-core.c| 1 -
drivers/mfd/ab3100-core.c | 1 -
drivers/mfd/adp5520.c | 1 -
drivers/mfd/arizona-i2c.c | 1 -
drivers/mfd/as3711.c | 1 -
drivers/mfd/as3722.c | 1 -
drivers/mfd/axp20x.c | 1 -
drivers/mfd/bcm590xx.c| 1 -
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/da903x.c | 1 -
drivers/mfd/da9052-i2c.c | 1 -
drivers/mfd/da9055-i2c.c | 1 -
drivers/mfd/da9063-i2c.c | 1 -
drivers/mfd/intel_soc_pmic_core.c | 1 -
drivers/mfd/lm3533-core.c | 1 -
drivers/mfd/lp3943.c | 1 -
drivers/mfd/lp8788.c | 1 -
drivers/mfd/max14577.c| 1 -
drivers/mfd/max77686.c| 1 -
drivers/mfd/max77693.c| 1 -
drivers/mfd/max8907.c | 1 -
drivers/mfd/max8925-i2c.c | 1 -
drivers/mfd/max8997.c | 1 -
drivers/mfd/max8998.c | 1 -
drivers/mfd/mc13xxx-i2c.c | 1 -
drivers/mfd/palmas.c | 1 -
drivers/mfd/rc5t583.c | 1 -
drivers/mfd/retu-mfd.c| 1 -
drivers/mfd/sec-core.c| 1 -
drivers/mfd/si476x-i2c.c | 1 -
drivers/mfd/smsc-ece1099.c| 1 -
drivers/mfd/stmpe-i2c.c | 1 -
drivers/mfd/tc3589x.c | 1 -
drivers/mfd/tps6507x.c| 1 -
drivers/mfd/tps65090.c| 1 -
drivers/mfd/tps65217.c| 1 -
drivers/mfd/tps65218.c| 1 -
drivers/mfd/tps6586x.c| 1 -
drivers/mfd/tps65910.c| 1 -
drivers/mfd/tps65912-i2c.c| 1 -
drivers/mfd/tps80031.c| 1 -
drivers/mfd/twl6040.c | 1 -
drivers/mfd/wm831x-i2c.c | 1 -
drivers/mfd/wm8350-i2c.c | 1 -
drivers/mfd/wm8400-core.c | 1 -
drivers/mfd/wm8994-core.c | 1 -
49 files changed, 49 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 841717a2842c..f2d9fb4c4e8e 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -609,7 +609,6 @@ static int pm800_remove(struct i2c_client *client)
static struct i2c_driver pm800_driver = {
.driver = {
.name = "88PM800",
- .owner = THIS_MODULE,
.pm = _pm_ops,
},
.probe = pm800_probe,
diff --git a/drivers/mfd/88pm805.c b/drivers/mfd/88pm805.c
index e9d50644660c..39f2302e137b 100644
--- a/drivers/mfd/88pm805.c
+++ b/drivers/mfd/88pm805.c
@@ -267,7 +267,6 @@ static int pm805_remove(struct i2c_client *client)
static struct i2c_driver pm805_driver = {
.driver = {
.name = "88PM805",
- .owner = THIS_MODULE,
.pm = _pm_ops,
},
.probe = pm805_probe,
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index e03b7f45b8f7..cb47d6e00ebe 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -1258,7 +1258,6 @@ MODULE_DEVICE_TABLE(of, pm860x_dt_ids);
static struct i2c_driver pm860x_driver = {
.driver = {
.name = "88PM860x",
- .owner = THIS_MODULE,
.pm = _pm_ops,
.of_match_table = pm860x_dt_ids,
},
diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index 4e6e03d63e12..29b6a2d4ac72 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -500,7 +500,6 @@ MODULE_DEVICE_TABLE(i2c, aat2870_i2c_id_table);
static struct i2c_driver aat2870_i2c_driver = {
.driver = {
.name = "aat2870",
- .owner = THIS_MODULE,
.pm = _pm_ops,
},
.probe = aat2870_i2c_probe,
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 4659ac1db039..f0afb44271f8 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -972,7 +972,6 @@ MODULE_DEVICE_TABLE(i2c, ab3100_id);
static struct i2c_driver ab3100_driver = {
.driver = {
.name = "ab3100",
- .owner = THIS_MODULE,
},
.id_table = ab3100_id,
.probe = ab3100_probe,
diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index f495b8b57dd7..ae88654595dc 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -351,7 +351,6 @@ MODULE_DEVICE_TABLE(i2c, adp5520_id);
static struct i2c_driver adp5520_driver = {
.driver = {
.name = "adp5520",
- .owner = THIS_MODULE,
.pm = _pm,
},
.probe
[PATCH] ARM: EXYNOS: pmu: Drop owner assignment
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
arch/arm/mach-exynos/pmu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index e812c1c85624..960fc3510545 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -991,7 +991,6 @@ static int exynos_pmu_probe(struct platform_device *pdev)
static struct platform_driver exynos_pmu_driver = {
.driver = {
.name = "exynos-pmu",
- .owner = THIS_MODULE,
.of_match_table = exynos_pmu_of_device_ids,
},
.probe = exynos_pmu_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (1): ARM: EXYNOS: pmu: Drop owner assignment arch/arm/mach-exynos/pmu.c | 1 - 1 file changed, 1 deletion(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] ARM: add UART and EHCI support for UniPhier DTS and enable them.
The basic support for UniPhier SoC family (arch/arm/mach-uniphier) was mainlined at Linux 4.2-rc1. I am now tackling some drivers to support them in the mainline. I've got UART and EHCI done, so I'd like to enable them from the ARM-SOC subsystem. Changes in v2: - Add chip-specific compatible strings "socionext,uniphier-ehci" Masahiro Yamada (3): ARM: multi_v7_defconfig: enable UniPhier UART driver ARM: dts: UniPhier: add on-chip UART device nodes ARM: dts: UniPhier: add USB EHCI device nodes arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 29 +++-- arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 63 + arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 29 +++-- arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 56 + arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 36 +++-- arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 61 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 33 +-- arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 63 + arch/arm/configs/multi_v7_defconfig | 1 + 9 files changed, 359 insertions(+), 12 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] ARM: multi_v7_defconfig: enable UniPhier UART driver
The UniPhier on-chip UART driver was merged into the mainline by
commit 1a8d2903cb6a ("serial: 8250_uniphier: add UniPhier serial
driver").
Enable it from multi_v7_defconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 6d83a1b..9311cd9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -251,6 +251,7 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_8250_EM=y
CONFIG_SERIAL_8250_MT6577=y
+CONFIG_SERIAL_8250_UNIPHIER=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_SERIAL_ATMEL=y
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] ARM: dts: UniPhier: add on-chip UART device nodes
The UniPhier on-chip UART driver was merged into the mainline by
commit 1a8d2903cb6a ("serial: 8250_uniphier: add UniPhier serial
driver").
Add device nodes to make it really available.
We no longer have to depend on the on-board UART device (16550A),
so let's change the chosen and aliases to point to the on-chip ones.
Also, turn on the on-board Ethernet device.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 42 +
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 42 +
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 20 +++---
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 33 +++
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 21 ---
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 42 +
8 files changed, 230 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 200b0c9..0cd385a9 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -57,11 +57,14 @@
chosen {
bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path =
};
aliases {
- serial0 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
};
};
@@ -74,6 +77,18 @@
ranges = <0x 1 0x03f0 0x0010>;
};
- {
+ {
interrupts = <0 49 4>;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 6a34c56..1261e6d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -64,6 +64,12 @@
compatible = "fixed-clock";
clock-frequency = <5000>;
};
+
+ uart_clk: uart_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <36864000>;
+ };
};
soc {
@@ -79,6 +85,42 @@
#size-cells = <1>;
};
+ serial0: serial@54006800 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006800 0x40>;
+ interrupts = <0 33 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial1: serial@54006900 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006900 0x40>;
+ interrupts = <0 35 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial2: serial@54006a00 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006a00 0x40>;
+ interrupts = <0 37 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
+ serial3: serial@54006b00 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006b00 0x40>;
+ interrupts = <0 29 4>;
+ clocks = <_clk>;
+ fifo-size = <64>;
+ };
+
system-bus-controller-misc@5980 {
compatible =
"socionext,uniphier-system-bus-controller-misc",
"syscon";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index d891135..0951cbf 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -57,11 +57,14 @@
chosen {
bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path =
};
aliases {
- serial0 =
+ serial0 =
+ serial1 =
+ serial2 =
+ serial3 =
};
};
@@ -74,6 +77,18 @@
ranges = <0x 1 0x03f0 0x0010>;
};
- {
+ {
interrupts = <0 50 4>;
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
[PATCH v2 3/3] ARM: dts: UniPhier: add USB EHCI device nodes
No dedicated driver compatible with "socionext,uniphier-ehci" has
been supported in the mainline yet, so it falls into "generic-ehci"
and it works well enough with our USB 2.0 host controllers.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add chip-specific compatible strings "socionext,uniphier-ehci"
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 21 +
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 8
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 16
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 28
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 12
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 21 +
8 files changed, 128 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 0cd385a9..7ac053d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -92,3 +92,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 1261e6d..600a473 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -127,6 +127,27 @@
reg = <0x5980 0x2000>;
};
+ usb0: usb@5a800100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+ usb1: usb@5a810100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a810100 0x100>;
+ interrupts = <0 81 4>;
+ };
+
+ usb2: usb@5a820100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a820100 0x100>;
+ interrupts = <0 82 4>;
+ };
+
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 0951cbf..b669d32 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -92,3 +92,11 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index acd2c06..4598bb2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -134,6 +134,20 @@
reg = <0x5980 0x2000>;
};
+ usb2: usb@5a800100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+ usb3: usb@5a810100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a810100 0x100>;
+ interrupts = <0 81 4>;
+ };
+
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index 47a44da..48f7361 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -92,3 +92,19 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index feb253b..db74457 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -146,5 +146,33 @@
"syscon";
reg = <0x5980 0x2000>;
};
+
+ usb0: usb@5a800100 {
+ compatible = "socionext,uniphier-ehci", "generic-ehci";
+ status = "disabled";
+ reg = <0x5a800100 0x100>;
+ interrupts = <0 80 4>;
+ };
+
+
Re: [PATCH] staging: style fix for octeon/ethernet-tx.c
On Thu, Jul 09, 2015 at 08:46:04PM -0400, Jacob Kiefer wrote: > From: Jacob Kiefer No need to mention this From: as it will come from the email header. > > Style fix for octeon/ethernet-tx.c Please mention which style you have fixed. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] coccinelle: api: extend spatch for dropping unnecessary owner
i2c_add_driver (through i2c_register_driver) sets the owner field so we
can drop it also from i2c drivers, just like from platform drivers.
Signed-off-by: Krzysztof Kozlowski
---
scripts/coccinelle/api/platform_no_drv_owner.cocci | 73 ++
1 file changed, 73 insertions(+)
diff --git a/scripts/coccinelle/api/platform_no_drv_owner.cocci
b/scripts/coccinelle/api/platform_no_drv_owner.cocci
index e065b9e714fc..c5e3f73f2054 100644
--- a/scripts/coccinelle/api/platform_no_drv_owner.cocci
+++ b/scripts/coccinelle/api/platform_no_drv_owner.cocci
@@ -9,11 +9,14 @@ virtual org
virtual report
@match1@
+declarer name module_i2c_driver;
declarer name module_platform_driver;
declarer name module_platform_driver_probe;
identifier __driver;
@@
(
+ module_i2c_driver(__driver);
+|
module_platform_driver(__driver);
|
module_platform_driver_probe(__driver, ...);
@@ -28,6 +31,15 @@ identifier match1.__driver;
}
};
+@fix1_i2c depends on match1 && patch && !context && !org && !report@
+identifier match1.__driver;
+@@
+ static struct i2c_driver __driver = {
+ .driver = {
+- .owner = THIS_MODULE,
+ }
+ };
+
@match2@
identifier __driver;
@@
@@ -37,6 +49,8 @@ identifier __driver;
platform_driver_probe(&__driver, ...)
|
platform_create_bundle(&__driver, ...)
+|
+ i2c_add_driver(&__driver)
)
@fix2 depends on match2 && patch && !context && !org && !report@
@@ -48,6 +62,15 @@ identifier match2.__driver;
}
};
+@fix2_i2c depends on match2 && patch && !context && !org && !report@
+identifier match2.__driver;
+@@
+ static struct i2c_driver __driver = {
+ .driver = {
+- .owner = THIS_MODULE,
+ }
+ };
+
//
@fix1_context depends on match1 && !patch && (context || org || report)@
@@ -61,6 +84,17 @@ position j0;
}
};
+@fix1_i2c_context depends on match1 && !patch && (context || org || report)@
+identifier match1.__driver;
+position j0;
+@@
+
+ static struct i2c_driver __driver = {
+ .driver = {
+* .owner@j0 = THIS_MODULE,
+ }
+ };
+
@fix2_context depends on match2 && !patch && (context || org || report)@
identifier match2.__driver;
position j0;
@@ -72,6 +106,17 @@ position j0;
}
};
+@fix2_i2c_context depends on match2 && !patch && (context || org || report)@
+identifier match2.__driver;
+position j0;
+@@
+
+ static struct i2c_driver __driver = {
+ .driver = {
+* .owner@j0 = THIS_MODULE,
+ }
+ };
+
//
@script:python fix1_org depends on org@
@@ -81,6 +126,13 @@ j0 << fix1_context.j0;
msg = "No need to set .owner here. The core will do it."
coccilib.org.print_todo(j0[0], msg)
+@script:python fix1_i2c_org depends on org@
+j0 << fix1_i2c_context.j0;
+@@
+
+msg = "No need to set .owner here. The core will do it."
+coccilib.org.print_todo(j0[0], msg)
+
@script:python fix2_org depends on org@
j0 << fix2_context.j0;
@@
@@ -88,6 +140,13 @@ j0 << fix2_context.j0;
msg = "No need to set .owner here. The core will do it."
coccilib.org.print_todo(j0[0], msg)
+@script:python fix2_i2c_org depends on org@
+j0 << fix2_i2c_context.j0;
+@@
+
+msg = "No need to set .owner here. The core will do it."
+coccilib.org.print_todo(j0[0], msg)
+
//
@script:python fix1_report depends on report@
@@ -97,6 +156,13 @@ j0 << fix1_context.j0;
msg = "No need to set .owner here. The core will do it."
coccilib.report.print_report(j0[0], msg)
+@script:python fix1_i2c_report depends on report@
+j0 << fix1_i2c_context.j0;
+@@
+
+msg = "No need to set .owner here. The core will do it."
+coccilib.report.print_report(j0[0], msg)
+
@script:python fix2_report depends on report@
j0 << fix2_context.j0;
@@
@@ -104,3 +170,10 @@ j0 << fix2_context.j0;
msg = "No need to set .owner here. The core will do it."
coccilib.report.print_report(j0[0], msg)
+@script:python fix2_i2c_report depends on report@
+j0 << fix2_i2c_context.j0;
+@@
+
+msg = "No need to set .owner here. The core will do it."
+coccilib.report.print_report(j0[0], msg)
+
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote: > On 07/09/2015 10:13 AM, Vineet Gupta wrote: >> > There's already a generic implementation so use that instead. > There is or there was? If there is now I am fine with this patch, but if > it already was there the author might have had a reason for adding a > local function and I would like to hear that reason. > atomic_orr() was introduced to this driver with 2014-03-06 5cbb9c285bdc brcmfmac: Use atomic functions for intstatus update. as it seems atomic_set_mask() was not available cross arch. And atomic_or() in generic code was indeed introduced after that 2014-04-23 560cb12a4080 locking,arch: Rewrite generic atomic support Hence likely the reason author went with home grown atomic_orr() -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH] net: axienet: Fix devm_ioremap_resource return value check
From: Krzysztof Kozlowski
Date: Thu, 9 Jul 2015 22:21:20 +0900
> Value returned by devm_ioremap_resource() was checked for non-NULL but
> devm_ioremap_resource() returns IOMEM_ERR_PTR, not NULL. In case of
> error this could lead to dereference of ERR_PTR.
>
> Signed-off-by: Krzysztof Kozlowski
> Cc:
> Fixes: 46aa27df8853 ("net: axienet: Use devm_* calls")
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 02/24] arc: Provide atomic_{or,xor,and}
On Thursday 09 July 2015 11:26 PM, Peter Zijlstra wrote:
> Implement atomic logic ops -- atomic_{or,xor,and}.
>
> These will replace the atomic_{set,clear}_mask functions that are
> available on some archs.
>
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Vineet Gupta
Since we are on the topic, the cmpxchg() loop in arch/arc/kernel/smp.c still
irritates me.
Do we need a new set of primitives to operate atomically on non atomic_t data or
does that mean that the data *not* being atomic_t but requiring such semantics
is
the fundamental problem and thus needs to be converted first.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On (07/10/15 11:29), Minchan Kim wrote:
> Good question.
>
> My worry was failure of order-0 page allocation in zram-swap path
> when memory presssure is really heavy but I didn't insist to you
> from sometime. The reason I changed my mind was
>
> 1. It's almost dead system if there is no order-0 page
> 2. If old might be working well, it's not our design, just luck.
I mean I find your argument that some level of fragmentation
can be of use to be valid, to some degree.
hm... by the way,
unsigned long zs_malloc(struct zs_pool *pool, size_t size)
{
...
size += ZS_HANDLE_SIZE;
class = pool->size_class[get_size_class_index(size)];
...
if (!first_page) {
spin_unlock(>lock);
first_page = alloc_zspage(class, pool->flags);
if (unlikely(!first_page)) {
free_handle(pool, handle);
return 0;
}
...
I'm thinking now, does it make sense to try harder here? if we
failed to alloc_zspage(), then may be we can try any of unused
objects from a 'upper' (larger/next) class? there might be a
plenty of them.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] kexec: Make a pair of map and unmap reserved pages when kdump fails to start
On 07/09/15 at 05:54P, Michael Holzheu wrote:
> On Tue, 7 Jul 2015 17:18:40 -0400
> Vivek Goyal wrote:
>
> > On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote:
>
> [snip]
>
> > I am thinking of moving kernel loading code in a separate function to
> > make things little simpler. Right now it is confusing.
> >
> > Can you please test attached patch. I have only compile tested it. This
> > is primarily doing what you are doing but in a separate function. It
> > seems more readable now.
>
> The patch looks good to me. What about the following patch on top
> to make things even more readable?
> ---
> kernel/kexec.c | 50 +-
> 1 file changed, 17 insertions(+), 33 deletions(-)
>
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -1236,14 +1236,18 @@ int kexec_load_disabled;
>
> static DEFINE_MUTEX(kexec_mutex);
>
> -static int __kexec_load(struct kimage **rimage, unsigned long entry,
> - unsigned long nr_segments,
> +static int __kexec_load(unsigned long entry, unsigned long nr_segments,
> struct kexec_segment __user * segments,
> unsigned long flags)
> {
> + struct kimage *image, **dest_image;
> unsigned long i;
> int result;
> - struct kimage *image;
> +
> + dest_image = (flags & KEXEC_ON_CRASH) ? _crash_image :
> _image;
> +
> + if (nr_segments == 0)
> + return 0;
It is fine, if nr_segments is 0. So we should deal with this case like
original kexec code.
>
> if (flags & KEXEC_ON_CRASH) {
> /*
> @@ -1251,7 +1255,6 @@ static int __kexec_load(struct kimage **
>* crashes. Free any current crash dump kernel before
>* we corrupt it.
>*/
> -
> kimage_free(xchg(_crash_image, NULL));
> }
>
> @@ -1267,30 +1270,29 @@ static int __kexec_load(struct kimage **
>
> result = machine_kexec_prepare(image);
> if (result)
> - goto out;
> + goto fail;
>
> for (i = 0; i < nr_segments; i++) {
> result = kimage_load_segment(image, >segment[i]);
> if (result)
> - goto out;
> + goto fail;
> }
> -
> kimage_terminate(image);
> - *rimage = image;
> -out:
> + /* Install the new kernel, and uninstall the old */
> + kimage_free(xchg(dest_image, image));
> if (flags & KEXEC_ON_CRASH)
> crash_unmap_reserved_pages();
> -
> - /* Free image if there was an error */
> - if (result)
> - kimage_free(image);
> + return 0;
> +fail:
> + if (flags & KEXEC_ON_CRASH)
> + crash_unmap_reserved_pages();
> + kimage_free(image);
Kernel release image again, and will crash in here, since we do not
assign the image to NULL when we release the image above.
Thanks
Minfei
> return result;
> }
>
> SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
> struct kexec_segment __user *, segments, unsigned long, flags)
> {
> - struct kimage **dest_image, *image;
> int result;
>
> /* We only trust the superuser with rebooting the system. */
> @@ -1315,9 +1317,6 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
> if (nr_segments > KEXEC_SEGMENT_MAX)
> return -EINVAL;
>
> - image = NULL;
> - result = 0;
> -
> /* Because we write directly to the reserved memory
>* region when loading crash kernels we need a mutex here to
>* prevent multiple crash kernels from attempting to load
> @@ -1329,24 +1328,9 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
> if (!mutex_trylock(_mutex))
> return -EBUSY;
>
> - dest_image = _image;
> - if (flags & KEXEC_ON_CRASH)
> - dest_image = _crash_image;
> -
> /* Load new kernel */
> - if (nr_segments > 0) {
> - result = __kexec_load(, entry, nr_segments, segments,
> - flags);
> - if (result)
> - goto out;
> - }
> -
> - /* Install the new kernel, and Uninstall the old */
> - image = xchg(dest_image, image);
> -
> -out:
> + result = __kexec_load(entry, nr_segments, segments, flags);
> mutex_unlock(_mutex);
> - kimage_free(image);
>
> return result;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86: Fix pXd_flags() to handle _PAGE_PAT_LARGE
On 07/09/2015 07:03 PM, Toshi Kani wrote:
The PAT bit gets relocated to bit 12 when PUD and PMD mappings are
used. This bit 12, however, is not covered by PTE_FLAGS_MASK, which
is corrently used for masking the flag bits for all cases.
Fix pud_flags() and pmd_flags() to cover the PAT bit, _PAGE_PAT_LARGE,
when they are used to map a large page with _PAGE_PSE set.
Signed-off-by: Toshi Kani
Cc: Juergen Gross
Cc: Konrad Wilk
Cc: Robert Elliott
Cc: Thomas Gleixner
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Andrew Morton
---
arch/x86/include/asm/pgtable_types.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_types.h
b/arch/x86/include/asm/pgtable_types.h
index 13f310b..caaf45c 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -212,9 +212,13 @@ enum page_cache_mode {
/* PTE_PFN_MASK extracts the PFN from a (pte|pmd|pud|pgd)val_t */
#define PTE_PFN_MASK ((pteval_t)PHYSICAL_PAGE_MASK)
-/* PTE_FLAGS_MASK extracts the flags from a (pte|pmd|pud|pgd)val_t */
+/* Extracts the flags from a (pte|pmd|pud|pgd)val_t of a 4KB page */
#define PTE_FLAGS_MASK(~PTE_PFN_MASK)
+/* Extracts the flags from a (pmd|pud)val_t of a (1GB|2MB) page */
+#define PMD_FLAGS_MASK_LARGE ((~PTE_PFN_MASK) | _PAGE_PAT_LARGE)
+#define PUD_FLAGS_MASK_LARGE ((~PTE_PFN_MASK) | _PAGE_PAT_LARGE)
+
typedef struct pgprot { pgprotval_t pgprot; } pgprot_t;
typedef struct { pgdval_t pgd; } pgd_t;
@@ -278,12 +282,18 @@ static inline pmdval_t native_pmd_val(pmd_t pmd)
static inline pudval_t pud_flags(pud_t pud)
{
- return native_pud_val(pud) & PTE_FLAGS_MASK;
+ if (native_pud_val(pud) & _PAGE_PSE)
+ return native_pud_val(pud) & PUD_FLAGS_MASK_LARGE;
+ else
+ return native_pud_val(pud) & PTE_FLAGS_MASK;
}
static inline pmdval_t pmd_flags(pmd_t pmd)
{
- return native_pmd_val(pmd) & PTE_FLAGS_MASK;
+ if (native_pmd_val(pmd) & _PAGE_PSE)
+ return native_pmd_val(pmd) & PMD_FLAGS_MASK_LARGE;
+ else
+ return native_pmd_val(pmd) & PTE_FLAGS_MASK;
}
Hmm, I think this covers only half of the problem. pud_pfn() and
pmd_pfn() will return wrong results for large pages with PAT bit
set as well.
I'd rather use something like:
static inline unsigned long pmd_pfn_mask(pmd_t pmd)
{
if (pmd_large(pmd))
return PMD_PAGE_MASK & PHYSICAL_PAGE_MASK;
else
return PTE_PFN_MASK;
}
static inline unsigned long pmd_flags_mask(pmd_t pmd)
{
if (pmd_large(pmd))
return ~(PMD_PAGE_MASK & PHYSICAL_PAGE_MASK);
else
return ~PTE_PFN_MASK;
}
static inline unsigned long pmd_pfn(pmd_t pmd)
{
return (pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT;
}
static inline pmdval_t pmd_flags(pmd_t pmd)
{
return native_pmd_val(pmd) & ~pmd_flags_mask(pmd);
}
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] power: reset: at91: add sama5d3 reset function
Hi, Guenter On 7/10/2015 11:14 AM, Guenter Roeck wrote: On Fri, Jul 10, 2015 at 09:59:53AM +0800, Josh Wu wrote: Hi, Guenter On 7/10/2015 1:37 AM, Guenter Roeck wrote: On Thu, Jul 09, 2015 at 06:15:46PM +0800, Josh Wu wrote: As since sama5d3, to reset the chip, we don't need to shutdown the ddr controller. So add a new compatible string and new restart function for sama5d3 and later chips. As we don't use sama5d3 ddr controller, so remove it as well. That sounds like it should be two separate patches, or am I missing something ? I think using one patch makes more sense. Maybe the commit log is not clear enough. How about put it this way: This patch introduces a new compatible string: "atmel,sama5d3-rstc" for the reset driver of sama5d3 and later chips. As in sama5d3 or later chips, we don't have to shutdown the DDR controller before reset. Shutdown the DDR controller before reset is a workaround to avoid DDR signal driving the bus, but since sama5d3 and later chips there is no such a conflict. That means: 1. the sama5d3 reset function only need to write the rstc register and return. 2. for sama5d3, we can remove the code related with DDR controller as we don't use it at all. Sorry, I don't get it. Doesn't that mean there are two distinct logical changes, which would ask for two separate patches ? The rewritten reset function for sama5d3 has no need to access the ddr controller, so this patch rewrite the reset function and remove ddr access for sama5d3. Those two changes are related and so make it as one patch is reasonable. Best Regards, Josh Wu Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpufreq: Initialize the governor again while restoring policy
On 10 July 2015 at 05:35, Rafael J. Wysocki wrote: >> - Because governors matched, we skip governor initialization and return >> after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). > > But this sounds fragile in principle. What's the benefit from skipping the > governor initialization in that case? So this is the case where we have changed some property of the governor, and the governor is already initialised. We need to exit the earlier governor and initialize the new one only when the governor is actually switched. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: x86: Add host physical address width capability
Bandan Das writes: > Laszlo Ersek writes: > ... >> Yes. >> >>> Without EPT, you don't >>> hit the processor limitation with your setup, but the user should >>> nevertheless >>> still be notified. >> >> I disagree. >> >>> In fact, I think shadow paging code should also emulate >>> this behavior if the gpa is out of range. >> >> I disagree. >> >> There is no "out of range" gpa. QEMU allocates enough memory, and it >> should be completely transparent to the guest. The fact that it silently >> breaks with nested paging if the host processor doesn't have enough >> address bits is a bug (maybe a hardware bug, maybe a KVM bug; I'm not >> sure, but I suspect it's a hardware bug). In any case the guest >> shouldn't care at all. It is a *virtual* machine, and the VMM should lie >> to it plausibly enough. How much RAM, and how many phys address bits the >> host has, is a performance question, but it should not be a correctness >> question. A 256 GB guest should run (slowly, but correctly) on a laptop >> that has only 4 GB of RAM and only 36 phys addr bits, but plenty of swap >> space. >> >> Because otherwise your argument could be extrapolated as "TCG should >> break too if the gpa is 'out of range'". >> >> So, I disagree. Whatever memory you give to the guest should just work >> (unless of course you want to emulate a small address width for the >> *VCPU*, but that's absolutely not the use case here). What we have here >> is a leaky abstraction: a PCPU limitation giving away a lie that the >> guest should never notice. The guest should be able to use all memory >> that was specified with QEMU's -m, regardless of TCG vs. KVM-without-EPT >> vs. KVM-with-EPT. If the last case cannot work (due to hardware >> limitations), that's fine, but then (and only then) a warning should be >> printed. > > Hmm... Ok, I understand your point. So, this is more like a EPT > limitation/bug in that Qemu isn't complaining about the memory assigned > to the guest but EPT code is breaking owing to the processor physical > address width. And honestly, I now think that this patch just makes the whole > situation more confusing :) I am wondering if it's just possible for kvm to > simply throw an error like a EPT misconfiguration or something .. > > Or in other words, if using a hardware assisted mechanism is just not > possible, KVM will simply not let it run instead of letting a guest > stuck in boot. I noticed that when the guest gets stuck, trace shows an endless loop of EXTERNAL_INTERRUPT exits with code 14 (PF). There's a note in 28.2.2 of the spec that "No processors supporting the Intel64 architecture support more than 48 physical-address bits.. An attempt to use such an address causes a page fault". So, my first guess was to print out the guest physical address. That seems to be well beyond the range and is always 0xff000 (when the guest is stuck). The other thing I can think of is the EPT entries have bits in the 51:N range set which is reserved and always 0. I haven't verified but it looks like there's ept_misconfig_inspect_spte() that should already catch this condition. I am out of ideas for today :) > >> ... In any case, please understand that I'm not campaigning for this >> warning :) IIRC the warning was your (very welcome!) idea after I >> reported the problem; I'm just trying to ensure that the warning match >> the exact issue I encountered. >> >> Thanks! >> Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] cpufreq: Add ->get_rate() driver callback
On 10 July 2015 at 04:56, Rafael J. Wysocki wrote: > *You* can do them faily quickly. Say if all of the outstanding cpufreq > patches are queued up for 4.3, then it will be the time to submit more. > Otherwise I'll just have an ever growing queue of patches to process > which won't speed up things at all. Ack. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] coresight: replicator: Use module_platform_driver
On Fri, Jul 10, 2015 at 1:49 AM, Paul Bolle wrote:
>
> On vr, 2015-07-10 at 01:29 +0530, Vaishali Thakkar wrote:
> > --- a/drivers/hwtracing/coresight/coresight-replicator.c
> > +++ b/drivers/hwtracing/coresight/coresight-replicator.c
>
> > -static int __init replicator_init(void)
> > -{
> > - return platform_driver_register(_driver);
> > -}
> > -module_init(replicator_init);
> > -
> > -static void __exit replicator_exit(void)
> > -{
> > - platform_driver_unregister(_driver);
> > -}
> > -module_exit(replicator_exit);
> > +module_platform_driver(replicator_driver);
>
> coresight-replicator.o is built if CONFIG_CORESIGHT_LINKS_AND_SINKS is
> defined. CORESIGHT_LINKS_AND_SINKS is a bool symbol. It depends on
> CORESIGHT, which is also a bool symbol. CORESIGHT is a top level symbol,
> available on arm and arm64.
>
> I think coresight-replicator.o can only be built-in. So I suggest to use
> builtin_platform_driver() instead.
>
I thought about this solution before sending this patch. But I was not
sure about it. Thanks for the explanation. I will send v3 with this
change.
Can I add Suggested By: Paul Bolle
>
> Thanks,
>
>
> Paul Bolle
--
Vaishali
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] bnx2:Make various functions to have a return type of void in the file bnx2.c
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Wednesday, July 08, 2015 11:31 AM
> To: Sony Chacko
> Cc: Dept-GE Linux NIC Dev; netdev; linux-kernel
> Subject: [PATCH] bnx2:Make various functions to have a return
> type of void in the file bnx2.c
>
> This makes various functions that never fail nor signal their caller
> with a error code when a failure occurs to now have a return
> type of void for the file bnx2.c.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/net/ethernet/broadcom/bnx2.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2.c
> b/drivers/net/ethernet/broadcom/bnx2.c
> index 2b66ef3..ddf0ccc 100644
> --- a/drivers/net/ethernet/broadcom/bnx2.c
> +++ b/drivers/net/ethernet/broadcom/bnx2.c
> @@ -1087,7 +1087,7 @@ bnx2_resolve_flow_ctrl(struct bnx2
> *bp)
> }
> }
>
> -static int
> +static void
> bnx2_5709s_linkup(struct bnx2 *bp)
> {
> u32 val, speed;
> @@ -1101,7 +1101,7 @@ bnx2_5709s_linkup(struct bnx2 *bp)
> if ((bp->autoneg & AUTONEG_SPEED) == 0) {
> bp->line_speed = bp->req_line_speed;
> bp->duplex = bp->req_duplex;
> - return 0;
> + return;
> }
> speed = val & MII_BNX2_GP_TOP_AN_SPEED_MSK;
> switch (speed) {
> @@ -1123,10 +1123,9 @@ bnx2_5709s_linkup(struct bnx2 *bp)
> bp->duplex = DUPLEX_FULL;
> else
> bp->duplex = DUPLEX_HALF;
> - return 0;
> }
>
> -static int
> +static void
> bnx2_5708s_linkup(struct bnx2 *bp)
> {
> u32 val;
> @@ -1152,10 +1151,9 @@ bnx2_5708s_linkup(struct bnx2 *bp)
> else
> bp->duplex = DUPLEX_HALF;
>
> - return 0;
> }
>
> -static int
> +static void
> bnx2_5706s_linkup(struct bnx2 *bp)
> {
> u32 bmcr, local_adv, remote_adv, common; @@ -1172,7
> +1170,7 @@ bnx2_5706s_linkup(struct bnx2 *bp)
> }
>
> if (!(bmcr & BMCR_ANENABLE)) {
> - return 0;
> + return;
> }
>
> bnx2_read_phy(bp, bp->mii_adv, _adv); @@ -1188,11
> +1186,9 @@ bnx2_5706s_linkup(struct bnx2 *bp)
> bp->duplex = DUPLEX_HALF;
> }
> }
> -
> - return 0;
> }
>
> -static int
> +static void
> bnx2_copper_linkup(struct bnx2 *bp)
> {
> u32 bmcr;
> @@ -1264,8 +1260,6 @@ bnx2_copper_linkup(struct bnx2 *bp)
> if (ext_status & EXT_STATUS_MDIX)
> bp->phy_flags |= BNX2_PHY_FLAG_MDIX;
> }
> -
> - return 0;
> }
>
> static void
> --
> 2.1.4
Acked-by: Sony Chacko
Thanks,
Sony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/39] bpf tools: Collect eBPF programs from their own sections
On 2015/7/9 23:58, Arnaldo Carvalho de Melo wrote:
Em Thu, Jul 09, 2015 at 12:35:05PM +, Wang Nan escreveu:
This patch collects all programs in an object file into an array of
'struct bpf_program' for further processing. That structure is for
representing each eBPF program. 'bpf_prog' should be a better name, but
it has been used by linux/filter.h. Although it is a kernel space name,
I still prefer to call it 'bpf_program' to prevent possible confusion.
bpf_program__new() creates a new 'struct bpf_program' object. It first
init a variable in stack using __bpf_program__new(), then if success,
enlarges obj->programs array and copy the new object in.
Signed-off-by: Wang Nan
Acked-by: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: David Ahern
Cc: He Kuang
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1435716878-189507-13-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/bpf/libbpf.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 9b016c0..3b717de 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -78,12 +78,27 @@ void libbpf_set_print(libbpf_print_fn_t warn,
# define LIBBPF_ELF_C_READ_MMAP ELF_C_READ
#endif
+/*
+ * bpf_prog should be a better name but it has been used in
+ * linux/filter.h.
+ */
+struct bpf_program {
+ /* Index in elf obj file, for relocation use. */
+ int idx;
+ char *section_name;
+ struct bpf_insn *insns;
+ size_t insns_cnt;
+};
+
struct bpf_object {
char license[64];
u32 kern_version;
void *maps_buf;
size_t maps_buf_sz;
+ struct bpf_program *programs;
+ size_t nr_programs;
+
/*
* Information when doing elf related work. Only valid if fd
* is valid.
@@ -100,6 +115,84 @@ struct bpf_object {
};
#define obj_elf_valid(o) ((o)->efile.elf)
+static void bpf_program__clear(struct bpf_program *prog)
+{
+ if (!prog)
+ return;
+
+ zfree(>section_name);
+ zfree(>insns);
+ prog->insns_cnt = 0;
+ prog->idx = -1;
+}
So in perf land we use 'bpf_program__exit()' as the counterpart of
bpf_program__init(), i.e. one just initializes fields, allocating
memory for 'struct bpf_program' members, but does not allocates the
struct bpf_program itself, because sometimes we embed it inside other
structs, or we have it in arrays, as you do.
So, to keep that convention, please rename bpf_program__clear() to
bpf_program__exit() and the next function, __bpf_program__new() to
bpf_program__init(), with 'struct bpf_program *prog' as the first
parameter.
To speed things up, from now on, when I see such stuff, I will do the
changes, put them in a branch with a commiter note, and wait for your
Ack (or not, if you disagree with something).
One more comment below.
+
+static int
+__bpf_program__new(void *data, size_t size, char *name, int idx,
+ struct bpf_program *prog)
+{
+ if (size < sizeof(struct bpf_insn)) {
+ pr_warning("corrupted section '%s'\n", name);
+ return -EINVAL;
+ }
+
+ bzero(prog, sizeof(*prog));
+
+ prog->section_name = strdup(name);
+ if (!prog->section_name) {
+ pr_warning("failed to alloc name for prog %s\n",
+ name);
+ goto errout;
+ }
+
+ prog->insns = malloc(size);
+ if (!prog->insns) {
+ pr_warning("failed to alloc insns for %s\n", name);
+ goto errout;
+ }
+ prog->insns_cnt = size / sizeof(struct bpf_insn);
+ memcpy(prog->insns, data,
+ prog->insns_cnt * sizeof(struct bpf_insn));
+ prog->idx = idx;
+
+ return 0;
+errout:
+ bpf_program__clear(prog);
+ return -ENOMEM;
+}
+
+static struct bpf_program *
+bpf_program__new(struct bpf_object *obj, void *data, size_t size,
+char *name, int idx)
This, as well, is not a 'bpf_program' method, it is a 'struct
bpf_object' one, that will manipulate 'struct bpf_object' internal
state, changing its struct members to get space for an extra bpf_program
that was initialized on the stack, if the initialization of such
bpf_program went well, or bail out otherwise.
So I suggest you rename this to:
int bpf_object__add_program(struct bpf_object *obj, void *data, size_t size,
char *name, int idx)
And probably move that debug that uses prog->section_name to just after
the realloc, here in this function.
I will look at the other patches after lunch, thanks for providing the
git tree, I will try and use it before looking at the patches
individually, to get a feel of the whole thing.
I didn't find your code, so I updated my git tree. Please
Re: [PATCH 1/2] power: reset: at91: add sama5d3 reset function
On Fri, Jul 10, 2015 at 09:59:53AM +0800, Josh Wu wrote: > Hi, Guenter > > On 7/10/2015 1:37 AM, Guenter Roeck wrote: > >On Thu, Jul 09, 2015 at 06:15:46PM +0800, Josh Wu wrote: > >>As since sama5d3, to reset the chip, we don't need to shutdown the ddr > >>controller. > >> > >>So add a new compatible string and new restart function for sama5d3 and > >>later chips. As we don't use sama5d3 ddr controller, so remove it as > >>well. > >> > >That sounds like it should be two separate patches, or am I missing > >something ? > > I think using one patch makes more sense. Maybe the commit log is not clear > enough. How about put it this way: > > This patch introduces a new compatible string: "atmel,sama5d3-rstc" for the > reset driver of sama5d3 and later chips. > As in sama5d3 or later chips, we don't have to shutdown the DDR controller > before reset. Shutdown the DDR controller before reset is a workaround to > avoid DDR signal driving the bus, but since sama5d3 and later chips there is > no such a conflict. > That means: > 1. the sama5d3 reset function only need to write the rstc register and > return. > 2. for sama5d3, we can remove the code related with DDR controller as we > don't use it at all. > Sorry, I don't get it. Doesn't that mean there are two distinct logical changes, which would ask for two separate patches ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] power: reset: at91: add sama5d3 reset function
Hi, Maxime
On 7/9/2015 8:03 PM, Maxime Ripard wrote:
Hi,
On Thu, Jul 09, 2015 at 06:15:46PM +0800, Josh Wu wrote:
As since sama5d3, to reset the chip, we don't need to shutdown the ddr
controller.
So add a new compatible string and new restart function for sama5d3 and
later chips. As we don't use sama5d3 ddr controller, so remove it as
well.
Signed-off-by: Josh Wu
Acked-by: Nicolas Ferre
---
drivers/power/reset/at91-reset.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index 36dc52f..8944b63 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
@@ -123,6 +123,14 @@ static int at91sam9g45_restart(struct notifier_block
*this, unsigned long mode,
return NOTIFY_DONE;
}
+static int sama5d3_restart(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ writel(cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PERRST |
AT91_RSTC_PROCRST),
+ at91_rstc_base);
+ return NOTIFY_DONE;
+}
+
static void __init at91_reset_status(struct platform_device *pdev)
{
u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
@@ -155,13 +163,13 @@ static void __init at91_reset_status(struct
platform_device *pdev)
static const struct of_device_id at91_ramc_of_match[] = {
{ .compatible = "atmel,at91sam9260-sdramc", },
{ .compatible = "atmel,at91sam9g45-ddramc", },
- { .compatible = "atmel,sama5d3-ddramc", },
{ /* sentinel */ }
};
static const struct of_device_id at91_reset_of_match[] = {
{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9260_restart },
{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
+ { .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
{ /* sentinel */ }
};
@@ -181,17 +189,21 @@ static int at91_reset_of_probe(struct platform_device *pdev)
return -ENODEV;
}
- for_each_matching_node(np, at91_ramc_of_match) {
- at91_ramc_base[idx] = of_iomap(np, 0);
- if (!at91_ramc_base[idx]) {
- dev_err(>dev, "Could not map ram controller
address\n");
- return -ENODEV;
+ match = of_match_node(at91_reset_of_match, pdev->dev.of_node);
+ at91_restart_nb.notifier_call = match->data;
+
+ if (match->data != sama5d3_restart) {
Using of_device_is_compatible seems more appropriate.
Also, why are you changing the order of this loop and the notifier
registration?
I moved this order because I use the match->data to compare whether is
sama5d3_restart. So I need to move this function (of_match_node) up.
Best Regards,
Josh Wu
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail
On Thu, Jul 9, 2015 at 7:30 PM, Wei Yang wrote: > If you could update your for-pci-v4.3-next branch, that would be more > convenient for me to do the test. Just updated that branch, please check it. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On Fri, Jul 10, 2015 at 11:06:24AM +0900, Sergey Senozhatsky wrote:
> On (07/10/15 10:32), Minchan Kim wrote:
> > static struct page *isolate_source_page(struct size_class *class)
> > {
> > struct page *page;
> > + int i;
> > + bool found = false;
> >
>
> why use 'bool found'? just return `page', which will be either NULL
> or !NULL?
It seems my old version which had a bug during test. :(
I will resend with the fix.
Thanks, Sergey!
>
> -ss
>
> > - page = class->fullness_list[ZS_ALMOST_EMPTY];
> > - if (page)
> > - remove_zspage(page, class, ZS_ALMOST_EMPTY);
> > + for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
> > + page = class->fullness_list[i];
> > + if (!page)
> > + continue;
> >
> > - return page;
> > + remove_zspage(page, class, i);
> > + found = true;
> > + break;
> > + }
> > +
> > + return found ? page : NULL;
> > }
>
> -ss
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 36/36] PCI: Don't set flags to 0 when assign resource fail
On Thu, Jul 09, 2015 at 09:20:08AM -0700, Yinghai Lu wrote: >On Wed, Jul 8, 2015 at 11:04 PM, Wei Yang wrote: >> This one is on top of the last one ? or replace the last one? > >should be just before last one. I can't apply this on top of b0b9229 PCI, x86: Add pci=assign_pref_bars to re-allocate pref bars If you could update your for-pci-v4.3-next branch, that would be more convenient for me to do the test. > >Yinghai -- Richard Yang Help you, Help me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
Hi Sergey,
On Fri, Jul 10, 2015 at 10:58:28AM +0900, Sergey Senozhatsky wrote:
> On (07/10/15 10:32), Minchan Kim wrote:
> > There is no reason to prevent select ZS_ALMOST_FULL as migration
> > source if we cannot find source from ZS_ALMOST_EMPTY.
> >
> > With this patch, zs_can_compact will return more exact result.
> >
>
> wouldn't that be too aggresive?
>
> drainig 'only ZS_ALMOST_EMPTY classes' sounds safer than draining
> 'ZS_ALMOST_EMPTY and ZS_ALMOST_FULL clases'. you seemed to be worried
> that compaction can leave no unused objects in classes, which will
> result in zspage allocation happening right after compaction. it looks
> like here the chances to cause zspage allocation are even higher. don't
> you think so?
Good question.
My worry was failure of order-0 page allocation in zram-swap path
when memory presssure is really heavy but I didn't insist to you
from sometime. The reason I changed my mind was
1. It's almost dead system if there is no order-0 page
2. If old might be working well, it's not our design, just luck.
>
> > Signed-off-by: Minchan Kim
> > ---
> > mm/zsmalloc.c | 19 ---
> > 1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 8c78bcb..7bd7dde 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1687,12 +1687,20 @@ static enum fullness_group putback_zspage(struct
> > zs_pool *pool,
> > static struct page *isolate_source_page(struct size_class *class)
> > {
> > struct page *page;
> > + int i;
> > + bool found = false;
> >
> > - page = class->fullness_list[ZS_ALMOST_EMPTY];
> > - if (page)
> > - remove_zspage(page, class, ZS_ALMOST_EMPTY);
> > + for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
> > + page = class->fullness_list[i];
> > + if (!page)
> > + continue;
> >
> > - return page;
> > + remove_zspage(page, class, i);
> > + found = true;
> > + break;
> > + }
> > +
> > + return found ? page : NULL;
> > }
> >
> > /*
> > @@ -1706,9 +1714,6 @@ static unsigned long zs_can_compact(struct size_class
> > *class)
> > {
> > unsigned long obj_wasted;
> >
> > - if (!zs_stat_get(class, CLASS_ALMOST_EMPTY))
> > - return 0;
> > -
>
> well, you asked to add this check like a week or two ago (it's not even
> in -next yet) and now you remove it.
The reason I wanted to check CLASS_ALMOST_EMPTY is to make zs_can_compact exact.
But with this patch, we can achieve it without above.
>
> > obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
> > zs_stat_get(class, OBJ_USED);
> >
>
> -ss
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes
On 10.07.2015 00:43, Bartlomiej Zolnierkiewicz wrote: > Turbo modes should be marked with CPUFREQ_BOOST_FREQ flag in > the frequency table entry. > > Cc: Tomasz Figa > Cc: Michael Turquette > Cc: Javier Martinez Canillas > Cc: Thomas Abraham > Cc: Viresh Kumar > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/cpufreq/cpufreq_opp.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH v2 v2 6/6] x86/entry: Remove do_notify_resume, syscall_trace_leave, and their TIF masks
They are no longer used. Good riddance!
Deleting the TIF_ macros is really nice. It was never clear why
there were so many variants.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 57 --
arch/x86/include/asm/ptrace.h | 1 -
arch/x86/include/asm/signal.h | 1 -
arch/x86/include/asm/thread_info.h | 16 ---
4 files changed, 75 deletions(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index aeaf7d64be0f..994ae1ed6e9d 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -207,37 +207,6 @@ long syscall_trace_enter(struct pt_regs *regs)
return syscall_trace_enter_phase2(regs, arch, phase1_result);
}
-/* Deprecated. */
-void syscall_trace_leave(struct pt_regs *regs)
-{
- bool step;
-
- /*
-* We may come here right after calling schedule_user()
-* or do_notify_resume(), in which case we can be in RCU
-* user mode.
-*/
- user_exit();
-
- audit_syscall_exit(regs);
-
- if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
- trace_sys_exit(regs, regs->ax);
-
- /*
-* If TIF_SYSCALL_EMU is set, we only get here because of
-* TIF_SINGLESTEP (i.e. this is PTRACE_SYSEMU_SINGLESTEP).
-* We already reported this syscall instruction in
-* syscall_trace_enter().
-*/
- step = unlikely(test_thread_flag(TIF_SINGLESTEP)) &&
- !test_thread_flag(TIF_SYSCALL_EMU);
- if (step || test_thread_flag(TIF_SYSCALL_TRACE))
- tracehook_report_syscall_exit(regs, step);
-
- user_enter();
-}
-
static struct thread_info *pt_regs_to_thread_info(struct pt_regs *regs)
{
#ifdef CONFIG_VM86
@@ -398,29 +367,3 @@ __visible void syscall_return_slowpath(struct pt_regs
*regs)
local_irq_disable();
prepare_exit_to_usermode(regs);
}
-
-/*
- * Deprecated notification of userspace execution resumption
- * - triggered by the TIF_WORK_MASK flags
- */
-__visible void
-do_notify_resume(struct pt_regs *regs, void *unused, __u32 thread_info_flags)
-{
- user_exit();
-
- if (thread_info_flags & _TIF_UPROBE)
- uprobe_notify_resume(regs);
-
- /* deal with pending signal delivery */
- if (thread_info_flags & _TIF_SIGPENDING)
- do_signal(regs);
-
- if (thread_info_flags & _TIF_NOTIFY_RESUME) {
- clear_thread_flag(TIF_NOTIFY_RESUME);
- tracehook_notify_resume(regs);
- }
- if (thread_info_flags & _TIF_USER_RETURN_NOTIFY)
- fire_user_return_notifiers();
-
- user_enter();
-}
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 5fabf1362942..6271281f947d 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -88,7 +88,6 @@ extern long syscall_trace_enter_phase2(struct pt_regs *, u32
arch,
unsigned long phase1_result);
extern long syscall_trace_enter(struct pt_regs *);
-extern void syscall_trace_leave(struct pt_regs *);
static inline unsigned long regs_return_value(struct pt_regs *regs)
{
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index b42408bcf6b5..c481be78fcf1 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -31,7 +31,6 @@ typedef sigset_t compat_sigset_t;
#include
#ifndef __ASSEMBLY__
extern void do_signal(struct pt_regs *regs);
-extern void do_notify_resume(struct pt_regs *, void *, __u32);
#define __ARCH_HAS_SA_RESTORER
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 5a60392ce70e..7bd82e365df6 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -142,27 +142,11 @@ struct thread_info {
_TIF_SECCOMP | _TIF_SINGLESTEP | _TIF_SYSCALL_TRACEPOINT | \
_TIF_NOHZ)
-/* work to do in syscall_trace_leave() */
-#define _TIF_WORK_SYSCALL_EXIT \
- (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | _TIF_SINGLESTEP |\
-_TIF_SYSCALL_TRACEPOINT | _TIF_NOHZ)
-
-/* work to do on interrupt/exception return */
-#define _TIF_WORK_MASK \
- (0x & \
-~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT| \
- _TIF_SINGLESTEP|_TIF_SECCOMP|_TIF_SYSCALL_EMU))
-
/* work to do on any return to user space */
#define _TIF_ALLWORK_MASK \
((0x & ~_TIF_SECCOMP) | _TIF_SYSCALL_TRACEPOINT | \
_TIF_NOHZ)
-/* Only used for 64 bit */
-#define _TIF_DO_NOTIFY_MASK\
- (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | \
-_TIF_USER_RETURN_NOTIFY | _TIF_UPROBE)
-
/* flags to check in __switch_to() */
[RFC/PATCH v2 v2 4/6] x86/entry/32: Remove unnecessary asm check for returns to kernel mode
Unless I missed something, 44fbbb3dc687c ("x86: get rid of calling
do_notify_resume() when returning to kernel mode") was unnecessarily
paranoid. It split the exit path into resume_userspace and
resume_kernel, after which it was no longer possible to get to
work_notifysig when returning to kernel mode. The check for kernel
mode in work_notifysig is superfluous. Remove it.
Cc: Al Viro
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_32.S | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index a36d5df6a749..66ff9c4055d7 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -491,10 +491,6 @@ work_notifysig:# deal
with pending signals and
#endif
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
- movbPT_CS(%esp), %bl
- andb$SEGMENT_RPL_MASK, %bl
- cmpb$USER_RPL, %bl
- jb resume_kernel
xorl%edx, %edx
calldo_notify_resume
jmp resume_userspace
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH v2 v2 1/6] x86/selftests, x86/vm86: Improve entry_from_vm86 selftest
The entry_from_vm86 selftest was very weak. Improve it: test more
types of kernel entries from vm86 mode and test them more carefully.
While we're at it, try to improve behavior on non-SEP CPUs. The
old code was buggy because I misunderstood the intended semantics
of #UD in vm86, so I didn't handle a possible signal.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/entry_from_vm86.c | 132 --
1 file changed, 124 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/x86/entry_from_vm86.c
b/tools/testing/selftests/x86/entry_from_vm86.c
index 5c38a187677b..f004b2a09916 100644
--- a/tools/testing/selftests/x86/entry_from_vm86.c
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -28,6 +28,55 @@
static unsigned long load_addr = 0x1;
static int nerrs = 0;
+static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *),
+ int flags)
+{
+ struct sigaction sa;
+ memset(, 0, sizeof(sa));
+ sa.sa_sigaction = handler;
+ sa.sa_flags = SA_SIGINFO | flags;
+ sigemptyset(_mask);
+ if (sigaction(sig, , 0))
+ err(1, "sigaction");
+}
+
+static void clearhandler(int sig)
+{
+ struct sigaction sa;
+ memset(, 0, sizeof(sa));
+ sa.sa_handler = SIG_DFL;
+ sigemptyset(_mask);
+ if (sigaction(sig, , 0))
+ err(1, "sigaction");
+}
+
+static sig_atomic_t got_signal;
+
+static void sighandler(int sig, siginfo_t *info, void *ctx_void)
+{
+ ucontext_t *ctx = (ucontext_t*)ctx_void;
+
+ if (ctx->uc_mcontext.gregs[REG_EFL] & X86_EFLAGS_VM ||
+ (ctx->uc_mcontext.gregs[REG_CS] & 3) != 3) {
+ printf("[FAIL]\tSignal frame should not reflect vm86 mode\n");
+ nerrs++;
+ }
+
+ const char *signame;
+ if (sig == SIGSEGV)
+ signame = "SIGSEGV";
+ else if (sig == SIGILL)
+ signame = "SIGILL";
+ else
+ signame = "unexpected signal";
+
+ printf("[INFO]\t%s: FLAGS = 0x%lx, CS = 0x%hx\n", signame,
+ (unsigned long)ctx->uc_mcontext.gregs[REG_EFL],
+ (unsigned short)ctx->uc_mcontext.gregs[REG_CS]);
+
+ got_signal = 1;
+}
+
asm (
".pushsection .rodata\n\t"
".type vmcode_bound, @object\n\t"
@@ -38,6 +87,14 @@ asm (
"int3\n\t"
"vmcode_sysenter:\n\t"
"sysenter\n\t"
+ "vmcode_syscall:\n\t"
+ "syscall\n\t"
+ "vmcode_sti:\n\t"
+ "sti\n\t"
+ "vmcode_int3:\n\t"
+ "int3\n\t"
+ "vmcode_int80:\n\t"
+ "int $0x80\n\t"
".size vmcode, . - vmcode\n\t"
"end_vmcode:\n\t"
".code32\n\t"
@@ -45,9 +102,11 @@ asm (
);
extern unsigned char vmcode[], end_vmcode[];
-extern unsigned char vmcode_bound[], vmcode_sysenter[];
+extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[],
+ vmcode_sti[], vmcode_int3[], vmcode_int80[];
static void do_test(struct vm86plus_struct *v86, unsigned long eip,
+ unsigned int rettype, unsigned int retarg,
const char *text)
{
long ret;
@@ -73,13 +132,28 @@ static void do_test(struct vm86plus_struct *v86, unsigned
long eip,
else
sprintf(trapname, "%d", trapno);
- printf("[OK]\tExited vm86 mode due to #%s\n", trapname);
+ printf("[INFO]\tExited vm86 mode due to #%s\n", trapname);
} else if (VM86_TYPE(ret) == VM86_UNKNOWN) {
- printf("[OK]\tExited vm86 mode due to unhandled GP fault\n");
+ printf("[INFO]\tExited vm86 mode due to unhandled GP fault\n");
+ } else if (VM86_TYPE(ret) == VM86_TRAP) {
+ printf("[INFO]\tExited vm86 mode due to a trap (arg=%ld)\n",
+ VM86_ARG(ret));
+ } else if (VM86_TYPE(ret) == VM86_SIGNAL) {
+ printf("[INFO]\tExited vm86 mode due to a signal\n");
+ } else if (VM86_TYPE(ret) == VM86_STI) {
+ printf("[INFO]\tExited vm86 mode due to STI\n");
} else {
- printf("[OK]\tExited vm86 mode due to type %ld, arg %ld\n",
+ printf("[INFO]\tExited vm86 mode due to type %ld, arg %ld\n",
VM86_TYPE(ret), VM86_ARG(ret));
}
+
+ if (rettype == -1 ||
+ (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) {
+ printf("[OK]\tReturned correctly\n");
+ } else {
+ printf("[FAIL]\tIncorrect return reason\n");
+ nerrs++;
+ }
}
int main(void)
@@ -105,10 +179,52 @@ int main(void)
assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */
/* #BR -- should deliver SIG??? */
- do_test(, vmcode_bound - vmcode, "#BR");
-
- /* SYSENTER -- should cause #GP or #UD depending on CPU */
- do_test(, vmcode_sysenter - vmcode, "SYSENTER");
+ do_test(, vmcode_bound -
[RFC/PATCH v2 v2 5/6] x86/entry/32: Migrate to C exit path and rework vm86 exit hack
This removes the hybrid asm-and-C implementation of exit work.
This patch modifies a giant hack. vm86 used to fiddle with
TIF_NOTIFY_RESUME and fix itself up in the exit asm. The hack was
messy and completely incorrect: it broke vm86 if the syscall slow
path was being used.
Rework the hack. We now forcibly exit vm86 mode on return to
userspace if we're delivering a signal (this is needed to deliver
the signal correctly) or if a new TIF_EXIT_VM86 flag is set. The
TIF_NOTIFY_RESUME hack is changed to use TIF_EXIT_VM86 instead.
This makes prepare_exit_to_usermode a bit slower on CONFIG_VM86=y
kernels. People shouldn't use such kernels if they care about
sanity, security, or performance.
Brian Gerst is planning to further rework vm86 mode to leave pt_regs
where it belongs. That will allow us to revert the
pt_regs_to_thread_info slowdown the stack switching parts of this
code; instead we can just exit normally, as vm86 won't have a
special stack layout any more.
Before this change, the entry_from_vm86 test failed under strace.
Now it passes.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 56 ++-
arch/x86/entry/entry_32.S | 79 ++
arch/x86/include/asm/thread_info.h | 2 +
arch/x86/kernel/vm86_32.c | 6 +--
4 files changed, 69 insertions(+), 74 deletions(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index febc53086a69..aeaf7d64be0f 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -240,10 +240,51 @@ void syscall_trace_leave(struct pt_regs *regs)
static struct thread_info *pt_regs_to_thread_info(struct pt_regs *regs)
{
+#ifdef CONFIG_VM86
+ /*
+* In VM86 mode, pt_regs isn't in a well-defined place on the
+* stack. Skip the optimization entirely.
+*/
+ return current_thread_info();
+#else
unsigned long top_of_stack =
(unsigned long)(regs + 1) + TOP_OF_KERNEL_STACK_PADDING;
return (struct thread_info *)(top_of_stack - THREAD_SIZE);
+#endif
+}
+
+#ifdef CONFIG_VM86
+static void __noreturn exit_vm86_immediately(struct pt_regs *regs)
+{
+ /*
+* VM86 sometimes needs to exit back to normal user mode
+* (unsurprisingly) and its hack of resetting the stack and
+* jumping into the exit asm isn't always usable (also
+* unsurprisingly). Instead, we land in this abomination.
+*
+* While I can't defend this code as being anything other
+* than awful, at least it's more or less self-contained,
+* and it's less awful and much less buggy than the even
+* worse hack it replaces. --Andy
+*/
+ struct pt_regs *regs32;
+
+ clear_tsk_thread_flag(current, TIF_EXIT_VM86);
+ regs32 = save_v86_state((struct kernel_vm86_regs *)regs);
+ local_irq_disable();
+ __asm__ __volatile__(
+ "movl %0,%%esp\n\t"
+ "movl %1,%%ebp\n\t"
+ "jmp resume_userspace"
+ : : "r" (regs32), "r" (current_thread_info()));
+
+ /*
+* We don't get here. Instead we restart
+* prepare_exit_to_usermode via resume_userspace.
+*/
+ unreachable();
}
+#endif
/* Called with IRQs disabled. */
__visible void prepare_exit_to_usermode(struct pt_regs *regs)
@@ -264,12 +305,18 @@ __visible void prepare_exit_to_usermode(struct pt_regs
*regs)
READ_ONCE(pt_regs_to_thread_info(regs)->flags);
if (!(cached_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME |
- _TIF_UPROBE | _TIF_NEED_RESCHED)))
+ _TIF_UPROBE | _TIF_NEED_RESCHED |
+ _TIF_EXIT_VM86)))
break;
/* We have work to do. */
local_irq_enable();
+#ifdef CONFIG_VM86
+ if (cached_flags & _TIF_EXIT_VM86)
+ exit_vm86_immediately(regs);
+#endif
+
if (cached_flags & _TIF_NEED_RESCHED)
schedule();
@@ -277,8 +324,13 @@ __visible void prepare_exit_to_usermode(struct pt_regs
*regs)
uprobe_notify_resume(regs);
/* deal with pending signal delivery */
- if (cached_flags & _TIF_SIGPENDING)
+ if (cached_flags & _TIF_SIGPENDING) {
+#ifdef CONFIG_VM86
+ if (v8086_mode(regs))
+ exit_vm86_immediately(regs);
+#endif
do_signal(regs);
+ }
if (cached_flags & _TIF_NOTIFY_RESUME) {
clear_thread_flag(TIF_NOTIFY_RESUME);
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 66ff9c4055d7..b2909bf8cf70 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -256,14 +256,10 @@ ret_from_intr:
Re: [PATCH v2 1/7] opp: add dev_pm_opp_get_turbo_mode_setting() helper
On 10.07.2015 00:43, Bartlomiej Zolnierkiewicz wrote:
> Add dev_pm_opp_get_turbo_mode_setting() helper for getting turbo
> mode setting for a given opp.
>
> Cc: Tomasz Figa
> Cc: Michael Turquette
> Cc: Javier Martinez Canillas
> Cc: Thomas Abraham
> Cc: Viresh Kumar
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/base/power/opp.c | 31 +++
> include/linux/pm_opp.h | 7 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index e24502a2..6b34b2a 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -287,6 +287,37 @@ unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
> EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
>
> /**
> + * dev_pm_opp_get_turbo_mode_setting() - Gets the turbo setting
> + * @opp: opp for which turbo mode setting has to be returned for
> + *
> + * Return: turbo mode setting corresponding to the opp (true or false)
> + *
> + * Locking: This function must be called under rcu_read_lock(). opp is a rcu
> + * protected pointer. This means that opp which could have been fetched by
> + * opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
> + * under RCU lock. The pointer returned by the opp_find_freq family must be
> + * used in the same section as the usage of this function with the pointer
> + * prior to unlocking with rcu_read_unlock() to maintain the integrity of the
> + * pointer.
> + */
> +bool dev_pm_opp_get_turbo_mode_setting(struct dev_pm_opp *opp)
It is just true or false, so maybe dev_pm_opp_is_turbo_mode()?
Everything else looks good to me.
Best regards,
Krzysztof
> +{
> + struct dev_pm_opp *tmp_opp;
> + bool f = false;
> +
> + opp_rcu_lockdep_assert();
> +
> + tmp_opp = rcu_dereference(opp);
> + if (unlikely(IS_ERR_OR_NULL(tmp_opp)) || !tmp_opp->available)
> + pr_err("%s: Invalid parameters\n", __func__);
> + else
> + f = tmp_opp->turbo;
> +
> + return f;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_turbo_mode_setting);
> +
> +/**
> * dev_pm_opp_get_max_clock_latency() - Get max clock latency in nanoseconds
> * @dev: device for which we do this operation
> *
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index bb52fae..7856baf 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -30,6 +30,8 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp
> *opp);
>
> unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp);
>
> +bool dev_pm_opp_get_turbo_mode_setting(struct dev_pm_opp *opp);
> +
> int dev_pm_opp_get_opp_count(struct device *dev);
> unsigned long dev_pm_opp_get_max_clock_latency(struct device *dev);
>
> @@ -63,6 +65,11 @@ static inline unsigned long dev_pm_opp_get_freq(struct
> dev_pm_opp *opp)
> return 0;
> }
>
> +static inline bool dev_pm_opp_get_turbo_mode_setting(struct dev_pm_opp *opp)
> +{
> + return false;
> +}
> +
> static inline int dev_pm_opp_get_opp_count(struct device *dev)
> {
> return 0;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH v2 v2 2/6] x86/entry/32: Remove 32-bit syscall audit optimizations
The asm audit optimizations are ugly and obfuscate the code too much. Remove them. This will regress performance if syscall auditing is enabled on 32-bit kernels and sysenter is in use. If this becomes a problem, interested parties are encouraged to implement the equivalent of the 64-bit opportunistic sysret optimization. Alternatively, a case could be made that, on 32-bit kernels, a less messy asm audit optimization could be done. 32-bit kernels don't have the complicated partial register saving tricks that 64-bit kernels have, so the sysenter post-syscall path could just call the audit hooks directly. Any reimplementation of this ought to demonstrate that it only calls the audit hook once per syscall, though, which does not currently appear to be true. Someone would have to make the case that doing so would be better than implementing opportunistic sysexit, though. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S | 48 ++- 1 file changed, 2 insertions(+), 46 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 21dc60a60b5f..90f9e7f6c15e 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -45,16 +45,6 @@ #include #include -/* Avoid __ASSEMBLER__'ifying just for this. */ -#include -#define AUDIT_ARCH_I386(EM_386|__AUDIT_ARCH_LE) -#define __AUDIT_ARCH_LE0x4000 - -#ifndef CONFIG_AUDITSYSCALL -# define sysenter_auditsyscall_trace_entry -# define sysexit_audit syscall_exit_work -#endif - .section .entry.text, "ax" /* @@ -339,7 +329,7 @@ sysenter_past_esp: GET_THREAD_INFO(%ebp) testl $_TIF_WORK_SYSCALL_ENTRY, TI_flags(%ebp) - jnz sysenter_audit + jnz syscall_trace_entry sysenter_do_call: cmpl$(NR_syscalls), %eax jae sysenter_badsys @@ -351,7 +341,7 @@ sysenter_after_call: TRACE_IRQS_OFF movlTI_flags(%ebp), %ecx testl $_TIF_ALLWORK_MASK, %ecx - jnz sysexit_audit + jnz syscall_exit_work sysenter_exit: /* if something modifies registers it must also disable sysexit */ movlPT_EIP(%esp), %edx @@ -362,40 +352,6 @@ sysenter_exit: PTGS_TO_GS ENABLE_INTERRUPTS_SYSEXIT -#ifdef CONFIG_AUDITSYSCALL -sysenter_audit: - testl $(_TIF_WORK_SYSCALL_ENTRY & ~_TIF_SYSCALL_AUDIT), TI_flags(%ebp) - jnz syscall_trace_entry - /* movl PT_EAX(%esp), %eax already set, syscall number: 1st arg to audit */ - movlPT_EBX(%esp), %edx /* ebx/a0: 2nd arg to audit */ - /* movl PT_ECX(%esp), %ecx already set, a1: 3nd arg to audit */ - pushl PT_ESI(%esp)/* a3: 5th arg */ - pushl PT_EDX+4(%esp) /* a2: 4th arg */ - call__audit_syscall_entry - popl%ecx/* get that remapped edx off the stack */ - popl%ecx/* get that remapped esi off the stack */ - movlPT_EAX(%esp), %eax /* reload syscall number */ - jmp sysenter_do_call - -sysexit_audit: - testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), %ecx - jnz syscall_exit_work - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_ANY) - movl%eax, %edx /* second arg, syscall return value */ - cmpl$-MAX_ERRNO, %eax /* is it an error ? */ - setbe %al /* 1 if so, 0 if not */ - movzbl %al, %eax/* zero-extend that */ - call__audit_syscall_exit - DISABLE_INTERRUPTS(CLBR_ANY) - TRACE_IRQS_OFF - movlTI_flags(%ebp), %ecx - testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), %ecx - jnz syscall_exit_work - movlPT_EAX(%esp), %eax /* reload syscall return value */ - jmp sysenter_exit -#endif - .pushsection .fixup, "ax" 2: movl$0, PT_FS(%esp) jmp 1b -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH v2 v2 3/6] x86/entry/32: Fix an incorrect comment for work_notifysig_v86
This code path is for returns to user mode only. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 90f9e7f6c15e..a36d5df6a749 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -484,8 +484,7 @@ work_notifysig: # deal with pending signals and #ifdef CONFIG_VM86 testl $X86_EFLAGS_VM, PT_EFLAGS(%esp) movl%esp, %eax - jnz work_notifysig_v86 # returning to kernel-space or - # vm86-space + jnz work_notifysig_v86 # special case for v86 1: #else movl%esp, %eax -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH v2 v2 0/6] x86_32: Migrate to new entry/exit paths
This is a review version of the 32-bit asm-to-C migration. I think it works, but it's not yet well enough tested. I'm a lot more familiar with the 64-bit asm than the 32-bit asm. The vm86 stuff especially needs much more careful testing. Brian, since you're playing with vm86 now, can you take a look? Changes from v1: - Fix some nasty vm86 issues. v1 was a regression. v2 is an improvement over the status quo AFAICT. - Add patch 1, which is probably worthwhile on its own. - Get rid of the temporary ud2 hack. Andy Lutomirski (6): x86/selftests, x86/vm86: Improve entry_from_vm86 selftest x86/entry/32: Remove 32-bit syscall audit optimizations x86/entry/32: Fix an incorrect comment for work_notifysig_v86 x86/entry/32: Remove unnecessary asm check for returns to kernel mode x86/entry/32: Migrate to C exit path and rework vm86 exit hack x86/entry: Remove do_notify_resume, syscall_trace_leave, and their TIF masks arch/x86/entry/common.c | 107 ++--- arch/x86/entry/entry_32.S | 130 +++-- arch/x86/include/asm/ptrace.h | 1 - arch/x86/include/asm/signal.h | 1 - arch/x86/include/asm/thread_info.h| 18 +--- arch/x86/kernel/vm86_32.c | 6 +- tools/testing/selftests/x86/entry_from_vm86.c | 132 -- 7 files changed, 191 insertions(+), 204 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_ringbuffer.h
between commit:
ee412ecc74c4 ("drm/i915: Snapshot seqno of most recently submitted request.")
from the drm-intel-fixes tree and commit:
bccca494f75c ("drm/i915: Remove the now obsolete 'outstanding_lazy_request'")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h
index 4be66f60504d,0ea89ea30182..
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@@ -271,17 -292,6 +292,13 @@@ struct intel_engine_cs
*/
struct list_head request_list;
+ /**
-* Do we have some not yet emitted requests outstanding?
-*/
- struct drm_i915_gem_request *outstanding_lazy_request;
- /**
+ * Seqno of request most recently submitted to request_list.
+ * Used exclusively by hang checker to avoid grabbing lock while
+ * inspecting request list.
+ */
+ u32 last_submitted_seqno;
+
bool gpu_caches_dirty;
wait_queue_head_t irq_queue;
pgp1uceAF8rFo.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
8146ba1637a7 ("drm/i915: Store device pointer in contexts for late tracepoint
usafe")
from the drm-intel-fixes tree and commit:
b1b38278e12b ("drm/i915: add a context parameter to {en, dis}able zero
address mapping")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_drv.h
index 580762001f31,52d07fbd9cc8..
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -826,7 -866,7 +866,8 @@@ struct intel_context
struct kref ref;
int user_handle;
uint8_t remap_slice;
+ struct drm_i915_private *i915;
+ int flags;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
pgpmw5PcIaJP8.pgp
Description: OpenPGP digital signature
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On (07/10/15 10:32), Minchan Kim wrote:
> static struct page *isolate_source_page(struct size_class *class)
> {
> struct page *page;
> + int i;
> + bool found = false;
>
why use 'bool found'? just return `page', which will be either NULL
or !NULL?
-ss
> - page = class->fullness_list[ZS_ALMOST_EMPTY];
> - if (page)
> - remove_zspage(page, class, ZS_ALMOST_EMPTY);
> + for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
> + page = class->fullness_list[i];
> + if (!page)
> + continue;
>
> - return page;
> + remove_zspage(page, class, i);
> + found = true;
> + break;
> + }
> +
> + return found ? page : NULL;
> }
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] power: reset: at91: add sama5d3 reset function
Hi, Guenter
On 7/10/2015 1:37 AM, Guenter Roeck wrote:
On Thu, Jul 09, 2015 at 06:15:46PM +0800, Josh Wu wrote:
As since sama5d3, to reset the chip, we don't need to shutdown the ddr
controller.
So add a new compatible string and new restart function for sama5d3 and
later chips. As we don't use sama5d3 ddr controller, so remove it as
well.
That sounds like it should be two separate patches, or am I missing something ?
I think using one patch makes more sense. Maybe the commit log is not
clear enough. How about put it this way:
This patch introduces a new compatible string: "atmel,sama5d3-rstc" for
the reset driver of sama5d3 and later chips.
As in sama5d3 or later chips, we don't have to shutdown the DDR
controller before reset. Shutdown the DDR controller before reset is a
workaround to avoid DDR signal driving the bus, but since sama5d3 and
later chips there is no such a conflict.
That means:
1. the sama5d3 reset function only need to write the rstc register
and return.
2. for sama5d3, we can remove the code related with DDR controller as
we don't use it at all.
Best Regards,
Josh Wu
Guenter
Signed-off-by: Josh Wu
Acked-by: Nicolas Ferre
---
drivers/power/reset/at91-reset.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/power/reset/at91-reset.c b/drivers/power/reset/at91-reset.c
index 36dc52f..8944b63 100644
--- a/drivers/power/reset/at91-reset.c
+++ b/drivers/power/reset/at91-reset.c
@@ -123,6 +123,14 @@ static int at91sam9g45_restart(struct notifier_block
*this, unsigned long mode,
return NOTIFY_DONE;
}
+static int sama5d3_restart(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ writel(cpu_to_le32(AT91_RSTC_KEY | AT91_RSTC_PERRST |
AT91_RSTC_PROCRST),
+ at91_rstc_base);
+ return NOTIFY_DONE;
+}
+
static void __init at91_reset_status(struct platform_device *pdev)
{
u32 reg = readl(at91_rstc_base + AT91_RSTC_SR);
@@ -155,13 +163,13 @@ static void __init at91_reset_status(struct
platform_device *pdev)
static const struct of_device_id at91_ramc_of_match[] = {
{ .compatible = "atmel,at91sam9260-sdramc", },
{ .compatible = "atmel,at91sam9g45-ddramc", },
- { .compatible = "atmel,sama5d3-ddramc", },
{ /* sentinel */ }
};
static const struct of_device_id at91_reset_of_match[] = {
{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9260_restart },
{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },
+ { .compatible = "atmel,sama5d3-rstc", .data = sama5d3_restart },
{ /* sentinel */ }
};
@@ -181,17 +189,21 @@ static int at91_reset_of_probe(struct platform_device *pdev)
return -ENODEV;
}
- for_each_matching_node(np, at91_ramc_of_match) {
- at91_ramc_base[idx] = of_iomap(np, 0);
- if (!at91_ramc_base[idx]) {
- dev_err(>dev, "Could not map ram controller
address\n");
- return -ENODEV;
+ match = of_match_node(at91_reset_of_match, pdev->dev.of_node);
+ at91_restart_nb.notifier_call = match->data;
+
+ if (match->data != sama5d3_restart) {
+ /* we need to shutdown the ddr controller, so get ramc base */
+ for_each_matching_node(np, at91_ramc_of_match) {
+ at91_ramc_base[idx] = of_iomap(np, 0);
+ if (!at91_ramc_base[idx]) {
+ dev_err(>dev, "Could not map ram controller
address\n");
+ return -ENODEV;
+ }
+ idx++;
}
- idx++;
}
- match = of_match_node(at91_reset_of_match, pdev->dev.of_node);
- at91_restart_nb.notifier_call = match->data;
return register_restart_handler(_restart_nb);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
On (07/10/15 10:32), Minchan Kim wrote:
> There is no reason to prevent select ZS_ALMOST_FULL as migration
> source if we cannot find source from ZS_ALMOST_EMPTY.
>
> With this patch, zs_can_compact will return more exact result.
>
wouldn't that be too aggresive?
drainig 'only ZS_ALMOST_EMPTY classes' sounds safer than draining
'ZS_ALMOST_EMPTY and ZS_ALMOST_FULL clases'. you seemed to be worried
that compaction can leave no unused objects in classes, which will
result in zspage allocation happening right after compaction. it looks
like here the chances to cause zspage allocation are even higher. don't
you think so?
> Signed-off-by: Minchan Kim
> ---
> mm/zsmalloc.c | 19 ---
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 8c78bcb..7bd7dde 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1687,12 +1687,20 @@ static enum fullness_group putback_zspage(struct
> zs_pool *pool,
> static struct page *isolate_source_page(struct size_class *class)
> {
> struct page *page;
> + int i;
> + bool found = false;
>
> - page = class->fullness_list[ZS_ALMOST_EMPTY];
> - if (page)
> - remove_zspage(page, class, ZS_ALMOST_EMPTY);
> + for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
> + page = class->fullness_list[i];
> + if (!page)
> + continue;
>
> - return page;
> + remove_zspage(page, class, i);
> + found = true;
> + break;
> + }
> +
> + return found ? page : NULL;
> }
>
> /*
> @@ -1706,9 +1714,6 @@ static unsigned long zs_can_compact(struct size_class
> *class)
> {
> unsigned long obj_wasted;
>
> - if (!zs_stat_get(class, CLASS_ALMOST_EMPTY))
> - return 0;
> -
well, you asked to add this check like a week or two ago (it's not even
in -next yet) and now you remove it.
> obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
> zs_stat_get(class, OBJ_USED);
>
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to debug watchdog reset problems
On Fri, 2015-07-10 at 01:39 +0530, Ryan wrote: > Could anyone suggest a better way of debugging kernel freeze. If the serial console is locking up on you, you could try netconsole. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v2] asus-rbtn: new driver for asus radio button for Windows 8
On Fri, Jul 10, 2015 at 4:52 AM, Darren Hart wrote: > On Tue, Jul 07, 2015 at 04:25:18PM +0200, Pali Rohár wrote: >> On Monday 06 July 2015 15:43:28 Darren Hart wrote: >> > On Mon, Jul 06, 2015 at 09:35:40AM +0800, Alex Hung wrote: >> > > ATK4001 is an ACPI device for wireless hotkey, similar to how Dell and >> > > HP are doing it. It is just ASUS who decides LED should be controlled >> > > by software unlike HP whose LED is driven by hardware pins on mini >> > > card. >> > >> > Alex, please refrain from top posting on Linux kernel mailing lists, it >> > breaks >> > the established practice the readers are setup for. >> > >> > Regarding the ATK4001 device, it did sound like it did more than control >> > the >> > radios and the associcated LED. If that is all it does, then asus-rbtn is >> > fine. >> > If it does something beyond that, we need understand what that is, as a >> > more >> > platform-centric name would be more appropriate. >> > >> > Thanks, >> >> Yes, I understand too that ATK4001 device has more functions as one for >> LED control. And in this case it is not good to use name from one >> specific functionality. >> >> And about name: >> >> I chose name rbtn for dell driver because ACPI device in DSDT table is >> named RBTN and acpi id is DELRBTN. >> >> I think that acpi-rbtn.c (radio button) is not ideal name for driver >> which at SW level controls LED device associated with wireless devices. >> >> I would rather follow acpi device name, but in this case ATK4001 is even >> worse name which does not say anything... >> >> Maybe better name could be asus-wireless? Still I do not have any good >> name, so choose something... > > I suggested rbtn to try and start showing some kind of consistency in the > directory - however, it's no better than many of the other existing options, > including -rfkill -wireless -laptop, etc. > > Speaking of -laptop, the asus-laptop driver supports ATK0100 and ATK0101. This > ATK4001 device appears to perform the same type of features. The question is > whether or not it can be reasonably incorporated into the existing asus-laptop > driver or not. > > (I intended to do that review myself, but I haven't found the time in 48 > hours, > so I'm just going to send this out and ask that Alex have a look and provide > his > thoughts on asus-laptop) > > -- > Darren Hart > Intel Open Source Technology Center Certainly, I should have time to look into asus-laptop next week. -- Cheers, Alex Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC Patch V1 00/12] Reorganize struct msi_desc to prepare for support of generic MSI
On 2015/7/9 16:00, Jiang Liu wrote: > Recently Marc Zyngier has posted a patch set at > https://lkml.org/lkml/2015/7/7/712 > to enhance PCI MSI code to support generic MSI. > > This is a companion patch set to refine struct msi_desc and related data > structures to support generic MSI, and it would be better to combined with > Marc's patch set. It's also requested by > Stuart Yoder > > It first introduces a helper function msi_desc_to_pci_sysdata(), and > convert current PCI drivers to use helper functions to access fields > in struct msi_desc. > Then it moves msi_list from struct pci_dev into struct device and > refines struct msi_desc. > At last it moves alloc_msi_entry() into kernel/irq/msi.c for reuse. > > Currently msi_desc_to_pci_sysdata() and msi_desc_to_pci_dev() are > implemented as normal functions instead of inlines to avoid header file > inclusion issue. If inlined version is preferred for performance, we could > move all of first_pci_msi_entry, for_each_pci_msi_entry, msi_desc_to_pci_dev > and msi_desc_to_pci_sysdata from linxu/kernel/msi.h into linux/kernel/pci.h. > > This patch set is based on v4.2-rc1 and passes 0day test suite. You > may access the code at: > https://github.com/jiangliu/linux.git msi_desc_v1 > > Thanks! > Gerry > > Jiang Liu (12): > PCI: Add helper function msi_desc_to_pci_sysdata() > MIPS, PCI: Use for_pci_msi_entry() to access MSI device list > PowerPC, PCI: Use for_pci_msi_entry() to access MSI device list > s390/pci: Use for_pci_msi_entry() to access MSI device list > x86, PCI: Use for_pci_msi_entry() to access MSI device list > PCI: Use for_pci_msi_entry() to access MSI device list > sparc, PCI: Use helper functions to access fields in struct msi_desc > PCI: Use helper functions to access fields in struct msi_desc > genirq: Move msi_list from struct pci_dev to struct device > genirq, PCI: Store 'struct device *' instead 'struct pci_dev *' in > struct msi_desc > genirq, PCI: Reorginize struct msi_desc to prepare for support of > generic MSI > genirq, PCI: Move alloc_msi_entry() from PCI MSI code into generic > MSI code Great, it loos good to me, for patch 1,6,8,9,10,11,12, Reviewed-by: Yijing Wang > > arch/mips/pci/msi-octeon.c |2 +- > arch/powerpc/platforms/cell/axon_msi.c |6 +-- > arch/powerpc/platforms/pasemi/msi.c|4 +- > arch/powerpc/platforms/powernv/pci.c |4 +- > arch/powerpc/platforms/pseries/msi.c |6 +-- > arch/powerpc/sysdev/fsl_msi.c |4 +- > arch/powerpc/sysdev/mpic_u3msi.c |4 +- > arch/powerpc/sysdev/ppc4xx_hsta_msi.c |4 +- > arch/powerpc/sysdev/ppc4xx_msi.c |4 +- > arch/s390/pci/pci.c|6 +-- > arch/sparc/kernel/pci.c|2 +- > arch/x86/pci/xen.c |8 ++-- > drivers/base/core.c|3 ++ > drivers/pci/host/pci-keystone-dw.c |6 +-- > drivers/pci/host/pcie-designware.c |4 +- > drivers/pci/host/pcie-xilinx.c | 12 ++--- > drivers/pci/msi.c | 82 > +--- > drivers/pci/xen-pcifront.c |2 +- > include/linux/device.h |4 ++ > include/linux/msi.h| 55 +++-- > include/linux/pci.h|1 - > kernel/irq/msi.c | 17 +++ > 22 files changed, 136 insertions(+), 104 deletions(-) > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] dma: rename dma_*_writecombine() to dma_*_wc()
From: "Luis R. Rodriguez"
Rename dma_*_writecombine() to dma_*_wc(), so that the naming
is coherent across the various write-combining APIs.
The following Coccinelle SmPL patch was used for this simple
transformation:
@ rename_dma_alloc_writecombine @
expression dev, size, dma_addr, gfp;
@@
-dma_alloc_writecombine(dev, size, dma_addr, gfp)
+dma_alloc_wc(dev, size, dma_addr, gfp)
@ rename_dma_free_writecombine @
expression dev, size, cpu_addr, dma_addr;
@@
-dma_free_writecombine(dev, size, cpu_addr, dma_addr)
+dma_free_wc(dev, size, cpu_addr, dma_addr)
@ rename_dma_mmap_writecombine @
expression dev, vma, cpu_addr, dma_addr, size;
@@
-dma_mmap_writecombine(dev, vma, cpu_addr, dma_addr, size)
+dma_mmap_wc(dev, vma, cpu_addr, dma_addr, size)
Generated-by: Coccinelle SmPL
Suggested-by: Ingo Molnar
Signed-off-by: Luis R. Rodriguez
---
arch/arm/mach-lpc32xx/phy3250.c | 13 ++---
arch/arm/mach-netx/fb.c | 14 ++
arch/arm/mach-nspire/clcd.c | 13 ++---
arch/avr32/include/asm/dma-mapping.h | 20 ++--
arch/avr32/mm/dma-coherent.c | 12 ++--
arch/metag/include/asm/dma-mapping.h | 4 ++--
arch/metag/kernel/dma.c | 6 +++---
drivers/dma/iop-adma.c| 8
drivers/dma/mv_xor.c | 4 ++--
drivers/dma/qcom_bam_dma.c| 14 +++---
drivers/gpu/drm/drm_gem_cma_helper.c | 13 ++---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 13 ++---
drivers/gpu/drm/omapdrm/omap_gem.c| 8
drivers/gpu/drm/sti/sti_cursor.c | 20
drivers/gpu/drm/sti/sti_gdp.c | 3 +--
drivers/gpu/drm/sti/sti_hqvdp.c | 6 +++---
drivers/gpu/drm/tegra/gem.c | 11 +--
drivers/gpu/host1x/cdma.c | 8
drivers/gpu/host1x/job.c | 10 --
drivers/media/platform/coda/coda-bit.c| 10 +-
drivers/video/fbdev/acornfb.c | 4 ++--
drivers/video/fbdev/amba-clcd-versatile.c | 14 ++
drivers/video/fbdev/amba-clcd.c | 4 ++--
drivers/video/fbdev/atmel_lcdfb.c | 9 +
drivers/video/fbdev/ep93xx-fb.c | 8 +++-
drivers/video/fbdev/gbefb.c | 8
drivers/video/fbdev/imxfb.c | 12 ++--
drivers/video/fbdev/mx3fb.c | 9 -
drivers/video/fbdev/nuc900fb.c| 8
drivers/video/fbdev/omap/lcdc.c | 16
drivers/video/fbdev/pxa168fb.c| 8
drivers/video/fbdev/pxafb.c | 4 ++--
drivers/video/fbdev/s3c-fb.c | 7 +++
drivers/video/fbdev/s3c2410fb.c | 8
drivers/video/fbdev/sa1100fb.c| 8
include/linux/dma-mapping.h | 16
sound/arm/pxa2xx-pcm-lib.c| 20
sound/soc/fsl/imx-pcm-fiq.c | 10 --
sound/soc/nuc900/nuc900-pcm.c | 6 ++
sound/soc/omap/omap-pcm.c | 12
40 files changed, 185 insertions(+), 216 deletions(-)
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index 7858d5b6f6ce..43ff56c2a7a9 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -86,8 +86,8 @@ static int lpc32xx_clcd_setup(struct clcd_fb *fb)
{
dma_addr_t dma;
- fb->fb.screen_base = dma_alloc_writecombine(>dev->dev,
- PANEL_SIZE, , GFP_KERNEL);
+ fb->fb.screen_base = dma_alloc_wc(>dev->dev, PANEL_SIZE, ,
+ GFP_KERNEL);
if (!fb->fb.screen_base) {
printk(KERN_ERR "CLCD: unable to map framebuffer\n");
return -ENOMEM;
@@ -116,15 +116,14 @@ static int lpc32xx_clcd_setup(struct clcd_fb *fb)
static int lpc32xx_clcd_mmap(struct clcd_fb *fb, struct vm_area_struct *vma)
{
- return dma_mmap_writecombine(>dev->dev, vma,
- fb->fb.screen_base, fb->fb.fix.smem_start,
- fb->fb.fix.smem_len);
+ return dma_mmap_wc(>dev->dev, vma, fb->fb.screen_base,
+ fb->fb.fix.smem_start, fb->fb.fix.smem_len);
}
static void lpc32xx_clcd_remove(struct clcd_fb *fb)
{
- dma_free_writecombine(>dev->dev, fb->fb.fix.smem_len,
- fb->fb.screen_base, fb->fb.fix.smem_start);
+ dma_free_wc(>dev->dev, fb->fb.fix.smem_len, fb->fb.screen_base,
+ fb->fb.fix.smem_start);
}
/*
diff --git a/arch/arm/mach-netx/fb.c b/arch/arm/mach-netx/fb.c
index d122ee6ab991..8814ee5e98fd 100644
--- a/arch/arm/mach-netx/fb.c
+++ b/arch/arm/mach-netx/fb.c
@@ -42,8 +42,8 @@ int netx_clcd_setup(struct clcd_fb *fb)
fb->panel = netx_panel;
- fb->fb.screen_base = dma_alloc_writecombine(>dev->dev,
[PATCH v2 1/2] drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
From: "Luis R. Rodriguez"
dma_alloc_writecombine()'s call and return value check is tangled in all
in one call. Untangle both calls according to kernel coding style.
Signed-off-by: Luis R. Rodriguez
Cc: Dan Williams
Cc: dmaeng...@vger.kernel.org
Cc: Vinod Koul
Cc: x...@kernel.org
Link:
http://lkml.kernel.org/r/1435258191-543-2-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/dma/iop-adma.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 998826854fdd..e4f43125e0fb 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -1300,10 +1300,11 @@ static int iop_adma_probe(struct platform_device *pdev)
* note: writecombine gives slightly better performance, but
* requires that we explicitly flush the writes
*/
- if ((adev->dma_desc_pool_virt = dma_alloc_writecombine(>dev,
- plat_data->pool_size,
- >dma_desc_pool,
- GFP_KERNEL)) == NULL) {
+ adev->dma_desc_pool_virt = dma_alloc_writecombine(>dev,
+ plat_data->pool_size,
+ >dma_desc_pool,
+ GFP_KERNEL);
+ if (!adev->dma_desc_pool_virt) {
ret = -ENOMEM;
goto err_free_adev;
}
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] dma: rename write-combine APIs with short form
From: "Luis R. Rodriguez" Ingo, You had asked for this to be kept in my tree until the end of the merge window. I sent it a bit earlier than the end of the merge window, it failed to apply to Boris' tree as my series was based on linux-next and then I went on a small vacation. Boris is now on vacation as well. I've respinned this series today -- and fortunatley both of the patches in this series apply to both Linus' tree and linux-next, I am in hopes it applies to any other tree as well without conflicts. If not it should be easy to respin with the Coccinelle SmPL rule defined. I'll note that there are a few outstanding series related to MTRR, but those do not have conflicts with these patches at all so feel free to consider these before or after. Also I tried to get an ack for the first patch [1] but that has gone under the radar I believe so merging it now as part of this series and Cc'ing the maintainers. That change is needed in order to make the code match the grammar used by Coccinelle used in the expressed transformation. [0] http://lkml.kernel.org/r/20150601085332.ga14...@gmail.com [1] http://lkml.kernel.org/r/1434483609-25498-1-git-send-email-mcg...@do-not-panic.com Luis R. Rodriguez (2): drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style dma: rename dma_*_writecombine() to dma_*_wc() arch/arm/mach-lpc32xx/phy3250.c | 13 ++--- arch/arm/mach-netx/fb.c | 14 ++ arch/arm/mach-nspire/clcd.c | 13 ++--- arch/avr32/include/asm/dma-mapping.h | 20 ++-- arch/avr32/mm/dma-coherent.c | 12 ++-- arch/metag/include/asm/dma-mapping.h | 4 ++-- arch/metag/kernel/dma.c | 6 +++--- drivers/dma/iop-adma.c| 9 + drivers/dma/mv_xor.c | 4 ++-- drivers/dma/qcom_bam_dma.c| 14 +++--- drivers/gpu/drm/drm_gem_cma_helper.c | 13 ++--- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 13 ++--- drivers/gpu/drm/omapdrm/omap_gem.c| 8 drivers/gpu/drm/sti/sti_cursor.c | 20 drivers/gpu/drm/sti/sti_gdp.c | 3 +-- drivers/gpu/drm/sti/sti_hqvdp.c | 6 +++--- drivers/gpu/drm/tegra/gem.c | 11 +-- drivers/gpu/host1x/cdma.c | 8 drivers/gpu/host1x/job.c | 10 -- drivers/media/platform/coda/coda-bit.c| 10 +- drivers/video/fbdev/acornfb.c | 4 ++-- drivers/video/fbdev/amba-clcd-versatile.c | 14 ++ drivers/video/fbdev/amba-clcd.c | 4 ++-- drivers/video/fbdev/atmel_lcdfb.c | 9 + drivers/video/fbdev/ep93xx-fb.c | 8 +++- drivers/video/fbdev/gbefb.c | 8 drivers/video/fbdev/imxfb.c | 12 ++-- drivers/video/fbdev/mx3fb.c | 9 - drivers/video/fbdev/nuc900fb.c| 8 drivers/video/fbdev/omap/lcdc.c | 16 drivers/video/fbdev/pxa168fb.c| 8 drivers/video/fbdev/pxafb.c | 4 ++-- drivers/video/fbdev/s3c-fb.c | 7 +++ drivers/video/fbdev/s3c2410fb.c | 8 drivers/video/fbdev/sa1100fb.c| 8 include/linux/dma-mapping.h | 16 sound/arm/pxa2xx-pcm-lib.c| 20 sound/soc/fsl/imx-pcm-fiq.c | 10 -- sound/soc/nuc900/nuc900-pcm.c | 6 ++ sound/soc/omap/omap-pcm.c | 12 40 files changed, 186 insertions(+), 216 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 4/4] drivers/video/fbdev/atyfb: Use arch_phys_wc_add() and ioremap_wc()
From: "Luis R. Rodriguez"
This driver uses strong UC for the MMIO region, and ioremap_wc() for the
framebuffer to whitelist for the WC MTRR that can be changed to WC. On
PAT systems we don't need the MTRR call so just use arch_phys_wc_add()
there, this lets us remove all those ifdefs. Let's also be consistent
and use ioremap_wc() for ATARI as well.
There are a few motivations for this:
a) Take advantage of PAT when available.
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 it is being replaced by PAT.
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()").
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the ifdeffery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message about
when MTRR fails and doing nothing when we didn't get an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Signed-off-by: Luis R. Rodriguez
Cc: airl...@redhat.com
Cc: Andrew Morton
Cc: Andrzej Hajda
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: b...@kernel.crashing.org
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mathias Krause
Cc: Mel Gorman
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Link:
http://lkml.kernel.org/r/1435196060-27350-4-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/aty/atyfb.h | 4 +---
drivers/video/fbdev/aty/atyfb_base.c | 36 +++-
2 files changed, 8 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 89ec4398d201..63c4842eb224 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -182,9 +182,7 @@ struct atyfb_par {
unsigned long irq_flags;
unsigned int irq;
spinlock_t int_lock;
-#ifdef CONFIG_MTRR
- int mtrr_aper;
-#endif
+ int wc_cookie;
u32 mem_cntl;
struct crtc saved_crtc;
union aty_pll saved_pll;
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index ea27ba3e5e6d..a807c0196464 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -98,9 +98,6 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include
#endif
-#ifdef CONFIG_MTRR
-#include
-#endif
/*
* Debug flags.
@@ -303,9 +300,7 @@ static struct fb_ops atyfb_ops = {
};
static bool noaccel;
-#ifdef CONFIG_MTRR
static bool nomtrr;
-#endif
static int vram;
static int pll;
static int mclk;
@@ -2628,17 +2623,13 @@ static int aty_init(struct fb_info *info)
aty_st_le32(BUS_CNTL, aty_ld_le32(BUS_CNTL, par) |
BUS_APER_REG_DIS, par);
-#ifdef CONFIG_MTRR
- par->mtrr_aper = -1;
- if (!nomtrr) {
+ if (!nomtrr)
/*
* Only the ioremap_wc()'d area will get WC here
* since ioremap_uc() was used on the entire PCI BAR.
*/
- par->mtrr_aper = mtrr_add(par->res_start, par->res_size,
- MTRR_TYPE_WRCOMB, 1);
- }
-#endif
+ par->wc_cookie = arch_phys_wc_add(par->res_start,
+ par->res_size);
info->fbops = _ops;
info->pseudo_palette = par->pseudo_palette;
@@ -2766,13 +2757,8 @@ aty_init_exit:
/* restore video mode */
aty_set_crtc(par, >saved_crtc);
par->pll_ops->set_pll(info, >saved_pll);
+
Re: [RFC/PATCH 5/7] x86/vm86: Teach handle_vm86_trap to return to 32bit mode directly
On Thu, Jul 9, 2015 at 3:41 PM, Andy Lutomirski wrote: > On Wed, Jul 8, 2015 at 12:24 PM, Andy Lutomirski wrote: >> The TIF_NOTIFY_RESUME hack it was using was buggy and unsupportable. >> vm86 mode was completely broken under ptrace, for example, because >> we'd never make it to v8086 mode. >> >> This code is still a huge, scary mess, but at least it's no longer >> tangled with the exit-to-userspace loop. > > This patch is incorrect. Brian, what's the ETA for your vm86 cleanup? > If it's very soon, then I'll see if I can rely on it. If not, I'll > have to come up with a way to fix this patch. > > Grr. The kernel state when handle_vm86_trap is called is absurd right > now. Somehow we're supposed to survive do_trap, send a signal > corresponding to the outside-vm86 state, and exit vm86 cleanly (with > ax = 0), all before returning to user mode. I doubt these semantics > are even intentional. > > This code sucks. OK, I have a version that seems to work. It comes with a much better selftest, too. I'll send it shortly. Brian, would it make sense to base your work on top of it? Now that I've looked at this stuff, if I were designing Linux support for v8086 mode, I'd do it very differently. There wouldn't be a vm86 syscall at all. Instead you'd call sigaltstack, then raise a signal, set X86_EFLAGS_VM, and return. The kernel would handle X86_EFLAGS_VM being set by setting TIF_V8086 and adjusting sp0. On entry, TIF_V8086 would move the segment registers from the hardware frame into pt_regs and, on exit, TIF_V8086 would move them back. Clearing X86_EFLAGS_VM (via ptrace, signal delivery, or sigreturn) would sanitize the segment registers. SYSENTER would be safe, so the SYSENTER_CS hack wouldn't be needed. Of course, we'd lose the CPU state, so the user would have to be careful. And that's it. There wouldn't be any emulation -- user code could emulate syscalls all by itself in a signal handler. Exiting v8086 mode would be straightforward -- just do anything that would raise a signal. Of course, this isn't at all ABI-compatible with the current turd, and v8086 mode isn't really that useful, so this is just idle retroactive speculation. But the TIF_V8086 trick would still be useful to let us get rid of all the awful hacks in the trap and exit code. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/4] drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC
From: "Luis R. Rodriguez"
Replace a WC MTRR call followed by a UC MTRR "hole" call with a single
WC MTRR call and use strong UC to protect the MMIO region and account
for the device's architecture and MTRR size requirements.
The atyfb driver relies on two overlapping MTRRs. It does this to
account for the fact that, on some devices, it has the MMIO region
bundled together with the framebuffer on the same PCI BAR and the
hardware requirement on MTRRs on both base and size to be powers
of two.
In the worst case, the PCI BAR is of 16 MiB while the MMIO region is on
the last 4 KiB of the same PCI BAR. If we use just one MTRR for WC, we
can only end up with an 8 MiB or 16 MiB framebuffer. Using a 16 MiB WC
framebuffer area is unacceptable since we need the MMIO region to not be
write-combined. An 8 MiB WC framebuffer option does not let use quite a
bit of framebuffer space, it would reduce the resolution capability of
the device considerably.
An alternative is to use many MTRRs but on some systems that could mean
not having enough MTRRs to cover the framebuffer. The current solution
is to issue a 16 MiB WC MTRR followed by a 4 KiB UC MTRR on the last 4
KiB. Its worth mentioning and documenting that the current ioremap*()
strategy as well: the first ioremap() is used only for the MMIO region,
a second ioremap() call is used for the framebuffer *and* the MMIO
region, the MMIO region then ends up mmapped twice.
Two ioremap() calls are used since in some situations the framebuffer
actually ends up on a separate auxiliary PCI BAR, but this is not always
true. In the worst case, the PCI BAR is shared for both MMIO and the
framebuffer. By allowing overlapping ioremap() calls, the driver enables
two types of devices with one simple ioremap() strategy.
See also:
2f9e897353fc ("x86/mm/mtrr, pat: Document Write Combining MTRR type effects
on PAT / non-PAT pages")
By default, Linux today defaults both pci_mmap_page_range() and
ioremap_nocache() to use _PAGE_CACHE_MODE_UC_MINUS. On x86, ioremap()
aliases ioremap_nocache(). The preferred value for Linux may soon
change, however, the goal is to use _PAGE_CACHE_MODE_UC by default in
the future.
We can use ioremap_uc() to set PCD=1, PWT=1 on non-PAT systems and use
a PAT value of UC for PAT systems. This will ensure the same settings
are in place regardless of what Linux decides to use by default later
and to not regress our MTRR strategy since the effective memory type
will differ depending on the value used. Using a WC MTRR on such an area
will be nullified. This technique can be used to protect the MMIO region
in this driver's case and address the restrictions of the device's
architecture as well as restrictions set upon us by powers of 2 when
using MTRRs.
This allows us to replace the two MTRR calls with a single 16 MiB WC
MTRR and use page-attribute settings for non-PAT and PAT entry values
for PAT systems to ensure the appropriate effective memory type won't
have a write-combining effect on the MMIO region on both non-PAT and PAT
systems. The framebuffer area will be sure to get the write-combined
effective memory type by white-listing it with ioremap_wc().
We ensure the desired effective memory types are set by:
0) Using one ioremap_uc() for the MMIO region alone.
This will set the page attribute settings for the MMIO
region to PCD=1, PWT=1 for non-PAT systems while using a
strong UC value on PAT systems.
1) Fixing the framebuffer ioremapped area to exclude the
MMIO region and using ioremap_wc() instead to whitelist
the area we want for write-combining.
In both cases, an implementation defined (as per 2f9e897353fc) effective
memory type of WC is used for the framebuffer for non-PAT systems.
Signed-off-by: Luis R. Rodriguez
Cc: airl...@redhat.com
Cc: Andrew Morton
Cc: Andrzej Hajda
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: b...@kernel.crashing.org
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mathias Krause
Cc: Mel Gorman
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Link:
http://lkml.kernel.org/r/1435196060-27350-3-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/aty/atyfb.h | 1 -
drivers/video/fbdev/aty/atyfb_base.c | 36 ++--
2 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 1f39a62f899b..89ec4398d201 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -184,7 +184,6 @@ struct atyfb_par {
spinlock_t int_lock;
#ifdef CONFIG_MTRR
int mtrr_aper;
- int mtrr_reg;
#endif
u32 mem_cntl;
struct crtc
[PATCH] zsmalloc: consider ZS_ALMOST_FULL as migrate source
There is no reason to prevent select ZS_ALMOST_FULL as migration
source if we cannot find source from ZS_ALMOST_EMPTY.
With this patch, zs_can_compact will return more exact result.
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 8c78bcb..7bd7dde 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1687,12 +1687,20 @@ static enum fullness_group putback_zspage(struct
zs_pool *pool,
static struct page *isolate_source_page(struct size_class *class)
{
struct page *page;
+ int i;
+ bool found = false;
- page = class->fullness_list[ZS_ALMOST_EMPTY];
- if (page)
- remove_zspage(page, class, ZS_ALMOST_EMPTY);
+ for (i = ZS_ALMOST_EMPTY; i >= ZS_ALMOST_FULL; i--) {
+ page = class->fullness_list[i];
+ if (!page)
+ continue;
- return page;
+ remove_zspage(page, class, i);
+ found = true;
+ break;
+ }
+
+ return found ? page : NULL;
}
/*
@@ -1706,9 +1714,6 @@ static unsigned long zs_can_compact(struct size_class
*class)
{
unsigned long obj_wasted;
- if (!zs_stat_get(class, CLASS_ALMOST_EMPTY))
- return 0;
-
obj_wasted = zs_stat_get(class, OBJ_ALLOCATED) -
zs_stat_get(class, OBJ_USED);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/4] drivers/video/fbdev/atyfb: Clarify ioremap() base and length used
From: "Luis R. Rodriguez"
Adjust the ioremap() call for the framebuffer to use the same values we
later use for the framebuffer. This will make it easier to review the
next change.
The size of the framebuffer varies but since this is for PCI we *know*
this defaults to 0x80. atyfb_setup_generic() is *only* used on PCI
probe.
No functional change.
Signed-off-by: Luis R. Rodriguez
Cc: airl...@redhat.com
Cc: Andrew Morton
Cc: Andrzej Hajda
Cc: Andy Lutomirski
Cc: Antonino Daplas
Cc: b...@kernel.crashing.org
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Davidlohr Bueso
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Jean-Christophe Plagniol-Villard
Cc: Juergen Gross
Cc: Linus Torvalds
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mathias Krause
Cc: Mel Gorman
Cc: m...@redhat.com
Cc: Rob Clark
Cc: Suresh Siddha
Cc: syrj...@sci.fi
Cc: Thomas Gleixner
Cc: Tomi Valkeinen
Cc: Toshi Kani
Cc: Ville Syrjälä
Cc: Vlastimil Babka
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/aty/atyfb_base.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 16936bb1f865..513e58df9d3f 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3489,7 +3489,21 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
/* Map in frame buffer */
info->fix.smem_start = addr;
- info->screen_base = ioremap(addr, 0x80);
+
+ /*
+* The framebuffer is not always 8 MiB that's just the size of the
+* PCI BAR. We temporarily abuse smem_len here to store the size
+* of the BAR. aty_init() will later correct it to match the actual
+* framebuffer size.
+*
+* On devices that don't have the auxiliary register aperture, the
+* registers are housed at the top end of the framebuffer PCI BAR.
+* aty_fudge_framebuffer_len() is used to reduce smem_len to not
+* overlap with the registers.
+*/
+ info->fix.smem_len = 0x80;
+
+ info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
if (info->screen_base == NULL) {
ret = -ENOMEM;
goto atyfb_setup_generic_fail;
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cxl: Destroy afu->contexts_idr on release of an afu
Acked-by: Ian Munsie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/4] drivers/video/fbdev/atyfb: Carve out framebuffer length fudging into a helper
From: "Luis R. Rodriguez"
The size of the framebuffer to be used needs to be fudged to account for
the different type of devices that are out there. This captures what is
required to do well, we'll reuse this later.
This has no functional changes.
Signed-off-by: Luis R. Rodriguez
Cc: H. Peter Anvin
Cc: Jean-Christophe Plagniol-Villard
Cc: Mathias Krause
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1435251019-32421-1-git-send-email-mcg...@do-not-panic.com
Signed-off-by: Borislav Petkov
---
drivers/video/fbdev/aty/atyfb_base.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8789e487b96e..16936bb1f865 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -427,6 +427,20 @@ static struct {
#endif /* CONFIG_FB_ATY_CT */
};
+/*
+ * Last page of 8 MB (4 MB on ISA) aperture is MMIO,
+ * unless the auxiliary register aperture is used.
+ */
+static void aty_fudge_framebuffer_len(struct fb_info *info)
+{
+ struct atyfb_par *par = (struct atyfb_par *) info->par;
+
+ if (!par->aux_start &&
+ (info->fix.smem_len == 0x80 ||
+(par->bus_type == ISA && info->fix.smem_len == 0x40)))
+ info->fix.smem_len -= GUI_RESERVE;
+}
+
static int correct_chipset(struct atyfb_par *par)
{
u8 rev;
@@ -2603,14 +2617,7 @@ static int aty_init(struct fb_info *info)
if (par->pll_ops->resume_pll)
par->pll_ops->resume_pll(info, >pll);
- /*
-* Last page of 8 MB (4 MB on ISA) aperture is MMIO,
-* unless the auxiliary register aperture is used.
-*/
- if (!par->aux_start &&
- (info->fix.smem_len == 0x80 ||
-(par->bus_type == ISA && info->fix.smem_len == 0x40)))
- info->fix.smem_len -= GUI_RESERVE;
+ aty_fudge_framebuffer_len(info);
/*
* Disable register access through the linear aperture
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/4] atyfb: atyfb: address MTRR corner case
From: "Luis R. Rodriguez" Ingo, Boris is on vacation so sending these through you. This v6 addresses one code comment update requested by Ville. Boris had picked up these patches on his tree and this series had gone through 0-day bot testing. The only issue it found was the lack of ioremap_uc() implementation on some architectures which have an IOMMU. There are two approaches to this issue, one is to go and define ioremap_uc() on all architectures, another is to provide a default for ioremap_uc() as architectures catch up. I've gone with the later approach [0], and so to ensure things won't build-break this patch series must also go through the same tree as the patch-fixes for ioremap_uc() for missing ioremap_uc() implementations go through. I intend on following up with implementing ioremap_uc() for other architectures but for that I need to get feedback from other architecture developers and that will take time. Tomi, the framebuffer maintainer had already expressed he was OK for this to go through you. The driver maintainer, Ville, has been Cc'd on all the series, but has only provided feedback for the comment request as I noted above. This series addresses the more complex work on the entire series I've been putting out and as such I've provided a TL;DR full review of what this series does in my previous v5 patch series, that can be looked at for more details if needed [1]. This series depends on the patch which I recently posted to address compilation issue on architectures missing ioremap_uc() [0]. If that goes through then it should be safe to apply this series, otherwise we have to sit and wait until all architectures get ioremap_uc() properly defined. Please let me know if there are any questions. [0] http://lkml.kernel.org/r/1436488096-3165-1-git-send-email-mcg...@do-not-panic.com [1] http://lkml.kernel.org/r/1435196060-27350-1-git-send-email-mcg...@do-not-panic.com Luis R. Rodriguez (4): drivers/video/fbdev/atyfb: Carve out framebuffer length fudging into a helper drivers/video/fbdev/atyfb: Clarify ioremap() base and length used drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC drivers/video/fbdev/atyfb: Use arch_phys_wc_add() and ioremap_wc() drivers/video/fbdev/aty/atyfb.h | 5 +- drivers/video/fbdev/aty/atyfb_base.c | 109 --- 2 files changed, 51 insertions(+), 63 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] KVM: SVM: use NPT page attributes
On 07/09/2015 11:18 PM, Paolo Bonzini wrote:
On 09/07/2015 04:30, Xiao Guangrong wrote:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 602b974a60a6..0f125c1860ec 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1085,6 +1085,47 @@ static u64 svm_compute_tsc_offset(struct
kvm_vcpu *vcpu, u64 target_tsc)
return target_tsc - tsc;
}
+static void svm_set_guest_pat(struct vcpu_svm *svm, u64 *g_pat)
+{
+struct kvm_vcpu *vcpu = >vcpu;
+
+/* Unlike Intel, AMD takes the guest's CR0.CD into account.
I noticed this code in svm_set_cr0():
if (!(vcpu->kvm->arch.disabled_quirks & KVM_QUIRK_CD_NW_CLEARED))
cr0 &= ~(X86_CR0_CD | X86_CR0_NW);
gCR0.CD is hidden to CPU if KVM_QUIRK_CD_NW_CLEARED is not set and looks
like it is the normal case after grepping Qemu code.
Hi Xiao,
yes, this is correct. QEMU still does not have support for disabling
"quirks", so gCR0.CD is currently hidden on SVM. I would like to
include this series in 4.2, while for 4.3 I will disable the quirk above
altogether (it is superseded by the way PAT is forced to all-WB).
That plan sounds good to me.
You will drop disabled_quirks completely or just enable it in Qemu? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-tip v2 0/2] locking/qrwlock: Improve qrwlock performance
On 07/09/2015 06:04 PM, Davidlohr Bueso wrote: On Thu, 2015-07-09 at 12:32 -0400, Waiman Long wrote: With this patch series in place, we can start converting some spinlocks back to rwlocks where it makes sense and the lock size increase isn't a concern. Nice, have any users to convert? I can think of a few I've encountered, but there must be quite a few, specially those nasty global spinlocks where nobody cares about the size. o hugetlb reservation map lock: Updating hugepage ranges does a two step read/update for the reservation map. The first step could now be done concurrently if converted. o The infamous swap_lock; although I doubt any of the serious offenders (ie zswap callbacks) would benefit much for anything beyond /proc/meminfo and related. o async cookie sync wait_event, battery/ata bootup(?). etc. etc. Obviously the fairness factor is also something to consider. Yes, I saw a couple of global spinlocks that can be converted to rwlocks. The read lock can be used for lookup, whereas the write lock is used for modification. Doing so will enable parallel lookups. As the qrwlock is almost fair compared with the old implementation, it removes a big roadblock for the conversion. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] mm/shrinker: define INIT_SHRINKER macro
Hello,
Forked from http://www.gossamer-threads.com/lists/linux/kernel/2209873#2209873
with some adjustments.
Shrinker API does not handle nicely unregister_shrinker() on a not-registered
->shrinker. Looking at shrinker users, they all have to (a) carry on some sort
of a flag telling that "unregister_shrinker()" will not blow up... or (b) just
be fishy
: int ldlm_pools_init(void)
: {
: int rc;
:
: rc = ldlm_pools_thread_start();
: if (rc == 0) {
: register_shrinker(_pools_srv_shrinker);
: register_shrinker(_pools_cli_shrinker);
: }
: return rc;
: }
: EXPORT_SYMBOL(ldlm_pools_init);
:
: void ldlm_pools_fini(void)
: {
: unregister_shrinker(_pools_srv_shrinker);
: unregister_shrinker(_pools_cli_shrinker);
: ldlm_pools_thread_stop();
: }
: EXPORT_SYMBOL(ldlm_pools_fini);
or (c) access private members `struct shrinker'
:struct cache_set {
: ...
: struct shrinker shrink;
: ...
:};
:
: ...
:
: void bch_btree_cache_free(struct cache_set *c)
: {
: struct btree *b;
: struct closure cl;
: closure_init_stack();
:
: if (c->shrink.list.next)
: unregister_shrinker(>shrink);
Note that `shrink.list.next' check.
We can't `fix' unregister_shrinker() (by looking at some flag or checking
`!shrinker->nr_deferred'), simply because someone can do something like
this:
:struct foo {
: const char *b;
: ...
: struct shrinker s;
:};
:
:void bar(void)
:{
: struct foo *f = kmalloc(...); /* or kzalloc() to NULL deref it*/
:
: if (!f)
: return;
:
: f->a = kmalloc(...);
: if (!f->a)
: goto err;
: ...
: register_shrinker(...);
: ...
: return;
:
:err:
: unregister_shrinker(>s);
: ^^ boom
: ...
:}
Passing a `garbaged' or zeroed out `struct shrinker' to unregister_shrinker()
:void unregister_shrinker(struct shrinker *shrinker)
:{
:down_write(_rwsem);
:list_del(>list);
:up_write(_rwsem);
:kfree(shrinker->nr_deferred);
:}
I was thinking of a trivial INIT_SHRINKER macro to init `struct shrinker'
internal members (composed in email client, not tested)
include/linux/shrinker.h
#define INIT_SHRINKER(s)\
do {\
(s)->nr_deferred = NULL;\
INIT_LIST_HEAD(&(s)->list); \
} while (0)
Of course, every shrinker user need to INIT_SHRINKER() early enough to
guarantee that unregister_shrinker() will be legal should anything go
wrong. Example:
:struct zs_pool *zs_create_pool(char *name, gfp_t flags)
:{
: ..
:+ INIT_SHRINKER(>shrinker);
:
: pool->name = kstrdup(name, GFP_KERNEL);
: if (!pool->name)
goto err;
: ..
: register_shrinker(>shrinker);
: ..
: return pool;
:
:err:
: unregister_shrinker(>shrinker);
: ..
:}
Not much better, but at least some hacks can be avoided and
accidental unregister_shrinker() happening in error path is
safe now.
How does it sound?
---
include/linux/shrinker.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index 4fcacd9..10adfc2 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -63,6 +63,12 @@ struct shrinker {
};
#define DEFAULT_SEEKS 2 /* A good number if you don't know better. */
+#define INIT_SHRINKER(s) \
+ do {\
+ INIT_LIST_HEAD(&(s)->list); \
+ (s)->nr_deferred = NULL;\
+ } while (0)
+
/* Flags */
#define SHRINKER_NUMA_AWARE(1 << 0)
#define SHRINKER_MEMCG_AWARE (1 << 1)
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] locking/qrwlock: Reduce reader/writer to reader lock transfer latency
On 07/09/2015 04:52 PM, Davidlohr Bueso wrote: On Thu, 2015-07-09 at 12:32 -0400, Waiman Long wrote: This patch eliminates that waiting. It also has the side effect of reducing the chance of writer lock stealing and improving the fairness of the lock. Using a locking microbenchmark, a 10-threads 5M locking loop of mostly readers (RW ratio = 10,000:1) has the following performance numbers in a Haswell-EX box: Kernel Locking Rate (Kops/s) -- - 4.1.1 15,063,081 Patched 4.1.1 17,241,552 In any case, for such read-mostly scenarios, you'd probably want to be using rcu ;-). Yes, I agree:-) Signed-off-by: Waiman Long --- kernel/locking/qrwlock.c | 12 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c index d9c36c5..6a7a3b8 100644 --- a/kernel/locking/qrwlock.c +++ b/kernel/locking/qrwlock.c @@ -88,15 +88,11 @@ void queued_read_lock_slowpath(struct qrwlock *lock, u32 cnts) arch_spin_lock(>lock); /* -* At the head of the wait queue now, wait until the writer state -* goes to 0 and then try to increment the reader count and get -* the lock. It is possible that an incoming writer may steal the -* lock in the interim, so it is necessary to check the writer byte -* to make sure that the write lock isn't taken. +* At the head of the wait queue now, increment the reader count +* and wait until the writer, if it has the lock, has gone away. +* At ths ^^ this stage, it is not possible for a writer to remain in the +* waiting state (_QW_WAITING). So there won't be any deadlock. Because the writer setting _QW_WAITING is done in the slowpath, serialized with the qrwlock->lock, right? _QW_WAITING can only be set when the writer is at the queue head, and it will become _QW_LOCKED when it gets the lock. When a reader becomes queue head, the writer byte can either be 0 or _QW_LOCKED, but it can never be _QW_WAITING. */ - while (atomic_read(>cnts)& _QW_WMASK) - cpu_relax_lowlatency(); - cnts = atomic_add_return(_QR_BIAS,>cnts) - _QR_BIAS; Nit: since 'cnts' is now only the original value of lock->cnts before adding _QR_BIAS, could we rename it to 'prev_cnts' (or something)? -- iirc you removed the need for the variable when in interrupt context. The subtraction sign is there to simulate an xadd instruction. Without that, the generated code will have an additional add instruction. Yes, it is kind of a hack. It will be changed later on when other architectures start using qrwlock. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
