Re: [PATCH 14/20] thermal: cpu_cooling: Use cpufreq_for_each_valid_entry macro for iteration
On 15 April 2014 02:40, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_valid_entry macro
> helper for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/thermal/cpu_cooling.c | 33 +
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 4246262..3040629 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -144,11 +144,11 @@ static int get_property(unsigned int cpu, unsigned long
> input,
> unsigned int *output,
> enum cpufreq_cooling_property property)
> {
> - int i, j;
> + int i;
> unsigned long max_level = 0, level = 0;
> unsigned int freq = CPUFREQ_ENTRY_INVALID;
> int descend = -1;
> - struct cpufreq_frequency_table *table =
> + struct cpufreq_frequency_table *pos, *table =
> cpufreq_frequency_get_table(cpu);
>
> if (!output)
> @@ -157,20 +157,16 @@ static int get_property(unsigned int cpu, unsigned long
> input,
> if (!table)
> return -EINVAL;
>
> - for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> - /* ignore invalid entries */
> - if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
> - continue;
> -
> + cpufreq_for_each_valid_entry(pos, table) {
> /* ignore duplicate entry */
> - if (freq == table[i].frequency)
> + if (freq == pos->frequency)
> continue;
>
> /* get the frequency order */
> if (freq != CPUFREQ_ENTRY_INVALID && descend == -1)
> - descend = !!(freq > table[i].frequency);
> + descend = !!(freq > pos->frequency);
drop !! as well, its not required here. Mention that in log.
--
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 V5] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers
Add tunable RX interrupt trigger I/F of FIFO buffers.
Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.
According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.
This patch makes some devices change RX interrupt trigger from userland.
- Read current setting
# cat /sys/dev/char/4\:64/rx_int_trig
8
- Write user setting
# echo 1 > /sys/dev/char/4\:64/rx_int_trig
# cat /sys/dev/char/4\:64/rx_int_trig
1
- 16550A and Tegra (1, 4, 8, or 14 bytes)
- 16650V2 (8, 16, 24, or 28 bytes)
- 16654 (8, 16, 56, or 60 bytes)
- 16750 (1, 16, 32, or 56 bytes)
Changed in V2:
- Use _IOW for TIOCSFIFORTRIG definition
- Pass the interrupt trigger value itself
Changes in V3:
- Change I/F from ioctl(2) to sysfs(rx_int_trig)
Changes in V4:
- Introduce fifo_bug flag in uart_8250_port structure
This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
for up->bugs. If this flag is enabled, user cannot set RX trigger.
- Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
at convert_val2rxtrig()
- Set the nearest lower RX trigger when users input a meaningless value at
convert_val2rxtrig()
- Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos()
- Set fcr = up->fcr in the begging of serial8250_do_set_termios()
Changes in V5:
- Support Tegra, 16650V2, 16654, and 16750
- Store default FCR value to up->fcr when the port is first created
- Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
in convert_fcr2val() and convert_val2rxtrig()
Signed-off-by: Yoshihiro YUNOMAE
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Heikki Krogerus
Cc: Jingoo Han
Cc: Aaron Sierra
Cc: Stephen Warren
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/tty/serial/8250/8250.h |7 +
drivers/tty/serial/8250/8250_core.c | 184 ---
drivers/tty/serial/serial_core.c| 18 ++-
include/linux/serial_8250.h |2
include/linux/serial_core.h |4 +
5 files changed, 193 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 1ebf853..ab5d812 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -12,6 +12,7 @@
*/
#include
+#include
#include
struct uart_8250_dma {
@@ -55,11 +56,17 @@ struct old_serial_port {
unsigned long irqflags;
};
+#define FCR_RX_TRIG_OFFSET 6
+#define FCR_RX_TRIG_BITS(x)(((x) >> FCR_RX_TRIG_OFFSET) & 0x3)
+#define FCR_RX_TRIG_MAX_STATE \
+((FCR_RX_TRIG_BITS(UART_FCR_R_TRIG_11))-(FCR_RX_TRIG_BITS(UART_FCR_R_TRIG_00)))
+
struct serial8250_config {
const char *name;
unsigned short fifo_size;
unsigned short tx_loadsz;
unsigned char fcr;
+ unsigned char rx_trig_byte[FCR_RX_TRIG_MAX_STATE];
unsigned intflags;
};
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 81f909c..9987845 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -161,6 +160,7 @@ static const struct serial8250_config uart_config[] = {
.fifo_size = 16,
.tx_loadsz = 16,
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+ .rx_trig_byte = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
[PORT_CIRRUS] = {
@@ -180,6 +180,7 @@ static const struct serial8250_config uart_config[] = {
.tx_loadsz = 16,
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_01 |
UART_FCR_T_TRIG_00,
+ .rx_trig_byte = {8, 16, 24, 28},
.flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
},
[PORT_16750] = {
@@ -188,6 +189,7 @@ static const struct serial8250_config uart_config[] = {
.tx_loadsz = 64,
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10 |
UART_FCR7_64BYTE,
+ .rx_trig_byte = {1, 16, 32, 56},
.flags = UART_CAP_FIFO | UART_CAP_SLEEP | UART_CAP_AFE,
},
[PORT_STARTECH] = {
@@ -209,6 +211,7 @@
Re: [Patch v5 3/6] IIO: core: Modify scan element type
On April 14, 2014 11:33:12 PM GMT+01:00, Peter Meerwald
wrote:
>> The current scan element type uses the following format:
>> [be|le]:[s|u]bits/storagebits[>>shift].
>> To specify multiple elements in this type, added a repeat value.
>> So new format is:
>> [be|le]:[s|u]bits/storagebits{X[repeat]}[>>shift].
>> Here X is specifying how may times, real/storage bits are repeating.
>>
>> When X is value is 0 or 1, then repeat value is not used in the
>format,
>> and it will be same as existing format.
>
>minor comments inline
>
>> ---
>> drivers/iio/industrialio-buffer.c | 41
>+--
>> include/linux/iio/iio.h | 9 +
>> 2 files changed, 44 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iio/industrialio-buffer.c
>b/drivers/iio/industrialio-buffer.c
>> index e108f2a..aa90c68 100644
>> --- a/drivers/iio/industrialio-buffer.c
>> +++ b/drivers/iio/industrialio-buffer.c
>> @@ -150,7 +150,16 @@ static ssize_t iio_show_fixed_type(struct device
>*dev,
>> type = IIO_BE;
>> #endif
>> }
>> -return sprintf(buf, "%s:%c%d/%d>>%u\n",
>> +if (this_attr->c->scan_type.repeat > 1)
>> +return sprintf(buf, "%s:%c%d/%d{%d[repeat]}>>%u\n",
>> + iio_endian_prefix[type],
>> + this_attr->c->scan_type.sign,
>> + this_attr->c->scan_type.realbits,
>> + this_attr->c->scan_type.storagebits,
>> + this_attr->c->scan_type.repeat,
>> + this_attr->c->scan_type.shift);
>> +else
>> +return sprintf(buf, "%s:%c%d/%d>>%u\n",
>> iio_endian_prefix[type],
>> this_attr->c->scan_type.sign,
>> this_attr->c->scan_type.realbits,
>> @@ -474,14 +483,22 @@ static int iio_compute_scan_bytes(struct
>iio_dev *indio_dev,
>> for_each_set_bit(i, mask,
>> indio_dev->masklength) {
>> ch = iio_find_channel_from_si(indio_dev, i);
>> -length = ch->scan_type.storagebits / 8;
>> +if (ch->scan_type.repeat > 1)
>> +length = ch->scan_type.storagebits / 8 *
>> +ch->scan_type.repeat;
>
>so storagebits should be a multiple of 8 and != 0;
>we cannot have repeated groups of say 4 bits
Indeed not. Having unaligned data would probably prove more painful than using
more
memory... Real requirements will be stricter as power of 2 multiples of bytes
only.
This is in theory the plan for all buffer elements..
>
>> +else
>> +length = ch->scan_type.storagebits / 8;
>> bytes = ALIGN(bytes, length);
>> bytes += length;
>> }
>> if (timestamp) {
>> ch = iio_find_channel_from_si(indio_dev,
>>indio_dev->scan_index_timestamp);
>> -length = ch->scan_type.storagebits / 8;
>> +if (ch->scan_type.repeat > 1)
>> +length = ch->scan_type.storagebits / 8 *
>> +ch->scan_type.repeat;
>> +else
>> +length = ch->scan_type.storagebits / 8;
>> bytes = ALIGN(bytes, length);
>> bytes += length;
>> }
>> @@ -957,7 +974,11 @@ static int iio_buffer_update_demux(struct
>iio_dev *indio_dev,
>> indio_dev->masklength,
>> in_ind + 1);
>> ch = iio_find_channel_from_si(indio_dev, in_ind);
>> -length = ch->scan_type.storagebits/8;
>> +if (ch->scan_type.repeat > 1)
>> +length = ch->scan_type.storagebits / 8 *
>> +ch->scan_type.repeat;
>> +else
>> +length = ch->scan_type.storagebits / 8;
>> /* Make sure we are aligned */
>> in_loc += length;
>> if (in_loc % length)
>> @@ -969,7 +990,11 @@ static int iio_buffer_update_demux(struct
>iio_dev *indio_dev,
>> goto error_clear_mux_table;
>> }
>> ch = iio_find_channel_from_si(indio_dev, in_ind);
>> -length = ch->scan_type.storagebits/8;
>> +if (ch->scan_type.repeat > 1)
>> +length = ch->scan_type.storagebits / 8 *
>> +ch->scan_type.repeat;
>> +else
>> +length = ch->scan_type.storagebits / 8;
>> if (out_loc % length)
>> out_loc += length - out_loc % length;
>> if (in_loc % length)
>> @@ -990,7 +1015,11 @@ static int iio_buffer_update_demux(struct
>iio_dev *indio_dev,
>> }
>> ch = iio_find_channel_from_si(indio_dev,
>> indio_dev->scan_index_timestamp);
>>
Re: [PATCH v5 1/6] SP800-90A Deterministic Random Bit Generator
On Tue, 2014-04-15 at 07:35 +0200, Stephan Mueller wrote:
> diff --git a/crypto/drbg.c b/crypto/drbg.c
[]
> @@ -0,0 +1,1997 @@
[]
> +/***
> + * Backend cipher definitions available to DRBG
> + ***/
> +
> +const struct drbg_core cores[] = {
cores isn't a very good global name.
I presume this should be static.
--
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 09/20] cpufreq: longhaul: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:39, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/longhaul.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
> index d00e5d1..6de99c4 100644
> --- a/drivers/cpufreq/longhaul.c
> +++ b/drivers/cpufreq/longhaul.c
> @@ -528,6 +528,7 @@ static int longhaul_get_ranges(void)
>
> static void longhaul_setup_voltagescaling(void)
> {
> + struct cpufreq_frequency_table *freq;
Be consistent and use 'pos' here as well.
--
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] perf machine: Search for modules in %s/lib/modules/%s
Hi Richard, On Thu, 10 Apr 2014 12:52:59 -0400, Richard Yao wrote: > Modules installed outside of the kernel's build system should go into > "%s/lib/modules/%s/extra", but at present, perf will only look at them > when they are in "%s/lib/modules/%s/kernel". Lets encourage good > citizenship by relaxing this requirement to "%s/lib/modules/%s". This > way open source modules that are out-of-tree have no incentive to start > populating a directory reserved for in-kernle modules and I can stop hex > editing my system's perf binary when profiling OSS out-of-tree modules. But it'll make the perf traverses all the source and build directories too, right? I don't think it's a right thing to do. Maybe we can also change stat() in map_groups__set_modules_path_dir() to lstat() so that it cannot go to unwanted directories in that case. Or else, just checking "kernel" and "extra" directories will work. Thanks, Namhyung -- 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 08/20] cpufreq: exynos5440: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:39, Stratos Karafotis wrote:
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> static void exynos_enable_dvfs(unsigned int cur_frequency)
> {
> - unsigned int tmp, i, cpu;
> + unsigned int tmp, cpu;
> struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
> + struct cpufreq_frequency_table *pos;
Merge above two.
> /* Disable DVFS */
> __raw_writel(0, dvfs_info->base + XMU_DVFS_CTRL);
>
> @@ -182,15 +182,15 @@ static void exynos_enable_dvfs(unsigned int
> cur_frequency)
> __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
>
> /* Set initial performance index */
> - for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
> - if (freq_table[i].frequency == cur_frequency)
> + cpufreq_for_each_entry(pos, freq_table) {
> + if (pos->frequency == cur_frequency)
> break;
> + }
>
> - if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
> + if (pos->frequency == CPUFREQ_TABLE_END) {
> dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
> /* Assign the highest frequency */
> - i = 0;
> - cur_frequency = freq_table[i].frequency;
> + cur_frequency = freq_table->frequency;
First this is not readable enough and you introduced a bug here, see
below.
> }
>
> dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
> @@ -199,7 +199,7 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
> for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
> tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu *
> 4);
> tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
> - tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
> + tmp |= ((pos - freq_table) << C0_3_PSTATE_NEW_SHIFT);
We used modified value of 'i' here earlier, i.e. 0 ..
> __raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu *
> 4);
> }
>
> --
> 1.9.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/
Re: [PATCH 07/20] cpufreq: exynos: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:39, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/exynos-cpufreq.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index f99cfe2..0e19bce 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -28,18 +28,18 @@ static unsigned int locking_frequency;
>
> static int exynos_cpufreq_get_index(unsigned int freq)
> {
> - struct cpufreq_frequency_table *freq_table = exynos_info->freq_table;
> - int index;
> + struct cpufreq_frequency_table *pos, *freq_table;
>
> - for (index = 0;
> - freq_table[index].frequency != CPUFREQ_TABLE_END; index++)
> - if (freq_table[index].frequency == freq)
> + freq_table = exynos_info->freq_table;
Keep it as it was, i.e. fill freq_table during its definition. If with
addition of
pos it is crossing 80 columns, then define pos in a separate line.
> + cpufreq_for_each_entry(pos, freq_table) {
> + if (pos->frequency == freq)
> break;
> + }
>
> - if (freq_table[index].frequency == CPUFREQ_TABLE_END)
> + if (pos->frequency == CPUFREQ_TABLE_END)
> return -EINVAL;
>
> - return index;
> + return pos - freq_table;
> }
>
> static int exynos_cpufreq_scale(unsigned int target_freq)
> --
> 1.9.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/
Re: [PATCH v4 3/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined
On Monday, April 14, 2014 05:11:15 PM Igor Mammedov wrote:
> acpi_processor_add() assumes that present at boot CPUs
> are always onlined, it is not so if a CPU failed to become
> onlined. As result acpi_processor_add() will mark such CPU
> device as onlined in sysfs and following attempts to
> online/offline it using /sys/device/system/cpu/cpuX/online
> attribute will fail.
>
> Do not poke into device internals in acpi_processor_add()
> and touch "struct device { .offline }" attribute, since
> for CPUs onlined at boot it's set by:
> topology_init() -> arch_register_cpu() -> register_cpu()
> before ACPI device tree is parsed, and for hotplugged
> CPUs it's set when userspace onlines CPU via sysfs.
>
> Signed-off-by: Igor Mammedov
> ---
> v2:
> - fix regression in v1 leading to NULL pointer dereference
>on CPU unplug, do not remove "pr->dev = dev;"
> ---
> drivers/acpi/acpi_processor.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c29c2c3..42d66f8 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -404,7 +404,6 @@ static int acpi_processor_add(struct acpi_device *device,
> goto err;
>
> pr->dev = dev;
> - dev->offline = pr->flags.need_hotplug_init;
This line is to ensure that dev->offline and pr->flags.need_hotplug_init are
consistent with each other. If you remove it, you need to ensure that they
will be consistent in some other way.
>
> /* Trigger the processor driver's .probe() if present. */
> if (device_attach(dev) >= 0)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 05/20] cpufreq: dbx500: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:38, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/dbx500-cpufreq.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/dbx500-cpufreq.c
> b/drivers/cpufreq/dbx500-cpufreq.c
> index 412a78b..2a0635c 100644
> --- a/drivers/cpufreq/dbx500-cpufreq.c
> +++ b/drivers/cpufreq/dbx500-cpufreq.c
> @@ -45,7 +45,7 @@ static struct cpufreq_driver dbx500_cpufreq_driver = {
>
> static int dbx500_cpufreq_probe(struct platform_device *pdev)
> {
> - int i = 0;
> + struct cpufreq_frequency_table *pos;
>
> freq_table = dev_get_platdata(>dev);
> if (!freq_table) {
> @@ -60,9 +60,8 @@ static int dbx500_cpufreq_probe(struct platform_device
> *pdev)
> }
>
> pr_info("dbx500-cpufreq: Available frequencies:\n");
> - while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> - pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
> - i++;
> + cpufreq_for_each_entry(pos, freq_table) {
> + pr_info(" %d Mhz\n", pos->frequency / 1000);
> }
Remove {}
--
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 03/20] cpufreq: stats: Use cpufreq_for_each_valid_entry macro for iteration
On 15 April 2014 02:38, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_valid_entry macro
> helper for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/cpufreq_stats.c | 22 --
> 1 file changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index ecaaebf..223078d 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
>
> static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
> {
> - unsigned int i, j, count = 0, ret = 0;
> + unsigned int i, count = 0, ret = 0;
> struct cpufreq_stats *stat;
> unsigned int alloc_size;
> unsigned int cpu = policy->cpu;
> - struct cpufreq_frequency_table *table;
> + struct cpufreq_frequency_table *pos, *table;
>
> table = cpufreq_frequency_get_table(cpu);
> if (unlikely(!table))
> @@ -205,10 +205,7 @@ static int __cpufreq_stats_create_table(struct
> cpufreq_policy *policy)
> stat->cpu = cpu;
> per_cpu(cpufreq_stats_table, cpu) = stat;
>
> - for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> - unsigned int freq = table[i].frequency;
> - if (freq == CPUFREQ_ENTRY_INVALID)
> - continue;
> + cpufreq_for_each_valid_entry(pos, table) {
> count++;
> }
Remove {} as well..
--
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/20] cpufreq: acpi-cpufreq: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:38, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/acpi-cpufreq.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 000e4e0..12a5750 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct
> acpi_cpufreq_data *data)
>
> static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
> {
> - int i;
> + struct cpufreq_frequency_table *pos;
> struct acpi_processor_performance *perf;
>
> if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
> @@ -223,11 +223,11 @@ static unsigned extract_msr(u32 msr, struct
> acpi_cpufreq_data *data)
>
> perf = data->acpi_data;
>
> - for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
> - if (msr ==
> perf->states[data->freq_table[i].driver_data].status)
> - return data->freq_table[i].frequency;
> + cpufreq_for_each_entry(pos, data->freq_table) {
> + if (msr == perf->states[pos->driver_data].status)
> + return pos->frequency;
> }
> - return data->freq_table[0].frequency;
> + return data->freq_table->frequency;
This isn't a related change, isn't it? Also it make it less readable.
So probably
just leave it as is.
--
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 v4 3/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined
On Monday, April 14, 2014 05:11:15 PM Igor Mammedov wrote:
> acpi_processor_add() assumes that present at boot CPUs
> are always onlined, it is not so if a CPU failed to become
> onlined. As result acpi_processor_add() will mark such CPU
> device as onlined in sysfs and following attempts to
> online/offline it using /sys/device/system/cpu/cpuX/online
> attribute will fail.
>
> Do not poke into device internals in acpi_processor_add()
> and touch "struct device { .offline }" attribute, since
> for CPUs onlined at boot it's set by:
> topology_init() -> arch_register_cpu() -> register_cpu()
> before ACPI device tree is parsed, and for hotplugged
> CPUs it's set when userspace onlines CPU via sysfs.
>
> Signed-off-by: Igor Mammedov
> ---
> v2:
> - fix regression in v1 leading to NULL pointer dereference
>on CPU unplug, do not remove "pr->dev = dev;"
Yeah.
Does this patch depend on any other patches in the series?
I don't think so, but just asking.
If it doesn't, why is it part of this series at all?
> ---
> drivers/acpi/acpi_processor.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c29c2c3..42d66f8 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -404,7 +404,6 @@ static int acpi_processor_add(struct acpi_device *device,
> goto err;
>
> pr->dev = dev;
> - dev->offline = pr->flags.need_hotplug_init;
>
> /* Trigger the processor driver's .probe() if present. */
> if (device_attach(dev) >= 0)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 01/20] cpufreq: Introduce macros for cpufreq_frequency_table iteration
On 15 April 2014 02:37, Stratos Karafotis wrote:
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> @@ -193,9 +191,9 @@ int cpufreq_frequency_table_get_index(struct
> cpufreq_policy *policy,
> return -ENOENT;
> }
>
> - for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
> - if (table[i].frequency == freq)
> - return i;
> + cpufreq_for_each_entry(pos, table) {
> + if (pos->frequency == freq)
> + return pos - table;
> }
I asked you to do this in V1:
use cpufreq_for_each_valid_entry() here as well.
--
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 v4] mm: support madvise(MADV_FREE)
On 04/15/2014 12:46 PM, Minchan Kim wrote: > Linux doesn't have an ability to free pages lazy while other OS > already have been supported that named by madvise(MADV_FREE). > > The gain is clear that kernel can discard freed pages rather than > swapping out or OOM if memory pressure happens. > > Without memory pressure, freed pages would be reused by userspace > without another additional overhead(ex, page fault + allocation > + zeroing). > > How to work is following as. > > When madvise syscall is called, VM clears dirty bit of ptes of > the range. If memory pressure happens, VM checks dirty bit of > page table and if it found still "clean", it means it's a > "lazyfree pages" so VM could discard the page instead of swapping out. > Once there was store operation for the page before VM peek a page > to reclaim, dirty bit is set so VM can swap out the page instead of > discarding. > > Firstly, heavy users would be general allocators(ex, jemalloc, > tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already > have supported the feature for other OS(ex, FreeBSD) Reviewed-by: Zhang Yanfei > > barrios@blaptop:~/benchmark/ebizzy$ lscpu > Architecture: x86_64 > CPU op-mode(s):32-bit, 64-bit > Byte Order:Little Endian > CPU(s):4 > On-line CPU(s) list: 0-3 > Thread(s) per core:2 > Core(s) per socket:2 > Socket(s): 1 > NUMA node(s): 1 > Vendor ID: GenuineIntel > CPU family:6 > Model: 42 > Stepping: 7 > CPU MHz: 2801.000 > BogoMIPS: 5581.64 > Virtualization:VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 4096K > NUMA node0 CPU(s): 0-3 > > ebizzy benchmark(./ebizzy -S 10 -n 512) > > vanilla-jemalloc MADV_free-jemalloc > > 1 thread > records: 10 records: 10 > avg: 7436.70 avg: 15292.70 > std: 48.01(0.65%)std: 496.40(3.25%) > max: 7542.00 max: 15944.00 > min: 7366.00 min: 14478.00 > > 2 thread > records: 10 records: 10 > avg: 12190.50avg: 24975.50 > std: 1011.51(8.30%) std: 1127.22(4.51%) > max: 13012.00max: 26382.00 > min: 10192.00min: 23265.00 > > 4 thread > records: 10 records: 10 > avg: 16875.30avg: 36320.90 > std: 562.59(3.33%) std: 1503.75(4.14%) > max: 17465.00max: 38314.00 > min: 15552.00min: 33863.00 > > 8 thread > records: 10 records: 10 > avg: 16966.80avg: 35915.20 > std: 229.35(1.35%) std: 2153.89(6.00%) > max: 17456.00max: 37943.00 > min: 16742.00min: 29891.00 > > 16 thread > records: 10 records: 10 > avg: 20590.90avg: 37388.40 > std: 362.33(1.76%) std: 1282.59(3.43%) > max: 20954.00max: 38911.00 > min: 19985.00min: 34928.00 > > 32 thread > records: 10 records: 10 > avg: 22633.40avg: 37118.00 > std: 413.73(1.83%) std: 766.36(2.06%) > max: 23120.00max: 38328.00 > min: 22071.00min: 35557.00 > > In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED. > Patchset is based on 3.14 > > * From v3 > * Add "how to work part" in description - Zhang > * Add page_discardable utility function - Zhang > * Clean up > > * From v2 > * Remove forceful dirty marking of swap-readed page - Johannes > * Remove deactivation logic of lazyfreed page > * Rebased on 3.14 > * Remove RFC tag > > * From v1 > * Use custom page table walker for madvise_free - Johannes > * Remove PG_lazypage flag - Johannes > * Do madvise_dontneed instead of madvise_freein swapless system > > Cc: Hugh Dickins > Cc: Johannes Weiner > Cc: Rik van Riel > Cc: KOSAKI Motohiro > Cc: Mel Gorman > Cc: Jason Evans > Signed-off-by: Minchan Kim > --- > include/linux/mm.h | 2 + > include/linux/rmap.h | 21 - > include/linux/vm_event_item.h | 1 + > include/uapi/asm-generic/mman-common.h | 1 + > mm/madvise.c | 25 ++ > mm/memory.c| 140 > + > mm/rmap.c | 82 +-- > mm/vmscan.c| 29 ++- > mm/vmstat.c| 1 + > 9 files changed, 290 insertions(+), 12 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index c1b7414c7bef..79af90212c19 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1063,6 +1063,8 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned > long address, > unsigned long
Re: [PATCH v3 5/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined
On Thursday, April 10, 2014 07:14:21 PM Igor Mammedov wrote:
> acpi_processor_add() assumes that present at boot CPUs
> are always onlined, it is not so if a CPU failed to become
> onlined.
What do you mean by that? What *exactly* is the failure scenario?
> As result acpi_processor_add() will mark such CPU
> device as onlined in sysfs and following attempts to
> online/offline it using /sys/device/system/cpu/cpuX/online
> attribute will fail.
>
> Do not poke into device internals in acpi_processor_add()
> and touch "struct device { .offline }" attribute, since
> for CPUs onlined at boot it's set by:
> topology_init() -> arch_register_cpu() -> register_cpu()
> before ACPI device tree is parsed, and for hotplugged
> CPUs it's set when userspace onlines CPU via sysfs.
>
> Signed-off-by: Igor Mammedov
> ---
> drivers/acpi/acpi_processor.c |3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c29c2c3..d56e4b4 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -403,9 +403,6 @@ static int acpi_processor_add(struct acpi_device *device,
> if (result)
> goto err;
>
> - pr->dev = dev;
The line above has to stay as is.
> - dev->offline = pr->flags.need_hotplug_init;
> -
> /* Trigger the processor driver's .probe() if present. */
> if (device_attach(dev) >= 0)
> return 1;
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 V1 Resend 3/5] tick-common: do additional checks in tick_check_preferred()
We return false from tick_check_preferred() if newdev doesn't have ONESHOT
feature but curdev has, but we don't return true when newdev has ONESHOT and
curdev doesn't. Instead we go on, check ratings and other things in that case.
This patch tries to fix this by rewriting some portion of this code and adds
sufficient comments to make logic clear.
Signed-off-by: Viresh Kumar
---
kernel/time/tick-common.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 69cab28..2f13889 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -252,18 +252,29 @@ static bool tick_check_percpu(struct clock_event_device
*curdev,
static bool tick_check_preferred(struct clock_event_device *curdev,
struct clock_event_device *newdev)
{
- /* Prefer oneshot capable device */
- if (!(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) {
- if (curdev && (curdev->features & CLOCK_EVT_FEAT_ONESHOT))
- return false;
- }
+ if (!curdev)
+ return true;
+
+ /*
+* Prefer oneshot capable device.
+* return values based on if ONESHOT is available or not:
+*
+* curdev newdev operation
+* 00 check priority
+* 01 return true
+* 10 return false
+* 11 check priority
+*/
+
+ if ((newdev->features & CLOCK_EVT_FEAT_ONESHOT) ^
+ (curdev->features & CLOCK_EVT_FEAT_ONESHOT))
+ return newdev->features & CLOCK_EVT_FEAT_ONESHOT;
/*
* Use the higher rated one, but prefer a CPU local device with a lower
* rating than a non-CPU local device
*/
- return !curdev ||
- newdev->rating > curdev->rating ||
+ return newdev->rating > curdev->rating ||
!cpumask_equal(curdev->cpumask, newdev->cpumask);
}
--
1.7.12.rc2.18.g61b472e
--
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 V1 Resend 2/5] tick-common: don't check tick_oneshot_mode_active() from tick_check_preferred()
If 'curdev' passed to tick_check_preferred() is the current clock_event_device
then these two checks look exactly same, because td->mode is set to
TICKDEV_MODE_ONESHOT only when the event device has ONESHOT feature.
if (curdev && (curdev->features & CLOCK_EVT_FEAT_ONESHOT))
return false;
if (tick_oneshot_mode_active())
return false;
Now left the case where 'curdev' is not the current clock_event_device. This can
happen from the sequence started from clockevents_replace(). Here we are trying
to find the best possible device that we should choose. And so even in this case
we don't need the above check as we aren't really worried about the current
device.
So, the second check can be removed.
Signed-off-by: Viresh Kumar
---
kernel/time/tick-common.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 0a0608e..69cab28 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -256,8 +256,6 @@ static bool tick_check_preferred(struct clock_event_device
*curdev,
if (!(newdev->features & CLOCK_EVT_FEAT_ONESHOT)) {
if (curdev && (curdev->features & CLOCK_EVT_FEAT_ONESHOT))
return false;
- if (tick_oneshot_mode_active())
- return false;
}
/*
--
1.7.12.rc2.18.g61b472e
--
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 V1 Resend 0/5] tick: bugfixes
Hi Thomas, As suggested by you (https://lkml.org/lkml/2014/4/14/797), this is the first lot of changes I have. These are all potential bug fixes (Sorry if I haven't read the most obvious code correctly at some place :) ). Patch 2/5 isn't a bug fix but was required as a dependency for 3/5. Some discussions already happened for 5/5 here: https://lkml.org/lkml/2014/4/9/243 https://lkml.org/lkml/2014/4/9/346 I have tried to mark stable release wherever possible. Viresh Kumar (5): tick-common: fix wrong check in tick_check_replacement() tick-common: don't check tick_oneshot_mode_active() from tick_check_preferred() tick-common: do additional checks in tick_check_preferred() tick-sched: don't call update_wall_time() when delta is lesser than tick_period tick-sched: replace tick_nohz_active with tick_nohz_enabled in tick_nohz_switch_to_nohz() kernel/time/tick-common.c | 29 +++-- kernel/time/tick-sched.c | 34 ++ 2 files changed, 37 insertions(+), 26 deletions(-) -- 1.7.12.rc2.18.g61b472e -- 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 5/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined
On Monday, April 14, 2014 11:21:47 AM Ingo Molnar wrote:
>
> * Igor Mammedov wrote:
>
> > acpi_processor_add() assumes that present at boot CPUs
> > are always onlined, it is not so if a CPU failed to become
> > onlined. As result acpi_processor_add() will mark such CPU
> > device as onlined in sysfs and following attempts to
> > online/offline it using /sys/device/system/cpu/cpuX/online
> > attribute will fail.
> >
> > Do not poke into device internals in acpi_processor_add()
> > and touch "struct device { .offline }" attribute, since
> > for CPUs onlined at boot it's set by:
> > topology_init() -> arch_register_cpu() -> register_cpu()
> > before ACPI device tree is parsed, and for hotplugged
> > CPUs it's set when userspace onlines CPU via sysfs.
> >
> > Signed-off-by: Igor Mammedov
> > ---
> > drivers/acpi/acpi_processor.c |3 ---
> > 1 files changed, 0 insertions(+), 3 deletions(-)
>
> Can this fix be moved first too, or does it have undesirable side
> effects on unmodified kernels?
This patch is not correct.
Rafael
--
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] PM / devfreq: Use freq_table for available_frequencies
On 04/14/2014 06:36 PM, 함명주 wrote: >> MyungJoo/Kyungmin, >> >> Bump. Can we accept this patch please? >> >> -Saravana > > Nack. > > Please note that freq_table is also an optional value, which may > be null. Ah, I saw that the max_freq would be zero if freq_table was NULL and I assumed that it can't be NULL. But I see that the max_freq limit is not applied if it's zero. Thanks for catching it. > Besides, please be aware that your code is under rcu_read_lock(). Valid point. I was just trying to keep the diff simple. No one's really going to be catting this file often when performance matters. > > > Cheers, > MyungJoo. > > ps. I'll send a related patch (avoid accessing null but not-an-error > pointer at other sysfs nodes). Thank you for letting me catch such bugs > anyway. I can go ahead and do this myself if you don't mind. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: [PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
On 15 April 2014 07:29, Chanwoo Choi wrote:
> This patch fix the offset of CPU boot address and don't operate smc call
> of SMC_CMD_CPU1BOOT command for Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/firmware.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index aa01c42..6205d4f 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -30,13 +30,16 @@ static int exynos_do_idle(void)
>
> static int exynos_cpu_boot(int cpu)
> {
> + if (soc_is_exynos3250()) {
> + return 0;
> /*
> * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
> * But, Exynos4212 has only one secondary CPU so second parameter
> * isn't used for informing secure firmware about CPU id.
> */
> - if (soc_is_exynos4212())
> + } else if (soc_is_exynos4212()) {
> cpu = 0;
> + }
>
As you already return in case of Exynos3250, you need not change this.
First commit hunk without the opening brace should be sufficient.
> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> return 0;
> @@ -46,7 +49,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
> boot_addr)
> {
> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>
> - if (!soc_is_exynos4212())
> + if (!soc_is_exynos4212() && !soc_is_exynos3250())
> boot_reg += 4*cpu;
>
> __raw_writel(boot_addr, boot_reg);
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Tushar Behera
--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Mon, Apr 14, 2014 at 8:07 PM, Sylwester Nawrocki
wrote:
> On 08/04/14 16:36, Vivek Gautam wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 28f9edb..6d99ba9 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>
>> Refer to DT bindings documentation of particular PHY consumer devices for
>> more
>> information about required PHYs and the way of specification.
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> +Required clocks:
>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>> +used for register access.
>> + - ref: PHY's reference clock (usually crystal clock), associated by
>> +phy name, used to determine bit values for clock settings
>> +register.
>> + Additional clock required for Exynos5420:
>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> + control pmu registers for power isolation.
>
> Why to append "-phandle" to the property's name ? If this is for PMU
> perhaps make it more explicit and name it: samsung,pmu-syscon or
> samsung,pmureg ?
Right, thanks for pointing out this.
Will rename it to samsung,pmu-syscon. That will be inline with the
phandle it points to.
--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Sylwester, On Mon, Apr 14, 2014 at 7:51 PM, Sylwester Nawrocki wrote: > On 14/04/14 15:49, Vivek Gautam wrote: >> True, we don't have a scope of instantiating this driver using old >> platform device and >> old legacy board files. >> So we don't need this check then, right ? > > I think it can be dropped. > At least IMHO there is no point to increase size of the module with > an error log that has no chance to be ever called in practice. Ok, i will remove this error message and in fact this check. -- Best Regards Vivek Gautam Samsung R Institute, Bangalore India -- 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 RFC] x86:Improve memset with general 64bit instruction
On Mon, Apr 14, 2014 at 09:31:16PM +0800, Ling Ma wrote: > The kernel version 3.14 shows memcpy, memset occur 19622 and 14189 > times respectively. > so memset is still important for us, correct? Did you ever see it in a profile log as being hot? I haven't. Static counts don't mean much. -Andi -- 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: [PATCHSET cgroup/for-3.15] cgroup: implement unified hierarchy
Hello, On Tue, Apr 15, 2014 at 10:58:24AM +0800, Li Zefan wrote: > I know we should allow multiple hierarchies, but why we allow this even > if sane_behavior is specified? Oh, because we didn't have unified hierarchy before. The whole sane_behavior thing is gonna go away. It'll be absorbed into unified hierarchy and probably be handled as a separate filesystem type, so the current situation is transitional. Thanks. -- tejun -- 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: Hardware dependencies in Kconfig
On Mon, Apr 14, 2014 at 03:59:11PM -0400, Josh Boyer wrote: > > Maybe I'm overly grumpy. Still, it's frustrating to see Kconfig > entries that clearly say "blahblah found on foo ARM chip" in the help > with no "depends on ARM" (not meaning to pick on ARM). I would like > to think there is some balance that could be found here. Yes, that would make me grumpy, perhaps a few developers could be auditing the new Kconfig items of every kernel around -rc3 timeframe to ensure that they don't do stuff like this... thanks, greg k-h -- 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] spi: cadence: Add dependency on ARCH_ZYNQ
Add dependency on ARCH_ZYNQ in Kconfig. This is to fix the build error. Signed-off-by: Harini Katakam --- drivers/spi/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index b0f091b..0db219b 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -150,6 +150,7 @@ config SPI_BUTTERFLY config SPI_CADENCE tristate "Cadence SPI controller" + depends on ARCH_ZYNQ depends on SPI_MASTER help This selects the Cadence SPI controller master driver -- 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] [media] s2255drv: fix memory leak s2255_probe()
smatch says:
drivers/media/usb/s2255/s2255drv.c:2246 s2255_probe() warn:
possible memory leak of 'dev'
Signed-off-by: Daeseok Youn
---
drivers/media/usb/s2255/s2255drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index 1d4ba2b..8aca3ef 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -2243,6 +2243,7 @@ static int s2255_probe(struct usb_interface *interface,
dev->cmdbuf = kzalloc(S2255_CMDBUF_SIZE, GFP_KERNEL);
if (dev->cmdbuf == NULL) {
s2255_dev_err(>dev, "out of memory\n");
+ kfree(dev);
return -ENOMEM;
}
--
1.7.4.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/
Re: Hardware dependencies in Kconfig
On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote: > Hi Greg, > > On Mon, 14 Apr 2014 12:11:43 -0700, Greg KH wrote: > > On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote: > > > Configuring kernels from scratch has become an incredibly long and > > > tedious task. The reason is that the number of drivers and options has > > > exploded in the past few years. Which in itself is great - Linux is > > > successful, yeah! - but the side effects must be dealt with. > > > 6000-line .config files are no fun. > > > > > > Earlier today, I found that NET_CADENCE is set in my x86-64 kernel > > > configuration. The two ethernet drivers below this menu are for ARM > > > machines. I really shouldn't be asked about that on x86-64. I just sent > > > a patch addressing this specific issue, which follows about 50 similar > > > patches from me for similar issues in various subsystems. But I can't > > > do all of that by myself, this is too much work quantitatively, and I > > > am not always the best person to find out the proper hardware > > > dependencies that should be added. > > > > Ideally, the arch doesn't matter at all for a driver, only the > > infrastructure the driver depends on does. So perhaps the > > "infrastructure" dependancy should be added for the drivers that you > > feel are only present on ARM platforms? > > The infrastructure dependencies are already present and correct as far > as I can tell. In this specific case, NET_CADENCE depends on HAS_IOMEM > and the two actual drivers depend on HAS_DMA. I suppose this is > sufficient, otherwise there would have been build failures reported by > now. That's good to hear. > > Are these all platform devices? > > In the case above, yes. But I don't quite see how that makes a > difference. x86 has platform drivers too, they are the essence of the > mfd framework. Almost every architecture can have platform drivers, > just like almost every platform can have PCI devices. I have been > adding dependencies on X86_32 for PCI drivers recently, for example. > > I'm very fine with USB drivers being architecture-agnostic. They really > are. But in practice a lot of PCI and platform drivers are only useful > of one architecture, of a few ones at best. Why would PCI devices only be useful on one architecture? PCI works on almost all arches that Linux supports, if it's a PCI card, it could be on any of those processors. If it's a mini-pci, the chances are less, but still quite possible. > > > I would like to call for proper hardware dependencies to become a > > > general trend: every new hardware-specific driver which is added to the > > > kernel should depend on ($hardware || COMPILE_TEST), so as to make it > > > clear right away, which type of hardware is expected to need the driver > > > in question. > > > > Adding more COMPILE_TEST dependancies for platform drivers would be > > wonderful to have, and make your life a little bit easier. Other than > > that, a simple 'm' selection for a distro config should be fine :) > > Huh, please, no. "Just say m if you don't know" was fine in the late > 90s, when Linux was mostly x86. You could afford including 3% of > useless drivers, and people working on other architectures said "no" by > default and only included the few drivers they needed. > > But today things have changed. We have a lot of very active, mature > architectures, with a bunch of existing drivers and a batch of new > drivers coming with every new kernel version. Saying "m" to everything > increases build times beyond reason. You also hit build failures you > shouldn't have to care about, depmod takes forever, updates are slow as > hell. This is the problem I am trying to solve. What is the build time difference you are seeing? I do 'allmodconfig' builds all the time, with over 3000 modules. The build works just fine on "modern" hardware. Cutting out 100 modules might speed it up a bit, but really, is that a big deal overall? > openSUSE 13.1 for x86_64 comes with 2629 (modular) device drivers. In > comparison, openSUSE 11.4 came with 2301 device drivers. So we added at > least 328 new drivers in 2.5 years. How many of these are actually > useful on x86_64? My estimate is less than half. And really, that's only 130 new modules a year or so, with all of the new hardware coming out, is that really a lot? Yes, it's a pain for distros, and yes, it would be nice if people wrote better Kconfig help text. Pushing back on that is the key here. If you see new drivers show up that you don't know where they work on, ask the developers and make up patches. > Most likely less than one third. Quite possibly less than one quarter. > We did not see that many totally new devices in the (PC) x86 world > lately, really. There are a lot of new devices out there, and we are dragging in tons of previously out-of-tree drivers in. Look at the huge explosion of the IIO drivers that we now have, supporting hundreds of new types of sensors. We
[PATCH v4] mm: support madvise(MADV_FREE)
Linux doesn't have an ability to free pages lazy while other OS already have been supported that named by madvise(MADV_FREE). The gain is clear that kernel can discard freed pages rather than swapping out or OOM if memory pressure happens. Without memory pressure, freed pages would be reused by userspace without another additional overhead(ex, page fault + allocation + zeroing). How to work is following as. When madvise syscall is called, VM clears dirty bit of ptes of the range. If memory pressure happens, VM checks dirty bit of page table and if it found still "clean", it means it's a "lazyfree pages" so VM could discard the page instead of swapping out. Once there was store operation for the page before VM peek a page to reclaim, dirty bit is set so VM can swap out the page instead of discarding. Firstly, heavy users would be general allocators(ex, jemalloc, tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already have supported the feature for other OS(ex, FreeBSD) barrios@blaptop:~/benchmark/ebizzy$ lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) per core:2 Core(s) per socket:2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family:6 Model: 42 Stepping: 7 CPU MHz: 2801.000 BogoMIPS: 5581.64 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 4096K NUMA node0 CPU(s): 0-3 ebizzy benchmark(./ebizzy -S 10 -n 512) vanilla-jemalloc MADV_free-jemalloc 1 thread records: 10 records: 10 avg: 7436.70 avg: 15292.70 std: 48.01(0.65%)std: 496.40(3.25%) max: 7542.00 max: 15944.00 min: 7366.00 min: 14478.00 2 thread records: 10 records: 10 avg: 12190.50avg: 24975.50 std: 1011.51(8.30%) std: 1127.22(4.51%) max: 13012.00max: 26382.00 min: 10192.00min: 23265.00 4 thread records: 10 records: 10 avg: 16875.30avg: 36320.90 std: 562.59(3.33%) std: 1503.75(4.14%) max: 17465.00max: 38314.00 min: 15552.00min: 33863.00 8 thread records: 10 records: 10 avg: 16966.80avg: 35915.20 std: 229.35(1.35%) std: 2153.89(6.00%) max: 17456.00max: 37943.00 min: 16742.00min: 29891.00 16 thread records: 10 records: 10 avg: 20590.90avg: 37388.40 std: 362.33(1.76%) std: 1282.59(3.43%) max: 20954.00max: 38911.00 min: 19985.00min: 34928.00 32 thread records: 10 records: 10 avg: 22633.40avg: 37118.00 std: 413.73(1.83%) std: 766.36(2.06%) max: 23120.00max: 38328.00 min: 22071.00min: 35557.00 In summary, MADV_FREE is about 2 time faster than MADV_DONTNEED. Patchset is based on 3.14 * From v3 * Add "how to work part" in description - Zhang * Add page_discardable utility function - Zhang * Clean up * From v2 * Remove forceful dirty marking of swap-readed page - Johannes * Remove deactivation logic of lazyfreed page * Rebased on 3.14 * Remove RFC tag * From v1 * Use custom page table walker for madvise_free - Johannes * Remove PG_lazypage flag - Johannes * Do madvise_dontneed instead of madvise_freein swapless system Cc: Hugh Dickins Cc: Johannes Weiner Cc: Rik van Riel Cc: KOSAKI Motohiro Cc: Mel Gorman Cc: Jason Evans Signed-off-by: Minchan Kim --- include/linux/mm.h | 2 + include/linux/rmap.h | 21 - include/linux/vm_event_item.h | 1 + include/uapi/asm-generic/mman-common.h | 1 + mm/madvise.c | 25 ++ mm/memory.c| 140 + mm/rmap.c | 82 +-- mm/vmscan.c| 29 ++- mm/vmstat.c| 1 + 9 files changed, 290 insertions(+), 12 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index c1b7414c7bef..79af90212c19 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1063,6 +1063,8 @@ int zap_vma_ptes(struct vm_area_struct *vma, unsigned long address, unsigned long size); void zap_page_range(struct vm_area_struct *vma, unsigned long address, unsigned long size, struct zap_details *); +void lazyfree_range(struct vm_area_struct *vma, unsigned long address, + unsigned long size); void unmap_vmas(struct mmu_gather *tlb, struct vm_area_struct *start_vma, unsigned
Re: [PATCH 29/38] tick-sched: remove wrapper around __tick_nohz_task_switch()
On 15 April 2014 04:52, Frederic Weisbecker wrote: > On Mon, Apr 14, 2014 at 09:53:51PM +0530, Viresh Kumar wrote: >> __tick_nohz_task_switch() was called only from tick_nohz_task_switch() and >> there >> is nothing much in tick_nohz_task_switch() as well. IOW, we don't need >> unnecessary wrapper over __tick_nohz_task_switch() to be there. Merge all >> code >> from __tick_nohz_task_switch() into tick_nohz_task_switch() and move it to >> tick-sched.c. >> >> This also moves check for tick_nohz_tick_stopped() outside of irq_save() >> context. > > No, the wrapper is there on purpose in order to optimize the full dynticks > off case in > the context switch path with the jump label'ed check on > tick_nohz_full_enabled(). Just to clarify, you are saying that: Wrapper was there to save an extra function call when tick_nohz_full_enabled() returns false, as tick_nohz_task_switch() will be inlined ? In this case probably we can move !can_stop_full_tick() as well to the wrapper ? -- 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/
[PATCHv3] pci: moved EXPORT_SYMBOL so that it immediately followed its function/variable
change made to resolve following checkpatch message:
WARNING: EXPORT_SYMBOL(foo); should immediately follow
its function/variable
branch: Linux 3.14
Signed-off-by: Ryan Desfosses
---
drivers/pci/pci.c | 75 -
drivers/pci/setup-res.c | 1 +
2 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index fdbc294..305162b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -226,6 +226,7 @@ int pci_find_capability(struct pci_dev *dev, int cap)
return pos;
}
+EXPORT_SYMBOL(pci_find_capability);
/**
* pci_bus_find_capability - query for devices' capabilities
@@ -253,6 +254,7 @@ int pci_bus_find_capability(struct pci_bus *bus, unsigned
int devfn, int cap)
return pos;
}
+EXPORT_SYMBOL(pci_bus_find_capability);
/**
* pci_find_next_ext_capability - Find an extended capability
@@ -429,6 +431,7 @@ pci_find_parent_resource(const struct pci_dev *dev, struct
resource *res)
}
return best;
}
+EXPORT_SYMBOL(pci_find_parent_resource);
/**
* pci_wait_for_pending - wait for @mask bit(s) to clear in status word @pos
@@ -839,6 +842,7 @@ int pci_set_power_state(struct pci_dev *dev, pci_power_t
state)
return error;
}
+EXPORT_SYMBOL(pci_set_power_state);
/**
* pci_choose_state - Choose the power state of a PCI device
@@ -877,7 +881,6 @@ pci_power_t pci_choose_state(struct pci_dev *dev,
pm_message_t state)
}
return PCI_D0;
}
-
EXPORT_SYMBOL(pci_choose_state);
#define PCI_EXP_SAVE_REGS 7
@@ -1010,6 +1013,7 @@ pci_save_state(struct pci_dev *dev)
return i;
return 0;
}
+EXPORT_SYMBOL(pci_save_state);
static void pci_restore_config_dword(struct pci_dev *pdev, int offset,
u32 saved_val, int retry)
@@ -1080,6 +1084,7 @@ void pci_restore_state(struct pci_dev *dev)
dev->state_saved = false;
}
+EXPORT_SYMBOL(pci_restore_state);
struct pci_saved_state {
u32 config_space[16];
@@ -1219,6 +1224,7 @@ int pci_reenable_device(struct pci_dev *dev)
return do_pci_enable_device(dev, (1 << PCI_NUM_RESOURCES) - 1);
return 0;
}
+EXPORT_SYMBOL(pci_reenable_device);
static void pci_enable_bridge(struct pci_dev *dev)
{
@@ -1293,6 +1299,7 @@ int pci_enable_device_io(struct pci_dev *dev)
{
return pci_enable_device_flags(dev, IORESOURCE_IO);
}
+EXPORT_SYMBOL(pci_enable_device_io);
/**
* pci_enable_device_mem - Initialize a device for use with Memory space
@@ -1306,6 +1313,7 @@ int pci_enable_device_mem(struct pci_dev *dev)
{
return pci_enable_device_flags(dev, IORESOURCE_MEM);
}
+EXPORT_SYMBOL(pci_enable_device_mem);
/**
* pci_enable_device - Initialize device before it's used by a driver.
@@ -1322,6 +1330,7 @@ int pci_enable_device(struct pci_dev *dev)
{
return pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO);
}
+EXPORT_SYMBOL(pci_enable_device);
/*
* Managed PCI resources. This manages device on/off, intx/msi/msix
@@ -1404,6 +1413,7 @@ int pcim_enable_device(struct pci_dev *pdev)
}
return rc;
}
+EXPORT_SYMBOL(pcim_enable_device);
/**
* pcim_pin_device - Pin managed PCI device
@@ -1422,6 +1432,7 @@ void pcim_pin_device(struct pci_dev *pdev)
if (dr)
dr->pinned = 1;
}
+EXPORT_SYMBOL(pcim_pin_device);
/*
* pcibios_add_device - provide arch specific hooks when adding device dev
@@ -1511,6 +1522,7 @@ pci_disable_device(struct pci_dev *dev)
dev->is_busmaster = 0;
}
+EXPORT_SYMBOL(pci_disable_device);
/**
* pcibios_set_pcie_reset_state - set reset state for device dev
@@ -1539,6 +1551,7 @@ int pci_set_pcie_reset_state(struct pci_dev *dev, enum
pcie_reset_state state)
{
return pcibios_set_pcie_reset_state(dev, state);
}
+EXPORT_SYMBOL_GPL(pci_set_pcie_reset_state);
/**
* pci_check_pme_status - Check if given device has generated PME.
@@ -1618,6 +1631,7 @@ bool pci_pme_capable(struct pci_dev *dev, pci_power_t
state)
return !!(dev->pme_support & (1 << state));
}
+EXPORT_SYMBOL(pci_pme_capable);
static void pci_pme_list_scan(struct work_struct *work)
{
@@ -1724,6 +1738,7 @@ void pci_pme_active(struct pci_dev *dev, bool enable)
dev_dbg(>dev, "PME# %s\n", enable ? "enabled" : "disabled");
}
+EXPORT_SYMBOL(pci_pme_active);
/**
* __pci_enable_wake - enable PCI device as wakeup event source
@@ -1809,6 +1824,7 @@ int pci_wake_from_d3(struct pci_dev *dev, bool enable)
pci_enable_wake(dev, PCI_D3cold, enable) :
pci_enable_wake(dev, PCI_D3hot, enable);
}
+EXPORT_SYMBOL(pci_wake_from_d3);
/**
* pci_target_state - find an appropriate low power state for a given PCI dev
@@ -1887,6 +1903,7 @@ int pci_prepare_to_sleep(struct pci_dev *dev)
return error;
}
+EXPORT_SYMBOL(pci_prepare_to_sleep);
/**
*
RE: linux-next: build failure after merge of the spi tree
Hi Stephen/Mark, > -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Tuesday, April 15, 2014 7:47 AM > To: Mark Brown > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Harini > Katakam > Subject: linux-next: build failure after merge of the spi tree > > Hi Mark, > > After merging the spi tree, today's linux-next build (x86_64_allmodconfig) > failed like this: > > drivers/spi/spi-cadence.c: In function 'cdns_spi_write': > drivers/spi/spi-cadence.c:135:2: error: implicit declaration of function > 'writel_relaxed' [-Werror=implicit-function-declaration] > writel_relaxed(val, xspi->regs + offset); > ^ > I'm sorry - I just noticed that Soren's patches for I2C also gave a similar warning: http://patchwork.ozlabs.org/patch/337285/ I will send a patch adding dependency on ARCH_ZYNQ. Please let me know if you have a better suggestion. Regards, Harini -- 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 3/4] x86/insn: Extract more information about instructions
(2014/04/15 12:12), Masami Hiramatsu wrote: > (2014/04/15 2:44), Sasha Levin wrote: >> arch/x86/lib/x86-opcode-map.txt provides us quite a lot of information about >> instructions. So far we've discarded information we didn't need to use >> elsewhere. >> >> This patch extracts two more bits of information about instructions: > > These information looks obscure to me. What information (documents) > does it based on? Could you give me how would you get it? > >> - Mnemonic. We'd like to refer to instructions by their mnemonic, and not >> by their opcode. This both makes code readable, and less confusing and >> prone to typos since a single mnemonic may have quite a few different >> opcodes representing it. > > I don't like to call it as "mnemonic", it is just "operation". Ah, I see what you are doing now. Hmm, you'd like to generate a mnemonic-ID and its macros for each opcode, wouldn't you? Even though, it seems waste of memory that we have both opcode and mnemonic-ID, can you integrate that? for example, you can use insn->opcode.value instead of checking each opcode bytes. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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/
Re: [PATCH 00/38] tick cleanups and bugfixes
On 15 April 2014 05:08, Thomas Gleixner wrote: > And that's wrong to begin with. > > Bugfixes first and then all other stuff. We dont want dependencies of > bugfixes on cleanups, reordering of code ... Correct, should have taken care of this initially :( > Now looking at the thing some more, it contains gems like this: > > - printk(KERN_ERR "tick-broadcast: ignoring broadcast for " > - "offline CPU #%d\n", *oncpu); > + printk(KERN_ERR "tick-broadcast: ignoring broadcast for > offline CPU #%d\n", > + *oncpu); > > If you fix that checkpatch.pl line wrap issue, why do you not change > printk(KERN_ERR) to pr_err() as well? > > checkpatch.pl is happy, right? I did this for one patch and missed it for other.. I will fix all printk's in kernel/time/ now :) > Please send me the next series in the following way: > > - send a bug fix series, which does nothing else than fixing bugs. Right. > when that is applied, then > > - send a small batch of improvements for a particular issue and not a > mixed bag of random patches. Okay.. 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/
[PATCH V2] sched/core: fix formatting issues in sched_can_stop_tick()
sched_can_stop_tick() was using 7 spaces instead of 8 spaces or a 'tab' at the
beginning of each line. Which doesn't align with the Coding Guidelines.
Also it removes the *rq variable as it was used at only one place and hence we
can directly use this_rq() instead.
Signed-off-by: Viresh Kumar
---
V1->V2: Rebased over:
https://lkml.org/lkml/2014/3/19/456
kernel/sched/core.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1fadf61..3a4bb63 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -666,19 +666,15 @@ static inline bool got_nohz_idle_kick(void)
#ifdef CONFIG_NO_HZ_FULL
bool sched_can_stop_tick(void)
{
- struct rq *rq;
-
- rq = this_rq();
-
- /*
- * More than one running task need preemption.
- * nr_running update is assumed to be visible
- * after IPI is sent from wakers.
- */
- if (rq->nr_running > 1)
- return false;
+ /*
+* More than one running task need preemption.
+* nr_running update is assumed to be visible
+* after IPI is sent from wakers.
+*/
+ if (this_rq()->nr_running > 1)
+ return false;
- return true;
+ return true;
}
#endif /* CONFIG_NO_HZ_FULL */
--
1.7.12.rc2.18.g61b472e
--
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 v4 1/2] SPI: Add driver for Cadence SPI controller
Hi Mark, On Tue, Apr 15, 2014 at 1:31 AM, Mark Brown wrote: > On Mon, Apr 14, 2014 at 02:36:53PM +0530, Harini Katakam wrote: >> Add driver for Cadence SPI controller. This is used in Xilinx Zynq. > > Applied both, thanks. Please use subject lines consistent with the > style for the subsystem. Thanks! I'll keep that in mind. Regards, Harini -- 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/1] driver/net: cosa driver uses udelay incorrectly
From: "Li, Zhen-Hua" Date: Tue, 15 Apr 2014 09:53:11 +0800 > From: "Li, Zhen-Hua" > > In cosa driver, udelay with more than 2 may cause __bad_udelay. > Use msleep for instead. > > Signed-off-by: Li, Zhen-Hua Applied, thank you. -- 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] regulator: pbias: Convert to use regulator_[enable|is_enabled]_regmap
Since commit ca5d1b3524b4d
"regulator: helpers: Modify helpers enabling multi-bit control",
we can set enable_val setting for device that use multiple bits for control
when using regmap enable/disable/bypass ops.
Signed-off-by: Axel Lin
Tested-by: Balaji T K
---
drivers/regulator/pbias-regulator.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/pbias-regulator.c
b/drivers/regulator/pbias-regulator.c
index 6d38be3..708ddbb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -49,33 +49,13 @@ static const unsigned int pbias_volt_table[] = {
300
};
-static int pbias_regulator_enable(struct regulator_dev *rdev)
-{
- struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
- const struct pbias_reg_info *info = data->info;
-
- return regmap_update_bits(data->syscon, rdev->desc->enable_reg,
- info->enable_mask, info->enable);
-}
-
-static int pbias_regulator_is_enable(struct regulator_dev *rdev)
-{
- struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
- const struct pbias_reg_info *info = data->info;
- int value;
-
- regmap_read(data->syscon, rdev->desc->enable_reg, );
-
- return (value & info->enable_mask) == info->enable;
-}
-
static struct regulator_ops pbias_regulator_voltage_ops = {
.list_voltage = regulator_list_voltage_table,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
- .enable = pbias_regulator_enable,
+ .enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
- .is_enabled = pbias_regulator_is_enable,
+ .is_enabled = regulator_is_enabled_regmap,
};
static const struct pbias_reg_info pbias_mmc_omap2430 = {
@@ -180,6 +160,7 @@ static int pbias_regulator_probe(struct platform_device
*pdev)
drvdata[data_idx].desc.vsel_mask = info->vmode;
drvdata[data_idx].desc.enable_reg = res->start;
drvdata[data_idx].desc.enable_mask = info->enable_mask;
+ drvdata[data_idx].desc.enable_val = info->enable;
cfg.init_data = pbias_matches[idx].init_data;
cfg.driver_data = [data_idx];
--
1.8.1.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 30/38] tick-sched: move nohz_full_buf[] inside tick_nohz_init()
On 15 April 2014 04:58, Frederic Weisbecker wrote: > OTOH nohz_full_buf can have a big size and moving it to a local variable > will result in big increase in kernel stack consumption. > > Keeping it static is safer. > > Also it's already __initdata so it's released after bootup. No issue of > concurrent use either, so keeping it as is is fine. Okay, this patch is dropped. -- 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] mtd: nand: omap: fix compile warning on ‘erased_sector_bitflips’
>From: Jingoo Han [mailto:jg1@samsung.com] >>On Tuesday, April 15, 2014 7:32 AM, Christian Engelmayer wrote: >> >> Commit 2c9f2365 (mtd: nand: omap: ecc.calculate: merge >> omap3_calculate_ecc_bch4 >> in omap_calculate_ecc_bch) introduced minor compile warning >> "‘erased_sector_bitflips’ defined but not used [-Wunused-function]" when >> compiling without CONFIG_MTD_NAND_OMAP_BCH. Move function >> erased_sector_bitflips() into the same ifdef section as the only caller. >> >> Signed-off-by: Christian Engelmayer > >Reviewed-by: Jingoo Han > Thanks for the patch.. Acked-by: Pekon Gupta With regards, pekon
Re: [PATCH] sched/core: fix formatting issues in sched_can_stop_tick()
On 15 April 2014 04:18, Frederic Weisbecker wrote: > Right, I have a pending patch for that: > https://git.kernel.org/cgit/linux/kernel/git/frederic/linux-dynticks.git/commit/?h=nohz/ipi=ca981d9f87fe0f113ad972098cfe181180b3675a Cool!! I will rebase my patch over yours and resend. -- 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 22/38] tick-sched: no need to recheck cpu_online() in can_stop_idle_tick()
On 15 April 2014 01:22, Stephen Boyd wrote:
> On 04/14/14 09:23, Viresh Kumar wrote:
>> We have already checked if 'cpu' is online or not and so don't need to
>> recheck
>> it.
>>
>> Signed-off-by: Viresh Kumar
>
> Hm... doing some git archeology shows fa116ea35ec7 (nohz: no softirq
> pending warnings for offline cpus, 2008-12-11), where the cpu_online()
> check was added. Before that commit we already checked cpu_online()
> similar to how the code is today. Perhaps we need to add a comment here?
Okay, I didn't understood what you want completely. You want me to update
commit logs or drop this patch and update code?
But yes there is one more thing worth mentioning:
commit f7ea0fd6 (tick: Don't invoke tick_nohz_stop_sched_tick() if the cpu is
offline, May 13 2013), which did this:
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 0eed1db..0121421 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -469,6 +469,7 @@ static bool can_stop_idle_tick(int cpu, struct
tick_sched *ts)
if (unlikely(!cpu_online(cpu))) {
if (cpu == tick_do_timer_cpu)
tick_do_timer_cpu = TICK_DO_TIMER_NONE;
+ return false;
}
if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
So, when the patch you mentioned was added, we didn't had this and a
recheck of cpu_online() was perhaps required. But it is surely not required
anymore.
--
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 18/38] tick-common: don't set mode to CLOCK_EVT_MODE_UNUSED in tick_shutdown()
On 15 April 2014 01:08, Stephen Boyd wrote: > But see the comment above this assignment. The point is to avoid calling > the ->set_mode function. Okay, that was a stupid change :) -- 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 V3] tty: fix memleak in alloc_pid
There is memleak in alloc_pid:
--
unreferenced object 0xd3453a80 (size 64):
comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
hex dump (first 32 bytes):
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00 @.%.Y(..
backtrace:
[] kmemleak_alloc+0x3c/0xa0
[] kmem_cache_alloc+0xc6/0x190
[] alloc_pid+0x1e/0x400
[] copy_process.part.39+0xad4/0x1120
[] do_fork+0x99/0x330
[] sys_fork+0x28/0x30
[] syscall_call+0x7/0xb
[] 0x
the leak is due to unreleased pid->count, which execute in function:
get_pid()(pid->count++) and put_pid()(pid->count--).
The race condition as following:
task[dumpsys] task[adbd]
in disassociate_ctty() in tty_signal_session_leader()
--- -
tty = get_current_tty();
// tty is not NULL
...
spin_lock_irq(>sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(>sighand->siglock);
spin_lock_irq(>sighand->siglock);
...
p->signal->tty = NULL;
...
spin_unlock_irq(>sighand->siglock);
tty = get_current_tty();
// tty NULL, goto else branch by accident.
if (tty) {
...
put_pid(tty_session);
put_pid(tty_pgrp);
...
} else {
print msg
}
in task[dumpsys], in disassociate_ctty(), tty is set NULL by task[adbd],
tty_signal_session_leader(), then it goto else branch and lack of
put_pid(), cause memleak.
move spin_unlock(sighand->siglock) after get_current_tty() can avoid
the race and fix the memleak.
Signed-off-by: Zhang Jun
Signed-off-by: Chen Tingjie
---
drivers/tty/tty_io.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 31c4a57..72547a3 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -874,9 +874,8 @@ void disassociate_ctty(int on_exit)
spin_lock_irq(>sighand->siglock);
put_pid(current->signal->tty_old_pgrp);
current->signal->tty_old_pgrp = NULL;
- spin_unlock_irq(>sighand->siglock);
- tty = get_current_tty();
+ tty = tty_kref_get(current->signal->tty);
if (tty) {
unsigned long flags;
spin_lock_irqsave(>ctrl_lock, flags);
@@ -893,6 +892,7 @@ void disassociate_ctty(int on_exit)
#endif
}
+ spin_unlock_irq(>sighand->siglock);
/* Now clear signal->tty under the lock */
read_lock(_lock);
session_clear_tty(task_session(current));
--
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/
linux-next: Tree for Apr 15
Hi all, This tree still fails (more than usual) the powerpc allyesconfig build. Changes since 20140414: Dropped trees: akpm-current, akpm (too complex conflicts) The powerpc tree still had its build failure. The drm-intel tree gained a conflict against the drm-intel-fixes tree. The sound-asoc tree gained build failures so I used the version from next-20140414. The spi tree gained a build failure so I used the version from next-20140414. Non-merge commits (relative to Linus' tree): 730 1012 files changed, 14028 insertions(+), 12181 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" as mentioned in the FAQ on the wiki (see below). 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 and a multi_v7_defconfig for arm. 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 213 trees (counting Linus' and 28 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (55101e2d6ce1 Merge git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (0409726a81f2 ARC: fix mmuv2 warning) Merging arm-current/fixes (c9d347e02776 ARM: 8009/1: dcscb.c: remove call to outer_flush_all()) Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for v3.14-rc1) Merging metag-fixes/fixes (0414855fdc4a Linux 3.14-rc5) Merging powerpc-merge/merge (cc4f265ad9a3 powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self) Merging sparc/master (455c6fdbd219 Linux 3.14) Merging net/master (00cbc3dcd1e2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipsec/master (5596732fa8c1 xfrm: Fix crash with ipv6 IPsec tunnel and NAT.) Merging sound-current/for-linus (5e0c18799191 ALSA: es18xx driver should use udelay error) Merging pci-current/for-linus (140ab6452c42 powerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal) Merging wireless/master (c0da71ff4d2c wl18xx: align event mailbox with current fw) Merging driver-core.current/driver-core-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging tty.current/tty-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging usb.current/usb-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging staging.current/staging-linus (c9eaa447e77e Linux 3.15-rc1) Merging char-misc.current/char-misc-linus (b33ce4429938 Merge branch 'for-3.15/drivers' of git://git.kernel.dk/linux-block) Merging input-current/for-linus (692d96552c9a Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (eb4a5346e777 hwrng: bcm2835 - fix oops when rng h/w is accessed during registration) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for of_match_node()) Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter kernel symbols for arm) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling delayed works) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/s
Re: [PATCH] ext4: fix ext4_count_free_clusters() with EXT4FS_DEBUG and bigalloc enabled
On Mon, Apr 14, 2014 at 08:18:36PM +0400, Azat Khuzhin wrote: > With bigalloc enabled we must use EXT4_CLUSTERS_PER_GROUP() instead of > EXT4_BLOCKS_PER_GROUP() otherwise we will go beyond the allocated buffer. You forgot the signed-off-by, since it's a one-line patch, I'll apply it. Thanks! - Ted -- 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 -next 3.16 19/19] security: Convert use of typedef ctl_table to struct ctl_table
On Sun, 13 Apr 2014, Joe Perches wrote: > This typedef is unnecessary and should just be removed. > > Signed-off-by: Joe Perches > --- > security/keys/sysctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next -- James Morris -- 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: [3.14+] kernel BUG at mm/filemap.c:1347!
On Mon, 14 Apr 2014, Dave Jones wrote: > git tree from yesterday afternoon sometime, before Linus cut .15-rc1 > > kernel BUG at mm/filemap.c:1347! > invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > Modules linked in: 8021q garp bridge stp dlci snd_seq_dummy tun fuse rfcomm > ipt_ULOG nfnetlink llc2 af_key scsi_transport_iscsi hidp can_raw bnep can_bcm > nfc caif_socket caif af_802154 ieee802154 phonet af_rxrpc can pppoe pppox > ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 > psnap p8022 llc ax25 cfg80211 coretemp hwmon x86_pkg_temp_thermal kvm_intel > kvm snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic > snd_hda_intel snd_hda_controller btusb snd_hda_codec snd_hwdep bluetooth > snd_seq snd_seq_device snd_pcm xfs e1000e snd_timer crct10dif_pclmul snd > crc32c_intel libcrc32c ghash_clmulni_intel ptp 6lowpan_iphc rfkill usb_debug > shpchp soundcore pps_core microcode pcspkr serio_raw > CPU: 1 PID: 5440 Comm: trinity-c16 Not tainted 3.14.0+ #187 > task: 8801efe79ae0 ti: 8802082e4000 task.ti: 8802082e4000 > RIP: 0010:[] [] > find_get_pages_tag+0x1cb/0x220 > RSP: :8802082e5c70 EFLAGS: 00010246 > RAX: 7fff RBX: 000e RCX: 001d > RDX: 001d RSI: 880041c7d4f0 RDI: > RBP: 8802082e5cd0 R08: 2600 R09: ea00075104dc > R10: 0100 R11: 0228 R12: 8802082e5d08 > R13: 000a R14: 0101 R15: 8802082e5d20 > FS: 7f97c44f2740() GS:88024420() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0166d000 CR3: 00016515d000 CR4: 001407e0 > DR0: 015e9000 DR1: 00842000 DR2: 01da3000 > DR3: DR6: fffe0ff0 DR7: 0600 > Stack: > b815ad16 880067079da8 2681 > 26c0 7fff 4110b5bc 8802082e5d10 > ea0007477a80 8802082e5d90 2fd6 > Call Trace: > [] ? find_get_pages_tag+0x36/0x220 > [] pagevec_lookup_tag+0x21/0x30 > [] filemap_fdatawait_range+0xbe/0x1e0 > [] filemap_fdatawait+0x27/0x30 > [] sync_inodes_sb+0x204/0x2a0 > [] ? wait_for_completion+0xff/0x130 > [] ? vfs_fsync+0x40/0x40 > [] sync_inodes_one_sb+0x19/0x20 > [] iterate_supers+0xb2/0x110 > [] sys_sync+0x44/0xb0 > [] ia32_do_call+0x13/0x13 > Code: 89 c1 85 c9 0f 84 ee fe ff ff 8d 51 01 89 c8 f0 41 0f b1 11 39 c1 0f 84 > 20 ff ff ff eb e2 66 90 0f 0b 83 e7 01 0f 85 af fe ff ff <0f> 0b 0f 1f 00 e8 > ab 23 f1 ff 48 89 75 a8 e8 82 dd 00 00 48 8b > RIP [] find_get_pages_tag+0x1cb/0x220 > RSP > ---[ end trace ea01792c1c61cb22 ]--- > > > > 1343 /* > 1344 * This function is never used on a shmem/tmpfs > 1345 * mapping, so a swap entry won't be found here. > 1346 */ > 1347 BUG(); Thanks for finding that, Dave. Yes, it was me who put in that "shmem/tmpfs" comment and BUG(); but it's Hannes (Cc'ed) whom I'll blame for not removing the comment, in extending the use of radix_tree exceptional entries way beyond shmem/tmpfs in v3.15-rc1. (Of course I should have noticed.) As to the BUG(): at first I was aghast that it should have escaped all our mmotm/next testing of the last couple of months; but now realize that it is truly surprising for a PAGECACHE_TAG_WRITEBACK (and probably any other PAGECACHE_TAG_*) to appear on an exceptional entry. I expect it comes down to an occasional race in RCU lookup of the radix_tree: lacking absolute synchronization, we might sometimes catch an exceptional entry, with the tag which really belongs with the unexceptional entry which was there an instant before. (That's actually one of the reasons why I introduced exceptional entries, rather than tagging entries as exceptional: it's easier to synchonize a word with a bit in, than a word with a bit elsewhere.) Or I may be misreading it: whatever, Hannes will have a much surer grasp of what to do about it. It may be as simple as skipping over any exceptional entry in find_get_pages_tag() - that would be easy to provide as a quick fix if this BUG() starts to get in people's way. But I'd much prefer Hannes to consider the races, whether there's more to worry about, and provide a more thoughtful fix. (There are a few other "shmem/tmpfs" comments in mm/ that I put on exceptional entries in v3.1: again, I'd prefer Hannes to check through those, as he'll know best whether just to delete the comments now, or rewrite them, or update the code a little.) Hugh -- 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] workqueue: fix double unlock bug
Hi, Tejun
Acked-by: Lai Jiangshan
CC: sta...@kernel.org
Thanks,
Lai
On 04/15/2014 07:17 AM, Daeseok Youn wrote:
>
> Use default pwq when alloc_unbound_pwq() is failed.
>
> And remove "if" condition for whether "pwq" is same as "wq->dfl_pwq"
> when wq_calc_node_cpumask() returns false and just use "goto use_dfl_pwq"
>
> Signed-off-by: Daeseok Youn
> ---
> V2: replace "if condition" with "goto" as Lai's comment.
> V3: Use default pwq when alloc_unbound_pwq() is failed.
>
> kernel/workqueue.c |8 +++-
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 0ee63af..0679854 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -4087,10 +4087,7 @@ static void wq_update_unbound_numa(struct
> workqueue_struct *wq, int cpu,
> if (cpumask_equal(cpumask, pwq->pool->attrs->cpumask))
> goto out_unlock;
> } else {
> - if (pwq == wq->dfl_pwq)
> - goto out_unlock;
> - else
> - goto use_dfl_pwq;
> + goto use_dfl_pwq;
> }
>
> mutex_unlock(>mutex);
> @@ -4100,7 +4097,8 @@ static void wq_update_unbound_numa(struct
> workqueue_struct *wq, int cpu,
> if (!pwq) {
> pr_warning("workqueue: allocation failed while updating NUMA
> affinity of \"%s\"\n",
> wq->name);
> - goto out_unlock;
> + mutex_lock(>mutex);
> + goto use_dfl_pwq;
> }
>
> /*
--
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: [tip:x86/urgent] x86 idle: Repair large-server 50-watt idle-power regression
On Tue, 2014-04-08 at 21:43 +, Brown, Len wrote: > Davidlohr, > > Thanks for the note. > > Ideally (on Linux in general, and on servers, in particular) we strive > for the performance impact of power saving features to be small enough > to be considered in "measurement noise". > > Your report for 160 core Westmere AIM numbers being hit at 10-25% > shows 15% measurement noise? But even if true, this looks bad. > > Any chance you can re-run, with the following two tweaks, > one at a time? > > I'd be curious if you can wrap the invocation in turbostat -v > and capture that output to how what states we are seeing > during the benchmark run. Hi Len, apologies for the delay, I've been having to use my machine for other things and haven't gotten time to get around to this yet. I'll get you the requested information sometime this week. -- 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 0/2] nohz: fix idle accounting in NO_HZ kernels
Ping?
(2014/04/10 18:07), Hidetoshi Seto wrote:
> Hi all,
>
> This patch set (rebased on v3.14) is my 3rd try to fix an issue
> that idle/iowait of /proc/stat can go backward. Originally reported
> by Tetsuo and Fernando at last year, Mar 2013.
>
> This v3 takes new approach to fix the problem, and now use seqcount
> while v1 and v2 uses seqlock.
>
> Of course still reviews are welcome!
>
> Thanks,
> H.Seto
>
> Hidetoshi Seto (2):
> nohz: stop updating sleep stats from get_cpu_{idle,iowait}_time_us()
> nohz: use delayed iowait accounting to avoid race on idle time stats
>
> include/linux/tick.h |6 ++-
> kernel/time/tick-sched.c | 116
> --
> 2 files changed, 74 insertions(+), 48 deletions(-)
--
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/3] pinctrl: qcom: Add definitions for IPQ8064
This adds pinctrl definitions for the GPIO pins of the TLMM v2 block in the
Qualcomm IPQ8064 platform.
Signed-off-by: Andy Gross
---
drivers/pinctrl/Kconfig |8 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-ipq8064.c | 653 +
3 files changed, 662 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-ipq8064.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index aa3908f..917c46c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -222,6 +222,14 @@ config PINCTRL_MSM
select PINCONF
select GENERIC_PINCONF
+config PINCTRL_IPQ8064
+ tristate "Qualcomm IPQ8064 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found in the Qualcomm IPQ8064 platform.
+
config PINCTRL_APQ8064
tristate "Qualcomm APQ8064 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9e1fb67..a9dc61a 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PINCTRL_IMX23) += pinctrl-imx23.o
obj-$(CONFIG_PINCTRL_IMX25)+= pinctrl-imx25.o
obj-$(CONFIG_PINCTRL_IMX28)+= pinctrl-imx28.o
obj-$(CONFIG_PINCTRL_MSM) += pinctrl-msm.o
+obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
obj-$(CONFIG_PINCTRL_APQ8064) += pinctrl-apq8064.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
diff --git a/drivers/pinctrl/pinctrl-ipq8064.c
b/drivers/pinctrl/pinctrl-ipq8064.c
new file mode 100644
index 000..1700b49
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-ipq8064.c
@@ -0,0 +1,653 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+static const struct pinctrl_pin_desc ipq8064_pins[] = {
+ PINCTRL_PIN(0, "GPIO_1"),
+ PINCTRL_PIN(1, "GPIO_1"),
+ PINCTRL_PIN(2, "GPIO_2"),
+ PINCTRL_PIN(3, "GPIO_3"),
+ PINCTRL_PIN(4, "GPIO_4"),
+ PINCTRL_PIN(5, "GPIO_5"),
+ PINCTRL_PIN(6, "GPIO_6"),
+ PINCTRL_PIN(7, "GPIO_7"),
+ PINCTRL_PIN(8, "GPIO_8"),
+ PINCTRL_PIN(9, "GPIO_9"),
+ PINCTRL_PIN(10, "GPIO_10"),
+ PINCTRL_PIN(11, "GPIO_11"),
+ PINCTRL_PIN(12, "GPIO_12"),
+ PINCTRL_PIN(13, "GPIO_13"),
+ PINCTRL_PIN(14, "GPIO_14"),
+ PINCTRL_PIN(15, "GPIO_15"),
+ PINCTRL_PIN(16, "GPIO_16"),
+ PINCTRL_PIN(17, "GPIO_17"),
+ PINCTRL_PIN(18, "GPIO_18"),
+ PINCTRL_PIN(19, "GPIO_19"),
+ PINCTRL_PIN(20, "GPIO_20"),
+ PINCTRL_PIN(21, "GPIO_21"),
+ PINCTRL_PIN(22, "GPIO_22"),
+ PINCTRL_PIN(23, "GPIO_23"),
+ PINCTRL_PIN(24, "GPIO_24"),
+ PINCTRL_PIN(25, "GPIO_25"),
+ PINCTRL_PIN(26, "GPIO_26"),
+ PINCTRL_PIN(27, "GPIO_27"),
+ PINCTRL_PIN(28, "GPIO_28"),
+ PINCTRL_PIN(29, "GPIO_29"),
+ PINCTRL_PIN(30, "GPIO_30"),
+ PINCTRL_PIN(31, "GPIO_31"),
+ PINCTRL_PIN(32, "GPIO_32"),
+ PINCTRL_PIN(33, "GPIO_33"),
+ PINCTRL_PIN(34, "GPIO_34"),
+ PINCTRL_PIN(35, "GPIO_35"),
+ PINCTRL_PIN(36, "GPIO_36"),
+ PINCTRL_PIN(37, "GPIO_37"),
+ PINCTRL_PIN(38, "GPIO_38"),
+ PINCTRL_PIN(39, "GPIO_39"),
+ PINCTRL_PIN(40, "GPIO_40"),
+ PINCTRL_PIN(41, "GPIO_41"),
+ PINCTRL_PIN(42, "GPIO_42"),
+ PINCTRL_PIN(43, "GPIO_43"),
+ PINCTRL_PIN(44, "GPIO_44"),
+ PINCTRL_PIN(45, "GPIO_45"),
+ PINCTRL_PIN(46, "GPIO_46"),
+ PINCTRL_PIN(47, "GPIO_47"),
+ PINCTRL_PIN(48, "GPIO_48"),
+ PINCTRL_PIN(49, "GPIO_49"),
+ PINCTRL_PIN(50, "GPIO_50"),
+ PINCTRL_PIN(51, "GPIO_51"),
+ PINCTRL_PIN(52, "GPIO_52"),
+ PINCTRL_PIN(53, "GPIO_53"),
+ PINCTRL_PIN(54, "GPIO_54"),
+ PINCTRL_PIN(55, "GPIO_55"),
+ PINCTRL_PIN(56, "GPIO_56"),
+ PINCTRL_PIN(57, "GPIO_57"),
+ PINCTRL_PIN(58, "GPIO_58"),
+ PINCTRL_PIN(59, "GPIO_59"),
+ PINCTRL_PIN(60, "GPIO_60"),
+ PINCTRL_PIN(61, "GPIO_61"),
+ PINCTRL_PIN(62, "GPIO_62"),
+ PINCTRL_PIN(63, "GPIO_63"),
+ PINCTRL_PIN(64, "GPIO_64"),
+ PINCTRL_PIN(65, "GPIO_65"),
+ PINCTRL_PIN(66, "GPIO_66"),
+ PINCTRL_PIN(67, "GPIO_67"),
+ PINCTRL_PIN(68, "GPIO_68"),
+
+
[PATCH 2/3] dt: Document Qualcomm IPQ8064 pinctrl binding
Define a new binding for the Qualcomm TLMMv2 based pin controller inside the
IPQ8064.
Signed-off-by: Andy Gross
---
.../bindings/pinctrl/qcom,ipq8064-pinctrl.txt | 95
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
new file mode 100644
index 000..e0d35a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
@@ -0,0 +1,95 @@
+Qualcomm IPQ8064 TLMM block
+
+Required properties:
+- compatible: "qcom,ipq8064-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+The first cell is the gpio pin number and the
+second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+
+Valid values for qcom,pins are:
+ gpio0-gpio68
+ Supports mux, bias, and drive-strength
+
+ sdc3_clk, sdc3_cmd, sdc3_data
+ Supports bias and drive-strength
+
+
+Valid values for function are:
+ mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5,
+ gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1,
+ spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata,
+ pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt,
+ pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren,
+ pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n,
+ pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold
+
+Example:
+
+ pinmux: pinctrl@80 {
+ compatible = "qcom,ipq8064-pinctrl";
+ reg = <0x80 0x4000>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 32 0x4>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart_default>;
+
+ gsbi5_uart_default: gsbi5_uart_default {
+ mux {
+ pins = "gpio18", "gpio19";
+ function = "gsbi5";
+ };
+
+ tx {
+ pins = "gpio18";
+ drive-strength = <4>;
+ bias-disable;
+ };
+
+ rx {
+ pins = "gpio19";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 3/4] x86/insn: Extract more information about instructions
(2014/04/15 2:44), Sasha Levin wrote:
> arch/x86/lib/x86-opcode-map.txt provides us quite a lot of information about
> instructions. So far we've discarded information we didn't need to use
> elsewhere.
>
> This patch extracts two more bits of information about instructions:
These information looks obscure to me. What information (documents)
does it based on? Could you give me how would you get it?
> - Mnemonic. We'd like to refer to instructions by their mnemonic, and not
> by their opcode. This both makes code readable, and less confusing and
> prone to typos since a single mnemonic may have quite a few different
> opcodes representing it.
I don't like to call it as "mnemonic", it is just "operation".
> - Memory access size. We're currently decoding the size (in bytes) of an
> address size, and operand size. kmemcheck would like to know in addition
> how many bytes were read/written from/to an address by a given instruction,
> so we also keep the size of the memory access.
And also, at least in this time, since the operation/mem_size are
only used in kmemcheck, you should generate another table for that in kmemcheck
from x86-opcode-map.txt.
Hm, could you check out my private project repository of in-kernel disasm?
https://github.com/mhiramat/linux/tree/inkernel-disasm-20130414
it's a bit outdated, but I think you can do similar thing. :)
> /* Attribute checking functions */
> -static inline int inat_is_legacy_prefix(insn_attr_t attr)
> +static inline int inat_is_legacy_prefix(insn_flags_t flags)
> {
> - attr &= INAT_PFX_MASK;
> - return attr && attr <= INAT_LGCPFX_MAX;
> + flags &= INAT_PFX_MASK;
> + return flags && flags <= INAT_LGCPFX_MAX;
> }
Since "inat" stands for "instruction-attribute", it should have insn_attr_t.
And,
> @@ -141,15 +141,15 @@ void __kprobes synthesize_relcall(void *from, void *to)
> */
> static kprobe_opcode_t *__kprobes skip_prefixes(kprobe_opcode_t *insn)
> {
> - insn_attr_t attr;
> + insn_flags_t flags;
>
> - attr = inat_get_opcode_attribute((insn_byte_t)*insn);
> - while (inat_is_legacy_prefix(attr)) {
> + flags = inat_get_opcode((insn_byte_t)*insn)->flags;
Do not refer a member from the return value directly. If it returns NULL,
the kernel just crashes!
> @@ -61,6 +63,17 @@ BEGIN {
> imm_flag["Ov"] = "INAT_MOFFSET"
> imm_flag["Lx"] = "INAT_MAKE_IMM(INAT_IMM_BYTE)"
>
> + mem_expr = "^[EQXY][a-z]"
> + mem_flag["Ev"] = "-1"
> + mem_flag["Eb"] = "1"
> + mem_flag["Ew"] = "2"
> + mem_flag["Ed"] = "4"
> + mem_flag["Yb"] = "1"
> + mem_flag["Xb"] = "1"
> + mem_flag["Yv"] = "-1"
> + mem_flag["Xv"] = "-1"
> + mem_flag["Qd"] = "8"
> +
mem_flag? mem_size?
> @@ -232,7 +256,7 @@ function add_flags(old,new) {
> }
>
> # convert operands to flags.
> -function convert_operands(count,opnd, i,j,imm,mod)
> +function convert_operands(count,opnd,i,j,imm,mod)
Don't remove this space, that separates input arguments and local variables.
> @@ -281,15 +318,23 @@ function convert_operands(count,opnd, i,j,imm,mod)
> i = 2
> while (i <= NF) {
> opcode = $(i++)
> + if (!(opcode in opcode_list)) {
> + opcode_list[opcode] = opcode
> + gsub(/[^A-Za-z0-9 \t]/, "_", opcode_list[opcode])
> + print "#define INSN_OPC_" opcode_list[opcode] " "
> opcode_cnt
> + opcode_cnt++
> + }
No, don't do that. Defining some immediate macros in auto-generated header makes
code maintenance hard.
BTW, could you make a cover mail for the series?
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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 0/3] pinctrl: qcom: Add IPQ8064 pinctrl support
This set of patches adds pinctrl support for the Qualcomm IPQ8064 platform. The IPQ8064 uses the same TLMM block as the APQ8064, but has a different number of pins, functions, and function assignments. The second patch contains the devicetree documentation. The last patch selects PINCTRL for all ARCH_QCOM platforms. This allows for selection of pinctrl support via a make menuconfig. Andy Gross (3): pinctrl: qcom: Add definitions for IPQ8064 dt: Document Qualcomm IPQ8064 pinctrl binding ARM: qcom: Select PINCTRL by default for ARCH_QCOM .../bindings/pinctrl/qcom,ipq8064-pinctrl.txt | 95 +++ arch/arm/mach-qcom/Kconfig |1 + drivers/pinctrl/Kconfig|8 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-ipq8064.c | 653 5 files changed, 758 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-ipq8064.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 3/3] ARM: qcom: Select PINCTRL by default for ARCH_QCOM
Add missing PINCTRL selection. This enables selection of pinctrollers for Qualcomm processors. Signed-off-by: Andy Gross --- arch/arm/mach-qcom/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig index aded06d..2c561c0 100644 --- a/arch/arm/mach-qcom/Kconfig +++ b/arch/arm/mach-qcom/Kconfig @@ -5,6 +5,7 @@ config ARCH_QCOM select CLKSRC_OF select GENERIC_CLOCKEVENTS select HAVE_SMP + select PINCTRL select QCOM_SCM if SMP help Support for Qualcomm's devicetree based systems. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: Re: [PATCH 2/4] x86: Move instruction decoder data into header
(2014/04/15 11:28), Sasha Levin wrote: > On 04/14/2014 09:41 PM, Masami Hiramatsu wrote: >> (2014/04/15 2:44), Sasha Levin wrote: Right now we generate data for the instruction decoder and place it as a code file which gets #included directly (yuck). Instead, make it a header which will also be usable by other code that wants to use the data in there. >> Hmm, making the generated data into a header file may clone >> the data table instances for each object file. Since the inat >> table is not so small, I think we'd better just export the tables. > > The tables are defined as static, so the compiler drops them > once it detects they are not used. No, I meant that if the table is used in the different object files, will the copies of the tables be compiled in several different instances? And I can't see the part which makes the tables static in this patch... > I feel it would be easier to let the compiler do it's job rather > than do optimizations we don't need to do and which will complicate > the code quite a bit. I haven't tend to optimize it, but just encapsulate it, to hide from other parts. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.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/
RE: [PATCH] [PATCH V2] tty: memleak in alloc_pid
> > Change-Id: Ic960dda039c8f99aad3e0f4d176489a966c62f6a > > > > Why is this line here? > Tingjie, Greg is asking you the sentence of "Change-Id", which is not needed, > please remove it with one new patch. Sorry for mistaken, I will make a new patch for it. -- 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 0/5] perf: Create hist_entry groups
Hi Don, On Thu, 10 Apr 2014 16:10:56 -0400, Don Zickus wrote: > This patchset creates a new layer of hist entry objects called > hist_entry_groups. The purpose is to help organize the hist_entries > into groups before sorting them. As a result you can gain a > new perspective on the data by organizing the groups into cpu, pid > or cacheline. See patch 5 for sample output. > > The main driver for this patchset is to find a way to sort and display > cacheline data in a way that is useful. My previous attempts seemed > hackish until I realized cacheline sorting is really just a collection > of hist_entries. Anyway that was my focus for doing this. > > The overall idea looks like: > > evlist > evsel > hists > hist_entry_group <<< new object > hist_entry > > > Implementing this was not pretty. I tried to seperate the patches the > best I could. But in order for each patch to compile, patch 4 turned into > a 1400 line diff that is mostly noise. > > Also, this patchset breaks most tools (mainly because I don't understand > all the interactions), hence the RFC. I mostly tested with 'perf report > --stdio' and 'perf mem report --stdio'. > > Please let me know if this is an interesting idea to go forward with or not. I'd like to show you my previous two patchsets. The first one is for adding --field option and changing the sort behavior little different [1]. I'm about to send a new version to the list soon. I think what you want to do is sorting output by an order of sort keys not just by the overhead. So with the patchset applied, you can do it like: $ perf report --field overhead,pid,dso,sym --sort pid # Overhead Command: Pid Shared Object # . ... # 32.93% swapper:0 [kernel.kallsyms] [k] intel_idle 6.79% swapper:0 [kernel.kallsyms] [k] enqueue_entity 1.42% swapper:0 [kernel.kallsyms] [k] update_sd_lb_stats 1.30% swapper:0 [kernel.kallsyms] [k] timekeeping_max_deferme 1.18% swapper:0 [kernel.kallsyms] [k] update_cfs_shares 1.07% swapper:0 [kernel.kallsyms] [k] __irq_work_run 0.96% swapper:0 [kernel.kallsyms] [k] rcu_check_callbacks 0.64% swapper:0 [kernel.kallsyms] [k] irqtime_account_process 0.50% swapper:0 [kernel.kallsyms] [k] int_sqrt 0.47% swapper:0 [kernel.kallsyms] [k] __tick_nohz_idle_enter 0.47% swapper:0 [kernel.kallsyms] [k] menu_select 0.35% swapper:0 [kernel.kallsyms] [k] run_timer_softirq 0.16% swapper:0 [kernel.kallsyms] [k] __perf_event_enable 0.12% swapper:0 [kernel.kallsyms] [k] rcu_eqs_exit_common.isr 0.50% watchdog/6: 37 [kernel.kallsyms] [k] update_sd_lb_stats 3.45%Xorg: 1335 [kernel.kallsyms] [k] schedule 6.55% gnome-terminal: 1903 libc-2.17.so [.] __strcmp_sse42 1.59% firefox: 2137 [kernel.kallsyms] [k] cpuacct_charge 0.50% emacs: 2473 emacs-24.1 [.] 0x0012241a 0.38% emacs: 2473 emacs-24.1 [.] 0x000bfbf7 0.31% emacs: 2473 emacs-24.1 [.] 0x001780dd 0.29% emacs: 2473 emacs-24.1 [.] 0x0002eb48 4.40% kworker/7:1:11028 [kernel.kallsyms] [k] generic_exec_single 1.30% kworker/0:0:25667 [kernel.kallsyms] [k] generic_exec_single 5.93% kworker/5:1:26447 [kernel.kallsyms] [k] generic_exec_single 2.06% kworker/1:2:26653 [kernel.kallsyms] [k] generic_exec_single As you can see the output is now sorted by pid value (and then overhead, dso, sym if previous key resulted in a same value), so swapper (pid 0) comes first and then watchdog/6, Xorg, and so on.. But it's not guarantee that the hottest pid comes always first on the output, it just sorted it by pid and it gets the result simply because the system was idle mostly. I think you can handle it in your c2c tool properly though. Another one I'd like to introduce is somewhat similar to your work. It's called hierarchy view and groups each entries according to sort keys [2]. But it only supported --gtk output at that time (in order not to make the hands dirty unnecessarily ;-) and (thus?) didn't get much review. But I think the idea is same and requires less change by just adding few fields (rb_root) to hist_entry instead of new data structure. Thanks, Namhyung [1] https://lkml.org/lkml/2014/3/19/689 [2] https://lkml.org/lkml/2013/5/21/24 -- To unsubscribe from
Re: [PATCHSET cgroup/for-3.15] cgroup: implement unified hierarchy
on 2014/4/15 3:21, Tejun Heo wrote: > Hello, > > On Mon, Apr 14, 2014 at 02:14:21PM -0400, Vivek Goyal wrote: >> So is this an intermediate mode before we move to single hiearchy *only* >> mode. AFAIK, you had mentioned that we will support legacy multiple >> hiearchy mode but single hiearchy is the new default mode. > > Hmmm? It's a separate special hierarchy which can co-exist with other > hierarchies. There's no inherent intermediacy to it. As long as > traditional hierarchies exist, it's gonna be like this. > I know we should allow multiple hierarchies, but why we allow this even if sane_behavior is specified? Like this: # mount -t cgroup -o cpuset,__DEVEL__sane_behavior xxx /cgroup # mount -t cgroup -o __DEVEL__sane_behavior xxx /cgroup2/ -- 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] [PATCH V2] tty: memleak in alloc_pid
> > Change-Id: Ic960dda039c8f99aad3e0f4d176489a966c62f6a > > Why is this line here? Tingjie, Greg is asking you the sentence of "Change-Id", which is not needed, please remove it with one new patch. -- 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/2] x86, MCE: Cleanup macro __get_cpu_var
On Mon, Apr 14, 2014 at 09:23:08AM -0700, H. Peter Anvin wrote: > Please read Documentation/this_cpu_ops.txt for reference for how to use > these functions. However, you want to avoid forming a pointer if you > can; it is relatively expensive to do so. > :-). I just found your comment yesterday so that I was eager to finish it. I should do more homework as you told and send it again. Thanks very much for your patience. signature.asc Description: Digital signature
Re: [RFC PATCH v2] memory-hotplug: Update documentation to hide information about SECTIONS and remove end_phys_index
On Mon, 2014-04-14 at 17:13 +0800, Zhang Yanfei wrote: > On 04/14/2014 04:43 PM, Li Zhong wrote: > > Seems we all agree that information about SECTION, e.g. section size, > > sections per memory block should be kept as kernel internals, and not > > exposed to userspace. > > > > This patch updates Documentation/memory-hotplug.txt to refer to memory > > blocks instead of memory sections where appropriate and added a > > paragraph to explain that memory blocks are made of memory sections. > > The documentation update is mostly provided by Nathan. > > > > Also, as end_phys_index in code is actually not the end section id, but > > the end memory block id, which should always be the same as phys_index. > > So it is removed here. > > > > Signed-off-by: Li Zhong > > Reviewed-by: Zhang Yanfei > > Still the nitpick there. Ao.. Will fix it in next version. Thanks, Zhong > > > --- > > Documentation/memory-hotplug.txt | 125 > > +++--- > > drivers/base/memory.c| 12 > > 2 files changed, 61 insertions(+), 76 deletions(-) > > > > diff --git a/Documentation/memory-hotplug.txt > > b/Documentation/memory-hotplug.txt > > index 58340d5..1aa239f 100644 > > --- a/Documentation/memory-hotplug.txt > > +++ b/Documentation/memory-hotplug.txt > > @@ -88,16 +88,21 @@ phase by hand. > > > > 1.3. Unit of Memory online/offline operation > > > > -Memory hotplug uses SPARSEMEM memory model. SPARSEMEM divides the whole > > memory > > -into chunks of the same size. The chunk is called a "section". The size of > > -a section is architecture dependent. For example, power uses 16MiB, ia64 > > uses > > -1GiB. The unit of online/offline operation is "one section". (see Section > > 3.) > > +Memory hotplug uses SPARSEMEM memory model which allows memory to be > > divided > > +into chunks of the same size. These chunks are called "sections". The size > > of > > +a memory section is architecture dependent. For example, power uses 16MiB, > > ia64 > > +uses 1GiB. > > > > -To determine the size of sections, please read this file: > > +Memory sections are combined into chunks referred to as "memory blocks". > > The > > +size of a memory block is architecture dependent and represents the logical > > +unit upon which memory online/offline operations are to be performed. The > > +default size of a memory block is the same as memory section size unless an > > +architecture specifies otherwise. (see Section 3.) > > + > > +To determine the size (in bytes) of a memory block please read this file: > > > > /sys/devices/system/memory/block_size_bytes > > > > -This file shows the size of sections in byte. > > > > --- > > 2. Kernel Configuration > > @@ -123,42 +128,35 @@ config options. > > (CONFIG_ACPI_CONTAINER). > > This option can be kernel module too. > > > > + > > > > -4 sysfs files for memory hotplug > > +3 sysfs files for memory hotplug > > > > -All sections have their device information in sysfs. Each section is part > > of > > -a memory block under /sys/devices/system/memory as > > +All memory blocks have their device information in sysfs. Each memory > > block > > +is described under /sys/devices/system/memory as > > > > /sys/devices/system/memory/memoryXXX > > -(XXX is the section id.) > > +(XXX is the memory block id.) > > > > -Now, XXX is defined as (start_address_of_section / section_size) of the > > first > > -section contained in the memory block. The files 'phys_index' and > > -'end_phys_index' under each directory report the beginning and end section > > id's > > -for the memory block covered by the sysfs directory. It is expected that > > all > > +For the memory block covered by the sysfs directory. It is expected that > > all > > memory sections in this range are present and no memory holes exist in the > > range. Currently there is no way to determine if there is a memory hole, > > but > > the existence of one should not affect the hotplug capabilities of the > > memory > > block. > > > > -For example, assume 1GiB section size. A device for a memory starting at > > +For example, assume 1GiB memory block size. A device for a memory starting > > at > > 0x1 is /sys/device/system/memory/memory4 > > (0x1 / 1Gib = 4) > > This device covers address range [0x1 ... 0x14000) > > > > -Under each section, you can see 4 or 5 files, the end_phys_index file being > > -a recent addition and not present on older kernels. > > +Under each memory block, you can see 4 files: > > > > -/sys/devices/system/memory/memoryXXX/start_phys_index > > -/sys/devices/system/memory/memoryXXX/end_phys_index > > +/sys/devices/system/memory/memoryXXX/phys_index > > /sys/devices/system/memory/memoryXXX/phys_device > > /sys/devices/system/memory/memoryXXX/state > > /sys/devices/system/memory/memoryXXX/removable > > > >
RE: [PATCH] [PATCH V2] tty: memleak in alloc_pid
Hello,
The related code in disassociate_ctty() as following:
---
/* sometimes current->signal->tty_old_pgrp is NULL(a stand for
tty_old_pgrp not NULL, !a for tty_old_pgrp is NULL) */
spin_lock_irq(>sighand->siglock);
put_pid(current->signal->tty_old_pgrp);// when a is NULL, will
not actually put_pid() by decrease the count
current->signal->tty_old_pgrp = NULL;
spin_unlock_irq(>sighand->siglock);
/* sometimes current->signal->tty is NULL (b stand for signal->tty, !b
for signal->tty is NULL) */
tty = get_current_tty();
if (tty) {
unsigned long flags;
spin_lock_irqsave(>ctrl_lock, flags);
put_pid(tty->session);
put_pid(tty->pgrp);
tty->session = NULL;
tty->pgrp = NULL;
spin_unlock_irqrestore(>ctrl_lock, flags);
tty_kref_put(tty);
} else {
#ifdef TTY_DEBUG_HANGUP
printk(KERN_DEBUG "error attempted to write to tty [0x%p]"
" = NULL", tty);
#endif
}
Commonly there are 2 normal case flow for the code:
1/ in task: getprop: !a --> b
This case, current->signal->tty_old_pgrp is NULL, but get_current_tty() is
not NULL,
Really put_pid() as following:
put_pid(tty->session);
put_pid(tty->pgrp);
2/ in task: dumpsys: a --> !b
This case, currnet->signal->tty_old_pgrp is not NULL, but get_current_tty()
is NULL,
Really put_pid() as following:
put_pid(current->signal->tty_old_pgrp);
There is one abnormal case:
3/ in task: dumpsys: !a -> !b
This case, because of race, current->signal->tty_old_pgrp and
get_current_tty() are NULL,
Lack of put_pid(), pid->count will not be 0 at last, this pid will be leak.
When read the current->signal->tty_old_pgrp and current->signal->tty,
The 2 operations should be atomic, which protected by spinlock:
current->sighand->siglock.
So the sentence: spin_unlock_irq(>sighand->siglock);
need to move down after tty has process completed.
Thanks,
-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Monday, April 14, 2014 7:47 PM
To: Chen, Tingjie
Cc: Jiri Slaby; linux-kernel@vger.kernel.org; Zhang, Jun
Subject: Re: [PATCH] [PATCH V2] tty: memleak in alloc_pid
On Mon, Apr 14, 2014 at 03:31:15PM +0800, Chen Tingjie wrote:
> There is memleak in alloc_pid:
> --
> unreferenced object 0xd3453a80 (size 64):
> comm "adbd", pid 1730, jiffies 66363 (age 6586.950s)
> hex dump (first 32 bytes):
> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 40 c2 f6 d5 00 d3 25 c1 59 28 00 00 @.%.Y(..
> backtrace:
> [] kmemleak_alloc+0x3c/0xa0
> [] kmem_cache_alloc+0xc6/0x190
> [] alloc_pid+0x1e/0x400
> [] copy_process.part.39+0xad4/0x1120
> [] do_fork+0x99/0x330
> [] sys_fork+0x28/0x30
> [] syscall_call+0x7/0xb
> [] 0x
>
> the leak is due to unreleased pid->count, which execute in function:
> get_pid()(pid->count++) and put_pid()(pid->count--).
>
> The race condition as following:
> task[dumpsys] task[adbd]
> in disassociate_ctty() in tty_signal_session_leader()
> --- -
> tty = get_current_tty();
> // tty is not NULL
> ...
> spin_lock_irq(>sighand->siglock);
> put_pid(current->signal->tty_old_pgrp);
> current->signal->tty_old_pgrp = NULL;
> spin_unlock_irq(>sighand->siglock);
>
> spin_lock_irq(>sighand->siglock);
> ...
> p->signal->tty = NULL;
> ...
> spin_unlock_irq(>sighand->siglock);
>
> tty = get_current_tty();
> // tty NULL, goto else branch by accident.
> if (tty) {
> ...
> put_pid(tty_session);
> put_pid(tty_pgrp);
> ...
> } else {
> print msg
> }
>
> in task[dumpsys], in disassociate_ctty(), tty is set NULL by
> task[adbd], tty_signal_session_leader(), then it goto else branch and
> lack of put_pid(), cause memleak.
>
> move spin_unlock(sighand->siglock) after get_current_tty() can avoid
> the race and fix the memleak.
>
> Change-Id: Ic960dda039c8f99aad3e0f4d176489a966c62f6a
Why is this line here?
--
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 v3] Use kernfs_break_active_protection() for device online store callbacks
On Mon, 2014-04-14 at 16:13 -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 14, 2014 at 03:47:29PM +0800, Li Zhong wrote:
> > @@ -439,6 +439,7 @@ static ssize_t online_store(struct device *dev, struct
> > device_attribute *attr,
> > {
> > bool val;
> > int ret;
> > + struct kernfs_node *kn;
> >
> > ret = strtobool(buf, );
> > if (ret < 0)
> > @@ -448,7 +449,19 @@ static ssize_t online_store(struct device *dev, struct
> > device_attribute *attr,
> > if (ret)
> > return ret;
> >
> > + kn = kernfs_find_and_get(dev->kobj.sd, attr->attr.name);
> > + if (WARN_ON_ONCE(!kn))
> > + goto out;
> > +
> > + get_device(dev);
> > + kernfs_break_active_protection(kn);
> > ret = val ? device_online(dev) : device_offline(dev);
> > + kernfs_unbreak_active_protection(kn);
> > + put_device(dev);
> > +
> > + kernfs_put(kn);
> > +
> > +out:
> > unlock_device_hotplug();
> > return ret < 0 ? ret : count;
> > }
>
> Can you please add comment explainin why this is being down? As it
> currently stands, it's quite a bit of complexity without any
> indication what's going on why. Also, if device_hotplug is locked, is
> it really necessary to get @dev? Can it go away inbetween? The code
> snippet looks weird because getting @dev indicates that the device
> might go away without doing it but then it proceeds to invoke
> device_{on|off}line() which probably isn't safe to invoke on a removed
> device.
Hi Tejun,
I tried to write some draft words here... (I'm not good at writing
it...) Could you please help to have a review and comment? thanks.
/ *
* This process might deadlock with another process trying to
* remove this device:
* This process holding the s_active of "online" attribute, and tries
* to online/offline the device with some locks protecting hotplug.
* Device removing process holding some locks protecting hotplug, and
* tries to remove the "online" attribute, waiting for the s_active to
* be released.
*
* The deadlock described above should be solved with
* lock_device_hotplug_sysfs(). We temporarily drop the active
* protection here to avoid some lockdep warnings.
*
* If device_hotplug_lock is forgotten to be used when removing
* device(possibly some very simple device even don't need this lock?),
* @dev could go away any time after dropping the active protection.
* So increase its ref count before dropping active protection.
* Though invoking device_{on|off}line() on a removed device seems
* unreasonable, it should be less disastrous than playing with freed
* @dev. Also, we might be able to have some mechanism abort
* device_{on|off}line() if @dev already removed.
*/
Thanks, Zhong
>
> 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: [PATCH] ASoC: fsl_sai: Fix incorrect condition check in trigger()
On Mon, Apr 14, 2014 at 09:31:26PM +0100, Mark Brown wrote:
> On Fri, Apr 11, 2014 at 10:10:00PM +0800, Nicolin Chen wrote:
>
> > + /* Check if the opposite FRDE is also disabled */
> > + if (!(tx ? rcsr & FSL_SAI_CSR_FRDE : tcsr & FSL_SAI_CSR_FRDE)) {
>
> I've applied this since it's a fix but this is *not* a triumph of
> legibility, the ternery operator is often not helpful.
It looks like I've got a bad habit again. I'll be careful next time.
Thank you for reminding me,
Nicolin
--
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] iommu/vt-d: fix bug in matching PCI devices with DRHD/RMRR descriptors
Commit "59ce0515cdaf iommu/vt-d: Update DRHD/RMRR/ATSR device scope
caches when PCI hotplug happens" introduces a bug, which fails to
match PCI devices with DMAR device scope entries if PCI path array
in the entry has more than one level.
For example, it fails to handle
[1D2h 0466 1] Device Scope Entry Type : 01
[1D3h 0467 1] Entry Length : 0A
[1D4h 0468 2] Reserved :
[1D6h 0470 1] Enumeration ID : 00
[1D7h 0471 1] PCI Bus Number : 00
[1D8h 0472 2] PCI Path : 1C,04
[1DAh 0474 2] PCI Path : 00,02
And cause DMA failure on HP DL980 as:
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.2] fault addr 7f61e000
Reported-and-tested-by: Davidlohr Bueso
Signed-off-by: Jiang Liu
---
Hi David and Davidlohr,
I have made minor syntax change to the patch, but there should be no
functional change.
Thanks!
Gerry
---
drivers/iommu/dmar.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index f445c10df8df..39f8b717fe84 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -152,7 +152,8 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev, unsigned
long event)
info->seg = pci_domain_nr(dev->bus);
info->level = level;
if (event == BUS_NOTIFY_ADD_DEVICE) {
- for (tmp = dev, level--; tmp; tmp = tmp->bus->self) {
+ for (tmp = dev; tmp; tmp = tmp->bus->self) {
+ level--;
info->path[level].device = PCI_SLOT(tmp->devfn);
info->path[level].function = PCI_FUNC(tmp->devfn);
if (pci_is_root_bus(tmp->bus))
--
1.7.10.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/
Re: [PATCH v2 2/2] ARM: dts: Append clock bindings for sai2 on VF610 platform
On Mon, Apr 14, 2014 at 09:38:51PM +0100, Mark Brown wrote: > On Wed, Apr 02, 2014 at 06:10:20PM +0800, Nicolin Chen wrote: > > Since we added fours clock to the DT binding, we should update the current > > SAI dts/dtsi so as not to break their functions. > > This doesn't apply against v3.15-rc1, can you please check and resend? Please disregard this patch, since my v6 patch was compatible with the old binding, the patch here is provisionally useless and I can later send it via Shawn's tree. Thank you, Nicolin -- 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] ASoC: fsl_sai: Add clock controls for SAI
On Mon, Apr 14, 2014 at 09:43:31PM +0100, Mark Brown wrote: > On Wed, Apr 02, 2014 at 06:10:19PM +0800, Nicolin Chen wrote: > > > -- clock-names : Must include the "sai" entry. > > +- clock-names : Must include the "bus" for register access and "mclk1" > > "mclk2" > > + "mclk3" for bit clock and frame clock providing. > > This breaks compatibilty with old DTs - it just removes the "sai" name. > It's OK to deprecate the "sai" clock name but you need to keep support > for DTs that only specify that, there's no code for that left in the > driver. Sir, you've already applied the v6 of this patch last week :) And I can still find it in topic/fsl-sai. ca3e35c ASoC: fsl_sai: Add clock controls for SAI And regarding the old DTs compatibilty, Shawn has already reminded me in his comments against one of the version. I took his advice and made the patch compatible with the old 'sai' clock binding within that v6. Thank you, Nicolin -- 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] x86: Move instruction decoder data into header
On 04/14/2014 09:41 PM, Masami Hiramatsu wrote: > (2014/04/15 2:44), Sasha Levin wrote: >> > Right now we generate data for the instruction decoder and place it >> > as a code file which gets #included directly (yuck). >> > >> > Instead, make it a header which will also be usable by other code >> > that wants to use the data in there. > Hmm, making the generated data into a header file may clone > the data table instances for each object file. Since the inat > table is not so small, I think we'd better just export the tables. The tables are defined as static, so the compiler drops them once it detects they are not used. I feel it would be easier to let the compiler do it's job rather than do optimizations we don't need to do and which will complicate the code quite a bit. Thanks, Sasha -- 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: [PATCHSET cgroup/for-3.16] cgroup: implement unified hierarchy, v2
> This patchset finally implements the default unified hierarchy. The > goal is providing enough flexibility while enforcing stricter common > structure where appropriate to address the above listed issues. > > Controllers which aren't bound to other hierarchies are > automatically attached to the unified hierarchy, which is different in > that controllers are enabled explicitly for each subtree. > "cgroup.subtree_control" controls which controllers are enabled on the > child cgroups. Let's assume a hierarchy like the following. > > root - A - B - C >\ D > > root's "cgroup.subtree_control" determines which controllers are > enabled on A. A's on B. B's on C and D. This coincides with the > fact that controllers on the immediate sub-level are used to > distribute the resources of the parent. In fact, it's natural to > assume that resource control knobs of a child belong to its parent. > Enabling a controller in "cgroup.subtree_control" declares that > distribution of the respective resources of the cgroup will be > controlled. Note that this means that controller enable states are > shared among siblings. > > The default hierarchy has an extra restriction - only cgroups which > don't contain any task may have controllers enabled in > "cgroup.subtree_control". Combined with the other properties of the > default hierarchy, this guarantees that, from the view point of > controllers, tasks are only on the leaf cgroups. In other words, only > leaf csses may contain tasks. This rules out situations where child > cgroups compete against internal tasks of the parent. > Right after bootup: # mount -t cgroup -o __DEVEL__sane_behavior xxx /mnt # ls /mnt cgroup.controllers cgroup.procs cgroup.sane_behavior cgroup.subtree_control # cat /mnt/cgroup.controllers cpuset cpu cpuacct memory devices freezer net_cls blkio perf_event hugetlb I don't see any controller knobs... -- 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: build failure after merge of the spi tree
Hi Mark,
After merging the spi tree, today's linux-next build (x86_64_allmodconfig)
failed like this:
drivers/spi/spi-cadence.c: In function 'cdns_spi_write':
drivers/spi/spi-cadence.c:135:2: error: implicit declaration of function
'writel_relaxed' [-Werror=implicit-function-declaration]
writel_relaxed(val, xspi->regs + offset);
^
Caused by commit c474b3866546 ("spi: Add driver for Cadence SPI controller").
I have used the spi tree from next-20140414 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpDcsU0U1Nb_.pgp
Description: PGP signature
Re: [PATCH -mm 1/4] memcg, slab: do not schedule cache destruction when last page goes away
On Wed, Apr 09, 2014 at 07:02:30PM +0400, Vladimir Davydov wrote: > After the memcg is offlined, we mark its kmem caches that cannot be > deleted right now due to pending objects as dead by setting the > memcg_cache_params::dead flag, so that memcg_release_pages will schedule > cache destruction (memcg_cache_params::destroy) as soon as the last slab > of the cache is freed (memcg_cache_params::nr_pages drops to zero). > > I guess the idea was to destroy the caches as soon as possible, i.e. > immediately after freeing the last object. However, it just doesn't work > that way, because kmem caches always preserve some pages for the sake of > performance, so that nr_pages never gets to zero unless the cache is > shrunk explicitly using kmem_cache_shrink. Of course, we could account > the total number of objects on the cache or check if all the slabs > allocated for the cache are empty on kmem_cache_free and schedule > destruction if so, but that would be too costly. > > Thus we have a piece of code that works only when we explicitly call > kmem_cache_shrink, but complicates the whole picture a lot. Moreover, > it's racy in fact. For instance, kmem_cache_shrink may free the last > slab and thus schedule cache destruction before it finishes checking > that the cache is empty, which can lead to use-after-free. > > So I propose to remove this async cache destruction from > memcg_release_pages, and check if the cache is empty explicitly after > calling kmem_cache_shrink instead. This will simplify things a lot w/o > introducing any functional changes. > > And regarding dead memcg caches (i.e. those that are left hanging around > after memcg offline for they have objects), I suppose we should reap > them either periodically or on vmpressure as Glauber suggested > initially. I'm going to implement this later. memcg_release_pages() can be called after cgroup destruction, and thus it *must* ensure that the now-empty cache is destroyed - or we'll leak it. There is no excuse to downgrade to periodic reaping when we already directly hook into the event that makes the cache empty. If slab needs to hold on to the cache for slightly longer than the final memcg_release_pages(), then it should grab a refcount to it. -- 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 3/4] mmc: sdhci: defer probing on regulator_get_optional() failures
If regulator_get_optional() returns EPROBE_DEFER, it indicates
that the regulator may show up later (e.g. the DT property is
present but the corresponding regulator may not have probed).
Instead of continuing without the regulator, return EPROBE_DEFER
from sdhci_add_host(). Also, fix regulator leaks in the error
paths in sdhci_add_host().
Signed-off-by: Andrew Bresticker
---
drivers/mmc/host/sdhci.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..e87c5d3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2978,7 +2978,9 @@ int sdhci_add_host(struct sdhci_host *host)
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
host->vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
if (IS_ERR_OR_NULL(host->vqmmc)) {
- if (PTR_ERR(host->vqmmc) < 0) {
+ if (PTR_ERR(host->vqmmc) == -EPROBE_DEFER) {
+ return PTR_ERR(host->vqmmc);
+ } else if (PTR_ERR(host->vqmmc) < 0) {
pr_info("%s: no vqmmc regulator found\n",
mmc_hostname(mmc));
host->vqmmc = NULL;
@@ -2993,6 +2995,7 @@ int sdhci_add_host(struct sdhci_host *host)
if (ret) {
pr_warn("%s: Failed to enable vqmmc regulator: %d\n",
mmc_hostname(mmc), ret);
+ regulator_put(host->vqmmc);
host->vqmmc = NULL;
}
}
@@ -3056,7 +3059,10 @@ int sdhci_add_host(struct sdhci_host *host)
host->vmmc = regulator_get_optional(mmc_dev(mmc), "vmmc");
if (IS_ERR_OR_NULL(host->vmmc)) {
- if (PTR_ERR(host->vmmc) < 0) {
+ if (PTR_ERR(host->vmmc) == -EPROBE_DEFER) {
+ ret = PTR_ERR(host->vmmc);
+ goto put_vqmmc;
+ } else if (PTR_ERR(host->vmmc) < 0) {
pr_info("%s: no vmmc regulator found\n",
mmc_hostname(mmc));
host->vmmc = NULL;
@@ -3150,7 +3156,8 @@ int sdhci_add_host(struct sdhci_host *host)
if (mmc->ocr_avail == 0) {
pr_err("%s: Hardware doesn't report any "
"support voltages.\n", mmc_hostname(mmc));
- return -ENODEV;
+ ret = -ENODEV;
+ goto put_vmmc;
}
spin_lock_init(>lock);
@@ -3280,6 +3287,12 @@ reset:
untasklet:
tasklet_kill(>card_tasklet);
tasklet_kill(>finish_tasklet);
+put_vmmc:
+ if (host->vmmc)
+ regulator_put(host->vmmc);
+put_vqmmc:
+ if (host->vqmmc)
+ regulator_put(host->vqmmc);
return ret;
}
--
1.9.1.423.g4596e3a
--
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/
[PATCHv2 1/8] ARM: EXYNOS: Add Exynos3250 SoC ID
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/Kconfig | 22 ++
arch/arm/mach-exynos/exynos.c| 2 ++
arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
3 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
menu "SAMSUNG EXYNOS SoCs Support"
+config ARCH_EXYNOS3
+ bool "SAMSUNG EXYNOS3"
+ select ARM_AMBA
+ select CLKSRC_OF
+ select HAVE_ARM_SCU if SMP
+ select HAVE_SMP
+ select PINCTRL
+ select PM_GENERIC_DOMAINS if PM_RUNTIME
+ help
+ Samsung EXYNOS3 SoCs based systems
+
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
comment "EXYNOS SoCs"
+config SOC_EXYNOS3250
+ bool "SAMSUNG EXYNOS3250"
+ default y
+ depends on ARCH_EXYNOS3
+ select ARCH_HAS_BANDGAP
+ select ARM_CPU_SUSPEND if PM
+ select PINCTRL_EXYNOS
+ select SAMSUNG_DMADEV
+ help
+ Enable EXYNOS3250 CPU support
+
config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..a603dfa 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -370,6 +370,8 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+ "samsung,exynos3",
+ "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID 0x4311
#define S5PV210_CPU_MASK 0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID 0x4321
#define EXYNOS4212_CPU_ID 0x4322
#define EXYNOS4412_CPU_ID 0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210() 0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
#if defined(CONFIG_CPU_EXYNOS4210)
# define soc_is_exynos4210() is_samsung_exynos4210()
#else
--
1.8.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/
[PATCHv2 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
This patch add memory mapping for PMU (Power Management Unit) which is used
for power control of Exynos3250.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Arnd Bergmann suggested that need proper driver instead of static memory
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161
So, I'm going to re-implement following patch related to static memory mapping
after merged Sachin Kamat patch[1].
ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
arch/arm/mach-exynos/exynos.c | 5 +
arch/arm/mach-exynos/include/mach/map.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c7c9472..8f6f73d 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -41,6 +41,11 @@ static struct map_desc exynos3250_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS3_PA_SYSRAM_NS),
.length = SZ_4K,
.type = MT_DEVICE,
+ }, {
+ .virtual= (unsigned long)S5P_VA_PMU,
+ .pfn= __phys_to_pfn(EXYNOS3_PA_PMU),
+ .length = SZ_64K,
+ .type = MT_DEVICE,
},
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index a53981b..4aea694 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -36,6 +36,7 @@
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
+#define EXYNOS3_PA_PMU 0x1002
#define EXYNOS4_PA_PMU 0x1002
#define EXYNOS5_PA_PMU 0x1004
--
1.8.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/
[PATCHv2 2/8] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
The non-secure SYSRAM is used for secondary CPU bring-up. This patch add
IO mapping for non-scure SYSRAM.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Arnd Bergmann suggested that need proper driver instead of static memory
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161
So, I'm going to re-implement following patch related to static memory mapping
after merged Sachin Kamat patch[1].
ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
arch/arm/mach-exynos/exynos.c | 12
arch/arm/mach-exynos/include/mach/map.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a603dfa..c7c9472 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,15 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static struct map_desc exynos3250_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn= __phys_to_pfn(EXYNOS3_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -275,6 +284,9 @@ static int __init exynos_fdt_map_chipid(unsigned long node,
const char *uname,
*/
static void __init exynos_map_io(void)
{
+ if (soc_is_exynos3250())
+ iotable_init(exynos3250_iodesc, ARRAY_SIZE(exynos3250_iodesc));
+
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..a53981b 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -26,6 +26,7 @@
#define EXYNOS4_PA_SYSRAM0 0x02025000
#define EXYNOS4_PA_SYSRAM1 0x0202
#define EXYNOS5_PA_SYSRAM 0x0202
+#define EXYNOS3_PA_SYSRAM_NS 0x0205F000
#define EXYNOS4210_PA_SYSRAM_NS0x0203F000
#define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
#define EXYNOS5250_PA_SYSRAM_NS0x0204F000
--
1.8.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/
[PATCHv2 6/8] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/hotplug.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..99e54e0 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,22 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
+* we're ready for shutdown now, so do it. Exynos4 is A9 based
+* while Exynos5 is A15/Exynos3 is A7; check the CPU part
* number by reading the Main ID register and then perform the
* appropriate sequence for entering low power.
*/
- asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
- if ((primary_part & 0xfff0) == 0xc0f0)
+ primary_part = read_cpuid_part_number();
+
+ switch (primary_part) {
+ case ARM_CPU_PART_CORTEX_A7:
+ case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
- else
+ break;
+ default:
cpu_enter_lowpower_a9();
+ break;
+ }
platform_do_lowpower(cpu, );
--
1.8.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/
Re: [PATCH] arm64: Flush the process's mm context TLB entries when switching
On 2014/4/14 21:01, Will Deacon wrote:
> Hi Ding,
>
> On Mon, Apr 14, 2014 at 01:03:12PM +0100, Ding Tianhong wrote:
>> I met a problem when migrating process by following steps:
>>
>> 1) The process was already running on core 0.
>> 2) Set the CPU affinity of the process to 0x02 and move it to core 1,
>>it could work well.
>> 3) Set the CPU affinity of the process to 0x01 and move it to core 0 again,
>>the problem occurs and the process was killed.
>
> [...]
>
>> It was a very strange problem that the PC and LR are both 0, and the esr is
>> 0x8306, it means that the used for instruction access generated MMU
>> faults
>> and synchronous external aborts, including synchronous parity errors.
>>
>> I try to fix the problem by invalidating the process's TLB entries when
>> switching,
>> it will make the context stale and pick new one, and then it could work well.
>>
>> So I think in some situation that after the process switching, the
>> modification of
>> the TLB entries in the new core didn't inform all other cores to invalidate
>> the old
>> TLB entries which was in the inner shareable caches, and then if the process
>> schedule
>> to another core, the old TLB entries may occur MMU faults.
>
> Yes, it sounds like you don't have your TLBs configured correctly. Can you
> confirm that your EL3 firmware is configuring TLB broadcasting correctly
> please?
>
Hi will:
Do you mean the SCR_EL3.NS?
>> Signed-off-by: Ding Tianhong
>> ---
>> arch/arm64/kernel/process.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 6391485..d7d8439 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -283,6 +283,13 @@ static void tls_thread_switch(struct task_struct *next)
>> : : "r" (tpidr), "r" (tpidrro));
>> }
>>
>> +static void tlb_flush_thread(struct task_struct *prev)
>> +{
>> +/* Flush the prev task's TLB entries */
>> +if (prev->mm)
>> +flush_tlb_mm(prev->mm);
>> +}
>> +
>> /*
>> * Thread switching.
>> */
>> @@ -296,6 +303,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
>> hw_breakpoint_thread_switch(next);
>> contextidr_thread_switch(next);
>>
>> +tlb_flush_thread(prev);
>
> NAK to the patch -- the architecture certainly doesn't require this, and
> it's a huge hammer for what is more likely a firmware initialisation issue.
>
> Will
>
Yep, I am still doubt with this patch, thanks for your suggestion.
Regards
Ding
> .
>
--
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/
[PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
This patch fix the offset of CPU boot address and don't operate smc call
of SMC_CMD_CPU1BOOT command for Exynos3250.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/firmware.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..6205d4f 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -30,13 +30,16 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ if (soc_is_exynos3250()) {
+ return 0;
/*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
+ } else if (soc_is_exynos4212()) {
cpu = 0;
+ }
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
@@ -46,7 +49,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
boot_addr)
{
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
- if (!soc_is_exynos4212())
+ if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
--
1.8.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/
[PATCHv2 0/8] Support new Exynos3250 SoC based on Cortex-A7 dual core
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core. Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor for Smartphone. It is desigend with the 28nm low-power high-K metal gate process and provides the best performance features. This patchset include some patches such as: - Support secondary CPU of Exynos3250 (cpu up/down) - Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba - Support the clock control for Exynos3250 using common clk framework This patchset is completely tested and is based on following git repo/branch. - git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git - branch : for-next (Linux 3.15-rc1) Additional patch description about static memory mapping: Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patches related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 Changes from v1: - Add new "samsung,exynos3" compatible name - Add comment about exynos_cpu_boot in Exynos4212 - Remove unnecessary 'goto' statement in firmware.c - Use read_cpuid_part_number() function instead of assembler directly - Post separated pinctrl patch from this patchset : https://lkml.org/lkml/2014/4/13/156 - Remove unused pmu interrupts due to Exynos3250 dual-core - Cosolidate all the patches related to exynos3250.dtsi into one patch - Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same - Add sign-off of sender to all this patches - Fix minor typo Chanwoo Choi (5): ARM: EXYNOS: Add Exynos3250 SoC ID ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 ARM: EXYNOS: Support secondary CPU boot of Exynos3250 ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7 Kyungmin Park (1): ARM: EXYNOS: Support secondary CPU boot of Exynos4212 Tomasz Figa (2): clk: samsung: exynos3250: Add clocks using common clock framework ARM: dts: Add device tree sources for Exynos3250 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++ arch/arm/boot/dts/exynos3250.dtsi | 410 arch/arm/mach-exynos/Kconfig | 22 + arch/arm/mach-exynos/exynos.c | 19 + arch/arm/mach-exynos/firmware.c | 18 +- arch/arm/mach-exynos/hotplug.c| 16 +- arch/arm/mach-exynos/include/mach/map.h | 2 + arch/arm/plat-samsung/include/plat/cpu.h | 10 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 ++ include/dt-bindings/clock/exynos3250.h| 256 ++ 11 files changed, 2010 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos3250.dtsi create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h -- 1.8.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/
[PATCHv2 7/8] clk: samsung: exynos3250: Add clocks using common clock framework
From: Tomasz Figa This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR Changes from v1: - None Cc: Mike Turquette Cc: Kukjin Kim Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Tomasz Figa Signed-off-by: Chanwoo Choi Signed-off-by: Hyunhee Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Inki Dae Signed-off-by: Seung-Woo Kim Signed-off-by: Jaehoon Chung Signed-off-by: Karol Wrona Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "clk.h" +#include "clk-pll.h" + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564 +#define DIV_CAM1 0xc568 +#define CLKDIV2_RATIO 0xc580 +#define GATE_SCLK_CAM 0xc820 +#define GATE_SCLK_MFC 0xc828 +#define GATE_SCLK_G3D 0xc82c +#define GATE_SCLK_LCD 0xc834 +#define GATE_SCLK_ISP_TOP 0xc838 +#define GATE_SCLK_FSYS 0xc840 +#define GATE_SCLK_PERIL0xc850 +#define GATE_IP_CAM0xc920 +#define GATE_IP_MFC0xc928 +#define GATE_IP_G3D0xc92c +#define GATE_IP_LCD0xc934 +#define GATE_IP_ISP0xc938 +#define GATE_IP_FSYS 0xc940 +#define GATE_IP_PERIL 0xc950 +#define GATE_BLOCK 0xc970 +#define APLL_LOCK 0x14000 +#define APLL_CON0 0x14100 +#define SRC_CPU0x14200 +#define
[PATCHv2 8/8] ARM: dts: Add device tree sources for Exynos3250
From: Tomasz Figa
This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:
- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
Signed-off-by: Tomasz Figa
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
Signed-off-by: Hyunhee Kim
Signed-off-by: Jaehoon Chung
Signed-off-by: Bartlomiej Zolnierkiewicz
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
arch/arm/boot/dts/exynos3250.dtsi | 410 +
2 files changed, 887 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ pinctrl@1140 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <0x2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa0-4", "gpa0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c3_bus: i2c3-bus {
+ samsung,pins = "gpa1-2", "gpa1-3";
+
[PATCHv2 4/8] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
From: Kyungmin Park
This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.
Signed-off-by: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/mach-exynos/firmware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
#include
+#include
+
#include "smc.h"
static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+ if (soc_is_exynos4212())
+ cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
{
- void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
return 0;
--
1.8.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/
[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference
It need to be checking NULL before dereferencing. Signed-off-by: Daeseok Youn --- drivers/gpu/drm/nouveau/core/subdev/clock/base.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c index dd62bae..a586d030 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c @@ -290,9 +290,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx) return 0; pstate = kzalloc(sizeof(*pstate), GFP_KERNEL); - cstate = >base; if (!pstate) return -ENOMEM; + cstate = >base; INIT_LIST_HEAD(>list); -- 1.7.4.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 v7] fs: FAT: Add support for DOS 1.x formatted volumes
Add structure for parsed BPB information, struct fat_bios_param_block,
and move all of the deserialization and validation logic from
fat_fill_super() into fat_read_bpb().
Add a 'dos1xfloppy' mount option to infer DOS 2.x BIOS Parameter Block
defaults from block device geometry for ancient floppies and floppy
images, as a fall-back from the default BPB parsing logic.
When fat_read_bpb() finds an invalid FAT filesystem and dos1xfloppy is
set, fall back to fat_read_static_bpb(). fat_read_static_bpb() validates
that the entire BPB is zero, and that the floppy has a DOS-style 8086
code bootstrapping header. Then it fills in default BPB values from
media size and a table.[0]
Media size is assumed to be static for archaic FAT volumes. See also:
[1].
Fixes kernel.org bug #42617.
[0]: https://en.wikipedia.org/wiki/File_Allocation_Table#Exceptions
[1]: http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
Signed-off-by: Conrad Meyer
---
Changes since v6:
* Update show_options()
* Add option documentation to Doc/filesystems/vfat.txt
Thanks.
---
Documentation/filesystems/vfat.txt | 5 +
fs/fat/fat.h | 28 +++-
fs/fat/inode.c | 318 -
3 files changed, 274 insertions(+), 77 deletions(-)
diff --git a/Documentation/filesystems/vfat.txt
b/Documentation/filesystems/vfat.txt
index 5cf57b3..223c321 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -172,6 +172,11 @@ nfs=stale_rw|nostale_ro
To maintain backward compatibility, '-o nfs' is also accepted,
defaulting to stale_rw
+dos1xfloppy -- If set, use a fallback default BIOS Parameter Block
+ configuration, determined by backing device size. These static
+ parameters match defaults assumed by DOS 1.x for 160 kiB,
+ 180 kiB, 320 kiB, and 360 kiB floppies and floppy images.
+
: 0,1,yes,no,true,false
diff --git a/fs/fat/fat.h b/fs/fat/fat.h
index 7270bdb..bcb0d67 100644
--- a/fs/fat/fat.h
+++ b/fs/fat/fat.h
@@ -52,7 +52,8 @@ struct fat_mount_options {
usefree:1,/* Use free_clusters for FAT32 */
tz_set:1, /* Filesystem timestamps' offset set */
rodir:1, /* allow ATTR_RO for directory */
-discard:1;/* Issue discard requests on deletions */
+discard:1,/* Issue discard requests on deletions */
+dos1xfloppy:1;/* Assume default BPB for DOS 1.x floppies */
};
#define FAT_HASH_BITS 8
@@ -139,6 +140,31 @@ struct fat_slot_info {
struct buffer_head *bh;
};
+/*
+ * A deserialized copy of the on-disk structure laid out in struct
+ * fat_boot_sector.
+ */
+struct fat_bios_param_block {
+ u16 fat_sector_size;
+ u8 fat_sec_per_clus;
+ u16 fat_reserved;
+ u8 fat_fats;
+ u16 fat_dir_entries;
+ u16 fat_sectors;
+ u16 fat_fat_length;
+ u32 fat_total_sect;
+
+ u8 fat16_state;
+ u32 fat16_vol_id;
+
+ u32 fat32_length;
+ u32 fat32_root_cluster;
+ u16 fat32_info_sector;
+ u8 fat32_state;
+ u32 fat32_vol_id;
+
+};
+
static inline struct msdos_sb_info *MSDOS_SB(struct super_block *sb)
{
return sb->s_fs_info;
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 992e8cb..70ba768 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -35,9 +35,47 @@
#define CONFIG_FAT_DEFAULT_IOCHARSET ""
#endif
+#define KB_IN_SECTORS 2
+
static int fat_default_codepage = CONFIG_FAT_DEFAULT_CODEPAGE;
static char fat_default_iocharset[] = CONFIG_FAT_DEFAULT_IOCHARSET;
+static struct fat_floppy_defaults {
+ unsigned nr_sectors;
+ unsigned sec_per_clus;
+ unsigned dir_entries;
+ unsigned media;
+ unsigned fat_length;
+} floppy_defaults[] = {
+{
+ .nr_sectors = 160 * KB_IN_SECTORS,
+ .sec_per_clus = 1,
+ .dir_entries = 64,
+ .media = 0xFE,
+ .fat_length = 1,
+},
+{
+ .nr_sectors = 180 * KB_IN_SECTORS,
+ .sec_per_clus = 1,
+ .dir_entries = 64,
+ .media = 0xFC,
+ .fat_length = 2,
+},
+{
+ .nr_sectors = 320 * KB_IN_SECTORS,
+ .sec_per_clus = 2,
+ .dir_entries = 112,
+ .media = 0xFF,
+ .fat_length = 1,
+},
+{
+ .nr_sectors = 360 * KB_IN_SECTORS,
+ .sec_per_clus = 2,
+ .dir_entries = 112,
+ .media = 0xFD,
+ .fat_length = 2,
+},
+};
static int fat_add_cluster(struct inode *inode)
{
@@ -931,6 +969,8 @@ static int fat_show_options(struct seq_file *m, struct
dentry *root)
seq_puts(m, ",nfs=stale_rw");
if (opts->discard)
seq_puts(m, ",discard");
+ if (opts->dos1xfloppy)
+ seq_puts(m, ",dos1xfloppy");
return 0;
}
@@ -945,7 +985,7 @@ enum {
Opt_uni_xl_no, Opt_uni_xl_yes,
[PATCH 1/1] driver/net: cosa driver uses udelay incorrectly
From: "Li, Zhen-Hua" In cosa driver, udelay with more than 2 may cause __bad_udelay. Use msleep for instead. Signed-off-by: Li, Zhen-Hua --- drivers/net/wan/cosa.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c index 84734a8..83c39e2 100644 --- a/drivers/net/wan/cosa.c +++ b/drivers/net/wan/cosa.c @@ -1521,11 +1521,7 @@ static int cosa_reset_and_read_id(struct cosa_data *cosa, char *idstring) cosa_putstatus(cosa, 0); cosa_getdata8(cosa); cosa_putstatus(cosa, SR_RST); -#ifdef MODULE msleep(500); -#else - udelay(5*10); -#endif /* Disable all IRQs from the card */ cosa_putstatus(cosa, 0); -- 1.7.10.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/
Re: [GIT] kbuild/lto changes for 3.15-rc1
> > and it slows down > > kernel development'. > > No, it doesn't slow down development builds; it makes kernel builds > slower if and only if LTO is turned on, which most kernel developers > won't need to do. On the other hand, distro and embedded kernels can do > so for final builds, and developers pushing to minimize the kernel can > turn it on for their own work as needed. Yes and the patch even takes special care that you will not enable it by mistake. -Andi -- 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] mm/memcontrol.c: make mem_cgroup_read_stat() read all interested stat item in one go
Hi Jianyu, On Fri, Apr 11, 2014 at 01:11:08AM +0800, Jianyu Zhan wrote: > Currently, mem_cgroup_read_stat() is used for user interface. The > user accounts memory usage by memory cgroup and he _always_ requires > exact value because he accounts memory. So we don't use quick-and-fuzzy > -read-and-do-periodic-synchronization way. Thus, we iterate all cpus > for one read. > > And we mem_cgroup_usage() and mem_cgroup_recursive_stat() both finally > call into mem_cgroup_read_stat(). > > However, these *stat snapshot* operations are implemented in a quite > coarse way: it takes M*N iteration for each stat item(M=nr_memcgs, > N=nr_possible_cpus). There are two deficiencies: > > 1. for every stat item, we have to iterate over all percpu value, which >is not so cache friendly. > 2. for every stat item, we call mem_cgroup_read_stat() once, which >increase the probablity of contending on pcp_counter_lock. > > So, this patch improve this a bit. Concretely, for all interested stat > items, mark them in a bitmap, and then make mem_cgroup_read_stat() read > them all in one go. > > This is more efficient, and to some degree make it more like *stat snapshot*. > > Signed-off-by: Jianyu Zhan > --- > mm/memcontrol.c | 91 > +++-- > 1 file changed, 62 insertions(+), 29 deletions(-) This is when the user reads statistics or when OOM happens, neither of which I would consider fast paths. I don't think it's worth the extra code, which looks more cumbersome than what we have. -- 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] unicore32: include: asm: add missing ')' for PAGE_* macros in pgtable.h
Missing related ')', the related compiling error: CC [M] drivers/gpu/drm/udl/udl_fb.o drivers/gpu/drm/udl/udl_fb.c: In function ‘udl_fb_mmap’: drivers/gpu/drm/udl/udl_fb.c:273: error: expected ‘)’ before ‘return’ drivers/gpu/drm/udl/udl_fb.c:281: error: expected expression before ‘}’ token make[4]: *** [drivers/gpu/drm/udl/udl_fb.o] Error 1 make[3]: *** [drivers/gpu/drm/udl] Error 2 make[2]: *** [drivers/gpu/drm] Error 2 make[1]: *** [drivers/gpu] Error 2 make: *** [drivers] Error 2 Signed-off-by: Chen Gang --- arch/unicore32/include/asm/pgtable.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/unicore32/include/asm/pgtable.h b/arch/unicore32/include/asm/pgtable.h index 233c258..ed6f7d0 100644 --- a/arch/unicore32/include/asm/pgtable.h +++ b/arch/unicore32/include/asm/pgtable.h @@ -87,16 +87,16 @@ extern pgprot_t pgprot_kernel; #define PAGE_NONE pgprot_user #define PAGE_SHARED__pgprot(pgprot_val(pgprot_user | PTE_READ \ - | PTE_WRITE) + | PTE_WRITE)) #define PAGE_SHARED_EXEC __pgprot(pgprot_val(pgprot_user | PTE_READ \ | PTE_WRITE \ - | PTE_EXEC) + | PTE_EXEC)) #define PAGE_COPY __pgprot(pgprot_val(pgprot_user | PTE_READ) #define PAGE_COPY_EXEC __pgprot(pgprot_val(pgprot_user | PTE_READ \ - | PTE_EXEC) -#define PAGE_READONLY __pgprot(pgprot_val(pgprot_user | PTE_READ) + | PTE_EXEC)) +#define PAGE_READONLY __pgprot(pgprot_val(pgprot_user | PTE_READ)) #define PAGE_READONLY_EXEC __pgprot(pgprot_val(pgprot_user | PTE_READ \ - | PTE_EXEC) + | PTE_EXEC)) #define PAGE_KERNELpgprot_kernel #define PAGE_KERNEL_EXEC __pgprot(pgprot_val(pgprot_kernel | PTE_EXEC)) -- 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/
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build
(x86_64_allmodconfig) failed like this:
sound/soc/fsl/fsl_ssi.c: In function 'fsl_ssi_probe':
sound/soc/fsl/fsl_ssi.c:1471:2: error: implicit declaration of function
'of_find_node_by_path' [-Werror=implicit-function-declaration]
sprop = of_get_property(of_find_node_by_path("/"), "compatible", NULL);
^
Probably caused by commit eba9e06f0ceb ("ASoC: fsl: Separation of the
main audio options and boards").
I have used the sound-asoc tree from next-20140414 for today.
--
Cheers,
Stephen Rothwell
pgphsXVyz5H9u.pgp
Description: PGP signature
linux-next: build failure after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build
(x86_64_allmodconfig) failed like this:
sound/soc/codecs/wm8997.c:248:1: error: implicit declaration of function
'SOC_VALUE' [-Werror=implicit-function-declaration]
SOC_VALUE("ISRC1 FSL", arizona_isrc_fsl[0]),
^
Caused by commit e13dd8ce39a8 ("ASoC: wm8997: Replace usage deprecated
MUX/ENUM macros").
I have used the version of the sound-asoc tree from next-20140414 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpFBgoBQRPot.pgp
Description: PGP signature
Re: [PATCH 1/1] driver/net: remove unused code in cosa module
Thanks for your correction. I will send again with proper reason. On 04/15/2014 01:31 AM, David Miller wrote: From: "Li, Zhen-Hua" Date: Mon, 14 Apr 2014 18:08:36 +0800 For the cosa module, CONFIG_COSA can only be checked as 'm', and cosa module can only be compiled as a module. That's not true, it's "tristate" in drivers/net/wan/Kconfig so it could be set to 'y' too. But there is another reason to make this change, because for such large timeout values only msleep() makes sense, udelay() could overflow it's internal precision. Please resubmit this with the proper reasoning and commit message. -- 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: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
sound/soc/intel/sst-haswell-pcm.c: In function 'hsw_stream_volume_put':
sound/soc/intel/sst-haswell-pcm.c:139:38: warning: initialization from
incompatible pointer type [enabled by default]
struct snd_soc_platform *platform = snd_soc_kcontrol_platform(kcontrol);
^
And several others ... really, you should try build testing this stuff :-(
Caused by commit f6272ff8a5f4 ("ASoC: Add snd_soc_kcontrol_platform()
helper function").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpK38PE9sIvN.pgp
Description: PGP signature
[PATCH 0/4] Tegra SD/MMC fixes
The following patches fix a couple of issues which prevented Venice2 boards from booting via eMMC and SD card reliably. Note that this includes disabling UHS support since SDR50 and above require a Tegra-specific tuning procedure which is not supported yet (and still seems to have issues even in downstream kernels). Tested on Tegra124-based Venice2 and Norrin boards. Andrew Bresticker (4): mmc: tegra: disable UHS modes mmc: tegra: fix reporting of base clock frequency mmc: sdhci: defer probing on regulator_get_optional() failures ARM: tegra: fix Venice2 VQMMC regulators arch/arm/boot/dts/tegra124-venice2.dts | 3 ++- drivers/mmc/host/sdhci-tegra.c | 40 +- drivers/mmc/host/sdhci.c | 19 +--- 3 files changed, 48 insertions(+), 14 deletions(-) -- 1.9.1.423.g4596e3a -- 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 2/4] mmc: tegra: fix reporting of base clock frequency
Tegra SDHCI controllers, by default, report a base clock frequency
of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
actual base clock frequency. While this can be overridden by setting
BASE_CLK_FREQ in VENDOR_CLOCK_CTRL on Tegra30 and later SoCs, just
set SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN and supply a get_max_clock()
callback to get the actual rate of the base clock.
Signed-off-by: Andrew Bresticker
---
drivers/mmc/host/sdhci-tegra.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 3cadd9c..c3f92d9 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -165,13 +165,15 @@ static const struct sdhci_ops tegra_sdhci_ops = {
.write_l= tegra_sdhci_writel,
.platform_bus_width = tegra_sdhci_buswidth,
.platform_reset_exit = tegra_sdhci_reset_exit,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
};
static const struct sdhci_pltfm_data sdhci_tegra20_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops = _sdhci_ops,
};
@@ -186,7 +188,8 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = {
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops = _sdhci_ops,
};
@@ -202,7 +205,8 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata =
{
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
- SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
+ SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
+ SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
.ops = _sdhci_ops,
};
--
1.9.1.423.g4596e3a
--
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 4/4] ARM: tegra: fix Venice2 VQMMC regulators
VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD
slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC.
Signed-off-by: Andrew Bresticker
---
arch/arm/boot/dts/tegra124-venice2.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts
b/arch/arm/boot/dts/tegra124-venice2.dts
index c17283c..53061ef 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -933,12 +933,13 @@
power-gpios = < TEGRA_GPIO(R, 0) GPIO_ACTIVE_HIGH>;
status = "okay";
bus-width = <4>;
- vmmc-supply = <_sdmmc3>;
+ vqmmc-supply = <_sdmmc3>;
};
sdhci@0,700b0600 {
status = "okay";
bus-width = <8>;
+ vqmmc-supply = <_1v8>;
};
ahub@0,7030 {
--
1.9.1.423.g4596e3a
--
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/4] mmc: tegra: disable UHS modes
Program TEGRA_SDHCI_VENDOR_MISC_CTRL so that UHS modes aren't advertised
in SDHCI_CAPABILITIES_1. While the Tegra SDHCI controller does support
these modes, they require Tegra-specific tuning and calibration routines
which the driver does not support yet.
Signed-off-by: Andrew Bresticker
---
drivers/mmc/host/sdhci-tegra.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index a835898..3cadd9c 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -32,11 +32,17 @@
/* Tegra SDHOST controller vendor register definitions */
#define SDHCI_TEGRA_VENDOR_MISC_CTRL 0x120
+#define SDHCI_MISC_CTRL_ENABLE_SDR104 0x8
+#define SDHCI_MISC_CTRL_ENABLE_SDR50 0x10
#define SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300 0x20
+#define SDHCI_MISC_CTRL_ENABLE_DDR50 0x200
#define NVQUIRK_FORCE_SDHCI_SPEC_200 BIT(0)
#define NVQUIRK_ENABLE_BLOCK_GAP_DET BIT(1)
#define NVQUIRK_ENABLE_SDHCI_SPEC_300 BIT(2)
+#define NVQUIRK_DISABLE_SDR50 BIT(3)
+#define NVQUIRK_DISABLE_SDR104 BIT(4)
+#define NVQUIRK_DISABLE_DDR50 BIT(5)
struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
@@ -113,18 +119,23 @@ static void tegra_sdhci_reset_exit(struct sdhci_host
*host, u8 mask)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_tegra *tegra_host = pltfm_host->priv;
const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
+ u32 misc_ctrl;
if (!(mask & SDHCI_RESET_ALL))
return;
+ misc_ctrl = sdhci_readw(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
/* Erratum: Enable SDHCI spec v3.00 support */
- if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300) {
- u32 misc_ctrl;
-
- misc_ctrl = sdhci_readb(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
+ if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
- sdhci_writeb(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
- }
+ /* Don't advertise UHS modes which aren't supported yet */
+ if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR50)
+ misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50;
+ if (soc_data->nvquirks & NVQUIRK_DISABLE_DDR50)
+ misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50;
+ if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR104)
+ misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104;
+ sdhci_writew(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
}
static int tegra_sdhci_buswidth(struct sdhci_host *host, int bus_width)
@@ -181,7 +192,9 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata = {
static struct sdhci_tegra_soc_data soc_data_tegra30 = {
.pdata = _tegra30_pdata,
- .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300,
+ .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300 |
+ NVQUIRK_DISABLE_SDR50 |
+ NVQUIRK_DISABLE_SDR104,
};
static const struct sdhci_pltfm_data sdhci_tegra114_pdata = {
@@ -195,6 +208,9 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata =
{
static struct sdhci_tegra_soc_data soc_data_tegra114 = {
.pdata = _tegra114_pdata,
+ .nvquirks = NVQUIRK_DISABLE_SDR50 |
+ NVQUIRK_DISABLE_DDR50 |
+ NVQUIRK_DISABLE_SDR104,
};
static const struct of_device_id sdhci_tegra_dt_match[] = {
--
1.9.1.423.g4596e3a
--
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/
