[PATCH 7/7] scsi: storvsc: Set the tablesize based on the information given by the host
Set the tablesize based on the information given by the host.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
Tested-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 89 +++
1 files changed, 64 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 4156e29..d9dad90 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -351,7 +351,10 @@ struct storvsc_cmd_request {
/* Synchronize the request/response if needed */
struct completion wait_event;
- struct hv_multipage_buffer data_buffer;
+ struct vmbus_channel_packet_multipage_buffer mpb;
+ struct vmbus_packet_mpb_array *payload;
+ u32 payload_sz;
+
struct vstor_packet vstor_packet;
};
@@ -1103,6 +1106,8 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
struct Scsi_Host *host;
struct storvsc_device *stor_dev;
struct hv_device *dev = host_dev-dev;
+ u32 payload_sz = cmd_request-payload_sz;
+ void *payload = cmd_request-payload;
stor_dev = get_in_stor_device(dev);
host = stor_dev-host;
@@ -1132,10 +1137,14 @@ static void storvsc_command_completion(struct
storvsc_cmd_request *cmd_request)
sense_hdr.ascq);
scsi_set_resid(scmnd,
- cmd_request-data_buffer.len -
+ cmd_request-payload-range.len -
vm_srb-data_transfer_length);
scmnd-scsi_done(scmnd);
+
+ if (payload_sz
+ sizeof(struct vmbus_channel_packet_multipage_buffer))
+ kfree(payload);
}
static void storvsc_on_io_completion(struct hv_device *device,
@@ -1337,7 +1346,7 @@ static int storvsc_dev_remove(struct hv_device *device)
}
static int storvsc_do_io(struct hv_device *device,
- struct storvsc_cmd_request *request)
+struct storvsc_cmd_request *request)
{
struct storvsc_device *stor_device;
struct vstor_packet *vstor_packet;
@@ -1369,13 +1378,14 @@ static int storvsc_do_io(struct hv_device *device,
vstor_packet-vm_srb.data_transfer_length =
- request-data_buffer.len;
+ request-payload-range.len;
vstor_packet-operation = VSTOR_OPERATION_EXECUTE_SRB;
- if (request-data_buffer.len) {
- ret = vmbus_sendpacket_multipagebuffer(outgoing_channel,
- request-data_buffer,
+ if (request-payload-range.len) {
+
+ ret = vmbus_sendpacket_mpb_desc(outgoing_channel,
+ request-payload, request-payload_sz,
vstor_packet,
(sizeof(struct vstor_packet) -
vmscsi_size_delta),
@@ -1549,6 +1559,9 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
unsigned int sg_count = 0;
struct vmscsi_request *vm_srb;
struct scatterlist *cur_sgl;
+ struct vmbus_packet_mpb_array *payload;
+ u32 payload_sz;
+ u32 length;
if (vmstor_current_major = VMSTOR_WIN8_MAJOR) {
/*
@@ -1602,48 +1615,71 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
memcpy(vm_srb-cdb, scmnd-cmnd, vm_srb-cdb_length);
- cmd_request-data_buffer.len = scsi_bufflen(scmnd);
- if (scsi_sg_count(scmnd)) {
- sgl = (struct scatterlist *)scsi_sglist(scmnd);
- sg_count = scsi_sg_count(scmnd);
+ sgl = (struct scatterlist *)scsi_sglist(scmnd);
+ sg_count = scsi_sg_count(scmnd);
+ length = scsi_bufflen(scmnd);
+ payload = (struct vmbus_packet_mpb_array *)cmd_request-mpb;
+ payload_sz = sizeof(cmd_request-mpb);
+
+ if (sg_count) {
/* check if we need to bounce the sgl */
if (do_bounce_buffer(sgl, scsi_sg_count(scmnd)) != -1) {
cmd_request-bounce_sgl =
- create_bounce_buffer(sgl, scsi_sg_count(scmnd),
-scsi_bufflen(scmnd),
+ create_bounce_buffer(sgl, sg_count,
+length,
vm_srb-data_in);
if (!cmd_request-bounce_sgl)
return SCSI_MLQUEUE_HOST_BUSY;
cmd_request-bounce_sgl_count =
- ALIGN(scsi_bufflen(scmnd), PAGE_SIZE)
- PAGE_SHIFT;
+ ALIGN(length, PAGE_SIZE) PAGE_SHIFT;
if (vm_srb-data_in == WRITE_TYPE)
[PATCH V2 4/7] scsi: storvsc: Retrieve information about the capability of the target
The storage protocol informs the guest of the I/O capabilities of the storage
stack. Retrieve this information and use it in the guest.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 0ba7f2c..cdf048b 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,10 @@ struct storvsc_device {
unsigned char path_id;
unsigned char target_id;
+ /*
+* Max I/O, the device can support.
+*/
+ u32 max_transfer_bytes;
/* Used for vsc/vsp channel reset process */
struct storvsc_cmd_request init_request;
struct storvsc_cmd_request reset_request;
@@ -974,6 +978,8 @@ static int storvsc_channel_init(struct hv_device *device)
STORAGE_CHANNEL_SUPPORTS_MULTI_CHANNEL)
process_sub_channels = true;
}
+ stor_device-max_transfer_bytes =
+ vstor_packet-storage_channel_properties.max_transfer_bytes;
memset(vstor_packet, 0, sizeof(struct vstor_packet));
vstor_packet-operation = VSTOR_OPERATION_END_INITIALIZATION;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/7] scsi: storvsc: Size the queue depth based on the ringbuffer size
Size the queue depth based on the ringbuffer size. Also accomodate for the
fact that we could have multiple channels (ringbuffers) per adaptor.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
v2: Fixed a bug in computing queue depth: Venkatesh Srinivas
venkate...@google.com
drivers/scsi/storvsc_drv.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 27fe850..7f569f9 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -309,10 +309,15 @@ enum storvsc_request_type {
*/
static int storvsc_ringbuffer_size = (256 * PAGE_SIZE);
+static u32 max_outstanding_req_per_channel;
+
+static int storvsc_vcpus_per_sub_channel = 4;
module_param(storvsc_ringbuffer_size, int, S_IRUGO);
MODULE_PARM_DESC(storvsc_ringbuffer_size, Ring buffer size (bytes));
+module_param(storvsc_vcpus_per_sub_channel, int, S_IRUGO);
+MODULE_PARM_DESC(vcpus_per_sub_channel, Ratio of VCPUs to subchannels);
/*
* Timeout in seconds for all devices managed by this driver.
*/
@@ -320,7 +325,6 @@ static int storvsc_timeout = 180;
static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
-#define STORVSC_MAX_IO_REQUESTS200
static void storvsc_on_channel_callback(void *context);
@@ -1376,7 +1380,6 @@ static int storvsc_do_io(struct hv_device *device,
static int storvsc_device_configure(struct scsi_device *sdevice)
{
- scsi_change_queue_depth(sdevice, STORVSC_MAX_IO_REQUESTS);
blk_queue_max_segment_size(sdevice-request_queue, PAGE_SIZE);
@@ -1646,7 +1649,6 @@ static struct scsi_host_template scsi_driver = {
.eh_timed_out = storvsc_eh_timed_out,
.slave_configure = storvsc_device_configure,
.cmd_per_lun = 255,
- .can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
/* no use setting to 0 since ll_blk_rw reset it to 1 */
/* currently 32 */
@@ -1686,6 +1688,7 @@ static int storvsc_probe(struct hv_device *device,
const struct hv_vmbus_device_id *dev_id)
{
int ret;
+ int num_cpus = num_online_cpus();
struct Scsi_Host *host;
struct hv_host_device *host_dev;
bool dev_is_ide = ((dev_id-driver_data == IDE_GUID) ? true : false);
@@ -1694,6 +1697,7 @@ static int storvsc_probe(struct hv_device *device,
int max_luns_per_target;
int max_targets;
int max_channels;
+ int max_sub_channels = 0;
/*
* Based on the windows host we are running on,
@@ -1719,12 +1723,18 @@ static int storvsc_probe(struct hv_device *device,
max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_MAX_TARGETS;
max_channels = STORVSC_MAX_CHANNELS;
+ /*
+* On Windows8 and above, we support sub-channels for storage.
+* The number of sub-channels offerred is based on the number of
+* VCPUs in the guest.
+*/
+ max_sub_channels = (num_cpus / storvsc_vcpus_per_sub_channel);
break;
}
- if (dev_id-driver_data == SFC_GUID)
- scsi_driver.can_queue = (STORVSC_MAX_IO_REQUESTS *
-STORVSC_FC_MAX_TARGETS);
+ scsi_driver.can_queue = (max_outstanding_req_per_channel *
+(max_sub_channels + 1));
+
host = scsi_host_alloc(scsi_driver,
sizeof(struct hv_host_device));
if (!host)
@@ -1837,7 +1847,6 @@ static struct hv_driver storvsc_drv = {
static int __init storvsc_drv_init(void)
{
- u32 max_outstanding_req_per_channel;
/*
* Divide the ring buffer data size (which is 1 page less
@@ -1852,10 +1861,6 @@ static int __init storvsc_drv_init(void)
vmscsi_size_delta,
sizeof(u64)));
- if (max_outstanding_req_per_channel
- STORVSC_MAX_IO_REQUESTS)
- return -EINVAL;
-
return vmbus_driver_register(storvsc_drv);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/7] scsi: storvsc: Increase the ring buffer size
Increase the default ring buffer size as this can significantly
improve performance especially on high latency storage back-ends.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index efc6e44..27fe850 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -308,7 +308,7 @@ enum storvsc_request_type {
* This is the end of Protocol specific defines.
*/
-static int storvsc_ringbuffer_size = (20 * PAGE_SIZE);
+static int storvsc_ringbuffer_size = (256 * PAGE_SIZE);
module_param(storvsc_ringbuffer_size, int, S_IRUGO);
MODULE_PARM_DESC(storvsc_ringbuffer_size, Ring buffer size (bytes));
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/7] scsi: storvsc: Always send on the selected outgoing channel
The current code always sent packets without data on the primary channel.
Properly distribute sending of packets with no data amongst all available
channels. I would like to thank Long Li for noticing this problem.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 7f569f9..0ba7f2c 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1362,7 +1362,7 @@ static int storvsc_do_io(struct hv_device *device,
vmscsi_size_delta),
(unsigned long)request);
} else {
- ret = vmbus_sendpacket(device-channel, vstor_packet,
+ ret = vmbus_sendpacket(outgoing_channel, vstor_packet,
(sizeof(struct vstor_packet) -
vmscsi_size_delta),
(unsigned long)request,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/7] scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
We may exit this function without properly freeing up the maapings
we may have acquired. Fix the bug.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
Cc: sta...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index cdf048b..f8e4dd9 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -754,21 +754,22 @@ static unsigned int copy_to_bounce_buffer(struct
scatterlist *orig_sgl,
if (bounce_sgl[j].length == PAGE_SIZE) {
/* full..move to next entry */
sg_kunmap_atomic(bounce_addr);
+ bounce_addr = 0;
j++;
+ }
- /* if we need to use another bounce buffer */
- if (srclen || i != orig_sgl_count - 1)
- bounce_addr =
sg_kmap_atomic(bounce_sgl,j);
+ /* if we need to use another bounce buffer */
+ if (srclen bounce_addr == 0)
+ bounce_addr = sg_kmap_atomic(bounce_sgl, j);
- } else if (srclen == 0 i == orig_sgl_count - 1) {
- /* unmap the last bounce that is PAGE_SIZE */
- sg_kunmap_atomic(bounce_addr);
- }
}
sg_kunmap_atomic(src_addr - orig_sgl[i].offset);
}
+ if (bounce_addr)
+ sg_kunmap_atomic(bounce_addr);
+
local_irq_restore(flags);
return total_copied;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
God dag
God dag Få et lån i dag fra Santander Consumer Finance, med renten så lav som 3%. fyll følgende form hvis du er interessert i vårt tilbud: Kjønn: Land: Mengden Som Trengs: Varighet: Hensikt: Det er mange grunner til at et lån kan hjelpe Vennlig hilsen Lasse Møller -- 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] sched: Improve load balancing in the presence of idle CPUs
On Thu, Mar 26, 2015 at 10:07:21PM -0700, Jason Low wrote: On Fri, 2015-03-27 at 10:12 +0800, Wanpeng Li wrote: Hi Preeti, On Thu, Mar 26, 2015 at 06:32:44PM +0530, Preeti U Murthy wrote: 1. An ILB CPU was chosen from the first numa domain to trigger nohz idle load balancing [Given the experiment, upto 6 CPUs per core could be potentially idle in this domain.] 2. However the ILB CPU would call load_balance() on itself before initiating nohz idle load balancing. 3. Given cores are SMT8, the ILB CPU had enough opportunities to pull tasks from its sibling cores to even out load. 4. Now that the ILB CPU was no longer idle, it would abort nohz idle load balancing I don't see abort nohz idle load balancing when ILB CPU was no longer idle in nohz_idle_balance(), could you explain more in details? Hi Wanpeng, In nohz_idle_balance(), there is a check for need_resched() so if the cpu has something to run, it should exit nohz_idle_balance(), which may cause it to not do the idle balancing on the other CPUs. Got it, thanks. ;) Regards, Wanpeng Li -- 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: [RESEND PATCH 3/3] clk: cdce706: Constify struct regmap_config
On 03/22, Max Filippov wrote: On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The regmap_config struct may be const because it is not modified by the driver and regmap_init() accepts pointer to const. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/clk/clk-cdce706.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Max Filippov jcmvb...@gmail.com Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: [RESEND PATCH 2/3] clk: si570: Constify struct regmap_config
On 03/22, Max Filippov wrote: On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The regmap_config struct may be const because it is not modified by the driver and regmap_init() accepts pointer to const. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/clk/clk-si570.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Max Filippov jcmvb...@gmail.com Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] cpufreq: powernv: Add checks to report cpu frequency throttling conditions
Hi Viresh,
On 03/27/2015 10:05 AM, Viresh Kumar wrote:
Hi Shilpa,
On 27 March 2015 at 00:11, Shilpasri G Bhat
shilpa.b...@linux.vnet.ibm.com wrote:
Cpu frequency can be throttled due to failures of components like OCC,
power supply and fan. It can also be throttled due to temperature and
power limit. We can detect the throttling by checking 1)if max frequency
Add these points in separate lines please, with a space after ). Its not
readable this way..
Will do.
is reduced, 2)if the core is put to safe frequency 3)if the SPR based
frequency management is disabled.
All these three points refer to the state CPU has shifted to ? Sorry it wasn't
clear to the outsiders :), perhaps some more detail on why CPU would have
done that.
The power and thermal safety of the system is taken care by an
On-Chip-Controller (OCC) which is real-time subsystem embedded within the POWER8
processor. OCC continuously monitors the memory and core temperature, the total
system power, state of power supply and fan.
The cpu frequency can be throttled for the following reason:
1)If a processor crosses its power and temperature limit then OCC will lower its
Pmax to reduce the frequency and voltage.
2)If OCC crashes then the system is forced to Psafe frequency.
3)If OCC fails to recover then the kernel is not allowed to do any further
frequency changes and the chip will remain in Psafe.
The user can see a drop in performance when frequency is throttled and is
unaware of throttling. So we want to report such a condition so that user can
check the OCC status to reboot the system or check for power supply or fan
failures.
The current status of the core is read from Power Management Status
Register(PMSR) to check if any of the throttling condition is
occurred and the appropriate throttling message is reported.
So, what do we want to do on throttling? Just print a warning? Is that
enough? What if CPU gets heated up to a point that it burns up ?
On over temperature safety measures are taken by OCC one of which being
throttling frequency. As the chip frequency and voltage is already lowered, not
sure what we can do apart from reporting. Maybe on detection of throttling
kernel can take corrective measure to migrate the tasks from that cpu or it can
force the cpu to idle.
Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com
---
Changes from V1: Removed unused value of PMCR register
drivers/cpufreq/powernv-cpufreq.c | 39
++-
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 2dfd4fd..4837eed 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -36,7 +36,7 @@
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
-static bool rebooting;
+static bool rebooting, throttled;
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -294,6 +294,40 @@ static inline unsigned int get_nominal_index(void)
return powernv_pstate_info.max - powernv_pstate_info.nominal;
}
+static void powernv_cpufreq_throttle_check(unsigned int cpu)
+{
+ unsigned long pmsr;
+ int pmsr_pmax, pmsr_lp;
+
+ pmsr = get_pmspr(SPRN_PMSR);
+
+ /* Check for Pmax Capping */
+ pmsr_pmax = (s8)((pmsr 32) 0xFF);
u8 ?
Pstate is negative. I want to propagate the sign.
+ if (pmsr_pmax != powernv_pstate_info.max) {
+ throttled = true;
+ pr_warn(Cpu %d Pmax is reduced to %d\n, cpu, pmsr_pmax);
+ }
+
+ /* Check for Psafe by reading LocalPstate
+* or check if Psafe_mode_active- 34th bit is set in PMSR.
+*/
Proper multi-line comment format is:
/*
*
*/
Will do.
+ pmsr_lp = (s8)((pmsr 48) 0xFF);
+ if ((pmsr_lp powernv_pstate_info.min) || ((pmsr 30) 1)) {
+ throttled = true;
+ pr_warn(Cpu %d in Psafe %d PMSR[34]=%lx\n, cpu,
+ pmsr_lp, ((pmsr 30) 1));
+ }
+
+ /* Check if SPR_EM_DISABLED- 33rd bit is set in PMSR */
+ if ((pmsr 31) 1) {
+ throttled = true;
+ pr_warn(Frequency management disabled cpu %d
PMSR[33]=%lx\n,
+ cpu, ((pmsr 31) 1));
+ }
+ if (throttled)
+ pr_warn(Cpu Frequency is throttled\n);
+}
+
/*
* powernv_cpufreq_target_index: Sets the frequency corresponding to
* the cpufreq table entry indexed by new_index on the cpus in the
@@ -307,6 +341,9 @@ static int powernv_cpufreq_target_index(struct
cpufreq_policy *policy,
if (unlikely(rebooting) new_index != get_nominal_index())
return 0;
+ if (!throttled)
+ powernv_cpufreq_throttle_check(smp_processor_id());
And CPU can't come out of
[PATCH v3] cpufreq: powernv: Report cpu frequency throttling
The power and thermal safety of the system is taken care by an
On-Chip-Controller (OCC) which is real-time subsystem embedded within
the POWER8 processor. OCC continuously monitors the memory and core
temperature, the total system power, state of power supply and fan.
The cpu frequency can be throttled by OCC for the following reasons:
1)If a processor crosses its power and temperature limit then OCC will
lower its Pmax to reduce the frequency and voltage.
2)If OCC crashes then the system is forced to Psafe frequency.
3)If OCC fails to recover then the kernel is not allowed to do any
further frequency changes and the chip will remain in Psafe.
The user can see a drop in performance when frequency is throttled and
is unaware of throttling. So detect and report such a condition so
that user can check the OCC status to reboot the system or check for
power supply or fan failures.
The current status of the core is read from Power Management Status
Register(PMSR) to check if any of the throttling condition is occurred
and the appropriate throttling message is reported.
Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com
---
Changes from V2:
-Changed commit log to add more details.
-Fixed multi-line comment to proper format
Changes from V1: Removed unused value of PMCR register
drivers/cpufreq/powernv-cpufreq.c | 40 ++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 2dfd4fd..0eb89a9 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -36,7 +36,7 @@
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
-static bool rebooting;
+static bool rebooting, throttled;
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -294,6 +294,41 @@ static inline unsigned int get_nominal_index(void)
return powernv_pstate_info.max - powernv_pstate_info.nominal;
}
+static void powernv_cpufreq_throttle_check(unsigned int cpu)
+{
+ unsigned long pmsr;
+ int pmsr_pmax, pmsr_lp;
+
+ pmsr = get_pmspr(SPRN_PMSR);
+
+ /* Check for Pmax Capping */
+ pmsr_pmax = (s8)((pmsr 32) 0xFF);
+ if (pmsr_pmax != powernv_pstate_info.max) {
+ throttled = true;
+ pr_warn(Cpu %d Pmax is reduced to %d\n, cpu, pmsr_pmax);
+ }
+
+ /*
+* Check for Psafe by reading LocalPstate
+* or check if Psafe_mode_active- 34th bit is set in PMSR.
+*/
+ pmsr_lp = (s8)((pmsr 48) 0xFF);
+ if ((pmsr_lp powernv_pstate_info.min) || ((pmsr 30) 1)) {
+ throttled = true;
+ pr_warn(Cpu %d in Psafe %d PMSR[34]=%lx\n, cpu,
+ pmsr_lp, ((pmsr 30) 1));
+ }
+
+ /* Check if SPR_EM_DISABLED- 33rd bit is set in PMSR */
+ if ((pmsr 31) 1) {
+ throttled = true;
+ pr_warn(Frequency management disabled cpu %d PMSR[33]=%lx\n,
+ cpu, ((pmsr 31) 1));
+ }
+ if (throttled)
+ pr_warn(Cpu Frequency is throttled\n);
+}
+
/*
* powernv_cpufreq_target_index: Sets the frequency corresponding to
* the cpufreq table entry indexed by new_index on the cpus in the
@@ -307,6 +342,9 @@ static int powernv_cpufreq_target_index(struct
cpufreq_policy *policy,
if (unlikely(rebooting) new_index != get_nominal_index())
return 0;
+ if (!throttled)
+ powernv_cpufreq_throttle_check(smp_processor_id());
+
freq_data.pstate_id = powernv_freqs[new_index].driver_data;
/*
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: String literals in __init functions
On Fri, 2015-03-27 at 08:05 +0100, Mathias Krause wrote: On 26 March 2015 at 22:40, Andrew Morton a...@linux-foundation.org wrote: On Thu, 26 Mar 2015 21:49:06 +0100 Mathias Krause mini...@googlemail.com wrote: Andrew, what's your opinion on such a patch set? Do you too think it's useful? Or do you share Ingo's fear about the additional maintenance burden? I don't think the burden would be t high, although it will mess the code up a bit. [] Did anyone ask the gcc developers? I'd have thought that a function-wide __attribute__((__string_section__(foo)) wouldn't be a ton of work to implement. The point is you cannot blindly mark all strings referenced from __init / __exit code to end up in a matching string section because strings in this code might have to live longer when passed to functions keeping a pointer on them. This is the primary reason I support the pi_level/pe_level/ printk_init/printk_exit markings. It's simple and not a large burden to the coder/reader. If a few formats aren't marked appropriately, it's not generally a significant loss, but it is easily correctable by scripts. -- 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/
security problem with seccomp-filter
Hi, I have had some great success with seccomp-filter a while ago, so I decided to use it to add some defense in depth to a ping program I wrote. The premise is, like for all ping programs I assume, that it starts setuid root, gets a raw socket, drops privileges, parses the command line, potentially does a DNS lookup, and then it sends and receives packets, using gettimeofday and poll. So I added a seccomp filter that allows this. But where do you put it? Ideally you'd want the filter installed right away after dropping privileges, so the command line parsing and the DNS routines are secured, too. But then you'd allow unnecessary attack surface (why allow open after the DNS routines are done parsing /etc/resolv.conf, for example?). The documentation says you can add more than one seccomp filter, just call prctl multiple times and allow prctl initially. So that's what I did. But when I added the secondary filters (which would blacklist open and setsockopt), and for double checking tried installing the last one twice (after the last one was supposed to blacklist prctl), to my surprise my attempt did not lead to process termination but to a success return value. I think this is a serious security breach. Maybe I am the first one to attempt to install multiple seccomp filters in the same process? The observed behavior is consistent with only the first filter being consulted. I'm using stock kernel 3.19 for what it's worth. Thanks, Felix -- 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] ARM: dts: DRA7: Add bandgap and related thermal nodes
On Tuesday 24 March 2015 01:09 AM, Nishanth Menon wrote:
From: Keerthy j-keer...@ti.com
Add bandgap and related thermal nodes. The patch adds 5 thermal
sensors. Only one cooling device for mpu as of now. The sensors are
the exact same on both dra72 and dra7. Introduce CPU, GPU, core nodes
for the moment as they are direct reuse of OMAP5 entities.
NOTE: OMAP4 has a finer counter granularity, which allows for a delay
of 1000ms in the thermal zone polling intervals. DRA7 have different
counter mechanism, which allows at maximum a 500ms timer. Adjust the
cpu thermal zone accordingly for DRA7.
Signed-off-by: Keerthy j-keer...@ti.com
[t-kri...@ti.com: few reuse from OMAP5 entities]
Signed-off-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes since V1:
- omap5-cpu-thermal.dtsi dropped
- approach similar to omap5
- added core and gpu thermal dtsi(they can be reused)
- Squashed patch #1 from v1 to patch #2 - this patch.
- Not carrying forward ack due to change
Thanks for updating Nishanth. Looks good to me.
- Keerthy
V1: http://marc.info/?t=14268810276r=1w=2
arch/arm/boot/dts/dra7.dtsi | 23 +++
arch/arm/boot/dts/dra72x.dtsi |5 +
arch/arm/boot/dts/dra74x.dtsi |5 +
3 files changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index eea4a54d6cb3..2d6a7e3e001f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -177,6 +177,18 @@
};
};
+ bandgap: bandgap@4a0021e0 {
+ reg = 0x4a0021e0 0xc
+ 0x4a00232c 0xc
+ 0x4a002380 0x2c
+ 0x4a0023C0 0x3c
+ 0x4a002564 0x8
+ 0x4a002574 0x50;
+ compatible = ti,dra752-bandgap;
+ interrupts = GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH;
+ #thermal-sensor-cells = 1;
+ };
+
cm_core_aon: cm_core_aon@4a005000 {
compatible = ti,dra7-cm-core-aon;
reg = 0x4a005000 0x2000;
@@ -1419,6 +1431,17 @@
status = disabled;
};
};
+
+ thermal_zones: thermal-zones {
+ #include omap4-cpu-thermal.dtsi
+ #include omap5-gpu-thermal.dtsi
+ #include omap5-core-thermal.dtsi
+ };
+
+};
+
+cpu_thermal {
+ polling-delay = 500; /* milliseconds */
};
/include/ dra7xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..6ac8e3601499 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -20,6 +20,11 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0;
+
+ /* cooling options */
+ cooling-min-level = 0;
+ cooling-max-level = 2;
+ #cooling-cells = 2; /* min followed by max */
};
};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..eef981f4bcd5 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -31,6 +31,11 @@
clock-names = cpu;
clock-latency = 30; /* From omap-cpufreq driver */
+
+ /* cooling options */
+ cooling-min-level = 0;
+ cooling-max-level = 2;
+ #cooling-cells = 2; /* min followed by max */
};
cpu@1 {
device_type = cpu;
--
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 00/16] net: dsa: HW bridging, EEE support
Hi Guenter, 2015-03-26 18:36 GMT-07:00 Guenter Roeck li...@roeck-us.net: Patch 1 to 7 of this series prepare the drivers using the mv88e6xxx code for HW bridging support, without adding the code itself. For the most part this factors out common port initialization code. There is no functional change except for patch 3, which disables the message port bit for the CPU port to prevent packet duplication if HW bridging is configured. Patch 8 adds the infrastructure for hardware bridging support to the mv88e6xxx code. Patch 9 wires the MV88E6352 driver to support hardware bridging. Patches 10 to 12 add support for ndo_fdb functions to the dsa subsystem, and wire up the MV88E6352 driver to support those functions. Patches 13 to 16 add EEE support and HW bridging support to the mv88e6171 driver. This set of patches is from Andrew, applied on top of the first set of patches. The series applies to net-next as of 3/24/2015. Thanks a lot to Andrew Lunn for testing and valuable feedback. This looks really good to me: Reviewed-by: Florian Fainelli f.faine...@gmail.com -- Florian -- 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] cpufreq: powernv: Add checks to report cpu frequency throttling conditions
On 27 March 2015 at 12:02, Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com wrote: The power and thermal safety of the system is taken care by an On-Chip-Controller (OCC) which is real-time subsystem embedded within the POWER8 processor. OCC continuously monitors the memory and core temperature, the total system power, state of power supply and fan. The cpu frequency can be throttled for the following reason: 1)If a processor crosses its power and temperature limit then OCC will lower its Pmax to reduce the frequency and voltage. 2)If OCC crashes then the system is forced to Psafe frequency. 3)If OCC fails to recover then the kernel is not allowed to do any further frequency changes and the chip will remain in Psafe. The user can see a drop in performance when frequency is throttled and is unaware of throttling. So we want to report such a condition so that user can check the OCC status to reboot the system or check for power supply or fan failures. All these details are required to be part of the commit, so that reviewers can understand it better. -- 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] MAINTAINERS: clk: discuss on the linux-...@vger.kernel.org list
On 03/25, Paul Walmsley wrote: Most Linux clock framework discussions take place on the linux-kernel@vger.kernel.org or linux-arm-ker...@lists.infradead.org mailing lists. The volume of unrelated messages on these lists makes it difficult for non-maintainers to follow along with discussions. Switch the discussion list for clock framework discussions to linux-...@vger.kernel.org. Also, add linux-...@vger.kernel.org as a mailing list for clock API discussions. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Mike Turquette mturque...@linaro.org Cc: Stephen Boyd sb...@codeaurora.org Cc: Thomas Gleixner t...@linutronix.de Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Viresh Kumar viresh.li...@gmail.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Prashant Gaikwad pgaik...@nvidia.com Cc: Tero Kristo t-kri...@ti.com Cc: Russell King li...@arm.linux.org.uk --- Acked-by: Stephen Boyd sb...@codeaurora.org Mike or I will pick this up for 4.1 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 32/35 linux-next] clk: constify of_device_id array
On 03/22, Fabian Frederick wrote: On 18 March 2015 at 15:15 Michael Turquette mturque...@linaro.org wrote: Quoting Fabian Frederick (2015-03-16 12:59:06) of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: Fabian Frederick f...@skynet.be Acked-by: Michael Turquette mturque...@linaro.org Thanks :) btw, something I forgot to mention in changelog is the __initdata - __initconst for ti_clkdm_match_table[] I can send it again with a new changelog if necessary ... Did you want us to take this through clk-next? If so please resend with the new commit text. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] sched: Improve load balancing in the presence of idle CPUs
Hi Srikar, On Fri, Mar 27, 2015 at 11:09:07AM +0530, Srikar Dronamraju wrote: Yes, the need_resched() in nohz_idle_balance() would exit the nohz_idle_balance if it has something to run. However I wonder if we should move the need_resched check out of the for loop. i.e the need_resched check should probably be there with the idle check. With the current code when the ilb cpus are not free: - We would be updating the nohz.next_balance even through we havent done any load balance. - We might iterate thro the nohz.idle_cpus_mask()s to find balance_cpus. Good idea, the nohz load balance will be delay since nohz.next_balance is updated inapposite when current ILB just be busy. I will send a patch to fix it. ;) Regards, Wanpeng Li -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the livepatching tree with the s390 tree
Hi Jiri, Today's linux-next merge of the livepatching tree got a conflict in arch/s390/Kconfig between commit 5a79859ae0f3 (s390: remove 31 bit support) from the s390 tree and commit b8887ad66c1c (livepatch: add support on s390) from the livepatching tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/s390/Kconfig index 1de26e1c48ac,eba9c1d0dab5.. --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@@ -132,7 -132,8 +132,8 @@@ config S39 select HAVE_KERNEL_XZ select HAVE_KPROBES select HAVE_KRETPROBES - select HAVE_KVM if 64BIT + select HAVE_KVM + select HAVE_LIVEPATCH select HAVE_MEMBLOCK select HAVE_MEMBLOCK_NODE_MAP select HAVE_MEMBLOCK_PHYS_MAP pgpVih90BjYUX.pgp Description: OpenPGP digital signature
Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote: A thing which bugs me about pread2() is that it is specifically tailored to applications which are able to use a partial read result. ie, by sending it over the network. Can you explain what you mean by this? Samba gets a pread request from a client for some bytes. The client will be confused when we send less than requested although the file is long enough to satisfy all. And of course fincore could be used by Samba etc to avoid blocking on reads. It wouldn't perform quite as well as pread2(), but I bet it's good enough. Bottom line: with pread2() there's still a need for fincore(), but with fincore() there probably isn't a need for pread2(). fincore would be a second syscall per pread, and it is not atomic. I've had discussions with MIPS based vendors who are worried about every single syscall. This is the #1 hottest code path in Samba. And I'm doubtful about claims that it absolutely has to be non-blocking 100% of the time. I bet that 99.99% is good enough. A fincore() option to run mark_page_accessed() against present pages would help with the race-with-reclaim situation. If you can make sure that after an fincore the pages remain in memory for x milliseconds the atomicity concern might go away. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-37-0, fax: +49-551-37-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kont...@sernet.de -- 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: [V4.0-rc5 Regression] drm/intel problem
Linus Torvalds torva...@linux-foundation.org writes: can you verify/confirm that current git works for you? And if not, maybe bisect exactly where it happened? I had a similar problem as Jörg on my Lenovo x230, display black on -rc5 except some small colored line on the top. I updated to current git (commit below) and everything looks to be ok after 10 minutes of testing. commit 3c435c1e472ba344ee25f795f4807d4457e61f6c Merge: be8a9bc63328 9822393d23ba Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Mar 26 15:04:05 2015 -0700 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Pull drm refcounting fixes from Dave Airlie: Here is the complete set of i915 bug/warn/refcounting fixes -- Kalle Valo -- 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: [RESEND PATCH 1/3] clk: si5351: Constify clock names and struct regmap_config
On 03/22, Max Filippov wrote: On Fri, Mar 20, 2015 at 2:34 PM, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: The regmap_config struct may be const because it is not modified by the driver and regmap_init() accepts pointer to const. Replace doubled const in the arrays of clock names with proper const pointer to const data. This fixes the warnings: drivers/clk/clk-si5351.c:71:25: warning: duplicate const drivers/clk/clk-si5351.c:74:25: warning: duplicate const drivers/clk/clk-si5351.c:77:25: warning: duplicate const drivers/clk/clk-si5351.c:80:25: warning: duplicate const Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com --- drivers/clk/clk-si5351.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Max Filippov jcmvb...@gmail.com Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
On Fri, 27 Mar 2015 06:41:25 +0100 Volker Lendecke volker.lende...@sernet.de wrote: On Thu, Mar 26, 2015 at 08:28:24PM -0700, Andrew Morton wrote: A thing which bugs me about pread2() is that it is specifically tailored to applications which are able to use a partial read result. ie, by sending it over the network. Can you explain what you mean by this? Samba gets a pread request from a client for some bytes. The client will be confused when we send less than requested although the file is long enough to satisfy all. Well it was my assumption that samba would be able to do something useful with a partial read - pread() is allowed to return less than requested. If it isn't the case that samba can use the partial read result then what does it do? It has to save the partial data, then do the additional IO? That's pretty clunky compared to if (it's all in cache) read it all now else ask a worker thread to read it all And of course fincore could be used by Samba etc to avoid blocking on reads. It wouldn't perform quite as well as pread2(), but I bet it's good enough. Bottom line: with pread2() there's still a need for fincore(), but with fincore() there probably isn't a need for pread2(). fincore would be a second syscall per pread, and it is not atomic. I've had discussions with MIPS based vendors who are worried about every single syscall. This is the #1 hottest code path in Samba. Bear in mind that these operations involve physical IO and large memcpy's. Yes, a fincore() approach will consume more CPU but the additional overhead will be relatively small. Tradeoffs are involved, and it may turn out that choosing a more flexible and powerful interface which is somewhat more CPU intensive is a better decision. It's hard to say until this is quantified (ie: measured). And I'm doubtful about claims that it absolutely has to be non-blocking 100% of the time. I bet that 99.99% is good enough. A fincore() option to run mark_page_accessed() against present pages would help with the race-with-reclaim situation. If you can make sure that after an fincore the pages remain in memory for x milliseconds the atomicity concern might go away. It won't be guaranteed that the fincore()+pread() will be non-blocking. But blocking will be very rare. I don't know whether the additional expense of activating the pages within fincore() is justified - needs runtime testing. -- 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] mmc: dw_mmc: Don't send clock off command if power is off
Hi, On 03/23/2015 06:59 AM, Doug Anderson wrote: Alim, On Sun, Mar 22, 2015 at 5:16 AM, Alim Akhtar alim.akh...@gmail.com wrote: case MMC_POWER_OFF: - /* Turn clock off before power goes down */ - dw_mci_setup_bus(slot, false); + /* Turn clock off before power goes down; only if powered */ + if (slot-host-vqmmc_enabled) + dw_mci_setup_bus(slot, false); vqmmc_enabled is always _true_ when entering MMC_POWER_OFF case..right? Is this done for extra protection? Or do you have a case where vqmmc is OFF and driver still calls dw_mci_setup_bus from here? Hmm. I know I got it into the debugger in at least one reboot case where it was failing to turn the clock off. I thought I confirmed it was the core trying to call MMC_POWER_OFF when the power was already off, but now I'm less certain. I looked back at my debug session and I don't see where I got that evidence. :-/ Certainly if I put a printout here right now I can't see my code making a difference. I'm not sure this is really needs...and i can't find any error case.. Best Regards, Jaehoon Chung Unfortunately the crash was a very rare one, so I may have to go back to the drawing board here... -Doug -- 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: Oops with tip/x86/fpu
On Thu, Mar 26, 2015 at 10:48:18PM +, Yu, Fenghua wrote: sctxt-fpstate=(void *)1 changes the fpstate pointer in the sigcontext. It will generate segfault and bad frame info in kernel. This is expected behavior, right? Is this still a valid test? Just to be clear, I saw a full-on kernel panic induced from an unprivileged application. Are you seeing something different? I use latest tip tree. Maybe it has the fixes already. I see bad frame reported in kernel. Seems the issue has been fixed in tip tree. Fenghua, if you're interested, the details are now public here: http://seclists.org/oss-sec/2015/q1/877 Quentin -- 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 6/7] scsi: storvsc: Don't assume that the scatterlist is not chained
The current code assumes that the scatterlists presented are not chained.
Fix the code to not make this assumption.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
V2: Got rid of double assignment. Olaf Hering o...@aepfle.de
drivers/scsi/storvsc_drv.c | 99 +--
1 files changed, 57 insertions(+), 42 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index f8e4dd9..4156e29 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -626,19 +626,6 @@ cleanup:
return NULL;
}
-/* Disgusting wrapper functions */
-static inline unsigned long sg_kmap_atomic(struct scatterlist *sgl, int idx)
-{
- void *addr = kmap_atomic(sg_page(sgl + idx));
- return (unsigned long)addr;
-}
-
-static inline void sg_kunmap_atomic(unsigned long addr)
-{
- kunmap_atomic((void *)addr);
-}
-
-
/* Assume the original sgl has enough room */
static unsigned int copy_from_bounce_buffer(struct scatterlist *orig_sgl,
struct scatterlist *bounce_sgl,
@@ -653,32 +640,38 @@ static unsigned int copy_from_bounce_buffer(struct
scatterlist *orig_sgl,
unsigned long bounce_addr = 0;
unsigned long dest_addr = 0;
unsigned long flags;
+ struct scatterlist *cur_dest_sgl;
+ struct scatterlist *cur_src_sgl;
local_irq_save(flags);
-
+ cur_dest_sgl = orig_sgl;
+ cur_src_sgl = bounce_sgl;
for (i = 0; i orig_sgl_count; i++) {
- dest_addr = sg_kmap_atomic(orig_sgl,i) + orig_sgl[i].offset;
+ dest_addr = (unsigned long)
+ kmap_atomic(sg_page(cur_dest_sgl)) +
+ cur_dest_sgl-offset;
dest = dest_addr;
- destlen = orig_sgl[i].length;
+ destlen = cur_dest_sgl-length;
if (bounce_addr == 0)
- bounce_addr = sg_kmap_atomic(bounce_sgl,j);
+ bounce_addr = (unsigned long)kmap_atomic(
+ sg_page(cur_src_sgl));
while (destlen) {
- src = bounce_addr + bounce_sgl[j].offset;
- srclen = bounce_sgl[j].length - bounce_sgl[j].offset;
+ src = bounce_addr + cur_src_sgl-offset;
+ srclen = cur_src_sgl-length - cur_src_sgl-offset;
copylen = min(srclen, destlen);
memcpy((void *)dest, (void *)src, copylen);
total_copied += copylen;
- bounce_sgl[j].offset += copylen;
+ cur_src_sgl-offset += copylen;
destlen -= copylen;
dest += copylen;
- if (bounce_sgl[j].offset == bounce_sgl[j].length) {
+ if (cur_src_sgl-offset == cur_src_sgl-length) {
/* full */
- sg_kunmap_atomic(bounce_addr);
+ kunmap_atomic((void *)bounce_addr);
j++;
/*
@@ -692,21 +685,27 @@ static unsigned int copy_from_bounce_buffer(struct
scatterlist *orig_sgl,
/*
* We are done; cleanup and return.
*/
- sg_kunmap_atomic(dest_addr -
orig_sgl[i].offset);
+ kunmap_atomic((void *)(dest_addr -
+ cur_dest_sgl-offset));
local_irq_restore(flags);
return total_copied;
}
/* if we need to use another bounce buffer */
- if (destlen || i != orig_sgl_count - 1)
- bounce_addr =
sg_kmap_atomic(bounce_sgl,j);
+ if (destlen || i != orig_sgl_count - 1) {
+ cur_src_sgl = sg_next(cur_src_sgl);
+ bounce_addr = (unsigned long)
+ kmap_atomic(
+ sg_page(cur_src_sgl));
+ }
} else if (destlen == 0 i == orig_sgl_count - 1) {
/* unmap the last bounce that is PAGE_SIZE */
- sg_kunmap_atomic(bounce_addr);
+ kunmap_atomic((void *)bounce_addr);
}
}
- sg_kunmap_atomic(dest_addr - orig_sgl[i].offset);
+
[PATCH V2 0/7] scsi: storvsc: Miscellaneous enhancements and fixes
This patch-set addresses perf issues discovered on the Azure storage stack. These patches also fix a couple of bugs. As in the first version of this patch-set, some of the patches are simply a resend. I have bumped up the version number of all patches though. In this version, I have addressed issues raised by Olaf Hering o...@aepfle.de, Long Li lon...@microsoft.com and Venkatesh Srinivas venkate...@google.com K. Y. Srinivasan (7): scsi: storvsc: Increase the ring buffer size scsi: storvsc: Size the queue depth based on the ringbuffer size scsi: storvsc: Always send on the selected outgoing channel scsi: storvsc: Retrieve information about the capability of the target scsi: storvsc: Fix a bug in copy_from_bounce_buffer() scsi: storvsc: Don't assume that the scatterlist is not chained scsi: storvsc: Set the tablesize based on the information given by the host drivers/scsi/storvsc_drv.c | 232 1 files changed, 149 insertions(+), 83 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
-Original Message-
From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
Sent: Thursday, March 26, 2015 7:18 AM
To: Wu, Feng; h...@zytor.com
Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
eric.au...@linaro.org; linux-kernel@vger.kernel.org;
io...@lists.linux-foundation.org; k...@vger.kernel.org
Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
is blocked
On Mon, Mar 16, 2015 at 11:42:06AM +, Wu, Feng wrote:
Do you have any reason why having the code at vcpu_put/vcpu_load is
better than the proposal to have the code at kvm_vcpu_block?
I think your proposal is good, I just want to better understand your idea
here.:)
Reduce the overhead of vcpu sched in / vcpu sched out, basically.
One thing, even we put the code to kvm_vcpu_block, we still need to add
code
at vcpu_put/vcpu_load for the preemption case like what I did now.
Global vector is a limited resources in the system, and this involves
common x86 interrupt code changes. I am not sure we can allocate
so many dedicated global vector for KVM usage.
Why not? Have KVM use all free vectors (so if vectors are necessary for
other purposes, people should shrink the KVM vector pool).
If we want to allocate more global vector for this usage, we need hpa's
input about it. Peter, what is your opinion?
Peter?
BTW the Intel docs talk about that (one vector per vCPU).
Yes, the Spec talks about this, but it is more complex using one vector per
vCPU.
It seems there is a bunch free:
commit 52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4
Author: Alex Shi alex@intel.com
Date: Thu Jun 28 09:02:23 2012 +0800
x86/tlb: replace INVALIDATE_TLB_VECTOR by
CALL_FUNCTION_VECTOR
Can you add only vcpus which have posted IRTEs that point to this
pCPU
to the HLT'ed vcpu lists? (so for example, vcpus without assigned
devices are not part of the list).
Is it easy to find whether a vCPU (or the associated domain) has
assigned
devices?
If so, we can only add those vCPUs with assigned devices.
When configuring IRTE, at kvm_arch_vfio_update_pi_irte?
Yes.
+
static int __init vmx_init(void)
{
int r, i, msr;
@@ -9429,6 +9523,8 @@ static int __init vmx_init(void)
update_ple_window_actual_max();
+ wakeup_handler_callback = wakeup_handler;
+
return 0;
out7:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0033df3..1551a46 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6152,6 +6152,21 @@ static int vcpu_enter_guest(struct
kvm_vcpu
*vcpu)
kvm_vcpu_reload_apic_access_page(vcpu);
}
+ /*
+* Since posted-interrupts can be set by VT-d HW now,
in this
+* case, KVM_REQ_EVENT is not set. We move the following
+* operations out of the if statement.
+*/
+ if (kvm_lapic_enabled(vcpu)) {
+ /*
+* Update architecture specific hints for APIC
+* virtual interrupt delivery.
+*/
+ if (kvm_x86_ops-hwapic_irr_update)
+ kvm_x86_ops-hwapic_irr_update(vcpu,
+
kvm_lapic_find_highest_irr(vcpu));
+ }
+
This is a hot fast path. You can set KVM_REQ_EVENT from
wakeup_handler.
I am afraid Setting KVM_REQ_EVENT from wakeup_handler doesn't
help
much,
if vCPU is running in ROOT mode, and VT-d hardware issues an
notification
event,
POSTED_INTR_VECTOR interrupt handler will be called.
If vCPU is in root mode, remapping HW will find IRTE configured with
vector == POSTED_INTR_WAKEUP_VECTOR, use that vector, which will
VM-exit, and execute the interrupt handler wakeup_handler. Right?
There are two cases:
Case 1: vCPU is blocked, so it is in root mode, this is what you
described
above.
Case 2, vCPU is running in root mode, such as, handling vm-exits, in
this
case,
the notification vector is 'POSTED_INTR_VECTOR', and if external
interrupts
from assigned devices happen, the handled of 'POSTED_INTR_VECTOR'
will
be called ( it is 'smp_kvm_posted_intr_ipi' in fact), this routine
doesn't
need
do real things, since the pending interrupts in PIR will be synced to
vIRR
before
VM-Entry (this code have already been there when
Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)
Hi Richard, At Thu, 26 Mar 2015 19:55:06 +0100, Richard Weinberger wrote: feeling that lib is the wrong name. It has not much do to with an architecture. could you care to elaborate your feeling more explicitly ? what is an architecture here and what is _not_ an architecture ? is UML an architecture in your sense (probably yes, but why)? UML is an architecture as it binds the whole kernel to a computer interface. Linux userspace in that case. and what is arch/lib missing for an architecture ? Your arch/lib does not bind the Linux kernel to an interface. It takes some part of Linux and duplicates kernel core subsystems to make that part work on its own. For example arch/lib contains a stub implementation of core VFS functions like register_filesystem(). Also it does not seem to use the kernel scheduler, you have your own. the scheduler is the part of which a library user (NUSE or DCE) should implement. This also infers that arch/lib will be broken most of the time as every time the networking stack references a new symbol it has to be duplicated into arch/lib. But this does not mean that your idea is bad, all I want to say that I'm not sure whether arch/lib is the right approach. Maybe Arnd has a better idea. one way to avoid the duplication is: to put our libos-specific implementation to the kernel core subsystem. Maybe this will introduce a bunch of #ifdefs (ifdef CONFIG_LIB) into cores, which I don't know it's okay or not. for example, add_timer() is implemented in arch/lib/timer.c while in kernel/time/timer.c in kernel core. # [04/11] to [08/11] of my RFC patches are these parts. We've been implemented these stubs (we call 'kernel glue code') into arch/lib because 1) we were in out-of-tree and 2) this won't disturb kernel core. OTOH, [03/11] (and [09/11] and [10/11]) is an original part of libos, which probably have no conflict (in terms of the concept) to the others. I'm still thinking arch/lib is an appropriate place. You don't implement an architecture, you take some part of Linux (the networking stack) and create stubs around it to make it work. That means that we'd also have to duplicate kernel functions into arch/lib to keep it running. again, the above same questions. it (arch/lib) is a hardware-independent architecture which provides necessary features to the remainder of kernel code, isn't it ? The stuff in arch/ is the code to glue the kernel to a specific piece of hardware. Your code does something between. You duplicate kernel core features to make a specific piece of code work in userland. indeed, 'something between' would be an appropriate word. thank you for your comment. -- Hajime -- 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] clk: qcom: Add support for NSS/GMAC clocks and resets
Add the NSS/GMAC clocks and the TCM clock and NSS resets.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/clk/qcom/gcc-ipq806x.c | 594 ++-
include/dt-bindings/clock/qcom,gcc-ipq806x.h | 2 +
include/dt-bindings/reset/qcom,gcc-ipq806x.h | 43 ++
3 files changed, 638 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
index ee73cc7f6e55..d66b3594c10f 100644
--- a/drivers/clk/qcom/gcc-ipq806x.c
+++ b/drivers/clk/qcom/gcc-ipq806x.c
@@ -140,12 +140,47 @@ static struct clk_regmap pll14_vote = {
},
};
+#define NSS_PLL_RATE(f, _l, _m, _n, i) \
+ { \
+ .freq = f, \
+ .l = _l, \
+ .m = _m, \
+ .n = _n, \
+ .ibits = i, \
+ }
+
+static struct pll_freq_tbl pll18_freq_tbl[] = {
+ NSS_PLL_RATE(55000, 44, 0, 1, 0x01495625),
+ NSS_PLL_RATE(73300, 58, 16, 25, 0x014b5625),
+};
+
+static struct clk_pll pll18 = {
+ .l_reg = 0x31a4,
+ .m_reg = 0x31a8,
+ .n_reg = 0x31ac,
+ .config_reg = 0x31b4,
+ .mode_reg = 0x31a0,
+ .status_reg = 0x31b8,
+ .status_bit = 16,
+ .post_div_shift = 16,
+ .post_div_width = 1,
+ .freq_tbl = pll18_freq_tbl,
+ .clkr.hw.init = (struct clk_init_data){
+ .name = pll18,
+ .parent_names = (const char *[]){ pxo },
+ .num_parents = 1,
+ .ops = clk_pll_ops,
+ },
+};
+
enum {
P_PXO,
P_PLL8,
P_PLL3,
P_PLL0,
P_CXO,
+ P_PLL14,
+ P_PLL18,
};
static const struct parent_map gcc_pxo_pll8_map[] = {
@@ -197,6 +232,22 @@ static const char *gcc_pxo_pll8_pll0_map[] = {
pll0_vote,
};
+static const struct parent_map gcc_pxo_pll8_pll14_pll18_pll0_map[] = {
+ { P_PXO, 0 },
+ { P_PLL8, 4 },
+ { P_PLL0, 2 },
+ { P_PLL14, 5 },
+ { P_PLL18, 1 },
+};
+
+static const char *gcc_pxo_pll8_pll14_pll18_pll0[] = {
+ pxo,
+ pll8_vote,
+ pll0_vote,
+ pll14,
+ pll18,
+};
+
static struct freq_tbl clk_tbl_gsbi_uart[] = {
{ 1843200, P_PLL8, 2, 6, 625 },
{ 3686400, P_PLL8, 2, 12, 625 },
@@ -2172,6 +2223,472 @@ static struct clk_branch usb_fs1_h_clk = {
},
};
+static const struct freq_tbl clk_tbl_gmac[] = {
+ { 13300, P_PLL0, 1, 50, 301 },
+ { 26600, P_PLL0, 1, 127, 382 },
+ { }
+};
+
+static struct clk_dyn_rcg gmac_core1_src = {
+ .ns_reg[0] = 0x3cac,
+ .ns_reg[1] = 0x3cb0,
+ .md_reg[0] = 0x3ca4,
+ .md_reg[1] = 0x3ca8,
+ .bank_reg = 0x3ca0,
+ .mn[0] = {
+ .mnctr_en_bit = 8,
+ .mnctr_reset_bit = 7,
+ .mnctr_mode_shift = 5,
+ .n_val_shift = 16,
+ .m_val_shift = 16,
+ .width = 8,
+ },
+ .mn[1] = {
+ .mnctr_en_bit = 8,
+ .mnctr_reset_bit = 7,
+ .mnctr_mode_shift = 5,
+ .n_val_shift = 16,
+ .m_val_shift = 16,
+ .width = 8,
+ },
+ .s[0] = {
+ .src_sel_shift = 0,
+ .parent_map = gcc_pxo_pll8_pll14_pll18_pll0_map,
+ },
+ .s[1] = {
+ .src_sel_shift = 0,
+ .parent_map = gcc_pxo_pll8_pll14_pll18_pll0_map,
+ },
+ .p[0] = {
+ .pre_div_shift = 3,
+ .pre_div_width = 2,
+ },
+ .p[1] = {
+ .pre_div_shift = 3,
+ .pre_div_width = 2,
+ },
+ .mux_sel_bit = 0,
+ .freq_tbl = clk_tbl_gmac,
+ .clkr = {
+ .enable_reg = 0x3ca0,
+ .enable_mask = BIT(1),
+ .hw.init = (struct clk_init_data){
+ .name = gmac_core1_src,
+ .parent_names = gcc_pxo_pll8_pll14_pll18_pll0,
+ .num_parents = 5,
+ .ops = clk_dyn_rcg_ops,
+ },
+ },
+};
+
+static struct clk_branch gmac_core1_clk = {
+ .halt_reg = 0x3c20,
+ .halt_bit = 4,
+ .hwcg_reg = 0x3cb4,
+ .hwcg_bit = 6,
+ .clkr = {
+ .enable_reg = 0x3cb4,
+ .enable_mask = BIT(4),
+ .hw.init = (struct clk_init_data){
+ .name = gmac_core1_clk,
+ .parent_names = (const char *[]){
+ gmac_core1_src,
+ },
+ .num_parents = 1,
+ .ops = clk_branch_ops,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+ },
+};
+
+static struct clk_dyn_rcg gmac_core2_src = {
+ .ns_reg[0] = 0x3ccc,
+ .ns_reg[1] = 0x3cd0,
+ .md_reg[0] = 0x3cc4,
+ .md_reg[1] = 0x3cc8,
+ .bank_reg = 0x3ca0,
+ .mn[0] = {
+ .mnctr_en_bit =
Re: String literals in __init functions
On 26 March 2015 at 23:15, Andrew Morton a...@linux-foundation.org wrote:
On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches j...@perches.com wrote:
I'd have thought that a function-wide
__attribute__((__string_section__(foo))
wouldn't be a ton of work to implement.
Maybe not.
Could some future version of gcc move string constants
in a function to a specific section marked in a manner
similar to what Andrew described above?
One thing which might complexicate this is
void foo()
{
p(bar);
}
void __attribute__((__string_section__(.init.rodata)) zot()
{
p(bar);
}
It would be silly to create two instances of bar.
No it wouldn't, because the bar in foo() has a different life time
than the bar in zot(). The compiler simply cannot know what the life
time of a section will be, so can only merge string within the same
section.
Beside that, your example is wrong and would generate a section
mismatch because zot() is not marked with __init so it's a function
that can be called after init. If one does, however, that p() will get
passed a dangling pointer. That's what modpost will complain about.
Change it thusly:
#define __mark_str(str) \
({ static const char var[]
__attribute__((__section__(.init.string))) = str; var; })
void foo()
{
p(bar);
}
void zot()
{
p(__mark_str(bar));
}
and we indeed get two copies of bar.
It would be nice not to do that, but I guess that losing this
optimization is a reasonable compromise.
As I said, it's legit to get two copies here, as the compiler simply
cannot deduce any semantics from the section name. However, this is a
synthetic example as in real life use-cases you'll only seldom have
the same format string be used twice. So this is, at best, a minor
issue.
Thanks,
Mathias
--
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 v8]: clk: Add common clock support for Mediatek MT8135 and MT8173
Mike, Stephen, Any chance to get this forward please? Sascha On Thu, Mar 19, 2015 at 09:42:04AM +0100, Sascha Hauer wrote: The following changes since commit 9eccca0843205f87c00404b663188b88eb248051: Linux 4.0-rc3 (2015-03-08 16:09:09 -0700) are available in the git repository at: git://git.pengutronix.de/git/imx/linux-2.6.git tags/v4.0-clk-mediatek-v8 for you to fetch changes up to 54449c74078c9d93619757c7a91b820eaa28c0f4: dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers (2015-03-19 09:15:33 +0100) This patchset contains the initial common clock support for Mediatek SoCs. Mediatek SoC's clock architecture comprises of various PLLs, dividers, muxes and clock gates. Changes in v8: - add patch to allow to put parent_name arrays in __initconst - put parent_name arrays into __initconst Changes in v7: - fix duplicate definition/declaration of mtk_register_reset_controller - fix pd_reg offset of tvdpll - make clk initialization arrays const Changes in v6: - rework PLL support, only a fraction of original size now - Move binding docs to Documentation/devicetree/bindings/arm/mediatek since the units are not really clock specific (they contain reset controllers) Changes in v5: - Add reset controller support for pericfg/infracfg - Use regmap for the gates - remove now unnecessary spinlock for the gates - Add PMIC wrapper support as of v3 Changes in v4: - Support MT8173 platform. - Re-ordered patchset. driver/clk/Makefile in 2nd patch. - Extract the common part definition(mtk_gate/mtk_pll/mtk_mux) from clk-mt8135.c/clk-mt8173.c to clk-mtk.c. - Refine code. Rmove unnessacary debug information and unsed defines, add prefix mtk_ for static functions. - Remove flag CLK_IGNORE_UNUSED and set flag CLK_SET_RATE_PARENT on gate/mux/fixed-factor. - Use spin_lock_irqsave(clk_ops_lock, flags) instead of mtk_clk_lock. - Example above include a node for the clock controller itself, followed by the i2c controller example above. Changes in v3: - Rebase to 3.19-rc1. - Refine code. Remove unneed functions, debug logs and comments, and fine tune error logs. Changes in v2: - Re-ordered patchset. Fold include/dt-bindings and DT document in 1st patch. James Liao (3): clk: mediatek: Add initial common clock support for Mediatek SoCs. clk: mediatek: Add basic clocks for Mediatek MT8135. clk: mediatek: Add basic clocks for Mediatek MT8173. Sascha Hauer (3): clk: make strings in parent name arrays const clk: mediatek: Add reset controller support dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset controllers .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 23 + .../bindings/arm/mediatek/mediatek,infracfg.txt| 30 + .../bindings/arm/mediatek/mediatek,pericfg.txt | 30 + .../bindings/arm/mediatek/mediatek,topckgen.txt| 23 + drivers/clk/Makefile | 1 + drivers/clk/clk-composite.c| 2 +- drivers/clk/clk-mux.c | 4 +- drivers/clk/mediatek/Makefile | 4 + drivers/clk/mediatek/clk-gate.c| 137 drivers/clk/mediatek/clk-gate.h| 49 ++ drivers/clk/mediatek/clk-mt8135.c | 640 drivers/clk/mediatek/clk-mt8173.c | 826 + drivers/clk/mediatek/clk-mtk.c | 197 + drivers/clk/mediatek/clk-mtk.h | 165 drivers/clk/mediatek/clk-pll.c | 325 drivers/clk/mediatek/reset.c | 99 +++ include/dt-bindings/clock/mt8135-clk.h | 190 + include/dt-bindings/clock/mt8173-clk.h | 231 ++ .../dt-bindings/reset-controller/mt8135-resets.h | 64 ++ .../dt-bindings/reset-controller/mt8173-resets.h | 63 ++ include/linux/clk-provider.h | 8 +- 21 files changed, 3104 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt create mode 100644 drivers/clk/mediatek/Makefile create mode 100644 drivers/clk/mediatek/clk-gate.c create mode 100644 drivers/clk/mediatek/clk-gate.h create mode 100644 drivers/clk/mediatek/clk-mt8135.c create mode 100644 drivers/clk/mediatek/clk-mt8173.c create mode 100644 drivers/clk/mediatek/clk-mtk.c create mode 100644
Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)
Hi Rusty,
At Fri, 27 Mar 2015 14:01:22 +1030,
Rusty Russell wrote:
Richard Weinberger rich...@nod.at writes:
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
has to be duplicated into arch/lib.
But this does not mean that your idea is bad, all I want to say that
I'm not sure whether arch/lib is the right approach.
Maybe Arnd has a better idea.
Exactly why I look forward to getting this in-tree. Jeremy Kerr and I
wrote nfsim back in 2005(!) which stubbed around the netfilter
infrastructure; with failtest and valgrind it found some nasty bugs. It
was too much hassle to maintain out-of-tree though :(
we're aware of (and respected ;)) nfsim, and expanded the
idea with DCE: make test ARCH=lib gives a broad testsuite
for network stack.
# we also have
make {test-valgrind, test-fault-injection} ARCH=lib
but not well tested (of the options themselves) yet.
there are the overview of test facility in my slides (the
link is in my original cover letter email)
I look forward to a flood of great bugfixes from this work :)
it has not been so much, but the following fix for xfrm
regression was detected by this framework (through jenkins
CI). git bisect is also easy (see tools/testing/libos/bisect.sh).
http://patchwork.ozlabs.org/patch/436351/
thanks for the comment.
-- Hajime
--
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: security problem with seccomp-filter
Cc'ing seccomp folks. On Fri, Mar 27, 2015 at 6:56 AM, Felix von Leitner felix-linuxker...@fefe.de wrote: Hi, I have had some great success with seccomp-filter a while ago, so I decided to use it to add some defense in depth to a ping program I wrote. The premise is, like for all ping programs I assume, that it starts setuid root, gets a raw socket, drops privileges, parses the command line, potentially does a DNS lookup, and then it sends and receives packets, using gettimeofday and poll. So I added a seccomp filter that allows this. But where do you put it? Ideally you'd want the filter installed right away after dropping privileges, so the command line parsing and the DNS routines are secured, too. But then you'd allow unnecessary attack surface (why allow open after the DNS routines are done parsing /etc/resolv.conf, for example?). The documentation says you can add more than one seccomp filter, just call prctl multiple times and allow prctl initially. So that's what I did. But when I added the secondary filters (which would blacklist open and setsockopt), and for double checking tried installing the last one twice (after the last one was supposed to blacklist prctl), to my surprise my attempt did not lead to process termination but to a success return value. I think this is a serious security breach. Maybe I am the first one to attempt to install multiple seccomp filters in the same process? The observed behavior is consistent with only the first filter being consulted. I'm using stock kernel 3.19 for what it's worth. Thanks, Felix -- 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/ -- Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] qspinlock stuff -v15
On 03/16/2015 06:46 PM, Peter Zijlstra wrote: Hi Waiman, As promised; here is the paravirt stuff I did during the trip to BOS last week. All the !paravirt patches are more or less the same as before (the only real change is the copyright lines in the first patch). The paravirt stuff is 'simple' and KVM only -- the Xen code was a little more convoluted and I've no real way to test that but it should be stright fwd to make work. I ran this using the virtme tool (thanks Andy) on my laptop with a 4x overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and it both booted and survived a hackbench run (perf bench sched messaging -g 20 -l 5000). So while the paravirt code isn't the most optimal code ever conceived it does work. Also, the paravirt patching includes replacing the call with movb $0, %arg1 for the native case, which should greatly reduce the cost of having CONFIG_PARAVIRT_SPINLOCKS enabled on actual hardware. I feel that if someone were to do a Xen patch we can go ahead and merge this stuff (finally!). These patches do not implement the paravirt spinlock debug stats currently implemented (separately) by KVM and Xen, but that should not be too hard to do on top and in the 'generic' code -- no reason to duplicate all that. Of course; once this lands people can look at improving the paravirt nonsense. last time I had reported some hangs in kvm case, and I can confirm that the current set of patches works fine. Feel free to add Tested-by: Raghavendra K T raghavendra...@linux.vnet.ibm.com #kvm pv As far as performance is concerned (with my 16core +ht machine having 16vcpu guests [ even w/ , w/o the lfsr hash patchset ]), I do not see any significant observations to report, though I understand that we could see much more benefit with large number of vcpus because of possible reduction in cache bouncing. -- 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: String literals in __init functions
On 26 March 2015 at 22:40, Andrew Morton a...@linux-foundation.org wrote: On Thu, 26 Mar 2015 21:49:06 +0100 Mathias Krause mini...@googlemail.com wrote: Andrew, what's your opinion on such a patch set? Do you too think it's useful? Or do you share Ingo's fear about the additional maintenance burden? I don't think the burden would be t high, although it will mess the code up a bit. The post-build checking for section reference mismatches will help, although that seems to have got itself turned off (what happened there?). Seem to be working fine here. This is make M=lib/, building the test module: CC [M] lib/test_module.o Building modules, stage 2. MODPOST 1 modules LD [M] lib/test_module.ko This is the same module with two pi_info() calls in a non-__init function, therefore generating section mismatches: CC [M] lib/test_module.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' LD [M] lib/test_module.ko Did anyone look at writing a postprocessor for the .s files? It doesn't look like it will be too hard from an initial peek. Did anyone ask the gcc developers? I'd have thought that a function-wide __attribute__((__string_section__(foo)) wouldn't be a ton of work to implement. The point is you cannot blindly mark all strings referenced from __init / __exit code to end up in a matching string section because strings in this code might have to live longer when passed to functions keeping a pointer on them. For example, the name passed to class_create() won't be copied. If that one would go into the .init.rodata section automatically, we would have dangling pointers after the .init.* memory got freed. To know if it's safe to automatically put a string into an .init / .exit section one needs to see the whole code. That's why I'm reasoning it needs to be an LTO pass, not a .s post-processor or function wide section attribute. Or, as in my approach, a source level annotation. Thanks, Mathias -- 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/
[tip:perf/core] perf tools: Set JOBS based on CPU or processor
Commit-ID: 6428c59a97de7c3d88fc4e66317daea5e5008758 Gitweb: http://git.kernel.org/tip/6428c59a97de7c3d88fc4e66317daea5e5008758 Author: David Ahern david.ah...@oracle.com AuthorDate: Tue, 24 Mar 2015 12:10:55 -0400 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Thu, 26 Mar 2015 10:52:28 -0300 perf tools: Set JOBS based on CPU or processor Number of JOBS to use is set automatically to the number of processors found in /proc/cpuinfo. SPARC uses 'CPU' lines rather than 'processor'. Update the check in perf's Makefile to work for SPARC. Signed-off-by: David Ahern david.ah...@oracle.com Acked-by: Jiri Olsa jo...@kernel.org Cc: Namhyung Kim namhy...@kernel.org Link: http://lkml.kernel.org/r/1427213455-127249-1-git-send-email-david.ah...@oracle.com Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index d5020ae..c699dc3 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -24,7 +24,7 @@ unexport MAKEFLAGS # (To override it, run 'make JOBS=1' and similar.) # ifeq ($(JOBS),) - JOBS := $(shell grep -c ^processor /proc/cpuinfo 2/dev/null) + JOBS := $(shell egrep -c '^processor|^CPU' /proc/cpuinfo 2/dev/null) ifeq ($(JOBS),0) JOBS := 1 endif -- 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/
[tip:perf/core] perf evlist: Return the first evsel with an invalid filter in apply_filters()
Commit-ID: 23d4aad48e31d3269af484dd2f9bd251278cd667
Gitweb: http://git.kernel.org/tip/23d4aad48e31d3269af484dd2f9bd251278cd667
Author: Arnaldo Carvalho de Melo a...@redhat.com
AuthorDate: Tue, 24 Mar 2015 19:23:47 -0300
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Thu, 26 Mar 2015 10:52:28 -0300
perf evlist: Return the first evsel with an invalid filter in apply_filters()
Use of a bad filter currently generates the message:
Error: failed to set filter with 22 (Invalid argument)
Add the event name to make it clear to which event the filter
failed to apply:
Error: Failed to set filter foo on event sched:sg_lb_stats: 22: Invalid
argument
To test it use something like:
# perf record -e sched:sched_switch -e sched:*fork --filter parent_pid==1 -e
sched:*wait* --filter bla usleep 1
Error: failed to set filter bla on event sched:sched_stat_iowait with 22
(Invalid argument)
#
Based-on-a-patch-by: David Ahern dsah...@gmail.com
Acked-by: David Ahern dsah...@gmail.com
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-d7gq2fjvaecozp9o2i0si...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
tools/perf/builtin-record.c | 5 +++--
tools/perf/builtin-stat.c | 5 +++--
tools/perf/util/evlist.c| 6 --
tools/perf/util/evlist.h| 2 +-
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 5a2ff51..18aad239 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -161,8 +161,9 @@ try_again:
}
}
- if (perf_evlist__apply_filters(evlist)) {
- error(failed to set filter with %d (%s)\n, errno,
+ if (perf_evlist__apply_filters(evlist, pos)) {
+ error(failed to set filter \%s\ on event %s with %d (%s)\n,
+ pos-filter, perf_evsel__name(pos), errno,
strerror_r(errno, msg, sizeof(msg)));
rc = -1;
goto out;
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index d4d1b77..f7b8218 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -684,8 +684,9 @@ static int __run_perf_stat(int argc, const char **argv)
unit_width = l;
}
- if (perf_evlist__apply_filters(evsel_list)) {
- error(failed to set filter with %d (%s)\n, errno,
+ if (perf_evlist__apply_filters(evsel_list, counter)) {
+ error(failed to set filter \%s\ on event %s with %d (%s)\n,
+ counter-filter, perf_evsel__name(counter), errno,
strerror_r(errno, msg, sizeof(msg)));
return -1;
}
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 8d0b623..82bf224 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1050,7 +1050,7 @@ out_delete_threads:
return -1;
}
-int perf_evlist__apply_filters(struct perf_evlist *evlist)
+int perf_evlist__apply_filters(struct perf_evlist *evlist, struct perf_evsel
**err_evsel)
{
struct perf_evsel *evsel;
int err = 0;
@@ -1062,8 +1062,10 @@ int perf_evlist__apply_filters(struct perf_evlist
*evlist)
continue;
err = perf_evsel__set_filter(evsel, ncpus, nthreads,
evsel-filter);
- if (err)
+ if (err) {
+ *err_evsel = evsel;
break;
+ }
}
return err;
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index f07c984..fb19c47 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -152,7 +152,7 @@ static inline void perf_evlist__set_maps(struct perf_evlist
*evlist,
}
int perf_evlist__create_maps(struct perf_evlist *evlist, struct target
*target);
-int perf_evlist__apply_filters(struct perf_evlist *evlist);
+int perf_evlist__apply_filters(struct perf_evlist *evlist, struct perf_evsel
**err_evsel);
void __perf_evlist__set_leader(struct list_head *list);
void perf_evlist__set_leader(struct perf_evlist *evlist);
--
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/
[tip:perf/core] perf trace: Fix syscall enter formatting bug
Commit-ID: 6ebad5c101de0d43dafc9aff88bad45819f10470 Gitweb: http://git.kernel.org/tip/6ebad5c101de0d43dafc9aff88bad45819f10470 Author: Arnaldo Carvalho de Melo a...@redhat.com AuthorDate: Wed, 25 Mar 2015 18:01:15 -0300 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Thu, 26 Mar 2015 10:52:29 -0300 perf trace: Fix syscall enter formatting bug commit e596663ebb28a068f5cca57f83285b7b293a2c83 Author: Arnaldo Carvalho de Melo a...@redhat.com Date: Fri Feb 13 13:22:21 2015 -0300 perf trace: Handle multiple threads better wrt syscalls being intermixed Introduced a bug where it considered the number of bytes output directly to the output file when formatting the syscall entry buffer that is stored to be finally printed at syscall exit, ending up leaving garbage at the start of syscalls that appeared while another syscall was being processed, in another thread. Fix it. Example of garbage in the output before this patch: 4280.102 ( 0.000 ms): lsmd/763 ... [continued]: select()) = 0 Timeout 4280.107 (275.250 ms): tuned/852 select(tvp: 0x7f41f7ffde50) ... 4280.109 ( 0.002 ms): lsmd/763 Xl��) = -10 4639.197 ( 0.000 ms): systemd-journa/542 ... [continued]: epoll_wait()) = 1 4639.202 (359.088 ms): lsmd/763 select(n: 6, inp: 0x721daad0, tvp: 0x721daac0) ... 4639.207 ( 0.005 ms): systemd-journa/542 Hn�� ) = 106 4639.221 ( 0.002 ms): systemd-journa/542 uname(name: 0x7ffdbaed8e00) = 0 4639.271 ( 0.008 ms): systemd-journa/542 ftruncate(fd: 11/run/log/journal/60cd52417cf440a4a80107518bbd3c20/system.journal, length: 50331648) = 0 Cc: Adrian Hunter adrian.hun...@intel.com Cc: Borislav Petkov b...@suse.de Cc: David Ahern dsah...@gmail.com Cc: Don Zickus dzic...@redhat.com Cc: Frederic Weisbecker fweis...@gmail.com Cc: Jiri Olsa jo...@redhat.com Cc: Namhyung Kim namhy...@kernel.org Cc: Stephane Eranian eran...@google.com Link: http://lkml.kernel.org/n/tip-9ckfe8mvsedgkg6y80gz1...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/builtin-trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c index 001c6ae..bcc98ce 100644 --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -1735,7 +1735,7 @@ static int trace__sys_enter(struct trace *trace, struct perf_evsel *evsel, } if (!trace-summary_only) - printed += trace__printf_interrupted_entry(trace, sample); + trace__printf_interrupted_entry(trace, sample); ttrace-entry_time = sample-time; msg = ttrace-entry_str; -- 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] cpufreq: powernv: Report cpu frequency throttling
On 27 March 2015 at 13:02, Shilpasri G Bhat
shilpa.b...@linux.vnet.ibm.com wrote:
The power and thermal safety of the system is taken care by an
On-Chip-Controller (OCC) which is real-time subsystem embedded within
the POWER8 processor. OCC continuously monitors the memory and core
temperature, the total system power, state of power supply and fan.
The cpu frequency can be throttled by OCC for the following reasons:
1)If a processor crosses its power and temperature limit then OCC will
lower its Pmax to reduce the frequency and voltage.
2)If OCC crashes then the system is forced to Psafe frequency.
3)If OCC fails to recover then the kernel is not allowed to do any
further frequency changes and the chip will remain in Psafe.
The user can see a drop in performance when frequency is throttled and
is unaware of throttling. So detect and report such a condition so
that user can check the OCC status to reboot the system or check for
power supply or fan failures.
The current status of the core is read from Power Management Status
Register(PMSR) to check if any of the throttling condition is occurred
and the appropriate throttling message is reported.
Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com
---
Changes from V2:
-Changed commit log to add more details.
-Fixed multi-line comment to proper format
Changes from V1: Removed unused value of PMCR register
drivers/cpufreq/powernv-cpufreq.c | 40
++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 2dfd4fd..0eb89a9 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -36,7 +36,7 @@
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
-static bool rebooting;
+static bool rebooting, throttled;
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -294,6 +294,41 @@ static inline unsigned int get_nominal_index(void)
return powernv_pstate_info.max - powernv_pstate_info.nominal;
}
+static void powernv_cpufreq_throttle_check(unsigned int cpu)
+{
+ unsigned long pmsr;
+ int pmsr_pmax, pmsr_lp;
+
+ pmsr = get_pmspr(SPRN_PMSR);
+
+ /* Check for Pmax Capping */
+ pmsr_pmax = (s8)((pmsr 32) 0xFF);
+ if (pmsr_pmax != powernv_pstate_info.max) {
+ throttled = true;
+ pr_warn(Cpu %d Pmax is reduced to %d\n, cpu, pmsr_pmax);
+ }
+
+ /*
+* Check for Psafe by reading LocalPstate
+* or check if Psafe_mode_active- 34th bit is set in PMSR.
+*/
+ pmsr_lp = (s8)((pmsr 48) 0xFF);
+ if ((pmsr_lp powernv_pstate_info.min) || ((pmsr 30) 1)) {
+ throttled = true;
+ pr_warn(Cpu %d in Psafe %d PMSR[34]=%lx\n, cpu,
+ pmsr_lp, ((pmsr 30) 1));
+ }
+
+ /* Check if SPR_EM_DISABLED- 33rd bit is set in PMSR */
+ if ((pmsr 31) 1) {
+ throttled = true;
+ pr_warn(Frequency management disabled cpu %d PMSR[33]=%lx\n,
+ cpu, ((pmsr 31) 1));
+ }
+ if (throttled)
+ pr_warn(Cpu Frequency is throttled\n);
+}
+
/*
* powernv_cpufreq_target_index: Sets the frequency corresponding to
* the cpufreq table entry indexed by new_index on the cpus in the
@@ -307,6 +342,9 @@ static int powernv_cpufreq_target_index(struct
cpufreq_policy *policy,
if (unlikely(rebooting) new_index != get_nominal_index())
return 0;
+ if (!throttled)
+ powernv_cpufreq_throttle_check(smp_processor_id());
+
freq_data.pstate_id = powernv_freqs[new_index].driver_data;
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
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/
[tip:perf/core] perf: Bump max number of cpus to 1024
Commit-ID: 4d255766d28b1fecec7e00ab4166b2c17bfc37be Gitweb: http://git.kernel.org/tip/4d255766d28b1fecec7e00ab4166b2c17bfc37be Author: David Ahern david.ah...@oracle.com AuthorDate: Tue, 24 Mar 2015 12:10:38 -0400 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Thu, 26 Mar 2015 10:52:28 -0300 perf: Bump max number of cpus to 1024 SPARC based systems currently support up to 1024 cpus (e.g. T5-8). Allow perf to work on those systems. Signed-off-by: David Ahern david.ah...@oracle.com Link: http://lkml.kernel.org/r/1427213438-127216-1-git-send-email-david.ah...@oracle.com Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/perf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/perf.h b/tools/perf/perf.h index 1caa70a..c38a085 100644 --- a/tools/perf/perf.h +++ b/tools/perf/perf.h @@ -29,7 +29,7 @@ static inline unsigned long long rdclock(void) return ts.tv_sec * 10ULL + ts.tv_nsec; } -#define MAX_NR_CPUS256 +#define MAX_NR_CPUS1024 extern const char *input_name; extern bool perf_host, perf_guest; -- 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/
[tip:perf/core] tools lib traceevent: Zero should not be considered not found in eval_flag()
Commit-ID: 7c27f78a297b54c3c2f5075cb15d33431b7f6333
Gitweb: http://git.kernel.org/tip/7c27f78a297b54c3c2f5075cb15d33431b7f6333
Author: Steven Rostedt rost...@goodmis.org
AuthorDate: Tue, 24 Mar 2015 14:58:13 -0400
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Thu, 26 Mar 2015 10:52:29 -0300
tools lib traceevent: Zero should not be considered not found in eval_flag()
Guilherme Cox found that:
There is, however, a potential bug if there is an item with code zero
that is not the first one in the symbol list, since eval_flag(..)
returns 0 when it doesn't find anything.
That is, if you have the following enums:
enum {
FOO_START = 0,
FOO_GO= 1,
FOO_END = 2
}
and then have:
__print_symbolic(foo, FOO_GO, go, FOO_START, start,
FOO_END, end)
If none of the enums are known to pevent, then eval_flag() will return
zero, and it will match it to the first item in the list, which would be
FOO_GO, which is not zero.
Luckily, in most cases, the first element would be zero, and the parsing
would match out of sheer luck.
Reported-by: Guilherme Cox c...@computer.org
Signed-off-by: Steven Rostedt rost...@goodmis.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Link: http://lkml.kernel.org/r/20150324145813.0bfe9...@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
tools/lib/traceevent/event-parse.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index b6d11ee..6d31b64 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3615,7 +3615,7 @@ static const struct flag flags[] = {
{ HRTIMER_RESTART, 1 },
};
-static unsigned long long eval_flag(const char *flag)
+static long long eval_flag(const char *flag)
{
int i;
@@ -3631,7 +3631,7 @@ static unsigned long long eval_flag(const char *flag)
if (strcmp(flags[i].name, flag) == 0)
return flags[i].value;
- return 0;
+ return -1LL;
}
static void print_str_to_seq(struct trace_seq *s, const char *format,
@@ -3705,7 +3705,7 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
struct print_flag_sym *flag;
struct format_field *field;
struct printk_map *printk;
- unsigned long long val, fval;
+ long long val, fval;
unsigned long addr;
char *str;
unsigned char *hex;
@@ -3764,11 +3764,11 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
print = 0;
for (flag = arg-flags.flags; flag; flag = flag-next) {
fval = eval_flag(flag-value);
- if (!val !fval) {
+ if (!val fval 0) {
print_str_to_seq(s, format, len_arg, flag-str);
break;
}
- if (fval (val fval) == fval) {
+ if (fval 0 (val fval) == fval) {
if (print arg-flags.delim)
trace_seq_puts(s, arg-flags.delim);
print_str_to_seq(s, format, len_arg, flag-str);
--
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 v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On Fri, 27 Mar 2015, Beomho Seo wrote: On 03/26/2015 10:54 PM, Lee Jones wrote: On Thu, 26 Mar 2015, Beomho Seo wrote: On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: 2015-03-24 9:01 GMT+01:00 Beomho Seo beomho@samsung.com: On 03/10/2015 10:44 PM, Beomho Seo wrote: On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: 2015-03-09 1:35 GMT+01:00 Beomho Seo beomho@samsung.com: On 03/08/2015 05:13 AM, Sebastian Reichel wrote: On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: From: Beomho Seo beomho@samsung.com This patch adds device driver of max77843 charger. This driver provide initialize each charging mode(e.g. fast charge, top-off mode and constant charging mode so on.). Additionally, control charging paramters to use i2c interface. Cc: Sebastian Reichel s...@kernel.org Signed-off-by: Beomho Seo beomho@samsung.com Reviewed-By: Sebastian Reichel s...@kernel.org I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian This patch reviewed by Sebastian. Could you Please merge that your git tree ? Hi, ... and again we are adding a new driver for very similar chipset to already supported. I looked at spec and the charger's registers are almost the same as for max77693. Their layout and addresses are the same. I see some minor differences, probably the most important would be different values current (fast-charge, top-off). But still 90% of registers are the same... Do we really have to add new driver? Best regards, Krzysztof Hi, Thank you for your comment. As you say, both chip set are similar. But new driver need for support max77843. It is support different below - Provide Battery presence information. Another set of power supply properties could be added for that chip. This way the get_property() function would be the same but actually the POWER_SUPPLY_PROP_PRESENT won't be called for max77693. - Can OTG FET control. Where the OTG FET feature is it enabled in your driver? I couldn't find it. Sorry. This driver don't control OTG FET feature. - Bigger Fast charge current, Top Off current Threshold selection. - Various and bigger OTG current limitation. - Bigger primary charger termination voltage setting. - Different maximum input current limit selection(Different step). Yes, I mentioned some of these differences (the Fast/top-off differences). These are differences in values so it does not require new driver. There is need to develop new driver just to support different current (3.0 A instead of 2.1 A) or voltage threshold. They are different charging current, OTG current limitation, top off current, charging limitation value. In case OTG current limitation different not limitation value but using register bit(max77843 use[7:6] max77693 use[7] bit only). Even if this driver not support all feature, some register different with max77693(support value, use register bit). If this driver will combined with max77693 may even be beneficial for new Maxim driver. But the present, this driver is related with max77843 core driver and max77843-regulator. So I hope this driver merge first. And then will extend two driver(max77843 charger and max77693 charger). I still prefer merging common drivers into one instead of creating some more of them. However I understand your point and I am not entirely opposed against. Especially that you invested quite a bit of time for developing this and my feedback was quite late. To summarize I am fine with your approach. Best regards, Krzysztof Dear Lee Jones, Could you please merge that your git tree ? Sorry, I'm lost. Why am I taking this though the MFD tree? What patches are left? Where are they going? Am I taking any other patches? Max77843 charger driver is max77843 mfd core dependency. What kind of dependancy? Runtime or build? Where is the patch that it depends on? Is it in -next for in Mainline already? If you think this patch will suitable for battery tree(or other tree), I would like request for merge battery tree. If this patch has no build dependencies on patches which are in -next, but not in Mainline then it will have to go in via the same tree that the dependencies were applied to. If the dependencies are already in Mainline, or they are not build-deps, then it should go in via the correct tree, which I believe is Sebastian's tree. Also, I will send again this patch and device tree binding document. Either way you should do that. Mark them as RESEND instead of PATCH and apply all of the Acks you have accumulated so far. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter |
Re: [PATCH] doc: completion: context, scope and language fixes
* Jonathan Corbet cor...@lwn.net wrote: On Fri, 20 Feb 2015 12:28:48 -0500 Nicholas Mc Guire hof...@osadl.org wrote: This hopfully address all of the issues Ingo Molnar mi...@kernel.org noted in https://lkml.org/lkml/2015/2/18/690. This looks OK to me, modulo some small English quibbles. Ingo, does this satisfy your concerns? I wasn't Cc:-ed to the patch and it wasn't Cc:-ed to lkml either :-( (It would be very useful if documentation update patches were Cc:-ed to the maintainers of the affected subsystem, to double check things and so.) Thanks, Ingo -- 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/
Support of usb_phy notifier in generic phy.
Hi Kishon This is regarding the notification of usb_phy_events option which was available with usb_phy. In my scenario, the phy driver gets the connect/disconnect event, and does the initial phy programming. Then I want to notify the gadget driver of the same. In usb_phy the notifier option was available, which I could use for the same. Can you please help me understand if, 1. there a plan to add notifications support to the generic phy? 2. If not, is there other option I can use for the same. Thanks and Regards Anjana -- 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 v10 04/11] sched: Make sched entity usage tracking scale-invariant
On 26 March 2015 at 18:38, Morten Rasmussen morten.rasmus...@arm.com wrote: On Wed, Mar 25, 2015 at 06:08:42PM +, Vincent Guittot wrote: On 25 March 2015 at 18:33, Peter Zijlstra pet...@infradead.org wrote: On Tue, Mar 24, 2015 at 11:00:57AM +0100, Vincent Guittot wrote: On 23 March 2015 at 14:19, Peter Zijlstra pet...@infradead.org wrote: On Fri, Feb 27, 2015 at 04:54:07PM +0100, Vincent Guittot wrote: + unsigned long scale_freq = arch_scale_freq_capacity(NULL, cpu); + sa-running_avg_sum += delta_w * scale_freq + SCHED_CAPACITY_SHIFT; so the only thing that could be improved is somehow making this multiplication go away when the arch doesn't implement the function. But I'm not sure how to do that without #ifdef. Maybe a little something like so then... that should make the compiler get rid of those multiplications unless the arch needs them. yes, it removes useless multiplication when not used by an arch. It also adds a constraint on the arch side which have to define arch_scale_freq_capacity like below: #define arch_scale_freq_capacity xxx_arch_scale_freq_capacity with xxx_arch_scale_freq_capacity an architecture specific function Yeah, but it not being weak should make that a compile time warn/fail, which should be pretty easy to deal with. If it sounds acceptable i can update the patch with your proposal ? I'll stick it to the end, I just wanted to float to patch to see if people had better solutions. ok. all other methods that i have tried, was removing the optimization when default arch_scale_freq_capacity was used Another potential solution is to stay with weak functions but move the multiplication and shift into the arch_scale_*() functions by passing the value we want to scale into the arch_scale_*() function. That way we can completely avoid multiplication and shift in the default case (no arch_scale*() implementations, which is better than what we have today. the sched_rt_avg_update only uses the mul with arch_scale_freq_capacity because the shift by SCHED_CAPACITY_SHIFT has been factorized in scale_rt_capacity The only downside is that for frequency invariance we need three arch_scale_freq_capacity() calls instead of two. -- 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 Mar 27
Hi all, Changes since 20150326: Thr arm64 tree has caused overnight build failures so I reverted 3 commits. The powerpc-mpe tree lost its build failure. The vfs tree still had its build failure for which I applied a patch. The dt-rh tree gained a conflict against the mips tree. The livepatching tree gained a conflict against the s390 tree. Non-merge commits (relative to Linus' tree): 6750 6278 files changed, 279774 insertions(+), 130291 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 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 212 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (3c435c1e472b Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (526299ce4eab ARM: 8313/1: Use read_cpuid_ext() macro instead of inline asm) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging powerpc-merge-mpe/fixes (44d5f6f5901e powerpc/book3s: Fix the MCE code to use CONFIG_KVM_BOOK3S_64_HANDLER) Merging sparc/master (90a5a895cc8b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging net/master (dde93dfea53c cxgb4: Fix frame size warning for 32 bit arch) Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in xfrm_lookup()) Merging sound-current/for-linus (af95b41426e0 ALSA: hda - Add one more node in the EAPD supporting candidate list) Merging pci-current/for-linus (bc3b5b47c80d PCI: cpcihp: Add missing curly braces in cpci_configure_slot()) Merging wireless-drivers/master (6ae4ccfee09e Merge tag 'iwlwifi-for-kalle-2014-03-22' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (bc465aa9d045 Linux 4.0-rc5) Merging tty.current/tty-linus (8e4934c6d6c6 tty: serial: fsl_lpuart: clear receive flag on FIFO flush) Merging usb.current/usb-linus (baf7a6c72668 Merge tag 'fixes-for-v4.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (65582a7f4ce5 usb: isp1760: fix spin unlock in the error path of isp1760_udc_start) Merging usb-serial-fixes/usb-linus (b229a0f840f7 USB: ftdi_sio: Use jtag quirk for SNAP Connect E10) Merging staging.current/staging-linus (3d8bbe243dc7 Merge tag 'iio-fixes-for-4.0c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (bc465aa9d045 Linux 4.0-rc5) Merging input-current/for-linus (98dc0703735d Input: synaptics - add quirk for Thinkpad E440) Merging crypto-current/master (ccfe8c3f7e52 crypto: aesni - fix memory usage in GCM decryption) Merging ide/master (b314acaccd7e Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (ec76f4007079 vfio-pci: Add missing break to enable VFIO_PCI_ERR_IRQ_INDEX)
Re: [PATCH v1 09/47] vidoe: fbdev: atyfb: remove and fix MTRR MMIO hole work around
On Sat, Mar 21, 2015 at 11:15:14AM +0200, Ville Syrjälä wrote:
On Fri, Mar 20, 2015 at 04:17:59PM -0700, Luis R. Rodriguez wrote:
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index 8025624..8875e56 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2630,21 +2630,10 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_MTRR
par-mtrr_aper = -1;
- par-mtrr_reg = -1;
if (!nomtrr) {
- /* Cover the whole resource. */
- par-mtrr_aper = mtrr_add(par-res_start, par-res_size,
+ par-mtrr_aper = mtrr_add(info-fix.smem_start,
+ info-fix.smem_len,
MTRR_TYPE_WRCOMB, 1);
MTRRs need power of two size, so how is this supposed to work?
Still waiting for an answer...
- if (par-mtrr_aper = 0 !par-aux_start) {
- /* Make a hole for mmio. */
- par-mtrr_reg = mtrr_add(par-res_start + 0x80 -
-GUI_RESERVE, GUI_RESERVE,
-MTRR_TYPE_UNCACHABLE, 1);
- if (par-mtrr_reg 0) {
- mtrr_del(par-mtrr_aper, 0, 0);
- par-mtrr_aper = -1;
- }
- }
}
#endif
@@ -2776,10 +2765,6 @@ aty_init_exit:
par-pll_ops-set_pll(info, par-saved_pll);
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
mtrr_del(par-mtrr_aper, 0, 0);
par-mtrr_aper = -1;
@@ -3466,7 +3451,7 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
}
info-fix.mmio_start = raddr;
- par-ati_regbase = ioremap(info-fix.mmio_start, 0x1000);
+ par-ati_regbase = ioremap_nocache(info-fix.mmio_start, 0x1000);
if (par-ati_regbase == NULL)
return -ENOMEM;
@@ -3491,6 +3476,8 @@ static int atyfb_setup_generic(struct pci_dev *pdev,
struct fb_info *info,
info-fix.smem_start = addr;
info-fix.smem_len = 0x80;
+ aty_fudge_framebuffer_len(info);
+
info-screen_base = ioremap(info-fix.smem_start, info-fix.smem_len);
if (info-screen_base == NULL) {
ret = -ENOMEM;
@@ -3563,6 +3550,7 @@ static int atyfb_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
par = info-par;
+ par-bus_type = PCI;
info-fix = atyfb_fix;
info-device = pdev-dev;
par-pci_id = pdev-device;
@@ -3732,10 +3720,6 @@ static void atyfb_remove(struct fb_info *info)
#endif
#ifdef CONFIG_MTRR
- if (par-mtrr_reg = 0) {
- mtrr_del(par-mtrr_reg, 0, 0);
- par-mtrr_reg = -1;
- }
if (par-mtrr_aper = 0) {
mtrr_del(par-mtrr_aper, 0, 0);
par-mtrr_aper = -1;
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
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: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Wed, 2015-03-25 at 10:54 +, Mel Gorman wrote:
On Mon, Mar 23, 2015 at 04:46:21PM +0800, Huang Ying wrote:
My attention is occupied by the automatic NUMA regression at the moment
but I haven't forgotten this. Even with the high client count, I was not
able to reproduce this so it appears to depend on the number of CPUs
available to stress the allocator enough to bypass the per-cpu allocator
enough to contend heavily on the zone lock. I'm hoping to think of a
better alternative than adding more padding and increasing the cache
footprint of the allocator but so far I haven't thought of a good
alternative. Moving the lock to the end of the freelists would probably
address the problem but still increases the footprint for order-0
allocations by a cache line.
Any update on this? Do you have some better idea? I guess this may be
fixed via putting some fields that are only read during order-0
allocation with the same cache line of lock, if there are any.
Sorry for the delay, the automatic NUMA regression took a long time to
close and it potentially affected anybody with a NUMA machine, not just
stress tests on large machines.
Moving it beside other fields shifts the problems. The lock is related
to the free areas so it really belongs nearby and from my own testing,
it does not affect mid-sized machines. I'd rather not put the lock in its
own cache line unless we have to. Can you try the following untested patch
instead? It is untested but builds and should be safe.
It'll increase the footprint of the page allocator but so would padding.
It means it will contend with high-order free page breakups but that
is not likely to happen during stress tests. It also collides with flags
but they are relatively rarely updated.
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index f279d9c158cd..2782df47101e 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -474,16 +474,15 @@ struct zone {
unsigned long wait_table_bits;
ZONE_PADDING(_pad1_)
-
- /* Write-intensive fields used from the page allocator */
- spinlock_t lock;
-
/* free areas of different sizes */
struct free_areafree_area[MAX_ORDER];
/* zone flags, see below */
unsigned long flags;
+ /* Write-intensive fields used from the page allocator */
+ spinlock_t lock;
+
ZONE_PADDING(_pad2_)
/* Write-intensive fields used by page reclaim */
Stress page allocator tests here shows that the performance restored to
its previous level with the patch above. I applied your patch on lasted
upstream kernel. Result is as below:
testbox/testcase/testparams: brickland1/aim7/performance-6000-page_test
c875f421097a55d9 dbdc458f1b7d07f32891509c06
--
%stddev %change %stddev
\ |\
84568 ± 1% +94.3% 164280 ± 1% aim7.jobs-per-min
2881944 ± 2% -35.1%1870386 ± 8%
aim7.time.voluntary_context_switches
681 ± 1% -3.4%658 ± 0% aim7.time.user_time
5538139 ± 0% -12.1%4867884 ± 0%
aim7.time.involuntary_context_switches
44174 ± 1% -46.0% 23848 ± 1% aim7.time.system_time
426 ± 1% -48.4%219 ± 1% aim7.time.elapsed_time
426 ± 1% -48.4%219 ± 1% aim7.time.elapsed_time.max
468 ± 1% -43.1%266 ± 2% uptime.boot
13691 ± 0% -24.2% 10379 ± 1% softirqs.NET_RX
931382 ± 2% +24.9%1163065 ± 1% softirqs.RCU
407717 ± 2% -36.3% 259521 ± 9% softirqs.SCHED
19690372 ± 0% -34.8% 12836548 ± 1% softirqs.TIMER
2442 ± 1% -28.9% 1737 ± 5% vmstat.procs.b
3016 ± 3% +19.4% 3603 ± 4% vmstat.procs.r
104330 ± 1% +34.6% 140387 ± 0% vmstat.system.in
22172 ± 0% +48.3% 32877 ± 2% vmstat.system.cs
1891 ± 12% -48.2%978 ± 10% numa-numastat.node0.other_node
1785 ± 14% -47.7%933 ± 6% numa-numastat.node1.other_node
1790 ± 12% -47.8%935 ± 10% numa-numastat.node2.other_node
1766 ± 14% -47.0%935 ± 12% numa-numastat.node3.other_node
426 ± 1% -48.4%219 ± 1% time.elapsed_time.max
426 ± 1% -48.4%219 ± 1% time.elapsed_time
5538139 ± 0% -12.1%4867884 ± 0% time.involuntary_context_switches
44174 ± 1% -46.0% 23848 ± 1% time.system_time
2881944 ± 2% -35.1%1870386 ± 8% time.voluntary_context_switches
7831898 ± 4% +31.8% 10325919 ± 5% meminfo.Active
7742498 ± 4% +32.2% 10237222 ± 5% meminfo.Active(anon)
7231211 ± 4% +28.7%9308183 ± 5% meminfo.AnonPages
7.55e+11 ± 4% +19.6% 9.032e+11 ± 8% meminfo.Committed_AS
14010
Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only)
On Fri, Mar 27, 2015 at 01:35:16AM -0700, Andrew Morton wrote: fincore() doesn't have to be ugly. Please address the design issues I raised. How is pread2() useful to the class of applications which cannot proceed until all data is available? It actually makes them work correctly? preadv2( ..., DONTWAIT) will return -EGAIN, which causes them to bounce to the threadpool where they call preadv(...). -- 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 RESEND] tty/n_gsm.c: fix a memory leak when gsmtty is removed
On 03/28/2015, 03:42 AM, Pan Xinhui wrote:
when gsmtty_remove put dlci, it will cause memory leak if dlci-port's
refcount is zero.
So we do the cleanup work in .cleanup callback instead.
dlci will be last put in two call chains.
1) gsmld_close - gsm_cleanup_mux - gsm_dlci_release - dlci_put
2) gsmld_remove - dlci_put
so there is a race. the memory leak depends on the race.
In call chain 2. we hit the memory leak. below comment tells.
release_tty - tty_driver_remove_tty - gsmtty_remove - dlci_put -
tty_port_destructor (WARN_ON(port-itty) and return directly)
|
tty-port-itty = NULL;
|
tty_kref_put --- release_one_tty - gsmtty_cleanup
(added by our patch)
So our patch fix the memory leak by doing the cleanup work after tty
core did.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Fixes: dfabf7ffa30585
Acked-by: Jiri Slaby jsl...@suse.cz
---
Changes in v2:
Don't use schedule_work to put dlci. Replace .remove with .cleanup
callback.
drivers/tty/n_gsm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c434376..bce16e4 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -3170,7 +3170,7 @@ static int gsmtty_break_ctl(struct tty_struct
*tty, int state)
return gsmtty_modem_update(dlci, encode);
}
-static void gsmtty_remove(struct tty_driver *driver, struct tty_struct
*tty)
+static void gsmtty_cleanup(struct tty_struct *tty)
{
struct gsm_dlci *dlci = tty-driver_data;
struct gsm_mux *gsm = dlci-gsm;
@@ -3178,7 +3178,6 @@ static void gsmtty_remove(struct tty_driver
*driver, struct tty_struct *tty)
dlci_put(dlci);
dlci_put(gsm-dlci[0]);
mux_put(gsm);
-driver-ttys[tty-index] = NULL;
}
/* Virtual ttys for the demux */
@@ -3199,7 +3198,7 @@ static const struct tty_operations gsmtty_ops = {
.tiocmget= gsmtty_tiocmget,
.tiocmset= gsmtty_tiocmset,
.break_ctl= gsmtty_break_ctl,
-.remove= gsmtty_remove,
+.cleanup= gsmtty_cleanup,
};
--
js
suse labs
--
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] xen-blkback: enlarge the array size of blkback name
El 27/03/15 a les 14.15, Tao Chen ha escrit: The blkback name is like blkback.domid.xvd[a-z], if domid has four digits (means larger than 1000), then the backmost xvd wouldn't be fully shown. Define a BLKBACK_NAME_LEN macro to be 20, enlarge the array size of blkback name, so it will be fully shown in any case. Signed-off-by: Tao Chen boby.c...@huawei.com Acked-by: Roger Pau Monné roger@citrix.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/
[RFC PATCH 2/5] GHES: Carve out the panic functionality
From: Borislav Petkov b...@suse.de
... into another function for more clarity. No functionality change.
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/acpi/apei/ghes.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index fe1e41bf5609..712ed95b1dca 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -823,6 +823,18 @@ static void __process_error(struct ghes *ghes)
#endif
}
+static void __ghes_panic(struct ghes *ghes)
+{
+ oops_begin();
+ ghes_print_queued_estatus();
+ __ghes_print_estatus(KERN_EMERG, ghes-generic, ghes-estatus);
+
+ /* reboot to log the error! */
+ if (panic_timeout == 0)
+ panic_timeout = ghes_panic_timeout;
+ panic(Fatal hardware error!);
+}
+
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
struct ghes *ghes, *ghes_global = NULL;
@@ -846,16 +858,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
if (ret == NMI_DONE)
goto out;
- if (sev_global = GHES_SEV_PANIC) {
- oops_begin();
- ghes_print_queued_estatus();
- __ghes_print_estatus(KERN_EMERG, ghes_global-generic,
-ghes_global-estatus);
- /* reboot to log the error! */
- if (panic_timeout == 0)
- panic_timeout = ghes_panic_timeout;
- panic(Fatal hardware error!);
- }
+ if (sev_global = GHES_SEV_PANIC)
+ __ghes_panic(ghes_global);
list_for_each_entry_rcu(ghes, ghes_nmi, list) {
if (!(ghes-flags GHES_TO_CLEAR))
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/5] GHES: Carve out error queueing in a separate function
From: Borislav Petkov b...@suse.de
Make the handler more readable.
No functionality change.
Signed-off-by: Borislav Petkov b...@suse.de
---
drivers/acpi/apei/ghes.c | 51 +++-
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index e82d0976a5d0..fe1e41bf5609 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -797,6 +797,32 @@ static void ghes_print_queued_estatus(void)
}
}
+/* Save estatus for further processing in IRQ context */
+static void __process_error(struct ghes *ghes)
+{
+#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
+ u32 len, node_len;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic_status *estatus;
+
+ if (ghes_estatus_cached(ghes-estatus))
+ return;
+
+ len = cper_estatus_len(ghes-estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+
+ estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
+ if (!estatus_node)
+ return;
+
+ estatus_node-ghes = ghes;
+ estatus_node-generic = ghes-generic;
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ memcpy(estatus, ghes-estatus, len);
+ llist_add(estatus_node-llnode, ghes_estatus_llist);
+#endif
+}
+
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
struct ghes *ghes, *ghes_global = NULL;
@@ -832,32 +858,13 @@ static int ghes_notify_nmi(unsigned int cmd, struct
pt_regs *regs)
}
list_for_each_entry_rcu(ghes, ghes_nmi, list) {
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- u32 len, node_len;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic_status *estatus;
-#endif
if (!(ghes-flags GHES_TO_CLEAR))
continue;
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- if (ghes_estatus_cached(ghes-estatus))
- goto next;
- /* Save estatus for further processing in IRQ context */
- len = cper_estatus_len(ghes-estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
- estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool,
- node_len);
- if (estatus_node) {
- estatus_node-ghes = ghes;
- estatus_node-generic = ghes-generic;
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- memcpy(estatus, ghes-estatus, len);
- llist_add(estatus_node-llnode, ghes_estatus_llist);
- }
-next:
-#endif
+
+ __process_error(ghes);
ghes_clear_estatus(ghes);
}
+
#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
irq_work_queue(ghes_proc_irq_work);
#endif
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] vmstat: Avoid waking up idle-cpu to service shepherd work
On Fri, Mar 27, 2015 at 10:16:13AM +0100, Peter Zijlstra wrote: On Fri, Mar 27, 2015 at 10:19:54AM +0530, Viresh Kumar wrote: On 27 March 2015 at 01:48, Andrew Morton a...@linux-foundation.org wrote: Shouldn't this be viewed as a shortcoming of the core timer code? Yeah, it is. Some (not so pretty) solutions were tried earlier to fix that, but they are rejected for obviously reasons [1]. vmstat_shepherd() is merely rescheduling itself with schedule_delayed_work(). That's a dead bog simple operation and if it's producing suboptimal behaviour then we shouldn't be fixing it with elaborate workarounds in the caller? I understand that, and that's why I sent it as an RFC to get the discussion started. Does anyone else have got another (acceptable) idea to get this resolved ? So the issue seems to be that we need base-running_timer in order to tell if a callback is running, right? We could align the base on 8 bytes to gain an extra bit in the pointer and use that bit to indicate the running state. Then these sites can spin on that bit while we can change the actual base pointer. Even though tvec_base has cacheline_aligned stuck on, most are allocated using kzalloc_node() which does not actually respect that but already guarantees a minimum u64 alignment, so I think we can use that third bit without too much magic. -- 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] livepatch: add support on s390
On Fri, 27 Mar 2015, Heiko Carstens wrote: On Thu, Mar 26, 2015 at 07:24:58PM +0100, Jiri Kosina wrote: On Thu, 26 Mar 2015, Jiri Slaby wrote: This is a trivial port from kGraft. Module relocations are not supported. Signed-off-by: Jiri Slaby jsl...@suse.cz --- [v2] return ENOSYS [v3] proper return value from klp_check_compiler_support Applied to for-4.1/core. Hello Jiri, while I do appreciate your work on the s390 architecture backend for livepatching: this should go upstream only via the s390 tree or with an Ack from Martin or me. Fair enough; I merged it because I was convinced that we have your Ack for the very same patch in our tree for kGraft, but now that I look again, we apparently don't. So sorry for that. What is your standpoint on this one then, please? That being said, what is the reason why module relocations are not supported? That's an addon feature that can be added gradually, it's not crucial for basic functionality. Basically: someone has to write the code, but it's useful even without it. As far as I can tell right now there is only one simple in-kernel test case available (which is fine). However is the tool chain to generate additional livepatch modules, available somewhere? If so, where? For the current feature set of livepatching as-is upstream, no tooling is really hard requirement and the patches are to be written by hand (exactly as the one in the samples/ directory). Thanks, -- Jiri Kosina SUSE Labs -- 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: Linux 3.14.37
diff --git a/Makefile b/Makefile
index 4e6537bd8aa0..c24acc0d34a1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 14
-SUBLEVEL = 36
+SUBLEVEL = 37
EXTRAVERSION =
NAME = Remembering Coco
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e96da9a898ad..f2512e1d28c7 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -243,10 +243,18 @@
ti,invert-autoidle-bit;
};
+ dpll_core_byp_mux: dpll_core_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ ti,bit-shift = 23;
+ reg = 0x012c;
+ };
+
dpll_core_ck: dpll_core_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-core-clock;
- clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ clocks = sys_clkin1, dpll_core_byp_mux;
reg = 0x0120, 0x0124, 0x012c, 0x0128;
};
@@ -309,10 +317,18 @@
clock-div = 1;
};
+ dpll_dsp_byp_mux: dpll_dsp_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, dsp_dpll_hs_clk_div;
+ ti,bit-shift = 23;
+ reg = 0x0240;
+ };
+
dpll_dsp_ck: dpll_dsp_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, dsp_dpll_hs_clk_div;
+ clocks = sys_clkin1, dpll_dsp_byp_mux;
reg = 0x0234, 0x0238, 0x0240, 0x023c;
};
@@ -335,10 +351,18 @@
clock-div = 1;
};
+ dpll_iva_byp_mux: dpll_iva_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, iva_dpll_hs_clk_div;
+ ti,bit-shift = 23;
+ reg = 0x01ac;
+ };
+
dpll_iva_ck: dpll_iva_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, iva_dpll_hs_clk_div;
+ clocks = sys_clkin1, dpll_iva_byp_mux;
reg = 0x01a0, 0x01a4, 0x01ac, 0x01a8;
};
@@ -361,10 +385,18 @@
clock-div = 1;
};
+ dpll_gpu_byp_mux: dpll_gpu_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ ti,bit-shift = 23;
+ reg = 0x02e4;
+ };
+
dpll_gpu_ck: dpll_gpu_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ clocks = sys_clkin1, dpll_gpu_byp_mux;
reg = 0x02d8, 0x02dc, 0x02e4, 0x02e0;
};
@@ -398,10 +430,18 @@
clock-div = 1;
};
+ dpll_ddr_byp_mux: dpll_ddr_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ ti,bit-shift = 23;
+ reg = 0x021c;
+ };
+
dpll_ddr_ck: dpll_ddr_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ clocks = sys_clkin1, dpll_ddr_byp_mux;
reg = 0x0210, 0x0214, 0x021c, 0x0218;
};
@@ -416,10 +456,18 @@
ti,invert-autoidle-bit;
};
+ dpll_gmac_byp_mux: dpll_gmac_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ ti,bit-shift = 23;
+ reg = 0x02b4;
+ };
+
dpll_gmac_ck: dpll_gmac_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, dpll_abe_m3x2_ck;
+ clocks = sys_clkin1, dpll_gmac_byp_mux;
reg = 0x02a8, 0x02ac, 0x02b4, 0x02b0;
};
@@ -482,10 +530,18 @@
clock-div = 1;
};
+ dpll_eve_byp_mux: dpll_eve_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
+ clocks = sys_clkin1, eve_dpll_hs_clk_div;
+ ti,bit-shift = 23;
+ reg = 0x0290;
+ };
+
dpll_eve_ck: dpll_eve_ck {
#clock-cells = 0;
compatible = ti,omap4-dpll-clock;
- clocks = sys_clkin1, eve_dpll_hs_clk_div;
+ clocks = sys_clkin1, dpll_eve_byp_mux;
reg = 0x0284, 0x0288, 0x0290, 0x028c;
};
@@ -1214,10 +1270,18 @@
clock-div = 1;
};
+ dpll_per_byp_mux: dpll_per_byp_mux {
+ #clock-cells = 0;
+ compatible = ti,mux-clock;
Re: Linux 3.10.73
diff --git a/Makefile b/Makefile
index 211bb34102bf..b1129094ebfd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 72
+SUBLEVEL = 73
EXTRAVERSION =
NAME = TOSSUG Baby Fish
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 2f5908f0b8c5..d8af0755bddc 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -37,7 +37,7 @@ static inline void at91rm9200_standby(void)
mcrp15, 0, %0, c7, c0, 4\n\t
str%5, [%1, %2]
:
- : r (0), r (AT91_BASE_SYS), r (AT91RM9200_SDRAMC_LPR),
+ : r (0), r (at91_ramc_base[0]), r (AT91RM9200_SDRAMC_LPR),
r (1), r (AT91RM9200_SDRAMC_SRR),
r (lpr));
}
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ee7ac5e6e28a..c5c640779549 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -544,8 +544,8 @@ int __cpuinit __cpu_up(unsigned int cpu, struct task_struct
*tidle)
if (smp_ops-give_timebase)
smp_ops-give_timebase();
- /* Wait until cpu puts itself in the online map */
- while (!cpu_online(cpu))
+ /* Wait until cpu puts itself in the online active maps */
+ while (!cpu_online(cpu) || !cpu_active(cpu))
cpu_relax();
return 0;
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index b5c38faa4ead..d461b7ddf30e 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -960,6 +960,8 @@ out:
cpuc-pcr[0] |= cpuc-event[0]-hw.config_base;
}
+static void sparc_pmu_start(struct perf_event *event, int flags);
+
/* On this PMU each PIC has it's own PCR control register. */
static void calculate_multiple_pcrs(struct cpu_hw_events *cpuc)
{
@@ -972,20 +974,13 @@ static void calculate_multiple_pcrs(struct cpu_hw_events
*cpuc)
struct perf_event *cp = cpuc-event[i];
struct hw_perf_event *hwc = cp-hw;
int idx = hwc-idx;
- u64 enc;
if (cpuc-current_idx[i] != PIC_NO_INDEX)
continue;
- sparc_perf_event_set_period(cp, hwc, idx);
cpuc-current_idx[i] = idx;
- enc = perf_event_get_enc(cpuc-events[i]);
- cpuc-pcr[idx] = ~mask_for_index(idx);
- if (hwc-state PERF_HES_STOPPED)
- cpuc-pcr[idx] |= nop_for_index(idx);
- else
- cpuc-pcr[idx] |= event_encoding(enc, idx);
+ sparc_pmu_start(cp, PERF_EF_RELOAD);
}
out:
for (i = 0; i cpuc-n_events; i++) {
@@ -1101,7 +1096,6 @@ static void sparc_pmu_del(struct perf_event *event, int
_flags)
int i;
local_irq_save(flags);
- perf_pmu_disable(event-pmu);
for (i = 0; i cpuc-n_events; i++) {
if (event == cpuc-event[i]) {
@@ -1127,7 +1121,6 @@ static void sparc_pmu_del(struct perf_event *event, int
_flags)
}
}
- perf_pmu_enable(event-pmu);
local_irq_restore(flags);
}
@@ -1361,7 +1354,6 @@ static int sparc_pmu_add(struct perf_event *event, int
ef_flags)
unsigned long flags;
local_irq_save(flags);
- perf_pmu_disable(event-pmu);
n0 = cpuc-n_events;
if (n0 = sparc_pmu-max_hw_events)
@@ -1394,7 +1386,6 @@ nocheck:
ret = 0;
out:
- perf_pmu_enable(event-pmu);
local_irq_restore(flags);
return ret;
}
diff --git a/arch/sparc/kernel/process_64.c b/arch/sparc/kernel/process_64.c
index b9cc9763faf4..036e43cef6fb 100644
--- a/arch/sparc/kernel/process_64.c
+++ b/arch/sparc/kernel/process_64.c
@@ -280,6 +280,8 @@ void arch_trigger_all_cpu_backtrace(void)
printk( TPC[%lx] O7[%lx] I7[%lx]
RPC[%lx]\n,
gp-tpc, gp-o7, gp-i7, gp-rpc);
}
+
+ touch_nmi_watchdog();
}
memset(global_cpu_snapshot, 0, sizeof(global_cpu_snapshot));
@@ -352,6 +354,8 @@ static void pmu_snapshot_all_cpus(void)
(cpu == this_cpu ? '*' : ' '), cpu,
pp-pcr[0], pp-pcr[1], pp-pcr[2], pp-pcr[3],
pp-pic[0], pp-pic[1], pp-pic[2], pp-pic[3]);
+
+ touch_nmi_watchdog();
}
memset(global_cpu_snapshot, 0, sizeof(global_cpu_snapshot));
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 2d6eda23..be8db9bb7878 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -336,7 +336,7 @@ SYSCALL_DEFINE6(sparc_ipc, unsigned int, call, int, first,
unsigned long, second
long err;
/* No need for backward compatibility. We can start fresh... */
- if (call = SEMCTL) {
+ if (call = SEMTIMEDOP) {
switch (call)
[PATCH] mm: Move zone lock to a different cache line than order-0 free page lists
Huang Ying reported the following problem due to commit 3484b2de9499
(mm: rearrange zone fields into read-only, page alloc, statistics and
page reclaim lines) from the Intel performance tests
24b7e5819ad5cbef 3484b2de9499df23c4604a513b
--
%stddev %change %stddev
\ |\
152288 \261 0% -46.2% 81911 \261 0% aim7.jobs-per-min
237 \261 0% +85.6%440 \261 0% aim7.time.elapsed_time
237 \261 0% +85.6%440 \261 0%
aim7.time.elapsed_time.max
25026 \261 0% +70.7% 42712 \261 0% aim7.time.system_time
2186645 \261 5% +32.0%2885949 \261 4%
aim7.time.voluntary_context_switches
4576561 \261 1% +24.9%5715773 \261 0%
aim7.time.involuntary_context_switches
The problem is specific to very large machines under stress. It was not
reproducible with the machines I had used to justify the original patch
because large numbers of CPUs are required. When pressure is high enough,
the cache line is bouncing between CPUs trying to acquire the lock and
the holder of the lock adjusting free lists. The intention was that the
acquirer of the lock would automatically have the cache line holding the
free lists but according to Huang, this is not a universal win.
One possibility is to move the zone lock to its own cache line but it
increases the size of the zone. This patch moves the lock to the other
end of the free lists where they do not contend under high pressure. It
does mean the page allocator paths now require more cache lines but Huang
reports that it restores performance to previous levels on large machines
%stddev %change %stddev
\ |\
84568 \261 1% +94.3% 164280 \261 1% aim7.jobs-per-min
2881944 \261 2% -35.1%1870386 \261 8%
aim7.time.voluntary_context_switches
681 \261 1% -3.4%658 \261 0% aim7.time.user_time
5538139 \261 0% -12.1%4867884 \261 0%
aim7.time.involuntary_context_switches
44174 \261 1% -46.0% 23848 \261 1% aim7.time.system_time
426 \261 1% -48.4%219 \261 1% aim7.time.elapsed_time
426 \261 1% -48.4%219 \261 1%
aim7.time.elapsed_time.max
468 \261 1% -43.1%266 \261 2% uptime.boot
Reported-and-tested-by: Huang Ying ying.hu...@intel.com
Signed-off-by: Mel Gorman mgor...@suse.de
---
include/linux/mmzone.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index f279d9c158cd..2782df47101e 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -474,16 +474,15 @@ struct zone {
unsigned long wait_table_bits;
ZONE_PADDING(_pad1_)
-
- /* Write-intensive fields used from the page allocator */
- spinlock_t lock;
-
/* free areas of different sizes */
struct free_areafree_area[MAX_ORDER];
/* zone flags, see below */
unsigned long flags;
+ /* Write-intensive fields used from the page allocator */
+ spinlock_t lock;
+
ZONE_PADDING(_pad2_)
/* Write-intensive fields used by page reclaim */
--
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 4/8] gpio: omap: drop 'gpio' param from omap_gpio_init_irq()
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org The 'gpio' parameter isn't needed any more as it duplicates 'offset' parameter, so drop it. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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] IIO: Adds ACPI support for ST gyroscopes
On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote:
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 568aa2b..9865627 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -511,6 +511,19 @@ static const struct irq_domain_ops
gpiochip_domain_ops = {
static int gpiochip_irq_reqres(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
+ int ret;
+
+ ret = gpiod_request(chip-desc[d-hwirq], IRQ);
+ if (ret) {
+ chip_err(chip, unable to request %lu for IRQ\n,
d-hwirq);
+ return ret;
+ }
What if the driver has already requested the GPIO?
Initially I implemented the above to take that into account, e.g. if
(test_and_set_bit(FLAG_REQUESTED, desc-flags) ...
But than I thought that we can't mess up with the GPIO anyway while
the interrupt is in use.
That's right but then the above will fail also normal cases. For example
if the driver gets the irq like:
desc = devm_gpiod_get(dev, ..);
gpiod_direction_input(desc);
irq = gpiod_to_irq(desc);
ret = request_irq(irq, ...)
at this point we end up calling gpiochip_irq_reqres() which cannot
request the GPIO again and fails.
Good point, let me add back that check then :)
I just realized that there is another issue: gpiochip_irq_reqres() is
called under a spinlock, so we can call gpiod_request() only if the
gpio controller does not sleep.
Good point.
For the sleep case I think the GPIO controller needs to do the pin
enable and set input direction operation in it's irq_bus_sync_unlock.
I wonder how DT handles all this? Is it the boot firmware that sets up
the pins accordingly or is there something we are missing?
--
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] perf build: Suppress warning about missing libbabeltrace
Be silent about missing babeltrace library until the needed version (1.3) is pushed into most common distros. Requested-by: Ingo Molnar mi...@kernel.org Signed-off-by: Jiri Olsa jo...@kernel.org Link: http://lkml.kernel.org/n/tip-95mcd8hoxyt43jighilgg...@git.kernel.org --- tools/perf/config/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index cd121dfc4de9..2d9142b10cd3 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -606,7 +606,12 @@ ifndef NO_LIBBABELTRACE EXTLIBS += -lbabeltrace-ctf $(call detected,CONFIG_LIBBABELTRACE) else -msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); +# +# Be silent about missing babeltrace library +# until the needed version (1.3) is pushed +# into most common distros. +# +#msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); NO_LIBBABELTRACE := 1 endif endif -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] doc: completion: context, scope and language fixes
* Peter Zijlstra pet...@infradead.org wrote: On Fri, Mar 27, 2015 at 08:56:37AM +0100, Ingo Molnar wrote: I wasn't Cc:-ed to the patch and it wasn't Cc:-ed to lkml either :-( /me hands mingo a strong cup of tea... http://marc.info/?l=linux-kernelm=142445364429042w=2 Hm, then it somehow got spam-filtered out :-/ Could someone forward me the actual patch please? Thanks, Ingo -- 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 0/8] gpio: omap: cleanup: get rid of system GPIO - GPIO offset converseations
On 03/23/2015 02:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now in TI OMAP GPIO driver there are a lot of places where System GPIO number calculated and then converted to GPIO offset. What is worse is that in many place such conversation performed twice or even three times. But actually, we don't need to do that at all, because - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset Hence, it is safe to convert all GPIO OMAP functions to use GPIO offset instead of system GPIO numbers. Also, this allows to remove unneeded conversations routines #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested on: - dra7-evm. - omap1 (osk5912), 770 and E3. Last two patches have to be tested on OMAP1: - gpio: omap: get rid of omap_irq_to_gpio() - gpio: omap: get rid of GPIO_INDEX() macro Based on top of Linux 4.0-rc4 plus patch '[PATCH 1/2] gpio: omap: irq_shutdown: remove unnecessary call of gpiochip_unlock_as_irq' http://www.spinics.net/lists/linux-omap/msg116482.html Changes in v2: - fixed build failure with Patch 5, no functional code changes. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Thanks Linus. regards, -grygorii -- regards, -grygorii -- 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/16] iommu/tegra-smmu: Make use of domain_alloc and domain_free
On Thu, Mar 26, 2015 at 01:43:12PM +0100, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de Implement domain_alloc and domain_free iommu-ops as a replacement for domain_init/domain_destroy. Signed-off-by: Joerg Roedel jroe...@suse.de --- drivers/iommu/tegra-smmu.c | 41 +++-- 1 file changed, 23 insertions(+), 18 deletions(-) Acked-by: Thierry Reding tred...@nvidia.com pgpf5yCEIYWGL.pgp Description: PGP signature
[PATCH] x86/asm/entry/64: Fix comment about SYSENTER MSRs
The comment is ancient, it dates to the time when only AMD's x86_64 implementation existed. AMD wasn't (and still isn't) supporting SYSENTER, so these writes were just in case back then. This has changed: Intel's x86_64 appeared, and Indel does support SYSENTER in long mode. Some future 64-bit CPU is here already. The code may appear buggy for AMD as it stands, since MSR_IA32_SYSENTER_EIP is only 32-bit for AMD CPUs. Writing a kernel function's address to it would drop high bits. Subsequent use of this MSR for branch via SYSENTER seem to allow user to transition to CPL0 while executing his code. Scary, eh? Explain why that is not a bug: because SYSENTER insn would not work on AMD CPU. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/cpu/common.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index b5ad0fa..7c57b12 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1212,8 +1212,10 @@ void syscall_init(void) #ifdef CONFIG_IA32_EMULATION wrmsrl(MSR_CSTAR, ia32_cstar_target); /* -* Always load these, in case some future 64-bit CPU supports -* SYSENTER from compat mode too: +* This only works for Intel CPUs. +* On AMD, these MSRs are 32-bit, CPU truncates MSR_IA32_SYSENTER_EIP. +* This does not cause SYSENTER to jump to wrong location because +* AMD doesn't allow SYSENTER in long mode (either 32- or 64-bit). */ wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS); wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL); -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v2] iommu: Move domain allocation into drivers
On Thu, Mar 26, 2015 at 01:43:03PM +0100, Joerg Roedel wrote: Changes v1-v2: * Rebased to v4.0-rc5 * Converted domain-types to a bit-field Hi, here is patch-set to replace the existing domain_init and domain_destroy iommu-ops with the new domain_alloc and domain_free callbacks The new callbacks move the allocation of iommu domains into the iommu driver, allowing them to put a generic iommu_domain struct into their own domain struct. This makes domain handling in the drivers more cache efficient and prepares the introduction of default domains in another patch-set. While at it, this patch-set also introduces domain types. These are internal to the iommu core code for now, there are three of them: * DMA-API domains * Identity mapped domains * Domains unmanaged by the iommu-core, used for iommu-api so that the users can create their own mappings The patches have been compile tested for x86, ARM and PPC and runtime tested on x86 (Intel VT-d and AMD IOMMU). Please review. Thanks, Joerg Joerg Roedel (15): iommu: Introduce domain_alloc and domain_free iommu_ops iommu: Introduce iommu domain types iommu/amd: Make use of domain_alloc and domain_free iommu/vt-d: Make use of domain_alloc and domain_free iommu/omap: Make use of domain_alloc and domain_free iommu/arm-smmu: Make use of domain_alloc and domain_free iommu/exynos: Make use of domain_alloc and domain_free iommu/tegra-smmu: Make use of domain_alloc and domain_free iommu/tegra-gart: Make use of domain_alloc and domain_free iommu/msm: Make use of domain_alloc and domain_free iommu/shmobile: Make use of domain_alloc and domain_free iommu/ipmmu-vmsa: Make use of domain_alloc and domain_free iommu/rockchip: Make use of domain_alloc and domain_free iommu/fsl: Make use of domain_alloc and domain_free iommu: Remove domain_init and domain_free iommu_ops drivers/iommu/amd_iommu.c | 84 +-- drivers/iommu/amd_iommu_types.h | 7 ++-- drivers/iommu/arm-smmu.c| 46 +- drivers/iommu/exynos-iommu.c| 87 ++--- drivers/iommu/fsl_pamu_domain.c | 60 +++- drivers/iommu/fsl_pamu_domain.h | 2 +- drivers/iommu/intel-iommu.c | 48 +-- drivers/iommu/iommu.c | 20 ++ drivers/iommu/ipmmu-vmsa.c | 43 +++- drivers/iommu/msm_iommu.c | 73 +- drivers/iommu/omap-iommu.c | 49 +-- drivers/iommu/rockchip-iommu.c | 40 +++ drivers/iommu/shmobile-iommu.c | 40 +++ drivers/iommu/tegra-gart.c | 67 +-- drivers/iommu/tegra-smmu.c | 41 ++- include/linux/iommu.h | 17 ++-- 16 files changed, 407 insertions(+), 317 deletions(-) The core and Tegra bits: Tested-by: Thierry Reding tred...@nvidia.com pgpCIu1kKNTbm.pgp Description: PGP signature
Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.
On 03/25/2015 05:17 PM, NeilBrown wrote: On Wed, 25 Mar 2015 12:30:00 -0400 Peter Hurley pe...@hurleysoftware.com wrote: On 03/18/2015 01:58 AM, NeilBrown wrote: + * A tty-slave is a device permanently attached to a particularly + * tty, typically wired to a UART. Why permanently? Is that a limitation of the implementation or design? The slave is described in devicetree - that only happens for permanently attached devices, doesn't it? I guess that with device-tree overlays and 'capes' for boards you could have a device attached to the uart for this power session rather than permanently, but I think it is a rather subtle distinction. Did you have something else in mind? My primary concern is that the abstraction match the scope. If the abstraction is at the tty layer, then the scope of the design should support tty devices, not just hard-wired, devicetree-defined uarts. Regards, Peter Hurley -- 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: [Intel-gfx] [Linux v4.0-rc5] Warnings in drm_framebuffer_reference() and drm_atomic_check_only()
On Fri, Mar 27, 2015 at 12:06 PM, Takashi Iwai ti...@suse.de wrote: At Fri, 27 Mar 2015 12:01:33 +0100, Sedat Dilek wrote: On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai ti...@suse.de wrote: At Wed, 25 Mar 2015 14:26:50 +0100, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 07:09:03PM +0100, Sedat Dilek wrote: On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote: Hi, I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over some warning in the drm area. Please have a look... Hi Daniel, Just to confirm: Both are new in -rc5 and haven't been around in -rc4? Yeah, rc4 was OK but with rc5 I have seen these warnings. Also can you pls give -nightly a spin and see what happens there? drm-intel-nightly (2015y-03m-24d-09h-19m-43s UTC) pulled on top of rc5 does not show any warnings in the drm | i915 area. drm-fixes has 2 cherry-picks from -next to address the worst offenders, there's one more which is waiting for confirmation: commit fb9981aa675eb7b398849915364916fd98833cfa Author: Damien Lespiau damien.lesp...@intel.com Date: Thu Feb 5 19:24:25 2015 + drm/i915: Fix atomic state when reusing the firmware fb Please apply that commit from -next on top of drm-fixes and retest. The problem is introduced by the commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa drm/i915: Ensure plane-state-fb stays in sync with plane-fb Obviously it accesses the uninitialized kref in get_initial_plane_config(). The commit in next f55548b5af87ebfc586ca75748947f1c1b1a4a52 drm/i915: Don't try to reference the fb in get_initial_plane_config() fixes the bug itself, but it leads to another similar warnings. For avoiding this, yet another cherry-picks (including the commit you mentioned above): fb9981aa675eb7b398849915364916fd98833cfa drm/i915: Fix atomic state when reusing the firmware fb 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 drm/i915: Store the initial framebuffer in initial_plane_config then warnings are finally gone. But, the second one can't be applied cleanly, so I had to adjust many codes manually by replacing primary fb references. Takashi Hi Takashi, hi Daniel, first of all thank you for your replies. The last days I did not use my notebook and will try drm-intel-fixes-2015-03-26. Takashi, is that Git branch on top of rc5 OK for you? The fixes have been already merged to Linus tree. Thanks a lot. ( I looked only at drm-intel Git repository. ) - Sedat - [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c435c1e472ba344ee25f795f4807d4457e61f6c -- 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] x86/asm/entry/64: better check for canonical address
* Denys Vlasenko dvlas...@redhat.com wrote: On 03/27/2015 09:11 AM, Ingo Molnar wrote: * Denys Vlasenko dvlas...@redhat.com wrote: This change makes the check exact (no more false positives on kernel addresses). It isn't really important to be fully correct here - almost all addresses we'll ever see will be userspace ones, but OTOH it looks to be cheap enough: the new code uses two more ALU ops but preserves %rcx, allowing to not reload it from pt_regs-cx again. On disassembly level, the changes are: cmp %rcx,0x80(%rsp) - mov 0x80(%rsp),%r11; cmp %rcx,%r11 shr $0x2f,%rcx - shl $0x10,%rcx; sar $0x10,%rcx; cmp %rcx,%r11 mov 0x58(%rsp),%rcx - (eliminated) Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Borislav Petkov b...@alien8.de CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- Andy, I'd undecided myself on the merits of doing this. If you like it, feel free to take it in your tree. I trimmed CC list to not bother too many people with this trivial and quite possibly useless churn-class change. arch/x86/kernel/entry_64.S | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index bf9afad..a36d04d 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -688,26 +688,27 @@ retint_swapgs: /* return to user-space */ * a completely clean 64-bit userspace context. */ movq RCX(%rsp),%rcx - cmpq %rcx,RIP(%rsp) /* RCX == RIP */ + movq RIP(%rsp),%r11 + cmpq %rcx,%r11 /* RCX == RIP */ jne opportunistic_sysret_failed Btw., in the normal syscall entry path, RIP(%rsp) == RCX(%rsp), because we set up pt_regs like that - and at this point RIP/RCX is guaranteed to be canonical, right? So if there's a mismatch generated, it's the kernel's doing. This is an optimization on IRET exit code path. We go here if we know that pt_regs can be modified by .e.g. ptrace. I think we also go here even on interrupt return. Yeah, missed that, this would kill any flag based approach. (Granted, chances that RCX was the same as RIP at the moment of interrupt are slim, but we still would check that and (ab)use SYSRET if it looks like it'll work). Btw., there's a neat trick we could do: in the HLT, MWAIT and ACPI-idle code we could attempt to set up RCX to match RIP, to trigger this optimization in the common 'irq interrupted the idle task' case? Thanks, Ingo -- 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 build: Suppress warning about missing libbabeltrace
* Jiri Olsa jo...@kernel.org wrote: Be silent about missing babeltrace library until the needed version (1.3) is pushed into most common distros. Requested-by: Ingo Molnar mi...@kernel.org Signed-off-by: Jiri Olsa jo...@kernel.org Link: http://lkml.kernel.org/n/tip-95mcd8hoxyt43jighilgg...@git.kernel.org --- tools/perf/config/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index cd121dfc4de9..2d9142b10cd3 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -606,7 +606,12 @@ ifndef NO_LIBBABELTRACE EXTLIBS += -lbabeltrace-ctf $(call detected,CONFIG_LIBBABELTRACE) else -msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); +# +# Be silent about missing babeltrace library +# until the needed version (1.3) is pushed +# into most common distros. +# +#msg := $(warning No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev); NO_LIBBABELTRACE := 1 endif endif But, but ... the feature detection is still executed, and it slows down the regular build on 99.% of the systems, right? I don't mind carrying the code, but could we make it such that it needs some special option to build or so? Thanks, Ingo -- 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/
[GIT PULL] Important ARC fixes for 4.0
Hi Linus, We found some issues with signal handling taking down the system. I know its late, but these are important and all marked for stable. Please pull. Thx, -Vineet --- The following changes since commit bc465aa9d045feb0e13b4a8f32cc33c1943f62d6: Linux 4.0-rc5 (2015-03-22 16:50:21 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-4.0-fixes-part-2 for you to fetch changes up to e4140819dadc3624accac8294881bca8a3cba4ed: ARC: signal handling robustify (2015-03-26 11:19:36 +0530) ARC signal handling related fixes uncovered during recent testing of NPTL tools Vineet Gupta (2): ARC: SA_SIGINFO ucontext regs off-by-one ARC: signal handling robustify arch/arc/kernel/signal.c | 24 ++-- 1 file changed, 18 insertions(+), 6 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 4/5] dmaengine: hsu: Fix memory leak when stopping a running transfer
The vd-node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/dma/hsu/hsu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/hsu/hsu.c b/drivers/dma/hsu/hsu.c
index 683ba9b62795..d1864bda008f 100644
--- a/drivers/dma/hsu/hsu.c
+++ b/drivers/dma/hsu/hsu.c
@@ -387,7 +387,10 @@ static int hsu_dma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(hsuc-vchan.lock, flags);
hsu_dma_stop_channel(hsuc);
- hsuc-desc = NULL;
+ if (hsuc-desc) {
+ hsu_dma_desc_free(hsuc-desc-vchan);
+ hsuc-desc = NULL;
+ }
vchan_get_all_descriptors(hsuc-vchan, head);
spin_unlock_irqrestore(hsuc-vchan.lock, flags);
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] dmaengine: edma: fix memory leak when terminating running transfers
From: Petr Kulhavy p...@barix.com
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan-edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy p...@barix.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: sta...@vger.kernel.org
CC: linux-o...@vger.kernel.org
---
drivers/dma/edma.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 741baa68365c..984c2b12dae3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -268,6 +268,13 @@ static int edma_terminate_all(struct dma_chan *chan)
*/
if (echan-edesc) {
int cyclic = echan-edesc-cyclic;
+
+ /*
+* free the running request descriptor
+* since it is not in any of the vdesc lists
+*/
+ edma_desc_free(echan-edesc-vdesc);
+
echan-edesc = NULL;
edma_stop(echan-ch_num);
/* Move the cyclic channel back to default queue */
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] dmaengine: moxart-dma: Fix memory leak when stopping a running transfer
The vd-node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Jonas Jensen jonas.jen...@gmail.com
---
drivers/dma/moxart-dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c
index 15cab7d79525..b4634109e010 100644
--- a/drivers/dma/moxart-dma.c
+++ b/drivers/dma/moxart-dma.c
@@ -193,8 +193,10 @@ static int moxart_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(ch-vc.lock, flags);
- if (ch-desc)
+ if (ch-desc) {
+ moxart_dma_desc_free(ch-desc-vd);
ch-desc = NULL;
+ }
ctrl = readl(ch-base + REG_OFF_CTRL);
ctrl = ~(APB_DMA_ENABLE | APB_DMA_FIN_INT_EN | APB_DMA_ERR_INT_EN);
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] dmaengine: bcm2835-dma: Fix memory leak when stopping a running transfer
The vd-node is removed from the lists when the transfer started so the
vchan_get_all_descriptors() will not find it. This results memory leak.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Stephen Warren swar...@wwwdotorg.org
CC: Lee Jones l...@kernel.org
---
drivers/dma/bcm2835-dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 0723096fb50a..c92d6a70ccf3 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -475,6 +475,7 @@ static int bcm2835_dma_terminate_all(struct dma_chan *chan)
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ bcm2835_dma_desc_free(c-desc-vd);
c-desc = NULL;
bcm2835_dma_abort(c-chan_base);
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 8/8] gpio: omap: get rid of GPIO_INDEX() macro
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing. Do It ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 v7 2/5] power: max77843_charger: Add Max77843 charger device driver
On Fri, 27 Mar 2015, Beomho Seo wrote: On 03/27/2015 04:57 PM, Lee Jones wrote: On Fri, 27 Mar 2015, Beomho Seo wrote: On 03/26/2015 10:54 PM, Lee Jones wrote: On Thu, 26 Mar 2015, Beomho Seo wrote: On 03/24/2015 05:38 PM, Krzysztof Kozlowski wrote: 2015-03-24 9:01 GMT+01:00 Beomho Seo beomho@samsung.com: On 03/10/2015 10:44 PM, Beomho Seo wrote: On 03/09/2015 09:13 PM, Krzysztof Kozlowski wrote: On pon, 2015-03-09 at 20:46 +0900, Beomho Seo wrote: On 03/09/2015 08:02 PM, Krzysztof Kozlowski wrote: 2015-03-09 1:35 GMT+01:00 Beomho Seo beomho@samsung.com: On 03/08/2015 05:13 AM, Sebastian Reichel wrote: On Mon, Mar 02, 2015 at 07:10:35PM +0900, Jaewon Kim wrote: From: Beomho Seo beomho@samsung.com This patch adds device driver of max77843 charger. This driver provide initialize each charging mode(e.g. fast charge, top-off mode and constant charging mode so on.). Additionally, control charging paramters to use i2c interface. Cc: Sebastian Reichel s...@kernel.org Signed-off-by: Beomho Seo beomho@samsung.com Reviewed-By: Sebastian Reichel s...@kernel.org I can't take it as is, since it depends on the private header file of PATCHv1. -- Sebastian This patch reviewed by Sebastian. Could you Please merge that your git tree ? Hi, ... and again we are adding a new driver for very similar chipset to already supported. I looked at spec and the charger's registers are almost the same as for max77693. Their layout and addresses are the same. I see some minor differences, probably the most important would be different values current (fast-charge, top-off). But still 90% of registers are the same... Do we really have to add new driver? Best regards, Krzysztof Hi, Thank you for your comment. As you say, both chip set are similar. But new driver need for support max77843. It is support different below - Provide Battery presence information. Another set of power supply properties could be added for that chip. This way the get_property() function would be the same but actually the POWER_SUPPLY_PROP_PRESENT won't be called for max77693. - Can OTG FET control. Where the OTG FET feature is it enabled in your driver? I couldn't find it. Sorry. This driver don't control OTG FET feature. - Bigger Fast charge current, Top Off current Threshold selection. - Various and bigger OTG current limitation. - Bigger primary charger termination voltage setting. - Different maximum input current limit selection(Different step). Yes, I mentioned some of these differences (the Fast/top-off differences). These are differences in values so it does not require new driver. There is need to develop new driver just to support different current (3.0 A instead of 2.1 A) or voltage threshold. They are different charging current, OTG current limitation, top off current, charging limitation value. In case OTG current limitation different not limitation value but using register bit(max77843 use[7:6] max77693 use[7] bit only). Even if this driver not support all feature, some register different with max77693(support value, use register bit). If this driver will combined with max77693 may even be beneficial for new Maxim driver. But the present, this driver is related with max77843 core driver and max77843-regulator. So I hope this driver merge first. And then will extend two driver(max77843 charger and max77693 charger). I still prefer merging common drivers into one instead of creating some more of them. However I understand your point and I am not entirely opposed against. Especially that you invested quite a bit of time for developing this and my feedback was quite late. To summarize I am fine with your approach. Best regards, Krzysztof Dear Lee Jones, Could you please merge that your git tree ? Sorry, I'm lost. Why am I taking this though the MFD tree? What patches are left? Where are they going? Am I taking any other patches? Max77843 charger driver is max77843 mfd core dependency. What kind of dependancy? Runtime or build? Where is the patch that it depends on? Is it in -next for in Mainline already? Build. Max77843 charger driver use max77843-private.h. It is in for-mfd-next branch. c7f585f mfd: max77843: Add max77843 MFD driver core driver If that's the case, then yes, I can take this patch through the MFD tree with the correct Acks applied. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/1] clkdev: change prototype of clk_register_clkdev()
Hello Andy, On 20/03/15 14:18, Andy Shevchenko wrote: Since clk_register_clkdev() is exported for modules the caller should get a pointer to the allocated resources. Otherwise the memory leak is guaranteed on the -remove() stage. Cc: Tomeu Vizoso tomeu.viz...@collabora.com Reviewed-by: Mika Westerberg mika.westerb...@linux.intel.com Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com --- arch/arm/mach-msm/clock-pcom.c | 9 + arch/arm/mach-vexpress/spc.c | 5 - arch/mips/ath79/clock.c| 6 +++--- drivers/clk/clk-bcm2835.c | 12 +++- drivers/clk/clk-max-gen.c | 9 - drivers/clk/clk-xgene.c| 6 +++--- drivers/clk/clkdev.c | 15 ++- drivers/clk/samsung/clk-pll.c | 15 +-- drivers/clk/samsung/clk-s3c2410-dclk.c | 22 +++-- drivers/clk/samsung/clk.c | 35 +++--- include/linux/clkdev.h | 2 +- 11 files changed, 78 insertions(+), 58 deletions(-) I tested this on exynos, for clk/samsung Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- 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] gpio: gpio-tb10x: remove incorrect __exit markup
On Wed, Mar 25, 2015 at 6:14 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Mar 25, 2015 at 04:32:13PM +0100, Linus Walleij wrote: For a bool driver of this type (typically compiled in and probed at boot) that makes most sense to me. Hmm, I do not think this is a good justification for disabling unbinding. However, as far as I can see, removing gpiochip will succeed even though there are users of gpios in the system and that might justify the change. But does this mean that we give up on making gpiochip clean up properly and we should schedule gpiochip_remove() and the rest of gpio cleanup infrastructure for removal and declare that gpio drivers can not ever be made modules? No. Johan Hovold is looking into use cases for GPIO chips that come and go, think GPIO on USB. These obviously need remove() semantics. What I'm thinking is that the SoC-embedded GPIO controllers (I don't know how many these are) should probably be bool in Kconfig and also patched not to have remove() functions and drop the sysfs attribs for unbinding. But now I think I'll just apply the patch anyways because it sure does not make a difference wrt to the bigger problem, so I'm just bitching around about details and thinking aloud, sorry.. Yours, Linus Walleij -- 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] x86/asm/entry/64: Add forgotten CFI annotation
This is a missing bit of the recent MOV-to-PUSH conversion. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index bf9afad..a2ef30a 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -248,6 +248,7 @@ GLOBAL(system_call_after_swapgs) pushq_cfi_reg r10 /* pt_regs-r10 */ pushq_cfi_reg r11 /* pt_regs-r11 */ sub $(6*8),%rsp /* pt_regs-bp,bx,r12-15 not saved */ + CFI_ADJUST_CFA_OFFSET 6*8 testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) jnz tracesys -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes
On Fri, Mar 27, 2015 at 11:06 AM, Mika Westerberg mika.westerb...@linux.intel.com wrote: On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote: For the sleep case I think the GPIO controller needs to do the pin enable and set input direction operation in it's irq_bus_sync_unlock. I wonder how DT handles all this? Is it the boot firmware that sets up the pins accordingly or is there something we are missing? DT systems mostly do not have firmware for power usecases, they handle it all using pin control. I would more say that is a feature of all-SW systems without power-firmware ideas, without ACPI and without PSCI (well PSCI systems do not care about much more than CPU power down in firmware anyway...) Sometimes the power-down/up path includes driving pins to GND using the generic pin config option PIN_CONFIG_OUTPUT to drive the logic. For details on this mess where HW designers think that low-power sleep mode is GPIO-something see Documentation/pinctrl.txt section named GPIO mode pitfalls. I..e the question is not what registers are involved and what these are named, but the actual usecase. Yours, Linus Walleij -- 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] doc: completion: context, scope and language fixes
On Fri, 27 Mar 2015, Peter Zijlstra wrote: On Fri, Mar 27, 2015 at 08:56:37AM +0100, Ingo Molnar wrote: I wasn't Cc:-ed to the patch and it wasn't Cc:-ed to lkml either :-( /me hands mingo a strong cup of tea... http://marc.info/?l=linux-kernelm=142445364429042w=2 strange: I sent it to To: Jonathan Corbet cor...@lwn.net Cc: Ingo Molnar mi...@kernel.org, Valdis Kletnieks valdis.kletni...@vt.edu, Peter Zijlstra pet...@infradead.org, linux-...@vger.kernel.org, linux-kernel@vger.kernel.org, Nicholas Mc Guire hof...@osadl.org No idea how that happened. Did the mail violate some size-limit or content restriction ? thx! hofrat -- 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: [Intel-gfx] [Linux v4.0-rc5] Warnings in drm_framebuffer_reference() and drm_atomic_check_only()
On Wed, Mar 25, 2015 at 3:34 PM, Takashi Iwai ti...@suse.de wrote: At Wed, 25 Mar 2015 14:26:50 +0100, Daniel Vetter wrote: On Tue, Mar 24, 2015 at 07:09:03PM +0100, Sedat Dilek wrote: On Mon, Mar 23, 2015 at 9:25 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Mar 23, 2015 at 07:25:27AM +0100, Sedat Dilek wrote: Hi, I did my weekly update of the Linux RC (here: v4.0-rc5) and fell over some warning in the drm area. Please have a look... Hi Daniel, Just to confirm: Both are new in -rc5 and haven't been around in -rc4? Yeah, rc4 was OK but with rc5 I have seen these warnings. Also can you pls give -nightly a spin and see what happens there? drm-intel-nightly (2015y-03m-24d-09h-19m-43s UTC) pulled on top of rc5 does not show any warnings in the drm | i915 area. drm-fixes has 2 cherry-picks from -next to address the worst offenders, there's one more which is waiting for confirmation: commit fb9981aa675eb7b398849915364916fd98833cfa Author: Damien Lespiau damien.lesp...@intel.com Date: Thu Feb 5 19:24:25 2015 + drm/i915: Fix atomic state when reusing the firmware fb Please apply that commit from -next on top of drm-fixes and retest. The problem is introduced by the commit 319c1d420a0b62d9dbb88104afebaabc968cdbfa drm/i915: Ensure plane-state-fb stays in sync with plane-fb Obviously it accesses the uninitialized kref in get_initial_plane_config(). The commit in next f55548b5af87ebfc586ca75748947f1c1b1a4a52 drm/i915: Don't try to reference the fb in get_initial_plane_config() fixes the bug itself, but it leads to another similar warnings. For avoiding this, yet another cherry-picks (including the commit you mentioned above): fb9981aa675eb7b398849915364916fd98833cfa drm/i915: Fix atomic state when reusing the firmware fb 2d14030b1a9d0e89cfdca6f16851e2eac8cb4de0 drm/i915: Store the initial framebuffer in initial_plane_config then warnings are finally gone. But, the second one can't be applied cleanly, so I had to adjust many codes manually by replacing primary fb references. Takashi Hi Takashi, hi Daniel, first of all thank you for your replies. The last days I did not use my notebook and will try drm-intel-fixes-2015-03-26. Takashi, is that Git branch on top of rc5 OK for you? Regards, - Sedat - -- 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 2/2] powerpc/mm: Tracking vDSO remap
On 26/03/2015 19:55, Ingo Molnar wrote:
* Laurent Dufour lduf...@linux.vnet.ibm.com wrote:
+{
+unsigned long vdso_end, vdso_start;
+
+if (!mm-context.vdso_base)
+return;
+vdso_start = mm-context.vdso_base;
+
+#ifdef CONFIG_PPC64
+/* Calling is_32bit_task() implies that we are dealing with the
+ * current process memory. If there is a call path where mm is not
+ * owned by the current task, then we'll have need to store the
+ * vDSO size in the mm-context.
+ */
+BUG_ON(current-mm != mm);
+if (is_32bit_task())
+vdso_end = vdso_start + (vdso32_pages PAGE_SHIFT);
+else
+vdso_end = vdso_start + (vdso64_pages PAGE_SHIFT);
+#else
+vdso_end = vdso_start + (vdso32_pages PAGE_SHIFT);
+#endif
+vdso_end += (1PAGE_SHIFT); /* data page */
+
+/* Check if the vDSO is in the range of the remapped area */
+if ((vdso_start = old_start old_start vdso_end) ||
+(vdso_start old_end old_end = vdso_end) ||
+(old_start = vdso_start vdso_start old_end)) {
+/* Update vdso_base if the vDSO is entirely moved. */
+if (old_start == vdso_start old_end == vdso_end
+(old_end - old_start) == (new_end - new_start))
+mm-context.vdso_base = new_start;
+else
+mm-context.vdso_base = 0;
+}
+}
Oh my, that really looks awfully complex, as you predicted, and right
in every mremap() call.
I do agree, that's awfully complex ;)
I'm fine with your original, imperfect, KISS approach. Sorry about
this detour ...
Reviewed-by: Ingo Molnar mi...@kernel.org
No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?
Thanks,
Laurent.
--
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: [RESEND PATCH v3 2/2] dma: Add Xilinx AXI Central Direct Memory Access Engine driver support
Ping ! -Original Message- From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com] Sent: Wednesday, March 25, 2015 10:39 AM To: Michal Simek; Soren Brinkmann; vinod.k...@intel.com; dan.j.willi...@intel.com Cc: app...@xilinx.com; dmaeng...@vger.kernel.org; linux-arm- ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Appana Durga Kedareswara Rao; Srikanth Thokala Subject: [RESEND PATCH v3 2/2] dma: Add Xilinx AXI Central Direct Memory Access Engine driver support This is the driver for the AXI Central Direct Memory Access (AXI CDMA) core, which is a soft Xilinx IP core that provides high-bandwidth Direct Memory Access (DMA) between a memory-mapped source address and a memory-mapped destination address. This module works on Zynq (ARM Based SoC) and Microblaze platforms. Signed-off-by: Srikanth Thokala stho...@xilinx.com Signed-off-by: Kedareswara rao Appana appa...@xilinx.com --- This patch is rebased on top of dma: xilinx-dma: move header file to common location. Changes in v3: - Check for CDMA idle condition before changing the configuration. - Modified the xilinx_dma.h header file location to the include/linux/dma/xilinx_dma.h Changes in v2: - Rebased on 3.16-rc7. drivers/dma/Kconfig | 12 + drivers/dma/xilinx/Makefile |1 + drivers/dma/xilinx/xilinx_cdma.c | 1000 ++ include/linux/dma/xilinx_dma.h | 15 +- 4 files changed, 1027 insertions(+), 1 deletion(-) create mode 100644 drivers/dma/xilinx/xilinx_cdma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index a874b6e..1bc17c6 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -425,6 +425,18 @@ config IMG_MDC_DMA help Enable support for the IMG multi-threaded DMA controller (MDC). +config XILINX_CDMA + tristate Xilinx AXI CDMA Engine + depends on (ARCH_ZYNQ || MICROBLAZE) + select DMA_ENGINE + help + Enable support for Xilinx AXI CDMA Soft IP. + + The AXI CDMA is a soft IP which provides high-bandwidth + Direct Memory Access (DMA) between a memory-mapped source + address and a memory-mapped destination address using the + AXI4 protocol. + config DMA_ENGINE bool diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile index 3c4e9f2..e1dee77 100644 --- a/drivers/dma/xilinx/Makefile +++ b/drivers/dma/xilinx/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o +obj-$(CONFIG_XILINX_CDMA) += xilinx_cdma.o diff --git a/drivers/dma/xilinx/xilinx_cdma.c b/drivers/dma/xilinx/xilinx_cdma.c new file mode 100644 index 000..ff82fab --- /dev/null +++ b/drivers/dma/xilinx/xilinx_cdma.c @@ -0,0 +1,1000 @@ +/* + * DMA driver for Xilinx Central DMA Engine + * + * Copyright (C) 2010 - 2015 Xilinx, Inc. All rights reserved. + * + * Based on the Freescale DMA driver. + * + * Description: + * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct +Memory + * Access (DMA) between a memory-mapped source address and a +memory-mapped + * destination address. + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/bitops.h +#include linux/dmapool.h +#include linux/dma/xilinx_dma.h +#include linux/init.h +#include linux/interrupt.h +#include linux/io.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_dma.h +#include linux/of_irq.h +#include linux/of_platform.h +#include linux/slab.h + +#include ../dmaengine.h + +/* Register Offsets */ +#define XILINX_CDMA_CONTROL_OFFSET 0x00 +#define XILINX_CDMA_STATUS_OFFSET 0x04 +#define XILINX_CDMA_CDESC_OFFSET 0x08 +#define XILINX_CDMA_TDESC_OFFSET 0x10 +#define XILINX_CDMA_SRCADDR_OFFSET 0x18 +#define XILINX_CDMA_DSTADDR_OFFSET 0x20 +#define XILINX_CDMA_BTT_OFFSET 0x28 + +/* General register bits definitions */ +#define XILINX_CDMA_CR_RESET BIT(2) +#define XILINX_CDMA_CR_SGMODE BIT(3) + +#define XILINX_CDMA_SR_IDLEBIT(1) + +#define XILINX_CDMA_XR_IRQ_IOC_MASKBIT(12) +#define XILINX_CDMA_XR_IRQ_DELAY_MASK BIT(13) #define +XILINX_CDMA_XR_IRQ_ERROR_MASK BIT(14) +#define XILINX_CDMA_XR_IRQ_ALL_MASKGENMASK(14, 12) + +#define XILINX_CDMA_XR_DELAY_MASK GENMASK(31, 24) +#define XILINX_CDMA_XR_COALESCE_MASK GENMASK(23, 16) + +#define XILINX_CDMA_DELAY_MAX GENMASK(7, 0) +#define XILINX_CDMA_DELAY_SHIFT24 + +#define XILINX_CDMA_COALESCE_MAX GENMASK(7, 0) +#define XILINX_CDMA_COALESCE_SHIFT 16 + +/* Delay loop counter to prevent hardware failure */ +#define XILINX_CDMA_RESET_LOOP 100 + +/* Maximum transfer length */ +#define
Re: [PATCH] x86/asm/entry/64: better check for canonical address
* Brian Gerst brge...@gmail.com wrote: Btw., there's a neat trick we could do: in the HLT, MWAIT and ACPI-idle code we could attempt to set up RCX to match RIP, to trigger this optimization in the common 'irq interrupted the idle task' case? sysret only returns to CPL3. Indeed, an IRET ought to be pretty cheap for same-ring interrupt returns in any case. Thanks, Ingo -- 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 4/4] x86/asm/entry/32: Use PUSH instructions to build pt_regs on stack
* Denys Vlasenko dvlas...@redhat.com wrote: This mimics the recent similar 64-bit change. Saves ~110 bytes of code. Would be nice to know whether you tested all the affected system entry variants, on both AMD and Intel CPUs? that would be: @@ -126,26 +126,27 @@ ENTRY(ia32_sysenter_target) @@ -334,20 +335,24 @@ ENTRY(ia32_cstar_target) @@ -478,12 +483,17 @@ ENTRY(ia32_syscall) Thanks, Ingo -- 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 10/15] serial: stm32-usart: Add STM32 USART Driver
On 03/26/2015 06:03 PM, Maxime Coquelin wrote:
+static void stm32_set_termios(struct uart_port *port, struct ktermios
*termios,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ u32 usardiv, mantissa, fraction;
+ tcflag_t cflag;
+ u32 cr1, cr2, cr3;
+ unsigned long flags;
+
+ baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk / 16);
+ cflag = termios-c_cflag;
+
+ spin_lock_irqsave(port-lock, flags);
+
+ /* Stop serial port and reset value */
+ writel_relaxed(0, port-membase + USART_CR1);
+
+ cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
+
+ if (cflag CSTOPB)
+ cr2 = USART_CR2_STOP_2B;
+
+ if (cflag PARENB) {
+ cr1 |= USART_CR1_PCE;
+ if ((cflag CSIZE) == CS8)
+ cr1 |= USART_CR1_M;
+ }
+
+ if (cflag PARODD)
+ cr1 |= USART_CR1_PS;
+
+ if (cflag CRTSCTS)
+ cr3 = USART_CR3_RTSE | USART_CR3_CTSE;
If this means autoflow control, then you need to define
throttle()/unthrottle() methods, otherwise the serial core won't
be able to throttle the remote when input buffers are about
to overflow.
And you should only enable the autoCTS and let the serial
core enable autoRTS through set_mctrl(TIOCM_RTS).
Just let me know if you need more info about how to do this.
Ok, let's see if I have well understood.
USART_CR3_RTSE should be set/cleared in set_mctrl(), depending on
TIOCM_RTS value.
The throttle callback should disable the rx interrupt, and the
unthrottle enable it.
For CTS, it should be enabled in set_termios() if CRTSCTS, as done here.
Am I right?
Yeah, basically. You also have to indicate to the serial core that you
require throttle/unthrottle handling in this mode by setting port-status.
Your set_termios() method would look like:
port-status = ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS);
if (cflag CRTSCTS) {
port-status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
cr3 = USART_CR3_CTSE;
}
and your set_mctrl() method would look like:
if ((mctrl TIOCM_RTS) (port-status UPSTAT_AUTORTS))
stm32_set_bits(port, USART_CR3, USART_CR3_RTSE);
else
stm32_clear_bits(port, USART_CR3, USART_CR3_RTSE);
The UPSTAT_AUTOCTS doesn't really do anything right now but please
use it anyway to indicate this driver has that functionality.
Regards,
Peter Hurley
--
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/8] gpio: omap: convert omap_gpio_is_input() to use gpio offset
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Convert omap_gpio_is_input() to use GPIO offset instead of mask and, in such way, make code simpler and remove few lines of code. Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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: mm: lru_add_drain_all hangs
On 03/27/2015 04:32 AM, Sasha Levin wrote:
Hi all,
I've started seeing pretty frequent hangs within lru_add_drain_all(). It
doesn't
seem to be hanging on a specific thing, and it appears that even a moderate
load
can cause it to hang (just 50 trinity threads in this case).
Notice that I've bumped up the hang timer to 20 minutes.
[ 3605.506554] INFO: task trinity-c0:14641 blocked for more than 1200 seconds.
[ 3605.507997] Not tainted 4.0.0-rc5-next-20150324-sasha-00038-g04b74cc
#2088
[ 3605.508889] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
[ 3605.509704] trinity-c0 D 8800776efd28 26512 14641 9194
0x1000
[ 3605.510704] 8800776efd28 880077633ca8
[ 3605.511568] 8800261e0558 8800261e0530 880077633008
8802f5c33000
[ 3605.513025] 880077633000 8800776efd08 8800776e8000
ed000eedd002
[ 3605.514004] Call Trace:
[ 3605.514368] schedule (./arch/x86/include/asm/bitops.h:311 (discriminator
1) kernel/sched/core.c:2827 (discriminator 1))
[ 3605.515025] schedule_preempt_disabled (kernel/sched/core.c:2859)
[ 3605.516025] mutex_lock_nested (kernel/locking/mutex.c:585
kernel/locking/mutex.c:623)
[ 3605.517265] ? lru_add_drain_all (mm/swap.c:867)
[ 3605.518663] ? rcu_eqs_exit_common (kernel/rcu/tree.c:735 (discriminator 8))
[ 3605.519305] ? lru_add_drain_all (mm/swap.c:867)
[ 3605.519879] ? mutex_trylock (kernel/locking/mutex.c:621)
[ 3605.520982] ? context_tracking_user_exit (kernel/context_tracking.c:164)
[ 3605.522302] ? perf_syscall_exit (kernel/trace/trace_syscalls.c:549)
[ 3605.523610] lru_add_drain_all (mm/swap.c:867)
[ 3605.524628] SyS_mlock (mm/mlock.c:618 mm/mlock.c:607)
[ 3605.526112] tracesys_phase2 (arch/x86/kernel/entry_64.S:344)
[ 3605.527819] 1 lock held by trinity-c0/14641:
[ 3605.528951] #0: (lock#4){+.+...}, at: lru_add_drain_all (mm/swap.c:867)
[ 3605.530561] Mutex: counter: -1 owner: trinity-c7
So that's the statically defined mutex in lru_add_drain_all() itself, right?
Many processes are waiting for it, except the owner trinity-c7:
[ 3614.918852] trinity-c7 D 8802f4487b58 26976 16252 9410
0x1000
[ 3614.919580] 8802f4487b58 8802f6b98ca8
[ 3614.920435] 88017d3e0558 88017d3e0530 8802f6b98008
88016bad
[ 3614.921219] 8802f6b98000 8802f4487b38 8802f448
ed005e890002
[ 3614.922069] Call Trace:
[ 3614.922346] schedule (./arch/x86/include/asm/bitops.h:311 (discriminator
1) kernel/sched/core.c:2827 (discriminator 1))
[ 3614.923023] schedule_preempt_disabled (kernel/sched/core.c:2859)
[ 3614.923707] mutex_lock_nested (kernel/locking/mutex.c:585
kernel/locking/mutex.c:623)
[ 3614.924486] ? lru_add_drain_all (mm/swap.c:867)
[ 3614.925211] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2580
kernel/locking/lockdep.c:2622)
[ 3614.925970] ? lru_add_drain_all (mm/swap.c:867)
[ 3614.926692] ? mutex_trylock (kernel/locking/mutex.c:621)
[ 3614.927464] ? mpol_new (mm/mempolicy.c:285)
[ 3614.928044] lru_add_drain_all (mm/swap.c:867)
[ 3614.928608] migrate_prep (mm/migrate.c:64)
[ 3614.929092] SYSC_mbind (mm/mempolicy.c:1188 mm/mempolicy.c:1319)
[ 3614.929619] ? rcu_eqs_exit_common (kernel/rcu/tree.c:735 (discriminator 8))
[ 3614.930318] ? __mpol_equal (mm/mempolicy.c:1304)
[ 3614.930877] ? trace_hardirqs_on (kernel/locking/lockdep.c:2630)
[ 3614.931485] ? syscall_trace_enter_phase2 (arch/x86/kernel/ptrace.c:1592)
[ 3614.932184] SyS_mbind (mm/mempolicy.c:1301)
That looks like trinity-c7 is waiting ot in too, but later on (after some more
listings like this for trinity-c7, probably threads?) we have:
[ 3615.523625] trinity-c7 D 8801fd9c7aa8 26688 16935 9518
0x1000
[ 3615.525214] 8801fd9c7aa8 8801fd9c7a48 b802b7e0
ed01
[ 3615.528062] 88017d3e0558 88017d3e0530 8801ee47b008
8801bb6e
[ 3615.529887] 8801ee47b000 ed002fa7c0d2 8801fd9c
ed003fb38002
[ 3615.531155] Call Trace:
[ 3615.531560] schedule (./arch/x86/include/asm/bitops.h:311 (discriminator
1) kernel/sched/core.c:2827 (discriminator 1))
[ 3615.532609] schedule_timeout (kernel/time/timer.c:1475)
[ 3615.533650] ? console_conditional_schedule (kernel/time/timer.c:1460)
[ 3615.534961] ? sched_clock_cpu (kernel/sched/clock.c:311)
[ 3615.536960] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 3615.539059] ? get_lock_stats (kernel/locking/lockdep.c:249)
[ 3615.539912] ? mark_held_locks (kernel/locking/lockdep.c:2546)
[ 3615.540903] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 3615.542034] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2580
kernel/locking/lockdep.c:2622)
[ 3615.543579] wait_for_completion (include/linux/spinlock.h:342
kernel/sched/completion.c:76 kernel/sched/completion.c:93
kernel/sched/completion.c:101
Re: [PATCH v2 6/8] gpio: omap: get rid of GPIO_BIT() macro
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for GPIO_BIT() macro removing. Do it ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 5/8] gpio: omap: convert gpio irq functions to use GPIO offset
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Convert GPIO IRQ functions to use GPIO offset instead of system GPIO numbers. This allows to drop unneeded conversations between system GPIO - GPIO offset which are done in many places and many times. It is safe to do now because: - gpiolib always passes GPIO offset to GPIO controller - OMAP GPIO driver converted to use IRQ domain, so struct irq_data-hwirq contains GPIO offset This is preparation step before removing: #define GPIO_INDEX(bank, gpio) #define GPIO_BIT(bank, gpio) int omap_irq_to_gpio() Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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 7/8] gpio: omap: get rid of omap_irq_to_gpio()
On Mon, Mar 23, 2015 at 1:18 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing. Do it ;) Tested-by: Tony Lindgren t...@atomide.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Santosh Shilimkar ssant...@kernel.org Acked-by: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org Patch applied. Yours, Linus Walleij -- 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] gpio: syscon: reduce message level when direction reg offset not in dt
On Tue, Mar 24, 2015 at 7:42 PM, grygorii.stras...@linaro.org wrote: From: Grygorii Strashko grygorii.stras...@linaro.org Now GPIO syscon driver produces bunch of warnings during the boot of Kesytone 2 SoCs: gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset! gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset! This message unintentionally was added using dev_err(), but its actual log level is debug, because third cell of ti,syscon-dev is optional. Hence change it to dev_dbg() as it should be. This patch fixes commit: 5a3e3f8 (gpio: syscon: retriave syscon node and regs offsets from dt) Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org OK sorry for missing this when asking about the strange messages. Patch applied for fixes with these test tags and ack. Yours, Linus Walleij -- 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/13] thermal: Make temperatures consistently unsigned long
Hi Sascha, Sascha Hauer s.ha...@pengutronix.de writes: The thermal framework uses int, long and unsigned long for temperatures in millicelsius. The majority of functions uses unsigned long, so change the remaining functions to use this type aswell. Signed-off-by: Sascha Hauer s.ha...@pengutronix.de I'd suggest changing to long instead. It would allow the use of the thermal framework in environments where temperatures are below 0C - quite easily reached in many parts of the world. Regards, Punit --- drivers/thermal/thermal_core.c | 10 +- include/linux/thermal.h| 6 +++--- 2 files changed, 8 insertions(+), 8 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/
Re: [PATCH] gpio: gpio-tb10x: remove incorrect __exit markup
On Mon, Mar 9, 2015 at 7:04 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: Even if bus is not hot-pluggable, the devices can be unbound from the driver via sysfs, so we should not be using __exit annotations on remove() methods. The only exception is drivers registered with platform_driver_probe() which specifically disables sysfs bind/unbind attributes. Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com Patch applied. Yours, Linus Walleij -- 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] Add coccinelle script that makes sure that tables are NULL terminated
Hi,
Could you please review my patch I sent last month? It checks if tables
in kernel are NULL terminated. Script matches only names specified in
source code by postfix='*_device_id$' and by list of prefixes which is
now prefix_list = ['platform', 'of', 'i2c']. I think it could by useful
in kernel sources.
On 02/27/2015 02:21 PM, Daniel Granat wrote:
pre wrap
Signed-off-by: Daniel Granat lt;d.gra...@samsung.comgt;
---
scripts/coccinelle/misc/device_id_tables.cocci | 95
++
1 file changed, 95 insertions(+)
create mode 100644 scripts/coccinelle/misc/device_id_tables.cocci
diff --git a/scripts/coccinelle/misc/device_id_tables.cocci
b/scripts/coccinelle/misc/device_id_tables.cocci
new file mode 100644
index 000..5968984
--- /dev/null
+++ b/scripts/coccinelle/misc/device_id_tables.cocci
@@ -0,0 +1,95 @@
+/// Make sure '*_device_id$' tables are NULL terminated
+//
+// Keywords: device_id
+// Confidence: Medium
+// Options: --include-headers
+
+virtual org
+virtual report
+virtual patch
+
+@initialize:python@
+@@
+import re
+
+postfix = '_device_id$'
+prefix_list = ['platform', 'of', 'i2c']
+
+@r1 depends on patch || org || report@
+position p1;
+identifier var, arr;
+identifier struct_name;
+expression E;
+@@
+
+(
+struct struct_name arr[] = {
+ ...,
+ {
+ .var = E,
+ }
+ @p1
+};
+|
+struct struct_name arr[] = {
+ ...,
+ { ..., var, ... },
+ @p1
+};
+)
+
+@script:python depends on report@
+struct_name lt;lt; r1.struct_name;
+p1 lt;lt; r1.p1;
+arr lt;lt; r1.arr;
+pattern;
+@@
+
+for i in prefix_list:
+ pattern = str(i)+postfix
+ if re.match(pattern, struct_name) != None:
+ print \nCOCCI: \%s\ matchs required pattern \%s\ %
(struct_name, pattern)
+ msg = \%s\ is not NULL terminated at line %s % (arr, p1[0].line)
+ coccilib.report.print_report(p1[0],msg)
+ break
+
+@script:python match depends on patch@
+struct_name lt;lt; r1.struct_name;
+matched_name;
+pattern;
+@@
+
+coccinelle.matched_name = ''
+
+for i in prefix_list:
+ pattern = str(i)+postfix
+ if re.match(pattern, struct_name) != None:
+ coccinelle.matched_name = struct_name
+ break
+
+@r2 depends on patch@
+position r1.p1;
+identifier var, arr;
+identifier match.matched_name;
+expression E;
+@@
+
+(
+struct matched_name arr[] = {
+ ...,
+ {
+ .var = E,
+- }
+ @p1
++ },
++ {},
+};
+|
+struct matched_name arr[] = {
+ ...,
+ { ..., var, ... },
+ @p1
++ {},
+};
+)
+
/pre/body
/html
/html
--
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/
