*|Deposit|*
Accept 19M USD as a cash gift? Write back asap. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] ALSA: bebob: constify various snd_bebob structures
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec,
snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are
initialized. Make them all const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
v3: change subject line
sound/firewire/bebob/bebob.c |2 +-
sound/firewire/bebob/bebob.h | 32
sound/firewire/bebob/bebob_focusrite.c | 26 +-
sound/firewire/bebob/bebob_maudio.c| 32
sound/firewire/bebob/bebob_pcm.c |2 +-
sound/firewire/bebob/bebob_proc.c |6 +++---
sound/firewire/bebob/bebob_stream.c|6 +++---
sound/firewire/bebob/bebob_terratec.c | 10 +-
sound/firewire/bebob/bebob_yamaha.c|6 +++---
9 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c
index 0ed5e5f..091290d 100644
--- a/sound/firewire/bebob/bebob.c
+++ b/sound/firewire/bebob/bebob.c
@@ -335,7 +335,7 @@ static void bebob_remove(struct fw_unit *unit)
snd_card_free_when_closed(bebob->card);
}
-static struct snd_bebob_rate_spec normal_rate_spec = {
+static const struct snd_bebob_rate_spec normal_rate_spec = {
.get= &snd_bebob_stream_get_rate,
.set= &snd_bebob_stream_set_rate
};
diff --git a/sound/firewire/bebob/bebob_focusrite.c
b/sound/firewire/bebob/bebob_focusrite.c
index a1a3949..f110900 100644
--- a/sound/firewire/bebob/bebob_focusrite.c
+++ b/sound/firewire/bebob/bebob_focusrite.c
@@ -200,7 +200,7 @@ end:
return err;
}
-struct snd_bebob_spec saffire_le_spec;
+const struct snd_bebob_spec saffire_le_spec;
static enum snd_bebob_clock_type saffire_both_clk_src_types[] = {
SND_BEBOB_CLOCK_TYPE_INTERNAL,
SND_BEBOB_CLOCK_TYPE_EXTERNAL,
@@ -229,7 +229,7 @@ static const char *const saffire_meter_labels[] = {
static int
saffire_meter_get(struct snd_bebob *bebob, u32 *buf, unsigned int size)
{
- struct snd_bebob_meter_spec *spec = bebob->spec->meter;
+ const struct snd_bebob_meter_spec *spec = bebob->spec->meter;
unsigned int channels;
u64 offset;
int err;
@@ -260,60 +260,60 @@ saffire_meter_get(struct snd_bebob *bebob, u32 *buf,
unsigned int size)
return err;
}
-static struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
+static const struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
.get= &saffirepro_both_clk_freq_get,
.set= &saffirepro_both_clk_freq_set,
};
/* Saffire Pro 26 I/O */
-static struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
+static const struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
.num= ARRAY_SIZE(saffirepro_26_clk_src_types),
.types = saffirepro_26_clk_src_types,
.get= &saffirepro_both_clk_src_get,
};
-struct snd_bebob_spec saffirepro_26_spec = {
+const struct snd_bebob_spec saffirepro_26_spec = {
.clock = &saffirepro_26_clk_spec,
.rate = &saffirepro_both_rate_spec,
.meter = NULL
};
/* Saffire Pro 10 I/O */
-static struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
+static const struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
.num= ARRAY_SIZE(saffirepro_10_clk_src_types),
.types = saffirepro_10_clk_src_types,
.get= &saffirepro_both_clk_src_get,
};
-struct snd_bebob_spec saffirepro_10_spec = {
+const struct snd_bebob_spec saffirepro_10_spec = {
.clock = &saffirepro_10_clk_spec,
.rate = &saffirepro_both_rate_spec,
.meter = NULL
};
-static struct snd_bebob_rate_spec saffire_both_rate_spec = {
+static const struct snd_bebob_rate_spec saffire_both_rate_spec = {
.get= &snd_bebob_stream_get_rate,
.set= &snd_bebob_stream_set_rate,
};
-static struct snd_bebob_clock_spec saffire_both_clk_spec = {
+static const struct snd_bebob_clock_spec saffire_both_clk_spec = {
.num= ARRAY_SIZE(saffire_both_clk_src_types),
.types = saffire_both_clk_src_types,
.get= &saffire_both_clk_src_get,
};
/* Saffire LE */
-static struct snd_bebob_meter_spec saffire_le_meter_spec = {
+static const struct snd_bebob_meter_spec saffire_le_meter_spec = {
.num= ARRAY_SIZE(saffire_le_meter_labels),
.labels = saffire_le_meter_labels,
.get= &saffire_meter_get,
};
-struct snd_bebob_spec saffire_le_spec = {
+const struct snd_bebob_spec saffire_le_spec = {
.clock = &saffire_both_clk_spec,
.rate = &saffire_both_rate_spec,
.meter = &saffire_le_meter_spec
};
/* Saffire */
-static struct snd_bebob_meter_spec saffire_meter_spec = {
+static const struct snd_bebob_meter_spec saffire_meter_spec = {
.num= ARRAY_SIZE(saffire_meter_labels),
.labels = saffire_meter_labels,
.get= &saffire_meter_get,
};
-struct snd_bebob_spec saffire_spec = {
+con
Re: [PATCH v2] ALSA: bebob: constify snd_bebob_rate_spec structures
On Sun, 11 Oct 2015, Takashi Sakamoto wrote: > Hi, > > On Oct 11 2015 06:24, Julia Lawall wrote: > > The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec, > > snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are > > initialized. Make them all const. > > > > Done with the help of Coccinelle. > > > > Signed-off-by: Julia Lawall > > > > --- > > > > v2: extend to snd_bebob_clock_spec, snd_bebob_meter_spec, and > > snd_bebob_spec structures. > > > > sound/firewire/bebob/bebob.c |2 +- > > sound/firewire/bebob/bebob.h | 32 > > > > sound/firewire/bebob/bebob_focusrite.c | 26 +- > > sound/firewire/bebob/bebob_maudio.c| 32 > > > > sound/firewire/bebob/bebob_pcm.c |2 +- > > sound/firewire/bebob/bebob_proc.c |6 +++--- > > sound/firewire/bebob/bebob_stream.c|6 +++--- > > sound/firewire/bebob/bebob_terratec.c | 10 +- > > sound/firewire/bebob/bebob_yamaha.c|6 +++--- > > 9 files changed, 61 insertions(+), 61 deletions(-) > > Tested-by: Takashi Sakamoto > Reviewed-by: Takashi Sakamoto > > Thank you to include my extra request and spend more time for this patch ;) > > But I prefer to change the title of this patch to 'ALSA: bebob: constify > some structures because they are never modified' or something like it > because this patch is not only for 'struct snd_bebob_rate_spec'. Sorry not to have paid attention to that. I will send it again. julia -- 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 REQUEST] md bugfix
The following changes since commit da6fb7a9e5bd6f04f7e15070f630bdf1ea502841: md/bitmap: don't pass -1 to bitmap_storage_alloc. (2015-10-02 17:24:13 +1000) are available in the git repository at: git://neil.brown.name/md tags/md/4.3-rc4-fix for you to fetch changes up to a452744bcbf706eac65abb4c98496a366820c60a: crash in md-raid1 and md-raid10 due to incorrect list manipulation (2015-10-09 08:33:46 +1100) One bug fix for raid1/raid10. Very careless bug earler in 4.3-rc, now fixed :-) Mikulas Patocka (1): crash in md-raid1 and md-raid10 due to incorrect list manipulation drivers/md/raid1.c | 4 ++-- drivers/md/raid10.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) signature.asc Description: PGP signature
[PATCH] staging: lustre: lclient: NULL comparison style
Fixes checkpatch.pl checks:
CHECK: Comparison to NULL could be written ...
Signed-off-by: Ryan Van Quinlan
---
drivers/staging/lustre/lustre/lclient/glimpse.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lclient/glimpse.c
b/drivers/staging/lustre/lustre/lclient/glimpse.c
index b9f2bb6..8533a1e 100644
--- a/drivers/staging/lustre/lustre/lclient/glimpse.c
+++ b/drivers/staging/lustre/lustre/lclient/glimpse.c
@@ -73,7 +73,7 @@ blkcnt_t dirty_cnt(struct inode *inode)
struct ccc_object *vob = cl_inode2ccc(inode);
void *results[1];
- if (inode->i_mapping != NULL)
+ if (inode->i_mapping)
cnt += radix_tree_gang_lookup_tag(&inode->i_mapping->page_tree,
results, 0, 1,
PAGECACHE_TAG_DIRTY);
@@ -129,7 +129,7 @@ int cl_glimpse_lock(const struct lu_env *env, struct cl_io
*io,
current);
cio->cui_glimpse = 0;
- if (lock == NULL)
+ if (!lock)
return 0;
if (IS_ERR(lock))
@@ -255,7 +255,7 @@ int cl_local_size(struct inode *inode)
*descr = whole_file;
descr->cld_obj = clob;
lock = cl_lock_peek(env, io, descr, "localsize", current);
- if (lock != NULL) {
+ if (lock) {
cl_merge_lvb(env, inode);
cl_unuse(env, lock);
cl_lock_release(env, lock, "localsize", current);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
Damn, I bow before the master. That is a much neater solution than mine; I had assumed a lock was required for writing. While it's good enough for benchmarking, there are a few leftover problems I mention so they don't get missed. One is the final write back of add_ptr on the last line of _mix_pool_bytes. It actually writes i, which includes the per-cpu nonce, and will have it jumping all over without the steady progression that the mixing polynomial assumes. (There's a similar, lesser problem with input_rotate.) The second, less obvious, problem is that by calling _mix_pool_bytes completely lockless, there's the risk that it will race with and overwrite the addition of new seed material to the pool. The add-back is not critical, and races between two writers don't really do any harm. But seed entropy is valuable. And unfortunately, transferring 256 bits (32 bytes) to the output pool will try to write every word, so *any* concurrent add-back is risky; there's no "safe" part of the pool that can be accessed lockless. (The first crude hack that comes to mind is to double the size of the output pool, without increasing its nominal capacity, and do seeding and add-back to different halves. Hopefully there's something more elegant.) Two minor suggestions about is_nonblock: 1) Rather than using (r == &nonblocking_pool), how about !r->limit? 2) Would you mind making is_nonblock bool? I know back before the sacred text of the prophets Kernighan and Ritchie was corrupted by modern heresies, we used "int" for everything, and we liked it. 5 miles in the snow, uphill both ways, yadda yadda. But I like to document range restrictions as much as possible, and "bool" makes it clearer to both the compiler and the reader of the code. -- 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 Foundation Technical Advisory Board Elections and Nomination process
I would like to nominate Sage Weil with his consent. Sage has lead the ceph project since its inception, contributed to the kernel as well as had an influence on projects like openstack. thanks! Ric On 10/06/2015 01:06 PM, Grant Likely wrote: [Resending because I messed up the first one] The elections for five of the ten members of the Linux Foundation Technical Advisory Board (TAB) are held every year[1]. This year the election will be at the 2015 Kernel Summit in Seoul, South Korea (probably on the Monday, 26 October) and will be open to all attendees of both Kernel Summit and Korea Linux Forum. Anyone is eligible to stand for election, simply send your nomination to: tech-board-disc...@lists.linux-foundation.org We currently have 3 nominees for five places: Thomas Gleixner Greg Kroah-Hartman Stephen Hemminger The deadline for receiving nominations is up until the beginning of the event where the election is held. Although, please remember if you're not going to be present that things go wrong with both networks and mailing lists, so get your nomination in early). Grant Likely, TAB Chair [1] TAB members sit for a term of 2 years, and half of the board is up for election every year. Five of the seats are up for election now. The other five are half way through their term and will be up for election next year. The history of the TAB elections can be found here: https://docs.google.com/spreadsheets/d/1jGLQtul0taSRq_opYzJFALI7_34cS4RMS1_YQoTNCKA/edit#gid=0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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] Linux PID algorithm is BRAINDEAD!
Hi Ted, Thanks for responding. Fair points all of them. I would like to take exception to one of them, the bottleneck part: > The biggest problem is that accessing this free pid queue is now > a locking bottleneck --- especially on a very large NUMA system That was exactly what I was trying to say towards the end: the the queue idea or implementation need not be strict. No one cares if instead of grabbing the very firts aof the queue, you grab, say, the third element. The /only/ real requirement is that newly entered elements not go near the head of the queue. I would argue that bottleneck or resource locking doesn't exist at all: If you have n cpu's, you can have n queues, albeit each now smaller. (Or, equivalently, the cpu's deciding to divvy up the queue into a mod n space.). And, the populator pushing into them in a round-robin fashion. -- 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] ALSA: bebob: constify snd_bebob_rate_spec structures
Hi,
On Oct 11 2015 06:24, Julia Lawall wrote:
> The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec,
> snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are
> initialized. Make them all const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
>
> v2: extend to snd_bebob_clock_spec, snd_bebob_meter_spec, and
> snd_bebob_spec structures.
>
> sound/firewire/bebob/bebob.c |2 +-
> sound/firewire/bebob/bebob.h | 32
>
> sound/firewire/bebob/bebob_focusrite.c | 26 +-
> sound/firewire/bebob/bebob_maudio.c| 32
>
> sound/firewire/bebob/bebob_pcm.c |2 +-
> sound/firewire/bebob/bebob_proc.c |6 +++---
> sound/firewire/bebob/bebob_stream.c|6 +++---
> sound/firewire/bebob/bebob_terratec.c | 10 +-
> sound/firewire/bebob/bebob_yamaha.c|6 +++---
> 9 files changed, 61 insertions(+), 61 deletions(-)
Tested-by: Takashi Sakamoto
Reviewed-by: Takashi Sakamoto
Thank you to include my extra request and spend more time for this patch ;)
But I prefer to change the title of this patch to 'ALSA: bebob: constify
some structures because they are never modified' or something like it
because this patch is not only for 'struct snd_bebob_rate_spec'.
Thanks
Takashi Sakamoto
> diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c
> index 0ed5e5f..091290d 100644
> --- a/sound/firewire/bebob/bebob.c
> +++ b/sound/firewire/bebob/bebob.c
> @@ -335,7 +335,7 @@ static void bebob_remove(struct fw_unit *unit)
> snd_card_free_when_closed(bebob->card);
> }
>
> -static struct snd_bebob_rate_spec normal_rate_spec = {
> +static const struct snd_bebob_rate_spec normal_rate_spec = {
> .get= &snd_bebob_stream_get_rate,
> .set= &snd_bebob_stream_set_rate
> };
> diff --git a/sound/firewire/bebob/bebob_focusrite.c
> b/sound/firewire/bebob/bebob_focusrite.c
> index a1a3949..f110900 100644
> --- a/sound/firewire/bebob/bebob_focusrite.c
> +++ b/sound/firewire/bebob/bebob_focusrite.c
> @@ -200,7 +200,7 @@ end:
> return err;
> }
>
> -struct snd_bebob_spec saffire_le_spec;
> +const struct snd_bebob_spec saffire_le_spec;
> static enum snd_bebob_clock_type saffire_both_clk_src_types[] = {
> SND_BEBOB_CLOCK_TYPE_INTERNAL,
> SND_BEBOB_CLOCK_TYPE_EXTERNAL,
> @@ -229,7 +229,7 @@ static const char *const saffire_meter_labels[] = {
> static int
> saffire_meter_get(struct snd_bebob *bebob, u32 *buf, unsigned int size)
> {
> - struct snd_bebob_meter_spec *spec = bebob->spec->meter;
> + const struct snd_bebob_meter_spec *spec = bebob->spec->meter;
> unsigned int channels;
> u64 offset;
> int err;
> @@ -260,60 +260,60 @@ saffire_meter_get(struct snd_bebob *bebob, u32 *buf,
> unsigned int size)
> return err;
> }
>
> -static struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
> +static const struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
> .get= &saffirepro_both_clk_freq_get,
> .set= &saffirepro_both_clk_freq_set,
> };
> /* Saffire Pro 26 I/O */
> -static struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
> +static const struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
> .num= ARRAY_SIZE(saffirepro_26_clk_src_types),
> .types = saffirepro_26_clk_src_types,
> .get= &saffirepro_both_clk_src_get,
> };
> -struct snd_bebob_spec saffirepro_26_spec = {
> +const struct snd_bebob_spec saffirepro_26_spec = {
> .clock = &saffirepro_26_clk_spec,
> .rate = &saffirepro_both_rate_spec,
> .meter = NULL
> };
> /* Saffire Pro 10 I/O */
> -static struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
> +static const struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
> .num= ARRAY_SIZE(saffirepro_10_clk_src_types),
> .types = saffirepro_10_clk_src_types,
> .get= &saffirepro_both_clk_src_get,
> };
> -struct snd_bebob_spec saffirepro_10_spec = {
> +const struct snd_bebob_spec saffirepro_10_spec = {
> .clock = &saffirepro_10_clk_spec,
> .rate = &saffirepro_both_rate_spec,
> .meter = NULL
> };
>
> -static struct snd_bebob_rate_spec saffire_both_rate_spec = {
> +static const struct snd_bebob_rate_spec saffire_both_rate_spec = {
> .get= &snd_bebob_stream_get_rate,
> .set= &snd_bebob_stream_set_rate,
> };
> -static struct snd_bebob_clock_spec saffire_both_clk_spec = {
> +static const struct snd_bebob_clock_spec saffire_both_clk_spec = {
> .num= ARRAY_SIZE(saffire_both_clk_src_types),
> .types = saffire_both_clk_src_types,
> .get= &saffire_both_clk_src_get,
> };
> /* Saffire LE */
> -static struct snd_bebob_meter_spec saffire_le_meter_spec = {
> +static const struct snd_bebob_meter_spec saffire_le_meter_spec = {
> .num= ARRAY_SIZE
Re: [PATCH 1/2] sched: Some sched trace points should depend on SCHEDSTATS
Steve, Any comments about this patch? I think I addressed your question about why sched_stat_template is still required. Because another tracepoint depends on it, and that tracepoint doesn't depend on SCHEDSTATS. If you thought this patch is valid, I could re-submit it with a separte patch. On Tue, 4 Aug 2015, Oliver Yang wrote: > > > On 2015/8/4 1:34, Steven Rostedt wrote: > > On Mon, 27 Jul 2015 09:11:51 -0400 > > yangoliver wrote: > > > >> When SCHEDSTATS is not enabled, follow trace points shouldn't be > >> accessed by default, > >> > >>sched:sched_stat_wait > >>sched:sched_stat_sleep > >>sched:sched_stat_iowait > >>sched:sched_stat_blocked > >> > >> These trace points should only be available when SCHEDSTATS is > >> enabled. > >> > >> Signed-off-by: Yong Yang > >> --- > >> include/trace/events/sched.h | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h > >> index d57a575..5b34309 100644 > >> --- a/include/trace/events/sched.h > >> +++ b/include/trace/events/sched.h > >> @@ -334,6 +334,7 @@ DECLARE_EVENT_CLASS(sched_stat_template, > >> ); > >> > >> > >> +#ifdef CONFIG_SCHEDSTATS > > Why not also surround the sched_stat_template too? That also creates > > code even if no event uses it. > Steve, > > Because the sched_stat_template is used by sched_stat_runtime. > The sched_stat_runtime is used event without SCHEDSTATS option enabled. > > And the se.sum_exec_runtime counter is also similar. I don't think this > counter is > defined for SCHEDSTATS. > > Yes. I just try to make our trace points design be similar with SCHEDSTATS > counters > design. > > > -- Steve > > > >> /* > >> * Tracepoint for accounting wait time (time the task is runnable > >> * but not actually running due to scheduler contention). > >> @@ -364,6 +365,7 @@ DEFINE_EVENT(sched_stat_template, sched_stat_iowait, > >> DEFINE_EVENT(sched_stat_template, sched_stat_blocked, > >> TP_PROTO(struct task_struct *tsk, u64 delay), > >> TP_ARGS(tsk, delay)); > >> +#endif > >> > >> /* > >> * Tracepoint for accounting runtime (time the task is executing > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][v5] x86, suspend: Save/restore extra MSR registers for suspend
A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
that, after resumed from S3, CPU is running at a low speed.
After investigation, it is found that, BIOS has modified the value
of THERM_CONTROL register during S3, and changes it from 0 to 0x10
(thus changes the clock modulation from reserved to enabled),
since value of 0x10 means CPU can only get 25% of the Duty Cycle,
this triggers the problem.
Here is a simple scenario to reproduce the issue(only for above case):
1.Boot up the system
2.Get MSR with address 0x19a, it should be 0
3.Put the system into sleep, then wake it up
4.Get MSR with address 0x19a, it should be 0(actually it shows 0x10)
Although this is a BIOS issue, it would be more robust for linux to deal
with this situation. This patch fixes this issue by introducing a framework
to save/restore specified MSR registers(THERM_CONTROL in this case)
for suspend/resume.
When user encounters a problematic platform and needs to protect the
MSRs during suspending, he can simply add a quirk entry in
msr_save_dmi_table, and customizes MSR registers inside the quirk
callback, for example:
u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
and the quirk mechanism ensures that, once resumed from suspended,
the MSRs indicated by these IDs will be restored to their original values
before suspended.
Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
common code path. And because the MSRs specified by the user might not
be available or readable in any situation, we use rdmsrl_safe to safely
save these MSRs.
Tested-by: Marcin Kaszewski
Signed-off-by: Chen Yu
---
v5:
- Rename some structures and variables for better understanding.
Put the defination of struct saved_msr and struct msr_save_data to
header: arch/x86/include/asm/msr.h.
Re-implement the msr_save_context and msr_restore_context for better
maintaining.
Convert the msr_context_array to be dynamically allocated.
Fix some typos in code comments.
v4:
- Revert v3 to v2, and fix some typos in changelog/comments.
Use msr_info structure instead of msr_id + msr_value.
Adjust some codes for better readability.
v3:
- Simplify the patch to only focus on THERM_CONTROL register.
This will make things 'just work'.
v2:
- Cover both 64/32-bit common code path.
Use rdmsrl_safe to safely read MSR.
Introduce a quirk framework for save/restore specified MSR on different
platforms.
---
arch/x86/include/asm/msr.h| 10
arch/x86/include/asm/suspend_32.h | 1 +
arch/x86/include/asm/suspend_64.h | 1 +
arch/x86/power/cpu.c | 98 +++
4 files changed, 110 insertions(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 77d8b28..5ae24ed 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -32,6 +32,16 @@ struct msr_regs_info {
int err;
};
+struct msr_save_data {
+ bool msr_saved;
+ struct msr_info rv;
+};
+
+struct msr_context {
+ unsigned short num;
+ struct msr_save_data *msr_array;
+};
+
static inline unsigned long long native_read_tscp(unsigned int *aux)
{
unsigned long low, high;
diff --git a/arch/x86/include/asm/suspend_32.h
b/arch/x86/include/asm/suspend_32.h
index d1793f0..5057f65 100644
--- a/arch/x86/include/asm/suspend_32.h
+++ b/arch/x86/include/asm/suspend_32.h
@@ -15,6 +15,7 @@ struct saved_context {
unsigned long cr0, cr2, cr3, cr4;
u64 misc_enable;
bool misc_enable_saved;
+ struct msr_context msr_to_save;
struct desc_ptr gdt_desc;
struct desc_ptr idt;
u16 ldt;
diff --git a/arch/x86/include/asm/suspend_64.h
b/arch/x86/include/asm/suspend_64.h
index 7ebf0eb..60941de 100644
--- a/arch/x86/include/asm/suspend_64.h
+++ b/arch/x86/include/asm/suspend_64.h
@@ -24,6 +24,7 @@ struct saved_context {
unsigned long cr0, cr2, cr3, cr4, cr8;
u64 misc_enable;
bool misc_enable_saved;
+ struct msr_context msr_to_save;
unsigned long efer;
u16 gdt_pad; /* Unused */
struct desc_ptr gdt_desc;
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 9ab5279..fd3243a 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_32
__visible unsigned long saved_context_ebx;
@@ -32,6 +33,29 @@ __visible unsigned long saved_context_eflags;
#endif
struct saved_context saved_context;
+static void msr_save_context(struct saved_context *ctxt)
+{
+ struct msr_save_data *msr = ctxt->msr_to_save.msr_array;
+ struct msr_save_data *end = msr + ctxt->msr_to_save.num;
+
+ while (msr < end) {
+ msr->msr_saved = !rdmsrl_safe(msr->rv.msr_no, &msr->rv.reg.q);
+ msr++;
+ }
+}
+
+static void msr_restore_context(struct saved_context *ctxt)
+{
+ struct msr_save_data *msr = ctxt->msr_to_save.msr_array;
+
Re: Updated scalable urandom patchkit
On Sat, Oct 10, 2015 at 10:31:46PM -0400, Theodore Ts'o wrote: > To that end, Andi, can you try benchmarking the scalability of the > patch below? I really hope it will be good enough, since besides > using less memory, there are security advantages in not spreading the > entropy across N pools. Andi, I forgot to menion --- if you could benchmark using both on your "run get_entropy() in a tight loop" and the actual real-life application --- since if is CPU cache behavior is going to be a large factor in the results, a real application is going to be more representative that a micro-benchmark, that would be much appreciated. Thanks! - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
Hi Rafael, thanks for your comment,
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Saturday, October 10, 2015 5:50 AM
> To: Chen, Yu C
> Cc: pa...@ucw.cz; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> b...@alien8.de; Zhang, Rui; linux...@vger.kernel.org; x...@kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for
> suspend
>
> On Thursday, August 27, 2015 11:18:27 AM Chen Yu wrote:
> >
> > +struct msr_type {
>
> I'd call this msr_data.
>
OK, will change its name. But msr_data is already defined
in kvm_host.h , so I changed it to msr_save_data in the new patch version.
> > + bool msr_saved;
> > + struct msr_info rv;
> > +};
> > +
> > +struct saved_msr {
>
> And this msr_context.
>
OK, will do.
> > + unsigned short num;
> > + struct msr_type *msr_array;
> > +};
> > +
> > /* image of the saved processor state */ struct saved_context {
> > u16 es, fs, gs, ss;
> > unsigned long cr0, cr2, cr3, cr4;
> > u64 misc_enable;
> > bool misc_enable_saved;
> > + struct saved_msr msr_for_save;
>
> "msr_to_save"?
>
OK, will change.
> > +struct msr_type {
> > + bool msr_saved;
> > + struct msr_info rv;
> > +};
> > +
> > +struct saved_msr {
> > + unsigned short num;
> > + struct msr_type *msr_array;
> > +};
>
> The definitions look the same as the previous ones.
>
> Can we share them somehow?
>
Yes, I've moved the common code to arch/x86/include/asm/msr.h.
> > +static void msr_save_context(struct saved_context *ctxt) {
> > + int i = 0;
> > +
> > + for (i = 0; i < ctxt->msr_for_save.num; i++) {
> > + struct msr_type *msr = &ctxt->msr_for_save.msr_array[i];
> > +
> > + msr->msr_saved = !rdmsrl_safe(msr->rv.msr_no,
> > + &msr->rv.reg.q);
> > + }
>
> If you did something like
>
> struct msr_type *msr = ctxt->msr_for_save.msr_array;
> struct msr_type *end = msr + ctxt->msr_for_save.num;
>
> while (msr < end) {
> msr->msr_saved = !rdmsrl_safe(msr->rv.msr_no, &msr-
> >rv.reg.q);
> msr++;
> }
>
> here (and analogously below), it would be somewhat easier to follow IMO.
>
OK, changed the code.
> > +/* We constrain the number of MSRs to 64. */
>
> Why 64 in particular?
>
Once I looked up the SDM and estimate that 64 should be enough for some
important
MSR registers.
> > +#define MAX_MSR_SAVED 64
> > +
> > +static struct msr_type msr_context_array[MAX_MSR_SAVED];
>
> I wonder if this array may be allocated dynamically?
>
> We'll waste memory here in the majority of cases.
>
OK, I've changed it to use kmalloc_array for storing.
> > +
> > +/*
> > + * Following section is a quirk framework for problematic BIOS:
>
> "The following ..."
>
OK.
> > + * Sometimes MSRs are modified by BIOS after suspended to
> > + * ram, this might cause unexpected behavior after resumed.
>
> "RAM" (in capitals) and "during resume" or "after wakeup".
>
OK. will do.
> > + * Thus we save/restore these specified MSRs during suspending
> > + * in order to work around it.
> > + * A typical bug is reported at:
> > + * https://bugzilla.redhat.com/show_bug.cgi?id=1227208
> > + */
> > +static int msr_set_info(const u32 *msr_id, const int total_num)
>
> I'd call it "msr_init_context" or something like that.
>
OK, changed it to msr_init_context.
> Thanks,
> Rafael
Best Regards,
Yu
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [patch] sched: disable task group re-weighting on the desktop
On Sun, 2015-10-11 at 07:14 +1100, paul.sz...@sydney.edu.au wrote: > Dear Mike, > > You CCed me on this patch. Is that because you expect this to solve "my" > problem also? You had some measurements of many oinks vs many perts or > vs "desktop", but not many oinks vs 1 or 2 perts as per my "complaint". > You also changed the subject line, so maybe this is all un-related. I haven't seen the problem you reported. I did stumble upon a problem, but turns out that is only present in master, so yes, un-related. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Updated scalable urandom patchkit
On Sat, Oct 10, 2015 at 02:45:46PM -0400, George Spelvin wrote:
> In general, fewer larger pools is better for entropy storage. The only
> reason for the current three-pool design is to achieve strict isolation
> of the /dev/random pool.
You're absolutely right, and I would like to see if we can get away
with keeping with a single pool design. Your idea of using the CPU id
as a nonce is a good one, and I think we can do something similar that
should be good enough for mixing the hash back into the pool. We can
simply use a hash of the CPU id to change the offset where we do the
mixing, and this should be good enough to avoid collisions when we do
the add-back.
HOWEVER. One downside of this approach is that, especially on a NUMA
system, the costs of the cache coherency across a single pool which is
constantly being modified and shared by all of the NUMA nodes could be
a killer, even if we go completely lockless.
To that end, Andi, can you try benchmarking the scalability of the
patch below? I really hope it will be good enough, since besides
using less memory, there are security advantages in not spreading the
entropy across N pools.
If it isn't, we might be able to play a trick where we sample the
r->add_ptr value before we start hashing the pool, and then check to
see if it's changed afterwards. If it has, we could skip doing the
hash back, which could reduce the cache coherency traffic, since as
you point out:
> 2d. A more complete solution involves noting that, if there are multiple
> concurrent readers, only one has to add back its output to prevent
> backtracking, because all of the concurrent reads are equivalent
> in that sense. (Even though, because they're salted with separate
> nonces like the CPU id, they're not identical.)
However, even if we put in that optimization, the primary question is
how good is Intel's cache coherency protocols on their NUMA systems?
I'm pretty sure this would be a disaster on, say, Sequent's old NUMA
machines, but I'm quite confident all of those servers are dead and
buried by now. :-)
- Ted
commit 3cb51896deab45bddc1b8f571b1103eae8f50e0e
Author: Theodore Ts'o
Date: Sat Oct 10 22:03:53 2015 -0400
random: make the reading from the non-blocking pool more scalable
Andi Kleen reported a case where a 4 socket system spent >80% of its
total CPU time contending on the global urandom nonblocking pool
spinlock. While the application could probably have used an own PRNG,
it may have valid reasons to use the best possible key for different
session keys.
Instead of creating separate multiple per-NUMA node non-blocking
pools, use a trick suggested by George Spelvin:
Entropy is a holographic property of the pool, not located in any
particular bit position.
And the most basic operation, of reading from the pool, can easily be
done by multiple readers at the same time from the same bit pattern.
They just need to be salted with distinguishing nonces (CPU IDs will do
nicely) to ensure they all get different results
We use this trick, and in addition use a hash of the cpu id to change
where we mix the hash back into the pool to avoid collisions.
Since we are already using a lockless technique (cmpxchg) to update
the entropy accounting, we don't need to change this around.
This technique won't be quite as scalable since on a NUMA node we will
still be forcing cache lines to bounce around, but from the
perspective of entropy storage we're much better using a single pool
rather than spreading it across multiple pools.
Signed-off-by: Theodore Ts'o
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d0da5d8..be6b315 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -260,6 +260,7 @@
#include
#include
#include
+#include
#include
#include
@@ -494,7 +495,9 @@ static void _mix_pool_bytes(struct entropy_store *r, const
void *in,
{
unsigned long i, tap1, tap2, tap3, tap4, tap5;
int input_rotate;
+ int is_nonblock = (r == &nonblocking_pool);
int wordmask = r->poolinfo->poolwords - 1;
+ int poolbits = r->poolinfo->poolbitshift - 5;
const char *bytes = in;
__u32 w;
@@ -506,6 +509,8 @@ static void _mix_pool_bytes(struct entropy_store *r, const
void *in,
input_rotate = r->input_rotate;
i = r->add_ptr;
+ if (is_nonblock)
+ i += hash_32(get_cpu(), poolbits);
/* mix one byte at a time to simplify size handling and churn faster */
while (nbytes--) {
@@ -534,6 +539,8 @@ static void _mix_pool_bytes(struct entropy_store *r, const
void *in,
r->input_rotate = input_rotate;
r->add_ptr = i;
+ if (is_nonblock)
+ put_cpu();
}
static void __mix_pool_bytes(struct entropy_store *r, const v
RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
Hi, Doug, thanks for your comment, > -Original Message- > From: Doug Smythies [mailto:dsmyth...@telus.net] > Sent: Saturday, October 10, 2015 2:56 AM > To: Chen, Yu C > Cc: Wysocki, Rafael J; t...@linutronix.de; h...@zytor.com; b...@alien8.de; > Zhang, Rui; linux...@vger.kernel.org; x...@kernel.org; linux- > ker...@vger.kernel.org; Brown, Len; 'Ingo Molnar'; 'Pavel Machek'; 'Kristen > Carlson Accardi' > Subject: RE: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for > suspend > > Note: This reply is more for general information than anything else. > > Since Yu's original e-mail I have searched all forums and bug reports that I > would find in an attempt to gain knowledge as to the extent of Clock > Modulation becoming enabled issues. > > It is common, but particularly with some types of Dell LapTops upon resume > from suspend on battery power. > > For the most part, users simply disable the intel_pstate driver, and move on > with their lives using the acpi-cpufreq driver. And once they move on we > never hear from 90% of them again, even though they agree to do more > tests and report back. > > Recall my original reply to this thread, a portion copied below: > > > The current version of the intel_pstate driver is incompatible with > > any use of Clock Modulation, always resulting in driving the target > > pstate to the minimum, regardless of load. The result is the apparent > > CPU frequency stuck at minimum * modulation percent. > > > The acpi-cpufreq driver works fine with Clock Modulation, resulting in > > desired frequency * modulation percent. > [Yu] Why intel_pstate driver is incompatible with Clock Modulation? I search the intel_pstate driver code, but can not find any operation that controls the value of MSR_IA32_THERM_CONTROL(0x19a), but other components such as acpi processor throttling may be involved in. Is there any bugzilla thread tracking this problem? > For the most part users don't even notice the reduced performance (which is > typically 75 or 87.5 percent of normal) when using the acpi-cpufreq driver. > > Yu's specific example is special, because the Clock Modulation percent is > undefined (reserved), and thus clearly unintentional, or just plain wrong if > it > is intentional. > > Other comments in-line below: > > > On 2015.10.07 02:39 Chen, Yu C wrote: > > On 2105.09.17 13:30 Pavel Machek wrote: > >> On Thu 2015-08-27 11:18:27, Chen Yu wrote: > >>> A bug is > >>> reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208) > >>> that, after resumed from S3, CPU is running at a low speed. > >>> After investigation, it is found that, BIOS has modified the value > >>> of THERM_CONTROL register during S3, and changes it from 0 to 0x10, > >>> since value of 0x10 means CPU can only get 25% of the Duty Cycle, > >>> this triggers the problem. > > Note: THERM_CONTROL register = IA32_CLOCK_MODULATION > > I suspect the outcome for an undefined Clock Modulation value of 0 is > processor dependent. For example on my i7-2600K I get 50% duty cycle if I > manually write 0x10 to the register. > BTW, how do you get the number of 50%? > >>> > >>> Here is a simple scenario to reproduce the issue: > >>> 1.Boot up the system > >>> 2.Get MSR with address 0x19a, it should be 0 > > It doesn't have to be, and in some cases I found it isn't, but Clock > Modulation > isn't enabled. > Only bit 4 matters. > You are right, I should add some descriptions that, this situation only makes sense for the case reported at that bugzilla thread. > >>> 3.Put the system into > >>> sleep, then wake it up 4.Get MSR with address 0x19a, it should be > >>> 0(actually it shows 0x10) > > Again, it doesn't have to be 0, only bit 4 matters. > > In the problem cases I found, typically the value is 0x1c or 0x1e, for Clock > Modulation percentages of 75% or 87.5% > > However, thanks very much for the "how to" I used it a lot. > > >>> > >>> Although this is a BIOS issue, > > In your specific case, and since the register value is undefined yes. > In the resume from suspend on battery power case, it might be intentional. > (there has been no response from Dell on the Dell forum where I asked.) > Do you mean, BIOS would modify this value intentionally(before wakeup) if BIOS found the battey power is too low? > >>> it would be more robust for linux to deal with this situation. This > >>> patch fixes this issue by introducing a framework to save/restore > >>> specified MSR registers(THERM_CONTROL in this case) for > >>> suspend/resume. > >>> > >>> When user encounters a problematic platform and needs to protect the > >>> MSRs during suspending, he can simply add a quirk entry in > >>> msr_save_dmi_table, and customizes MSR registers inside the quirk > >>> callback, for example: > > This might be hard to maintain and cause significant delays for actual end > user availability for these battery resume type cases. > > Is there a point to be made here?: Well, I think this is why quirk is
Re: [patch] sched: disable task group re-weighting on the desktop
On Sat, 2015-10-10 at 19:01 +0200, Peter Zijlstra wrote: > But the patch is most horrible.. :/ It completely destroys everything > group scheduling is supposed to be. Yeah, and it works great but... > What are these oink/pert things? Both spinners just with amusing names > to distinguish them? (yeah). > Is the interactivity the same (horrible) at fe32d3cd5e8e (ie, before the > load tracking rewrite from Yuyang)? ...you're right. fe32d3cd5e8e isn't as good as master with a big dent in its skull, but it is far from the ugly beast I clubbed to death. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/media/i2c/adv7604.c:1853:9: error: implicit declaration of function 'v4l2_subdev_get_try_format'
Hi Hans,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4a06c8ac2fb3ef484579ce44f9b809bd310fad48
commit: 85756a069c55e0315ac5990806899cfb607b987f [media] cobalt: add new driver
date: 5 months ago
config: x86_64-randconfig-s5-10110927 (attached as .config)
reproduce:
git checkout 85756a069c55e0315ac5990806899cfb607b987f
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/i2c/adv7604.c: In function 'adv76xx_get_format':
>> drivers/media/i2c/adv7604.c:1853:9: error: implicit declaration of function
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7604.c:1853:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7604.c: In function 'adv76xx_set_format':
drivers/media/i2c/adv7604.c:1882:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
cc1: some warnings being treated as errors
--
drivers/media/i2c/adv7842.c: In function 'adv7842_get_format':
>> drivers/media/i2c/adv7842.c:2093:9: error: implicit declaration of function
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7842.c:2093:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7842.c: In function 'adv7842_set_format':
drivers/media/i2c/adv7842.c:2125:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
cc1: some warnings being treated as errors
--
drivers/media/i2c/adv7511.c: In function 'adv7511_get_fmt':
>> drivers/media/i2c/adv7511.c:859:9: error: implicit declaration of function
>> 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7511.c:859:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
drivers/media/i2c/adv7511.c: In function 'adv7511_set_fmt':
drivers/media/i2c/adv7511.c:910:7: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
^
cc1: some warnings being treated as errors
vim +/v4l2_subdev_get_try_format +1853 drivers/media/i2c/adv7604.c
539b33b0 Laurent Pinchart 2014-01-26 1837 }
539b33b0 Laurent Pinchart 2014-01-26 1838
f7234138 Hans Verkuil 2015-03-04 1839 static int
adv76xx_get_format(struct v4l2_subdev *sd,
f7234138 Hans Verkuil 2015-03-04 1840struct
v4l2_subdev_pad_config *cfg,
539b33b0 Laurent Pinchart 2014-01-26 1841struct
v4l2_subdev_format *format)
539b33b0 Laurent Pinchart 2014-01-26 1842 {
b44b2e06 Pablo Anton 2015-02-03 1843 struct adv76xx_state *state =
to_state(sd);
539b33b0 Laurent Pinchart 2014-01-26 1844
539b33b0 Laurent Pinchart 2014-01-26 1845 if (format->pad !=
state->source_pad)
539b33b0 Laurent Pinchart 2014-01-26 1846 return -EINVAL;
539b33b0 Laurent Pinchart 2014-01-26 1847
b44b2e06 Pablo Anton 2015-02-03 1848 adv76xx_fill_format(state,
&format->format);
539b33b0 Laurent Pinchart 2014-01-26 1849
539b33b0 Laurent Pinchart 2014-01-26 1850 if (format->which ==
V4L2_SUBDEV_FORMAT_TRY) {
539b33b0 Laurent Pinchart 2014-01-26 1851 struct
v4l2_mbus_framefmt *fmt;
539b33b0 Laurent Pinchart 2014-01-26 1852
f7234138 Hans Verkuil 2015-03-04 @1853 fmt =
v4l2_subdev_get_try_format(sd, cfg, format->pad);
539b33b0 Laurent Pinchart 2014-01-26 1854 format->format.code =
fmt->code;
539b33b0 Laurent Pinchart 2014-01-26 1855 } else {
539b33b0 Laurent Pinchart 2014-01-26 1856 format->format.code =
state->format->code;
539b33b0 Laurent Pinchart 2014-01-26 1857 }
539b33b0 Laurent Pinchart 2014-01-26 1858
539b33b0 Laurent Pinchart 2014-01-26 1859 return 0;
539b33b0 Laurent Pinchart 2014-01-26 1860 }
539b33b0 Laurent Pinchart 2014-01-26 1861
:: The code at line 1853 was first introduced by commit
:: f7234138f14c2296c5eb6b8224abe00b507faf3f [media] v4l2-subdev: replace
v4l2_subdev_fh by v4l2_subdev_pad_config
:: TO: Hans Verkuil
:: CC: Mauro Carvalho Chehab
---
[PATCH 2/2] Fixed Trivial Warnings in file: Deleted Spaces prior to tabs, and added lines. modified: kernel/auditfilter.c
Signed-off-by: Scott Matheina
---
kernel/auditfilter.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 7714d93..774f9ad 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -39,13 +39,13 @@
* Locking model:
*
* audit_filter_mutex:
- * Synchronizes writes and blocking reads of audit's filterlist
- * data. Rcu is used to traverse the filterlist and access
- * contents of structs audit_entry, audit_watch and opaque
- * LSM rules during filtering. If modified, these structures
- * must be copied and replace their counterparts in the filterlist.
- * An audit_parent struct is not accessed during filtering, so may
- * be written directly provided audit_filter_mutex is held.
+ * Synchronizes writes and blocking reads of audit's filterlist
+ * data. Rcu is used to traverse the filterlist and access
+ * contents of structs audit_entry, audit_watch and opaque
+ * LSM rules during filtering. If modified, these structures
+ * must be copied and replace their counterparts in the filterlist.
+ * An audit_parent struct is not accessed during filtering, so may
+ * be written directly provided audit_filter_mutex is held.
*/
/* Audit filter lists, defined in */
@@ -109,6 +109,7 @@ void audit_free_rule_rcu(struct rcu_head *head)
{
struct audit_entry *e = container_of(head, struct audit_entry, rcu);
audit_free_rule(e);
+
}
/* Initialize an audit filterlist entry. */
@@ -176,9 +177,11 @@ static __u32 *classes[AUDIT_SYSCALL_CLASSES];
int __init audit_register_class(int class, unsigned *list)
{
__u32 *p = kcalloc(AUDIT_BITMASK_SIZE, sizeof(__u32), GFP_KERNEL);
+
if (!p)
return -ENOMEM;
while (*list != ~0U) {
+
unsigned n = *list++;
if (n >= AUDIT_BITMASK_SIZE * 32 - AUDIT_SYSCALL_CLASSES) {
kfree(p);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] misc: mic: use kstrdup() in cosm_sysfs
On Sat, Oct 10 2015 at 12:14:30 PM, Joe Perches wrote: > On Sat, 2015-10-10 at 04:46 -0700, Geliang Tang wrote: >> Use kstrdup instead of kmalloc and strncpy. > >> diff --git a/drivers/misc/mic/cosm/cosm_sysfs.c >> b/drivers/misc/mic/cosm/cosm_sysfs.c > [] >> @@ -211,18 +211,14 @@ cmdline_store(struct device *dev, struct >> device_attribute *attr, >> mutex_lock(&cdev->cosm_mutex); >> kfree(cdev->cmdline); >> >> -cdev->cmdline = kmalloc(count + 1, GFP_KERNEL); >> +cdev->cmdline = kstrdup(buf, GFP_KERNEL); >> > As count is a function argument, this isn't the same code. > Correct, is this code safe for unterminated strings from user land? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
Hi Punit,
[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
ignore]
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:227:15: sparse: cast to
restricted __le16
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:54: sparse: incorrect
>> type in argument 2 (different base types)
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:54:expected unsigned
char const [usertype] *addr2
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:54:got struct
wlan_bssid_ex network
drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function
'r871x_get_ap_info':
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:32: error: incompatible
type for argument 2 of 'ether_addr_equal'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
In file included from drivers/staging/rtl8712/osdep_service.h:39:0,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
include/linux/etherdevice.h:310:20: note: expected 'const u8 * {aka const
unsigned char *}' but argument is of type 'struct wlan_bssid_ex'
static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
^
vim +2010 drivers/staging/rtl8712/rtl871x_ioctl_linux.c
1994 return -EINVAL;
1995 spin_lock_irqsave(&(pmlmepriv->scanned_queue.lock), irqL);
1996 phead = &queue->queue;
1997 plist = phead->next;
1998 while (1) {
1999 if (end_of_queue_search(phead, plist) == true)
2000 break;
2001 pnetwork = LIST_CONTAINOR(plist, struct wlan_network,
list);
2002 if (hwaddr_aton_i(data, bssid)) {
2003 netdev_info(dev, "r8712u: Invalid BSSID
'%s'.\n",
2004 (u8 *)data);
2005
spin_unlock_irqrestore(&(pmlmepriv->scanned_queue.lock),
2006 irqL);
2007 return -EINVAL;
2008 }
2009 netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
> 2010 if (!ether_addr_equal(bssid, pnetwork->network)) {
2011 /* BSSID match, then check if supporting
wpa/wpa2 */
2012 pbuf =
r8712_get_wpa_ie(&pnetwork->network.IEs[12],
2013 &wpa_ielen,
pnetwork->network.IELength-12);
2014 if (pbuf && (wpa_ielen > 0)) {
2015 pdata->flags = 1;
2016 break;
2017 }
2018 pbuf =
r8712_get_wpa2_ie(&pnetwork->network.IEs[12],
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] tty: core: Use correct spinlock flavor in tiocspgrp()
tiocspgrp() is the ioctl handler for TIOCSPGRP, which runs in non-atomic context; use spin_lock/unlock_irq (since interrupt state is on). Signed-off-by: Peter Hurley --- drivers/tty/tty_io.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index eb210d7..bf404cd 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -2548,7 +2548,6 @@ static int tiocspgrp(struct tty_struct *tty, struct tty_struct *real_tty, pid_t struct pid *pgrp; pid_t pgrp_nr; int retval = tty_check_change(real_tty); - unsigned long flags; if (retval == -EIO) return -ENOTTY; @@ -2571,10 +2570,10 @@ static int tiocspgrp(struct tty_struct *tty, struct tty_struct *real_tty, pid_t if (session_of_pgrp(pgrp) != task_session(current)) goto out_unlock; retval = 0; - spin_lock_irqsave(&tty->ctrl_lock, flags); + spin_lock_irq(&tty->ctrl_lock); put_pid(real_tty->pgrp); real_tty->pgrp = get_pid(pgrp); - spin_unlock_irqrestore(&tty->ctrl_lock, flags); + spin_unlock_irq(&tty->ctrl_lock); out_unlock: rcu_read_unlock(); return retval; -- 2.6.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 3/3] tty: Prevent tty teardown during tty_write_message()
tty_write_message() allows the caller to directly write to a specific
tty. Since the line discipline is bypassed for the direct write,
nothing prevents the tty from being torn down after the tty count is
checked.
Hold the tty lock for the duration of the direct write.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index bf404cd..4530993 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1200,11 +1200,9 @@ void tty_write_message(struct tty_struct *tty, char *msg)
if (tty) {
mutex_lock(&tty->atomic_write_lock);
tty_lock(tty);
- if (tty->ops->write && tty->count > 0) {
- tty_unlock(tty);
+ if (tty->ops->write && tty->count > 0)
tty->ops->write(tty, msg, strlen(msg));
- } else
- tty_unlock(tty);
+ tty_unlock(tty);
tty_write_unlock(tty);
}
return;
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] tty: Combine SIGTTOU/SIGTTIN handling
The job_control() check in n_tty_read() has nearly identical purpose
and results as tty_check_change(). Both functions' purpose is to
determine if the current task's pgrp is the foreground pgrp for the tty,
and if not, to signal the current pgrp.
Introduce __tty_check_change() which takes the signal to send
and performs the shared operations for job control() and
tty_check_change().
Signed-off-by: Peter Hurley
---
drivers/tty/n_tty.c | 26 ++
drivers/tty/tty_io.c | 46 --
include/linux/tty.h | 1 +
3 files changed, 27 insertions(+), 46 deletions(-)
diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 20932cc..bd383c4 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2147,37 +2147,15 @@ extern ssize_t redirected_tty_write(struct file *,
const char __user *,
static int job_control(struct tty_struct *tty, struct file *file)
{
- struct pid *pgrp;
-
/* Job control check -- must be done at start and after
every sleep (POSIX.1 7.1.1.4). */
/* NOTE: not yet done after every sleep pending a thorough
check of the logic of this change. -- jlc */
/* don't stop on /dev/console */
- if (file->f_op->write == redirected_tty_write ||
- current->signal->tty != tty)
+ if (file->f_op->write == redirected_tty_write)
return 0;
- rcu_read_lock();
- pgrp = task_pgrp(current);
-
- spin_lock_irq(&tty->ctrl_lock);
- if (!tty->pgrp)
- printk(KERN_ERR "n_tty_read: no tty->pgrp!\n");
- else if (pgrp != tty->pgrp) {
- spin_unlock_irq(&tty->ctrl_lock);
- if (is_ignored(SIGTTIN) || is_current_pgrp_orphaned()) {
- rcu_read_unlock();
- return -EIO;
- }
- kill_pgrp(pgrp, SIGTTIN, 1);
- rcu_read_unlock();
- set_thread_flag(TIF_SIGPENDING);
- return -ERESTARTSYS;
- }
- spin_unlock_irq(&tty->ctrl_lock);
- rcu_read_unlock();
- return 0;
+ return __tty_check_change(tty, SIGTTIN);
}
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 02785d8..eb210d7 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -390,10 +390,10 @@ EXPORT_SYMBOL_GPL(tty_find_polling_driver);
* Locking: ctrl_lock
*/
-int tty_check_change(struct tty_struct *tty)
+int __tty_check_change(struct tty_struct *tty, int sig)
{
unsigned long flags;
- struct pid *pgrp;
+ struct pid *pgrp, *tty_pgrp;
int ret = 0;
if (current->signal->tty != tty)
@@ -403,33 +403,35 @@ int tty_check_change(struct tty_struct *tty)
pgrp = task_pgrp(current);
spin_lock_irqsave(&tty->ctrl_lock, flags);
-
- if (!tty->pgrp) {
- printk(KERN_WARNING "tty_check_change: tty->pgrp == NULL!\n");
- goto out_unlock;
- }
- if (pgrp == tty->pgrp)
- goto out_unlock;
+ tty_pgrp = tty->pgrp;
spin_unlock_irqrestore(&tty->ctrl_lock, flags);
- if (is_ignored(SIGTTOU))
- goto out_rcuunlock;
- if (is_current_pgrp_orphaned()) {
- ret = -EIO;
- goto out_rcuunlock;
+ if (tty_pgrp && pgrp != tty->pgrp) {
+ if (is_ignored(sig)) {
+ if (sig == SIGTTIN)
+ ret = -EIO;
+ } else if (is_current_pgrp_orphaned())
+ ret = -EIO;
+ else {
+ kill_pgrp(pgrp, sig, 1);
+ set_thread_flag(TIF_SIGPENDING);
+ ret = -ERESTARTSYS;
+ }
}
- kill_pgrp(pgrp, SIGTTOU, 1);
- rcu_read_unlock();
- set_thread_flag(TIF_SIGPENDING);
- ret = -ERESTARTSYS;
- return ret;
-out_unlock:
- spin_unlock_irqrestore(&tty->ctrl_lock, flags);
-out_rcuunlock:
rcu_read_unlock();
+
+ if (!tty_pgrp) {
+ pr_warn("%s: tty_check_change: sig=%d, tty->pgrp == NULL!\n",
+ tty_name(tty), sig);
+ }
+
return ret;
}
+int tty_check_change(struct tty_struct *tty)
+{
+ return __tty_check_change(tty, SIGTTOU);
+}
EXPORT_SYMBOL(tty_check_change);
static ssize_t hung_up_tty_read(struct file *file, char __user *buf,
diff --git a/include/linux/tty.h b/include/linux/tty.h
index c2889f4..533d7f6 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -423,6 +423,7 @@ extern int tty_paranoia_check(struct tty_struct *tty,
struct inode *inode,
const char *routine);
extern const char *tty_name(const struct tty_struct *tty);
extern void tty_wait_until_sent(struct tty_struct *tty, long timeout);
+extern int __tty_check_change(struct tty_struct *tty, int sig);
extern int tty_check_change(struct tty_struct *tty);
extern void __sto
[PATCHv5] staging: vme_user: provide DMA functionality
This introduces a new dma device that provides a single ioctl call that
provides DMA read and write functionality to the user space.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
In the last reply Martyn suggested a rework of this to make it use existing
bus/vme/ctl instead of creating a new bus/vme/dma%i device and also dynamically
allocate a dma resource in each request.
I think this doesn't need those adjustments. I think that dynamic allocation
doesn't solve any practical problem that isn't caused by current kernel api.
I also think that separate device is a good feature because it allows for
discovery of dma capatibility from userspace. The interface with separate
chardev also allows to provide DMA read() and write() syscalls that can
come handy in pair with /bin/dd.
v5:
Added a validation for dma_op argument in vme_user_sg_to_dma_list(). It is
already checked in caller but we would like to silence a warning:
drivers/staging/vme/devices/vme_user.c: In function 'vme_user_ioctl.isra.4':
>> drivers/staging/vme/devices/vme_user.c:324:7: warning: 'dest' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:52: note: 'dest' was declared here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
^
>> drivers/staging/vme/devices/vme_user.c:324:7: warning: 'src' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:46: note: 'src' was declared here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
---
drivers/staging/vme/devices/vme_user.c | 205 -
drivers/staging/vme/devices/vme_user.h | 11 ++
2 files changed, 213 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 8e61a3b..2434e5f 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -79,15 +79,18 @@ static unsigned int bus_num;
* We shall support 4 masters and 4 slaves with this driver.
*/
#define VME_MAJOR 221 /* VME Major Device Number */
-#define VME_DEVS 9 /* Number of dev entries */
+#define VME_DEVS 10 /* Number of dev entries */
#define MASTER_MINOR 0
#define MASTER_MAX 3
#define SLAVE_MINOR4
#define SLAVE_MAX 7
#define CONTROL_MINOR 8
+#define DMA_MINOR 9
-#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+
+#define VME_MAX_DMA_LEN0x400 /* Maximal DMA transfer length
*/
/*
* Structure to handle image related parameters.
@@ -112,7 +115,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
MASTER_MINOR, MASTER_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
- CONTROL_MINOR
+ CONTROL_MINOR, DMA_MINOR
};
struct vme_user_vma_priv {
@@ -281,6 +284,172 @@ static loff_t vme_user_llseek(struct file *file, loff_t
off, int whence)
return -EINVAL;
}
+static int vme_user_sg_to_dma_list(const struct vme_dma_op *dma_op,
+ struct sg_table *sgt,
+ int sg_count, struct vme_dma_list *dma_list)
+{
+ ssize_t pos = 0;
+ struct scatterlist *sg;
+ int i, ret;
+
+ if ((dma_op->dir != VME_DMA_MEM_TO_VME) &&
+ (dma_op->dir != VME_DMA_VME_TO_MEM))
+ return -EINVAL;
+
+ for_each_sg(sgt->sgl, sg, sg_count, i) {
+ struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
+ dma_addr_t hw_address = sg_dma_address(sg);
+ unsigned int hw_len = sg_dma_len(sg);
+
+ vme_attr = vme_dma_vme_attribute(dma_op->vme_addr + pos,
+dma_op->aspace,
+dma_op->cycle,
+dma_op->dwidth);
+ if (!vme_attr)
+ return -ENOMEM;
+
+ pci_attr = vme_dma_pci_attribute(hw_address);
+ if (!pci_attr) {
+
[PATCH] Style Error line 1: Deleted trailing space
>From 06fabebf521e29014fd59518c923d671e6df0fce Mon Sep 17 00:00:00 2001 From: Scott Matheina Date: Sat, 10 Oct 2015 16:05:51 -0500 Subject: [PATCH] Style Error line 1: Deleted trailing space This is a simple patch to line 1 of kernel/audit.h, deleting a trailing space to remove a style error. modified: kernel/audit.h --- kernel/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit.h b/kernel/audit.h index dadf86a..dd4d4d8 100644 --- a/kernel/audit.h +++ b/kernel/audit.h @@ -1,4 +1,4 @@ -/* audit -- definition of audit_context structure and supporting types +/* audit -- definition of audit_context structure and supporting types * * Copyright 2003-2004 Red Hat, Inc. * Copyright 2005 Hewlett-Packard Development Company, L.P. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
Hi Punit,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: x86_64-randconfig-x005-201541 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
In file included from include/linux/linkage.h:4:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from drivers/staging/rtl8712/osdep_service.h:32,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function
'r871x_get_ap_info':
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:32: error: incompatible
>> type for argument 2 of 'ether_addr_equal'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
if (__builtin_constant_p((cond)) ? !!(cond) : \
^
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:3: note: in expansion of
>> macro 'if'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
In file included from drivers/staging/rtl8712/osdep_service.h:39:0,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
include/linux/etherdevice.h:310:20: note: expected 'const u8 * {aka const
unsigned char *}' but argument is of type 'struct wlan_bssid_ex'
static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
^
In file included from include/linux/linkage.h:4:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from drivers/staging/rtl8712/osdep_service.h:32,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:32: error: incompatible
>> type for argument 2 of 'ether_addr_equal'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
include/linux/compiler.h:147:40: note: in definition of macro '__trace_if'
if (__builtin_constant_p((cond)) ? !!(cond) : \
^
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:3: note: in expansion of
>> macro 'if'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
In file included from drivers/staging/rtl8712/osdep_service.h:39:0,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
include/linux/etherdevice.h:310:20: note: expected 'const u8 * {aka const
unsigned char *}' but argument is of type 'struct wlan_bssid_ex'
static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
^
In file included from include/linux/linkage.h:4:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from drivers/staging/rtl8712/osdep_service.h:32,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:32: error: incompatible
>> type for argument 2 of 'ether_addr_equal'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
include/linux/compiler.h:158:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:2010:3: note: in expansion of
>> macro 'if'
if (!ether_addr_equal(bssid, pnetwork->network)) {
^
In file included from drivers/staging/rtl8712/osdep_service.h:39:0,
from drivers/staging/rtl8712/rtl871x_ioctl_linux.c:32:
include/linux/etherdevice.h:310:20: note: expected 'const u8 * {aka const
unsigned char *}' but argument is of type 'struct wlan_bssid_ex'
static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
^
vim +/ether_addr_equal +2010 drivers/staging/rtl8712/rtl871x_ioctl_linux.c
2004 (u8 *)data);
2005
spin_unlock_irqrestore(&(pmlmepriv->scanned_queue.lock),
2006 irqL);
2007 return -EINVAL;
2008 }
2009 netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
> 2010 if (!ether_addr_equal(bssid, pnetwork->network)) {
2011 /* BSSID match, then check if supporting
wpa/wpa2 */
2012 pbuf =
r8712_get_wpa_ie(&pnetwork->network.IEs[12],
2013 &wpa_ielen,
pnetwork->network.IELength-12);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Des
Re: [PATCHv4 RESEND] staging: vme_user: provide DMA functionality
Hi Dmitry,
[auto build test WARNING on driver-core/driver-core-next -- if it's
inappropriate base, please ignore]
config: x86_64-randconfig-x010-201541 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/staging/vme/devices/vme_user.c: In function 'vme_user_ioctl.isra.4':
>> drivers/staging/vme/devices/vme_user.c:324:7: warning: 'dest' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:52: note: 'dest' was declared here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
^
>> drivers/staging/vme/devices/vme_user.c:324:7: warning: 'src' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
ret = vme_dma_list_add(dma_list, src, dest, hw_len);
^
drivers/staging/vme/devices/vme_user.c:296:46: note: 'src' was declared here
struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
^
vim +/dest +324 drivers/staging/vme/devices/vme_user.c
308 if (!pci_attr) {
309 vme_dma_free_attribute(vme_attr);
310 return -ENOMEM;
311 }
312
313 switch (dma_op->dir) {
314 case VME_DMA_MEM_TO_VME:
315 src = pci_attr;
316 dest = vme_attr;
317 break;
318 case VME_DMA_VME_TO_MEM:
319 src = vme_attr;
320 dest = pci_attr;
321 break;
322 }
323
> 324 ret = vme_dma_list_add(dma_list, src, dest, hw_len);
325
326 /*
327 * XXX VME API doesn't mention whether we should keep
328 * attributes around
329 */
330 vme_dma_free_attribute(vme_attr);
331 vme_dma_free_attribute(pci_attr);
332
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH] nouveau: fix OpenFirmware support
On Sat, Oct 10, 2015 at 7:45 PM, Laurent Vivier wrote: > > > Le 10/10/2015 21:56, Ilia Mirkin a écrit : >> On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier wrote: >>> >>> >>> Le 10/10/2015 20:41, Ilia Mirkin a écrit : Hi Laurent, On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: > On PowerMac G5 (and I think on all OpenFirmware platforms), > nvbios_pcirTp() > returns NULL. But in fact the OpenFirmware has given us the size > we can store in image->size. > > This size is stored in bios->size by of_init() as there is no way > to retrieve it otherwise. And as we know the size, copy all data > to bios->data. > > Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). Can you give this patch a shot instead? http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63cc75eada9ad6b2a0275c1c8c4d3522864f >>> >>> Well, I think mine is also a good solution and it is much more simple. >>> ;) >>> >>> ... because it is useless to add a size() function if we can directly >>> copy the content/size of the bios in bios->data and bios->size. >>> We can do that because we have the size of the property, which is not >>> the case when we discover the BIOS directly from a PCI ROM or from ACPI >>> (this is why we need a shadow, I think). >> >> I'll let Ben rule on this. >> >>> >>> For pcir part, I think we can just ignore the result and take the size >>> from bios->size, as in the case of non openfirmware bios->size will be 4 >>> (we have only shadowed the first word to read the id, 0xaa55) and then >>> the checksum and others ID searches will fail. So I think the checksum >>> should not be ignored. >> >> Non-OF will still end up with a NVDA,BMP file? That seems surprising. >> My understanding is that if OF has it, it should be used. The problem >> is that e.g. on my GPU I have a perfectly valid PCI ROM, whose >> checksum matches and everything, but it contains who-knows-what apple >> happened to leave in there. So I still want OF. Ignoring checksum >> failures allows nouveau to always select the OF vbios. >> >>> >>> I've tried to restore behavior before commit: >>> >>> 7af4dec drm/nouveau/bios: use size/type from pci data structure >>> >>> and commit: >>> >>> ad4a362 drm/nouveau/bios: split out shadow methods >>> >>> Originally, openfirmware content was copied directly into bios->data: >> >> Yeah, but then the whole interface was redone. >> >>> >>> 77145f1 drm/nouveau: port remainder of drm code, and rip out compat layer >>> This resolved my issues on a PPC G5 + NV34. I think mine ran into a few additional problems that you didn't see -- no PCIR header and invalid checksum. >>> >>> I have no PCIR header too. >> >> Er right. I realized that shortly after I sent the email. However my >> bios isn't even 0x1000 in size, so the read would fail due to not >> enough length. (It's also an odd number in size, and your patch chops >> off the last few bytes.) The read could, of course, be reduced in >> size, but that whole logic is to deal with multiple parts in a vbios, >> which on GM20x contain some necessary blobs. I wasn't sure where the >> 0x1000 came from or whether it was significant. >> >>> >>> Could you send me the content of the file "NVDA,BMP" you can find >>> somewhere under /proc/device-tree/ ? >> >> http://filebin.ca/2Ib4SdDOAQqC/nv34-vbios.rom >> >> Note that it's a 2404 byte file as uploaded, but that was from an >> attempt to do something silly -- in reality it's 2403 bytes. >> >>> >>> Could you try my patch on your system, please ? >> >> My G5 is off for now, and the time I do spend with it goes towards >> working out mesa issues (it should kinda-sorta work with Mesa 11.0.3 >> again btw). If I have time, I'll try it out. > > I've checked on my second PowerMac G5 which seems to be the same as > yours (PowerMac7,3). > > It doesn't work but not because of the checksum: > > [ 140.410535] nouveau :f0:10.0: NVIDIA NV34 (034100a2) > [ 140.476781] nouveau :f0:10.0: bios: version 04.34.20.19.00 > [ 140.476993] nouveau :f0:10.0: bios: DCB table not found > [ 140.477186] nouveau :f0:10.0: bios: DCB table not found > [ 140.477283] nouveau :f0:10.0: bios: DCB table not found > [ 140.477289] nouveau :f0:10.0: bios: DCB table not found > [ 140.477664] nouveau :f0:10.0: bios: DCB table not found > [ 140.480949] nouveau :f0:10.0: devinit: 0x1a08[ ]: unknown opcode 0x10 > [ 140.480962] nouveau :f0:10.0: preinit failed with -22 > [ 140.480978] nouveau: DRM::0080: init failed with -22 > [ 140.487980] nouveau: probe of :f0:10.0 failed with error -22 > Because the checksum fails on OF but passes on the PCI ROM. But the PCI ROM contains silliness (in fact I'm fairly sure we should just remove that method, it never provides anything useful) which passes the checksum test. Try it with my patch from Ben's tree. -ilia -- To unsubscribe from this list: send the lin
Re: [PATCH] nouveau: fix OpenFirmware support
Le 10/10/2015 21:56, Ilia Mirkin a écrit : > On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier wrote: >> >> >> Le 10/10/2015 20:41, Ilia Mirkin a écrit : >>> Hi Laurent, >>> >>> On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() returns NULL. But in fact the OpenFirmware has given us the size we can store in image->size. This size is stored in bios->size by of_init() as there is no way to retrieve it otherwise. And as we know the size, copy all data to bios->data. Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). >>> >>> Can you give this patch a shot instead? >>> >>> http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63cc75eada9ad6b2a0275c1c8c4d3522864f >> >> Well, I think mine is also a good solution and it is much more simple. >> ;) >> >> ... because it is useless to add a size() function if we can directly >> copy the content/size of the bios in bios->data and bios->size. >> We can do that because we have the size of the property, which is not >> the case when we discover the BIOS directly from a PCI ROM or from ACPI >> (this is why we need a shadow, I think). > > I'll let Ben rule on this. > >> >> For pcir part, I think we can just ignore the result and take the size >> from bios->size, as in the case of non openfirmware bios->size will be 4 >> (we have only shadowed the first word to read the id, 0xaa55) and then >> the checksum and others ID searches will fail. So I think the checksum >> should not be ignored. > > Non-OF will still end up with a NVDA,BMP file? That seems surprising. > My understanding is that if OF has it, it should be used. The problem > is that e.g. on my GPU I have a perfectly valid PCI ROM, whose > checksum matches and everything, but it contains who-knows-what apple > happened to leave in there. So I still want OF. Ignoring checksum > failures allows nouveau to always select the OF vbios. > >> >> I've tried to restore behavior before commit: >> >> 7af4dec drm/nouveau/bios: use size/type from pci data structure >> >> and commit: >> >> ad4a362 drm/nouveau/bios: split out shadow methods >> >> Originally, openfirmware content was copied directly into bios->data: > > Yeah, but then the whole interface was redone. > >> >> 77145f1 drm/nouveau: port remainder of drm code, and rip out compat layer >> >>> This resolved my issues on a PPC G5 + NV34. I think mine ran into a >>> few additional problems that you didn't see -- no PCIR header and >>> invalid checksum. >> >> I have no PCIR header too. > > Er right. I realized that shortly after I sent the email. However my > bios isn't even 0x1000 in size, so the read would fail due to not > enough length. (It's also an odd number in size, and your patch chops > off the last few bytes.) The read could, of course, be reduced in > size, but that whole logic is to deal with multiple parts in a vbios, > which on GM20x contain some necessary blobs. I wasn't sure where the > 0x1000 came from or whether it was significant. > >> >> Could you send me the content of the file "NVDA,BMP" you can find >> somewhere under /proc/device-tree/ ? > > http://filebin.ca/2Ib4SdDOAQqC/nv34-vbios.rom > > Note that it's a 2404 byte file as uploaded, but that was from an > attempt to do something silly -- in reality it's 2403 bytes. > >> >> Could you try my patch on your system, please ? > > My G5 is off for now, and the time I do spend with it goes towards > working out mesa issues (it should kinda-sorta work with Mesa 11.0.3 > again btw). If I have time, I'll try it out. I've checked on my second PowerMac G5 which seems to be the same as yours (PowerMac7,3). It doesn't work but not because of the checksum: [ 140.410535] nouveau :f0:10.0: NVIDIA NV34 (034100a2) [ 140.476781] nouveau :f0:10.0: bios: version 04.34.20.19.00 [ 140.476993] nouveau :f0:10.0: bios: DCB table not found [ 140.477186] nouveau :f0:10.0: bios: DCB table not found [ 140.477283] nouveau :f0:10.0: bios: DCB table not found [ 140.477289] nouveau :f0:10.0: bios: DCB table not found [ 140.477664] nouveau :f0:10.0: bios: DCB table not found [ 140.480949] nouveau :f0:10.0: devinit: 0x1a08[ ]: unknown opcode 0x10 [ 140.480962] nouveau :f0:10.0: preinit failed with -22 [ 140.480978] nouveau: DRM::0080: init failed with -22 [ 140.487980] nouveau: probe of :f0:10.0 failed with error -22 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: [PATCH net-next 3/6] net: remove dsa.h include from linux/netdevice.h
Hi Vivien,
[auto build test ERROR on net-next/master -- if it's inappropriate base, please
ignore]
config: x86_64-randconfig-n0-10110700 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/usb/lan78xx.c: In function 'lan78xx_link_reset':
>> drivers/net/usb/lan78xx.c:841:8: error: implicit declaration of function
>> 'phy_read' [-Werror=implicit-function-declaration]
ret = phy_read(phydev, LAN88XX_INT_STS);
^
>> drivers/net/usb/lan78xx.c:850:2: error: implicit declaration of function
>> 'phy_read_status' [-Werror=implicit-function-declaration]
phy_read_status(phydev);
^
>> drivers/net/usb/lan78xx.c:852:13: error: dereferencing pointer to incomplete
>> type 'struct phy_device'
if (!phydev->link && dev->link_on) {
^
>> drivers/net/usb/lan78xx.c:867:3: error: implicit declaration of function
>> 'phy_ethtool_gset' [-Werror=implicit-function-declaration]
phy_ethtool_gset(phydev, &ecmd);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_set_wol':
>> drivers/net/usb/lan78xx.c:1067:2: error: implicit declaration of function
>> 'phy_ethtool_set_wol' [-Werror=implicit-function-declaration]
phy_ethtool_set_wol(netdev->phydev, wol);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_get_eee':
>> drivers/net/usb/lan78xx.c:1085:8: error: implicit declaration of function
>> 'phy_ethtool_get_eee' [-Werror=implicit-function-declaration]
ret = phy_ethtool_get_eee(phydev, edata);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_set_eee':
>> drivers/net/usb/lan78xx.c:1127:3: error: implicit declaration of function
>> 'phy_ethtool_set_eee' [-Werror=implicit-function-declaration]
phy_ethtool_set_eee(net->phydev, edata);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_nway_reset':
>> drivers/net/usb/lan78xx.c:1151:9: error: implicit declaration of function
>> 'phy_start_aneg' [-Werror=implicit-function-declaration]
return phy_start_aneg(net->phydev);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_get_mdix_status':
>> drivers/net/usb/lan78xx.c:1183:2: error: implicit declaration of function
>> 'phy_write' [-Werror=implicit-function-declaration]
phy_write(phydev, LAN88XX_EXT_PAGE_ACCESS, LAN88XX_EXT_PAGE_SPACE_1);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_set_settings':
>> drivers/net/usb/lan78xx.c:1275:8: error: implicit declaration of function
>> 'phy_ethtool_sset' [-Werror=implicit-function-declaration]
ret = phy_ethtool_sset(phydev, cmd);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_ioctl':
>> drivers/net/usb/lan78xx.c:1315:9: error: implicit declaration of function
>> 'phy_mii_ioctl' [-Werror=implicit-function-declaration]
return phy_mii_ioctl(netdev->phydev, rq, cmd);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_mdiobus_read':
>> drivers/net/usb/lan78xx.c:1374:31: error: dereferencing pointer to
>> incomplete type 'struct mii_bus'
struct lan78xx_net *dev = bus->priv;
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_mdio_init':
>> drivers/net/usb/lan78xx.c:1447:17: error: implicit declaration of function
>> 'mdiobus_alloc' [-Werror=implicit-function-declaration]
dev->mdiobus = mdiobus_alloc();
^
drivers/net/usb/lan78xx.c:1447:15: warning: assignment makes pointer from
integer without a cast [-Wint-conversion]
dev->mdiobus = mdiobus_alloc();
^
>> drivers/net/usb/lan78xx.c:1458:29: error: 'MII_BUS_ID_SIZE' undeclared
>> (first use in this function)
snprintf(dev->mdiobus->id, MII_BUS_ID_SIZE, "usb-%03d:%03d",
^
drivers/net/usb/lan78xx.c:1458:29: note: each undeclared identifier is
reported only once for each function it appears in
>> drivers/net/usb/lan78xx.c:1461:44: error: 'PHY_MAX_ADDR' undeclared (first
>> use in this function)
dev->mdiobus->irq = kzalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
^
>> drivers/net/usb/lan78xx.c:1469:26: error: 'PHY_IGNORE_INTERRUPT' undeclared
>> (first use in this function)
dev->mdiobus->irq[i] = PHY_IGNORE_INTERRUPT;
^
>> drivers/net/usb/lan78xx.c:1479:8: error: implicit declaration of function
>> 'mdiobus_register' [-Werror=implicit-function-declaration]
ret = mdiobus_register(dev->mdiobus);
^
>> drivers/net/usb/lan78xx.c:1490:2: error: implicit declaration of function
>> 'mdiobus_free' [-Werror=implicit-function-declaration]
mdiobus_free(dev->mdiobus);
^
drivers/net/usb/lan78xx.c: In function 'lan78xx_remove_mdio':
>> drivers/net/usb/lan78xx.c:1496:2: error: implicit declaration of function
>> 'mdiobus_unregister' [-Werror=implicit-function-declaration]
mdiobus_unregister(dev->mdiobus);
^
drive
Re: [PATCH v8 2/9] Input: goodix - reset device at init
Hi Irina,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: x86_64-randconfig-h0-10110617 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/input/touchscreen/goodix.c: In function 'goodix_int_sync':
>> drivers/input/touchscreen/goodix.c:250:10: error: implicit declaration of
>> function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
error = gpiod_direction_output(ts->gpiod_int, 0);
^
>> drivers/input/touchscreen/goodix.c:255:9: error: implicit declaration of
>> function 'gpiod_direction_input' [-Werror=implicit-function-declaration]
return gpiod_direction_input(ts->gpiod_int);
^
drivers/input/touchscreen/goodix.c: In function 'goodix_get_gpio_config':
>> drivers/input/touchscreen/goodix.c:304:10: error: implicit declaration of
>> function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN);
^
>> drivers/input/touchscreen/goodix.c:304:52: error: 'GPIOD_IN' undeclared
>> (first use in this function)
gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN);
^
drivers/input/touchscreen/goodix.c:304:52: note: each undeclared identifier
is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/gpiod_direction_output +250 drivers/input/touchscreen/goodix.c
244 }
245
246 static int goodix_int_sync(struct goodix_ts_data *ts)
247 {
248 int error;
249
> 250 error = gpiod_direction_output(ts->gpiod_int, 0);
251 if (error)
252 return error;
253 msleep(50); /* T5: 50ms */
254
> 255 return gpiod_direction_input(ts->gpiod_int);
256 }
257
258 /**
259 * goodix_reset - Reset device during power on
260 *
261 * @ts: goodix_ts_data pointer
262 */
263 static int goodix_reset(struct goodix_ts_data *ts)
264 {
265 int error;
266
267 /* begin select I2C slave addr */
268 error = gpiod_direction_output(ts->gpiod_rst, 0);
269 if (error)
270 return error;
271 msleep(20); /* T2: > 10ms */
272 /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */
273 error = gpiod_direction_output(ts->gpiod_int, ts->client->addr
== 0x14);
274 if (error)
275 return error;
276 usleep_range(100, 2000);/* T3: > 100us */
277 error = gpiod_direction_output(ts->gpiod_rst, 1);
278 if (error)
279 return error;
280 usleep_range(6000, 1); /* T4: > 5ms */
281 /* end select I2C slave addr */
282 error = gpiod_direction_input(ts->gpiod_rst);
283 if (error)
284 return error;
285 return goodix_int_sync(ts);
286 }
287
288 /**
289 * goodix_get_gpio_config - Get GPIO config from ACPI/DT
290 *
291 * @ts: goodix_ts_data pointer
292 */
293 static int goodix_get_gpio_config(struct goodix_ts_data *ts)
294 {
295 int error;
296 struct device *dev;
297 struct gpio_desc *gpiod;
298
299 if (!ts->client)
300 return -EINVAL;
301 dev = &ts->client->dev;
302
303 /* Get the interrupt GPIO pin number */
> 304 gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN);
305 if (IS_ERR(gpiod)) {
306 error = PTR_ERR(gpiod);
307 if (error != -EPROBE_DEFER)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 1/5] perf: unwind: fix unw_word_t pointer casts
Em Sat, Oct 10, 2015 at 05:49:40PM +0200, Rabin Vincent escreveu:
> Hi Arnaldo,
>
> Do you have any comments on this patch set?
I looked at the patches now, all seem fine from a quick look.
The last patch is interesting, and a more general way of installing what
is required for a full build using the native method for a distro, i.e.
using yum/dnf/apt/etc would come in handy as well, so that it doesn't
look like we recommend this fetch-the-sources-and-build-it method, but
sure, that can come later, when someone steps up to that work.
Since this touches the build system and libunwind, areas that Jiri
wrote/knows better, I'd like to get his ack, Jiri?
- Arnaldo
> Thanks.
>
> On Sun, Sep 27, 2015 at 08:37:55PM +0200, Rabin Vincent wrote:
> > unw_word_t is uint64_t even on 32-bit MIPS. Cast it to uintptr_t before
> > the cast to void *p to get rid of the following errors:
> >
> > util/unwind-libunwind.c: In function 'access_mem':
> > util/unwind-libunwind.c:464:4: error: cast to pointer from integer of
> > different size [-Werror=int-to-pointer-cast]
> > util/unwind-libunwind.c:475:2: error: cast to pointer from integer of
> > different size [-Werror=int-to-pointer-cast]
> > cc1: all warnings being treated as errors
> > make[3]: *** [util/unwind-libunwind.o] Error 1
> >
> > Signed-off-by: Rabin Vincent
> > ---
> > tools/perf/util/unwind-libunwind.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/perf/util/unwind-libunwind.c
> > b/tools/perf/util/unwind-libunwind.c
> > index 4c00507..ef799dc 100644
> > --- a/tools/perf/util/unwind-libunwind.c
> > +++ b/tools/perf/util/unwind-libunwind.c
> > @@ -461,7 +461,7 @@ static int access_mem(unw_addr_space_t __maybe_unused
> > as,
> > if (ret) {
> > pr_debug("unwind: access_mem %p not inside range"
> > " 0x%" PRIx64 "-0x%" PRIx64 "\n",
> > -(void *) addr, start, end);
> > +(void *) (uintptr_t) addr, start, end);
> > *valp = 0;
> > return ret;
> > }
> > @@ -471,7 +471,7 @@ static int access_mem(unw_addr_space_t __maybe_unused
> > as,
> > offset = addr - start;
> > *valp = *(unw_word_t *)&stack->data[offset];
> > pr_debug("unwind: access_mem addr %p val %lx, offset %d\n",
> > -(void *) addr, (unsigned long)*valp, offset);
> > +(void *) (uintptr_t) addr, (unsigned long)*valp, offset);
> > return 0;
> > }
> >
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
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/
collect2: error: ld returned 1 exit status
Hi Anton, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 4a06c8ac2fb3ef484579ce44f9b809bd310fad48 commit: 238abecde8ad43f914e095fcf23e0bd35dc7a7f2 powerpc: Don't use gcc specific options on clang date: 4 months ago config: powerpc-defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 238abecde8ad43f914e095fcf23e0bd35dc7a7f2 # save the attached .config to linux build tree make.cross ARCH=powerpc All errors (new ones prefixed by >>): /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/sigtramp.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/sigtramp.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/gettimeofday.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/gettimeofday.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/datapage.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/datapage.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/cacheflush.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/cacheflush.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/note.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/note.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: arch/powerpc/kernel/vdso32/getcpu.o: compiled for a little endian system and target is big endian /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: failed to merge target specific data of file arch/powerpc/kernel/vdso32/getcpu.o /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[0] FDE at 04c4 overlaps table[1] FDE at 0c30. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[1] FDE at 0c30 overlaps table[2] FDE at 0c88. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[2] FDE at 0c88 overlaps table[3] FDE at 0ca0. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[3] FDE at 0ca0 overlaps table[4] FDE at 0cb8. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[4] FDE at 0cb8 overlaps table[5] FDE at 0cd0. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[5] FDE at 0cd0 overlaps table[6] FDE at 0864. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[7] FDE at 0c48 overlaps table[8] FDE at 0c5c. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[8] FDE at 0c5c overlaps table[9] FDE at 0c18. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[9] FDE at 0c18 overlaps table[10] FDE at 0c74. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[10] FDE at 0c74 overlaps table[11] FDE at 0ce8. /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../powerpc64le-linux-gnu/bin/ld: .eh_frame_hdr table[11] FDE at 0ce8 overlaps table[12] FDE at 0cfc. >> collect2: error: ld returned 1 exit status -- /usr/lib/gcc-cross/powerpc64le-linux-gnu/5/../../../../
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:18: error: too many arguments to function 'horus3a_attach'
Hi Kozlov,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4a06c8ac2fb3ef484579ce44f9b809bd310fad48
commit: 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e [media] netup_unidvb: NetUP
Universal DVB-S/S2/T/T2/C PCI-E card driver
date: 9 weeks ago
config: x86_64-randconfig-s1-10110708 (attached as .config)
reproduce:
git checkout 52b1eaf4c59a3bbd07afbb4ab4f43418a807d02e
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
drivers/media/dvb-frontends/horus3a.h:51:13: warning: 'struct
cxd2820r_config' declared inside parameter list
struct i2c_adapter *i2c)
^
drivers/media/dvb-frontends/horus3a.h:51:13: warning: its scope is only this
definition or declaration, which is probably not what you want
In file included from include/media/videobuf2-dvb.h:4:0,
from drivers/media/pci/netup_unidvb/netup_unidvb.h:26,
from drivers/media/pci/netup_unidvb/netup_unidvb_core.c:32:
drivers/media/pci/netup_unidvb/netup_unidvb_core.c: In function
'netup_unidvb_dvb_init':
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:34: warning: passing
argument 1 of 'horus3a_attach' from incompatible pointer type
[-Wincompatible-pointer-types]
if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
^
drivers/media/dvb-core/dvbdev.h:170:11: note: in definition of macro
'dvb_attach'
FUNCTION(ARGS); \
^
In file included from
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
drivers/media/dvb-frontends/horus3a.h:49:36: note: expected 'const struct
cxd2820r_config *' but argument is of type 'struct dvb_frontend *'
static inline struct dvb_frontend *horus3a_attach(
^
In file included from include/media/videobuf2-dvb.h:4:0,
from drivers/media/pci/netup_unidvb/netup_unidvb.h:26,
from drivers/media/pci/netup_unidvb/netup_unidvb_core.c:32:
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:418:4: warning: passing
argument 2 of 'horus3a_attach' from incompatible pointer type
[-Wincompatible-pointer-types]
&horus3a_conf, &ndev->i2c[num].adap)) {
^
drivers/media/dvb-core/dvbdev.h:170:11: note: in definition of macro
'dvb_attach'
FUNCTION(ARGS); \
^
In file included from
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
drivers/media/dvb-frontends/horus3a.h:49:36: note: expected 'struct
i2c_adapter *' but argument is of type 'struct horus3a_config *'
static inline struct dvb_frontend *horus3a_attach(
^
In file included from include/media/videobuf2-dvb.h:4:0,
from drivers/media/pci/netup_unidvb/netup_unidvb.h:26,
from drivers/media/pci/netup_unidvb/netup_unidvb_core.c:32:
>> drivers/media/pci/netup_unidvb/netup_unidvb_core.c:417:18: error: too many
>> arguments to function 'horus3a_attach'
if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
^
drivers/media/dvb-core/dvbdev.h:170:2: note: in definition of macro
'dvb_attach'
FUNCTION(ARGS); \
^
In file included from
drivers/media/pci/netup_unidvb/netup_unidvb_core.c:34:0:
drivers/media/dvb-frontends/horus3a.h:49:36: note: declared here
static inline struct dvb_frontend *horus3a_attach(
^
vim +/horus3a_attach +417 drivers/media/pci/netup_unidvb/netup_unidvb_core.c
411 dev_dbg(&ndev->pci_dev->dev,
412 "%s(): unable to attach DVB-S/S2 frontend\n",
413 __func__);
414 goto frontend_detach;
415 }
416 horus3a_conf.set_tuner_priv = &ndev->dma[num];
> 417 if (!dvb_attach(horus3a_attach, fe0->dvb.frontend,
418 &horus3a_conf, &ndev->i2c[num].adap)) {
419 dev_dbg(&ndev->pci_dev->dev,
420 "%s(): unable to attach DVB-S/S2 tuner
frontend\n",
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v5 0/7] arm64: berlin: add pinctrl support
Jisheng, On Fri, Oct 09, 2015 at 07:56:43PM +0800, Jisheng Zhang wrote: > This series adds support for Marvell berlin4ct pin-controller, allowing > to configure the pin muxing from the device tree. For the whole series, Acked-by: Antoine Tenart Thanks! Antoine > > Since v4: > - drop ARCH_BERLIN dependency for it has been met > - drop COMPILE_TEST dependency but make berlin pinctrl driver visible >if COMPILE_TEST=y, and let this change be a seperate commit. > > Since v3: > - fix stupid build error: I missed local changes to berlin-bg4ct.c > > Since v2: > - introduce new berlin_pinctrl_probe_regmap() to avoid duplicated code > - renaming such as s/urt/uart etc. but keep the group name as URT* to keep >consistent with HW/ASIC > > Since v1: > - use generic name for pin functions > - a new commit to add pinmux for uart0 > - correct pinctrl usage in dts > > > Jisheng Zhang (7): > pinctrl: berlin: introduce berlin_pinctrl_probe_regmap() > pinctrl: berlin: Make berlin pinctrl driver visible if COMPILE_TEST=y > pinctrl: berlin: add the berlin4ct pinctrl driver > arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs > pinctrl: dt-binding: document berlin4ct SoC pinctrl > arm64: dts: berlin4ct: add the pinctrl node > arm64: dts: berlin4ct: add default pinmux for uart0 > > .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 +- > arch/arm64/Kconfig.platforms | 1 + > arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 22 + > drivers/pinctrl/berlin/Kconfig | 7 +- > drivers/pinctrl/berlin/Makefile| 1 + > drivers/pinctrl/berlin/berlin-bg4ct.c | 503 > + > drivers/pinctrl/berlin/berlin.c| 26 +- > drivers/pinctrl/berlin/berlin.h| 4 + > 8 files changed, 558 insertions(+), 11 deletions(-) > create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c > > -- > 2.6.1 > -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] arm64: berlin: add pinctrl support
Hi Jisheng, Please keep Acked-by tags when you submit a new version of a series. Thanks, Antoine On Fri, Oct 09, 2015 at 07:56:43PM +0800, Jisheng Zhang wrote: > This series adds support for Marvell berlin4ct pin-controller, allowing > to configure the pin muxing from the device tree. > > Since v4: > - drop ARCH_BERLIN dependency for it has been met > - drop COMPILE_TEST dependency but make berlin pinctrl driver visible >if COMPILE_TEST=y, and let this change be a seperate commit. > > Since v3: > - fix stupid build error: I missed local changes to berlin-bg4ct.c > > Since v2: > - introduce new berlin_pinctrl_probe_regmap() to avoid duplicated code > - renaming such as s/urt/uart etc. but keep the group name as URT* to keep >consistent with HW/ASIC > > Since v1: > - use generic name for pin functions > - a new commit to add pinmux for uart0 > - correct pinctrl usage in dts > > > Jisheng Zhang (7): > pinctrl: berlin: introduce berlin_pinctrl_probe_regmap() > pinctrl: berlin: Make berlin pinctrl driver visible if COMPILE_TEST=y > pinctrl: berlin: add the berlin4ct pinctrl driver > arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs > pinctrl: dt-binding: document berlin4ct SoC pinctrl > arm64: dts: berlin4ct: add the pinctrl node > arm64: dts: berlin4ct: add default pinmux for uart0 > > .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 +- > arch/arm64/Kconfig.platforms | 1 + > arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 22 + > drivers/pinctrl/berlin/Kconfig | 7 +- > drivers/pinctrl/berlin/Makefile| 1 + > drivers/pinctrl/berlin/berlin-bg4ct.c | 503 > + > drivers/pinctrl/berlin/berlin.c| 26 +- > drivers/pinctrl/berlin/berlin.h| 4 + > 8 files changed, 558 insertions(+), 11 deletions(-) > create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c > > -- > 2.6.1 > -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/6] pinctrl: berlin: add the berlin4ct pinctrl driver
Hi Jisheng, On Fri, Oct 09, 2015 at 05:22:38PM +0800, Jisheng Zhang wrote: > On Fri, 9 Oct 2015 11:03:53 +0200 > Antoine Tenart wrote: > > > > Finally you can move the OF dependency to the PINCTRL_BERLIN config as > > all Berlin pinctrl drivers depends on it. > > PINCTRL_BERLIN isn't user visible and it's selected by PINCTRL_BERLIN_BG4CT. > So > we may have the following random config case: > > CONFIG_OF=n > CONFIG_PINCTRL_BERLIN_BG4CT=y > > In this case, there will be build errors for we missed OF. So we have to > make PINCTRL_BERLIN_BG4CT depends on OF. What do you think? Or is there > better solution? That's true. But because other Berlin pinctrl drivers also depends on CONFIG_OF, we need to make then depend on it too. This isn't the topic of this series so I'll send a separate patch later. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 RESEND] staging: vme_user: provide DMA functionality
This introduces a new dma device that provides a single ioctl call that
provides DMA read and write functionality to the user space.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
In the last reply Martyn suggested a rework of this to make it use existing
bus/vme/ctl instead of creating a new bus/vme/dma%i device and also dynamically
allocate a dma resource in each request.
I think this doesn't need those adjustments. I think that dynamic allocation
doesn't solve any practical problem that isn't caused by current kernel api.
I also think that separate device is a good feature because it allows for
discovery of dma capatibility from userspace. The interface with separate
chardev also allows to provide DMA read() and write() syscalls that can
come handy in pair with /bin/dd.
---
drivers/staging/vme/devices/vme_user.c | 201 -
drivers/staging/vme/devices/vme_user.h | 11 ++
2 files changed, 209 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_user.c
b/drivers/staging/vme/devices/vme_user.c
index 9cca97a..5cc782e 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -79,15 +79,18 @@ static unsigned int bus_num;
* We shall support 4 masters and 4 slaves with this driver.
*/
#define VME_MAJOR 221 /* VME Major Device Number */
-#define VME_DEVS 9 /* Number of dev entries */
+#define VME_DEVS 10 /* Number of dev entries */
#define MASTER_MINOR 0
#define MASTER_MAX 3
#define SLAVE_MINOR4
#define SLAVE_MAX 7
#define CONTROL_MINOR 8
+#define DMA_MINOR 9
-#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+#define PCI_BUF_SIZE 0x2 /* Size of one slave image buffer */
+
+#define VME_MAX_DMA_LEN0x400 /* Maximal DMA transfer length
*/
/*
* Structure to handle image related parameters.
@@ -112,7 +115,7 @@ static const int type[VME_DEVS] = { MASTER_MINOR,
MASTER_MINOR,
MASTER_MINOR, MASTER_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
SLAVE_MINOR,SLAVE_MINOR,
- CONTROL_MINOR
+ CONTROL_MINOR, DMA_MINOR
};
struct vme_user_vma_priv {
@@ -343,6 +346,168 @@ static loff_t vme_user_llseek(struct file *file, loff_t
off, int whence)
return -EINVAL;
}
+static int vme_user_sg_to_dma_list(const struct vme_dma_op *dma_op,
+ struct sg_table *sgt,
+ int sg_count, struct vme_dma_list *dma_list)
+{
+ ssize_t pos = 0;
+ struct scatterlist *sg;
+ int i, ret;
+
+ for_each_sg(sgt->sgl, sg, sg_count, i) {
+ struct vme_dma_attr *pci_attr, *vme_attr, *src, *dest;
+ dma_addr_t hw_address = sg_dma_address(sg);
+ unsigned int hw_len = sg_dma_len(sg);
+
+ vme_attr = vme_dma_vme_attribute(dma_op->vme_addr + pos,
+dma_op->aspace,
+dma_op->cycle,
+dma_op->dwidth);
+ if (!vme_attr)
+ return -ENOMEM;
+
+ pci_attr = vme_dma_pci_attribute(hw_address);
+ if (!pci_attr) {
+ vme_dma_free_attribute(vme_attr);
+ return -ENOMEM;
+ }
+
+ switch (dma_op->dir) {
+ case VME_DMA_MEM_TO_VME:
+ src = pci_attr;
+ dest = vme_attr;
+ break;
+ case VME_DMA_VME_TO_MEM:
+ src = vme_attr;
+ dest = pci_attr;
+ break;
+ }
+
+ ret = vme_dma_list_add(dma_list, src, dest, hw_len);
+
+ /*
+* XXX VME API doesn't mention whether we should keep
+* attributes around
+*/
+ vme_dma_free_attribute(vme_attr);
+ vme_dma_free_attribute(pci_attr);
+
+ if (ret)
+ return ret;
+
+ pos += hw_len;
+ }
+
+ return 0;
+}
+
+static enum dma_data_direction vme_dir_to_dma_dir(unsigned vme_dir)
+{
+ switch (vme_dir) {
+ case VME_DMA_VME_TO_MEM:
+ return DMA_FROM_DEVICE;
+ case VME_DMA_MEM_TO_VME:
+ return DMA_TO_DEVICE;
+ }
+
+ return DMA_NONE;
+}
+
+static ssize_t vme_user_dma_ioctl(unsigned int minor,
+ const struct vme_dma_op *dma_op)
+{
+ unsigned int offset = offset_in_page(dma_op->buf_vaddr);
+ unsigned long nr_pages;
+ enum dma_data_direction dir;
+ struct vme
Re: [PATCH v7 1/2] efi: export efi_capsule_supported() function symbol
On Mon, 05 Oct, at 03:13:50PM, Borislav Petkov wrote: > On Tue, Oct 06, 2015 at 04:15:54AM +0800, Kweh, Hock Leong wrote: > > From: "Kweh, Hock Leong" > > > > This patch export efi_capsule_supported() function symbol for capsule > > kernel module to use. > > > > Cc: Matt Fleming > > Signed-off-by: Kweh, Hock Leong > > --- > > drivers/firmware/efi/capsule.c |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c > > index d8cd75c0..738d437 100644 > > --- a/drivers/firmware/efi/capsule.c > > +++ b/drivers/firmware/efi/capsule.c > > @@ -101,6 +101,7 @@ out: > > kfree(capsule); > > return rv; > > } > > +EXPORT_SYMBOL_GPL(efi_capsule_supported); > > So this one is still a separate patch. > > If you're going to ignore review comments, maybe I should stop wasting > my time reviewing your stuff... I agree that it makes sense to fold this patch into your PATCH 2, because then we know why we need the above symbol to be exported. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vme: 8-bit status/id takes 256 values, not 255
Fixes an off by one array size.
Signed-off-by: Dmitry Kalinkin
---
drivers/vme/vme_bridge.h | 4 +++-
include/linux/vme.h | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vme/vme_bridge.h b/drivers/vme/vme_bridge.h
index 397578a..b59cbee 100644
--- a/drivers/vme/vme_bridge.h
+++ b/drivers/vme/vme_bridge.h
@@ -1,6 +1,8 @@
#ifndef _VME_BRIDGE_H_
#define _VME_BRIDGE_H_
+#include
+
#define VME_CRCSR_BUF_SIZE (508*1024)
/*
* Resource structures
@@ -91,7 +93,7 @@ struct vme_callback {
struct vme_irq {
int count;
- struct vme_callback callback[255];
+ struct vme_callback callback[VME_NUM_STATUSID];
};
/* Allow 16 characters for name (including null character) */
diff --git a/include/linux/vme.h b/include/linux/vme.h
index c013135..71e4a6d 100644
--- a/include/linux/vme.h
+++ b/include/linux/vme.h
@@ -81,6 +81,9 @@ struct vme_resource {
extern struct bus_type vme_bus_type;
+/* Number of VME interrupt vectors */
+#define VME_NUM_STATUSID 256
+
/* VME_MAX_BRIDGES comes from the type of vme_bus_numbers */
#define VME_MAX_BRIDGES(sizeof(unsigned int)*8)
#define VME_MAX_SLOTS 32
--
1.8.3.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: [Linux] Linux PID algorithm is BRAINDEAD!
On Fri, Oct 09, 2015 at 10:00:34PM -0400, Dave Goel wrote: > > All that the entire system needs is one queue of free PIDs. Any time you > need a PID, take it from the head. Any time a PID is newly freed, push it at > the back of the queue. That's it! The overhead seems minimal to me. > > The queue is initially populated by 2-32768, of course. The worst-case overhead is 64k -- 2 bytes times 32k pid's. You can use a 64k circular buffer to store the list of pid's to use, sure. So the RAM utilization isn't _that_ bad, except that you need to keep one of these for each pid namespace. So for systems using a large number of containers and lots of pid namespaces for isolation purposes, the memory utilization overhead is not necessarily going to be considered cheap. But that's actually not be biggest problem. The biggest problem is that accessing this free pid queue is now a locking bottleneck --- especially on a very large NUMA system, and especially on a system where people are running tons of shell scripts are launching processes all the time. So in other words, those systems which are most likely to suffer from pid workaround will also be the systems that will be punished the most by needing to take a lock each time you allocate a new pid. Given that there *are* people who use Linux on systems with hundreds of CPU's, where global locks are exquisitely painful, the solution you've outlined is not something that could be the only solution available in the kernel. In addition, most people don't find the the workarounds to be terribly onerous. Using "trap" to catch signals and then having the shell script clean up after itself (so you don't need to depend on a cleaner program) is not terribly hard, and in is considered best practice. So adding something complex into the kernel just to work around sloppy shell scripts doesn't seem like something that most people would considered a great use of resources. And if it causes significant performance regressions on kernel scalability for large NUMA systems, people will probably be even less interested in implementing something just for the convenience of sloppy shell script programmers. Telling kernel developers that Linux's PID algorithm is braindead isn't going to help. :-) So what to do instead? I'm going to assume you are in an environment where you have a huge number of legacy shell scripts and fixing them all is too hard (tm). What then? Well, the fact that you are talking about running some kind of task cleaner means that in all likelihood it's running in some kind of structured environment where you know that temp files will have a certain format. So in that world, what I'd suggest is that you have all of the jobs be started from a management daemon. For the sake of argument, let's call that management daemon a "borglet"[1]. The borglet starts each of your jobs running on your machine, so it knows when the job exits, and when it does, you can just have the borglet delete the job's entire task directory. For bonus points you could have the borglet use container technology to control the amount of cpu, memory, networing, and disk time used by a particular job, but if you need all of that functionality, it might simpler for you to grab Kubernetes and just use that to control your jobs. :-) [1] http://thenewstack.io/google-lifts-the-veil-on-borg-revealing-apache-auroras-heritage/ The advantage of using Kubernetes is that when you're ready to take a leap into cloud computing, it will be a lot less work since you will have already structurered your jobs in a way that makes this easy. :-) Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
thinkpad_acpi: Lenovo ThinkPad Yoga 12 side lock button (0x6020)
The Lenovo ThinkPad Yogo 12 has a button on the side by the power and volume keys with a padlock icon on it, I presume intended to be used as Screenlock. It emits 0x6020 which means it falls into the hotkey_notify_6xxx() block. It seems this should be handled similarly to the 0x1xxx events instead (as a hotkey). Is this a keymap change candidate? If so, How do I map 0x6020 to a scancode? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thinkpad_acpi: Add TP_HKEY_EV_SCREEN_FLIP (0x60c0) for Lenovo ThinkPad Yoga 12
On Sat, Oct 10, 2015 at 06:40:34PM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 10 Oct 2015, Darren Hart wrote: > > On Sat, Oct 10, 2015 at 11:41:47AM -0700, Darren Hart wrote: > > > From: Darren Hart > > > > > > thinkpad_acpi reports "unhandled HKEY event 0x60c0" when switching > > > between laptop and tent/tablet mode on the ThinkPad Yoga 12. This key is > > > reported by atkbd serio0 as e058 and e059. > > > > > > Add TP_HKEY_EV_SCREEN_FLIP to the list of ignored events and silence the > > > warning. > > > > > > Cleanup whitespace on preceeding line for TP_HKEY_EV_KEY_FN_ESC. > > > > > > Signed-off-by: Darren Hart > > > Cc: Henrique de Moraes Holschuh > > > Cc: ibm-acpi-de...@lists.sourceforge.net > > Acked-by: Henrique de Moraes Holschuh Thanks Henrique, Now, as I'm digging into this I'm finding maybe there is more to this. Should I be attempting to tie this in to the tablet switch mechanism for the older x61t? Or is this something we now want to strictly hand off to a userspace helper via the atkbd event? -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ohci-pci: use USB_DT_*
Toshiba Portege 4000 quirk entry can be written shorter using the
PCI_DEVICE_SUB() macro.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
drivers/usb/host/ohci-pci.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
Index: usb/drivers/usb/host/ohci-pci.c
===
--- usb.orig/drivers/usb/host/ohci-pci.c
+++ usb/drivers/usb/host/ohci-pci.c
@@ -192,10 +192,8 @@ static const struct pci_device_id ohci_p
},
{
/* Toshiba portege 4000 */
- .vendor = PCI_VENDOR_ID_AL,
- .device = 0x5237,
- .subvendor = PCI_VENDOR_ID_TOSHIBA,
- .subdevice = 0x0004,
+ PCI_DEVICE_SUB(PCI_VENDOR_ID_AL, 0x5237,
+ PCI_VENDOR_ID_TOSHIBA, 0x0004),
.driver_data= (unsigned long) broken_suspend,
},
{
--
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 v2] arm: add missing of_node_put
for_each_child_of_node performs an of_node_get on each iteration, so
a break out of the loop requires an of_node_put.
The of_node_put is duplicated in front of each error return, because the
function contains a later error return that is beyond the end of the
for_each_child_of_node and thus doesn't need of_node_put.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
//
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
(
return child;
|
+ of_node_put(child);
? return ...;
)
...
}
@@
expression root,e;
local idexpression child;
@@
for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
//
Additionally, concatenated a string in an affected line to avoid introducing
a checkpatch warning.
Signed-off-by: Julia Lawall
---
v2: Fixed the returns as well, adjusted a string in a test expression.
arch/arm/kernel/devtree.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..65addcb 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -101,6 +101,7 @@ void __init arm_dt_init_cpu_maps(void)
if (of_property_read_u32(cpu, "reg", &hwid)) {
pr_debug(" * %s missing reg property\n",
cpu->full_name);
+ of_node_put(cpu);
return;
}
@@ -108,8 +109,10 @@ void __init arm_dt_init_cpu_maps(void)
* 8 MSBs must be set to 0 in the DT since the reg property
* defines the MPIDR[23:0].
*/
- if (hwid & ~MPIDR_HWID_BITMASK)
+ if (hwid & ~MPIDR_HWID_BITMASK) {
+ of_node_put(cpu);
return;
+ }
/*
* Duplicate MPIDRs are a recipe for disaster.
@@ -119,9 +122,11 @@ void __init arm_dt_init_cpu_maps(void)
* to avoid matching valid MPIDR[23:0] values.
*/
for (j = 0; j < cpuidx; j++)
- if (WARN(tmp_map[j] == hwid, "Duplicate /cpu reg "
-"properties in the DT\n"))
+ if (WARN(tmp_map[j] == hwid,
+"Duplicate /cpu reg properties in the DT\n")) {
+ of_node_put(cpu);
return;
+ }
/*
* Build a stashed array of MPIDR values. Numbering scheme
@@ -143,6 +148,7 @@ void __init arm_dt_init_cpu_maps(void)
"max cores %u, capping them\n",
cpuidx, nr_cpu_ids)) {
cpuidx = nr_cpu_ids;
+ of_node_put(cpu);
break;
}
--
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] thinkpad_acpi: Add TP_HKEY_EV_SCREEN_FLIP (0x60c0) for Lenovo ThinkPad Yoga 12
On Sat, 10 Oct 2015, Darren Hart wrote: > On Sat, Oct 10, 2015 at 11:41:47AM -0700, Darren Hart wrote: > > From: Darren Hart > > > > thinkpad_acpi reports "unhandled HKEY event 0x60c0" when switching > > between laptop and tent/tablet mode on the ThinkPad Yoga 12. This key is > > reported by atkbd serio0 as e058 and e059. > > > > Add TP_HKEY_EV_SCREEN_FLIP to the list of ignored events and silence the > > warning. > > > > Cleanup whitespace on preceeding line for TP_HKEY_EV_KEY_FN_ESC. > > > > Signed-off-by: Darren Hart > > Cc: Henrique de Moraes Holschuh > > Cc: ibm-acpi-de...@lists.sourceforge.net Acked-by: Henrique de Moraes Holschuh -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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] vme: tsi148: silence uninitialized variable warning
Hi Martyn,
Sorry, your comment is too late. This patch is already in staging-next.
Dmitri
> On 2015/10/10, at 17:35, Martyn Welch wrote:
>
> On 5 October 2015 at 04:59, Dmitry Kalinkin wrote:
>> The warning is a false positive.
>>
>
> That seems very likely.
>
> Please could you role this into the original patch (vme: change bus
> error handling scheme)?
>
> Martyn
>
>> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_write':
>> drivers/vme/bridges/vme_tsi148.c:1358:31: warning: 'handler' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> vme_unregister_error_handler(handler);
>> ^
>> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_read':
>> drivers/vme/bridges/vme_tsi148.c:1260:31: warning: 'handler' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> vme_unregister_error_handler(handler);
>> ^
>>
>> Fixes: 0b0496625715 ("vme: change bus error handling scheme")
>> Signed-off-by: Dmitry Kalinkin
>> ---
>> drivers/vme/bridges/vme_tsi148.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vme/bridges/vme_tsi148.c
>> b/drivers/vme/bridges/vme_tsi148.c
>> index d1e383b..6052483 100644
>> --- a/drivers/vme/bridges/vme_tsi148.c
>> +++ b/drivers/vme/bridges/vme_tsi148.c
>> @@ -1186,7 +1186,7 @@ static ssize_t tsi148_master_read(struct
>> vme_master_resource *image, void *buf,
>>int retval, enabled;
>>unsigned long long vme_base, size;
>>u32 aspace, cycle, dwidth;
>> - struct vme_error_handler *handler;
>> + struct vme_error_handler *handler = NULL;
>>struct vme_bridge *tsi148_bridge;
>>void __iomem *addr = image->kern_base + offset;
>>unsigned int done = 0;
>> @@ -1276,7 +1276,7 @@ static ssize_t tsi148_master_write(struct
>> vme_master_resource *image, void *buf,
>>unsigned int done = 0;
>>unsigned int count32;
>>
>> - struct vme_error_handler *handler;
>> + struct vme_error_handler *handler = NULL;
>>struct vme_bridge *tsi148_bridge;
>>struct tsi148_driver *bridge;
>>
>> --
>> 1.8.3.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vme: tsi148: silence uninitialized variable warning
On 5 October 2015 at 04:59, Dmitry Kalinkin wrote:
> The warning is a false positive.
>
That seems very likely.
Please could you role this into the original patch (vme: change bus
error handling scheme)?
Martyn
> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_write':
> drivers/vme/bridges/vme_tsi148.c:1358:31: warning: 'handler' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>vme_unregister_error_handler(handler);
>^
> drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_read':
> drivers/vme/bridges/vme_tsi148.c:1260:31: warning: 'handler' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>vme_unregister_error_handler(handler);
>^
>
> Fixes: 0b0496625715 ("vme: change bus error handling scheme")
> Signed-off-by: Dmitry Kalinkin
> ---
> drivers/vme/bridges/vme_tsi148.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vme/bridges/vme_tsi148.c
> b/drivers/vme/bridges/vme_tsi148.c
> index d1e383b..6052483 100644
> --- a/drivers/vme/bridges/vme_tsi148.c
> +++ b/drivers/vme/bridges/vme_tsi148.c
> @@ -1186,7 +1186,7 @@ static ssize_t tsi148_master_read(struct
> vme_master_resource *image, void *buf,
> int retval, enabled;
> unsigned long long vme_base, size;
> u32 aspace, cycle, dwidth;
> - struct vme_error_handler *handler;
> + struct vme_error_handler *handler = NULL;
> struct vme_bridge *tsi148_bridge;
> void __iomem *addr = image->kern_base + offset;
> unsigned int done = 0;
> @@ -1276,7 +1276,7 @@ static ssize_t tsi148_master_write(struct
> vme_master_resource *image, void *buf,
> unsigned int done = 0;
> unsigned int count32;
>
> - struct vme_error_handler *handler;
> + struct vme_error_handler *handler = NULL;
> struct vme_bridge *tsi148_bridge;
> struct tsi148_driver *bridge;
>
> --
> 1.8.3.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] ALSA: bebob: constify snd_bebob_rate_spec structures
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec,
snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are
initialized. Make them all const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
v2: extend to snd_bebob_clock_spec, snd_bebob_meter_spec, and
snd_bebob_spec structures.
sound/firewire/bebob/bebob.c |2 +-
sound/firewire/bebob/bebob.h | 32
sound/firewire/bebob/bebob_focusrite.c | 26 +-
sound/firewire/bebob/bebob_maudio.c| 32
sound/firewire/bebob/bebob_pcm.c |2 +-
sound/firewire/bebob/bebob_proc.c |6 +++---
sound/firewire/bebob/bebob_stream.c|6 +++---
sound/firewire/bebob/bebob_terratec.c | 10 +-
sound/firewire/bebob/bebob_yamaha.c|6 +++---
9 files changed, 61 insertions(+), 61 deletions(-)
diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c
index 0ed5e5f..091290d 100644
--- a/sound/firewire/bebob/bebob.c
+++ b/sound/firewire/bebob/bebob.c
@@ -335,7 +335,7 @@ static void bebob_remove(struct fw_unit *unit)
snd_card_free_when_closed(bebob->card);
}
-static struct snd_bebob_rate_spec normal_rate_spec = {
+static const struct snd_bebob_rate_spec normal_rate_spec = {
.get= &snd_bebob_stream_get_rate,
.set= &snd_bebob_stream_set_rate
};
diff --git a/sound/firewire/bebob/bebob_focusrite.c
b/sound/firewire/bebob/bebob_focusrite.c
index a1a3949..f110900 100644
--- a/sound/firewire/bebob/bebob_focusrite.c
+++ b/sound/firewire/bebob/bebob_focusrite.c
@@ -200,7 +200,7 @@ end:
return err;
}
-struct snd_bebob_spec saffire_le_spec;
+const struct snd_bebob_spec saffire_le_spec;
static enum snd_bebob_clock_type saffire_both_clk_src_types[] = {
SND_BEBOB_CLOCK_TYPE_INTERNAL,
SND_BEBOB_CLOCK_TYPE_EXTERNAL,
@@ -229,7 +229,7 @@ static const char *const saffire_meter_labels[] = {
static int
saffire_meter_get(struct snd_bebob *bebob, u32 *buf, unsigned int size)
{
- struct snd_bebob_meter_spec *spec = bebob->spec->meter;
+ const struct snd_bebob_meter_spec *spec = bebob->spec->meter;
unsigned int channels;
u64 offset;
int err;
@@ -260,60 +260,60 @@ saffire_meter_get(struct snd_bebob *bebob, u32 *buf,
unsigned int size)
return err;
}
-static struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
+static const struct snd_bebob_rate_spec saffirepro_both_rate_spec = {
.get= &saffirepro_both_clk_freq_get,
.set= &saffirepro_both_clk_freq_set,
};
/* Saffire Pro 26 I/O */
-static struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
+static const struct snd_bebob_clock_spec saffirepro_26_clk_spec = {
.num= ARRAY_SIZE(saffirepro_26_clk_src_types),
.types = saffirepro_26_clk_src_types,
.get= &saffirepro_both_clk_src_get,
};
-struct snd_bebob_spec saffirepro_26_spec = {
+const struct snd_bebob_spec saffirepro_26_spec = {
.clock = &saffirepro_26_clk_spec,
.rate = &saffirepro_both_rate_spec,
.meter = NULL
};
/* Saffire Pro 10 I/O */
-static struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
+static const struct snd_bebob_clock_spec saffirepro_10_clk_spec = {
.num= ARRAY_SIZE(saffirepro_10_clk_src_types),
.types = saffirepro_10_clk_src_types,
.get= &saffirepro_both_clk_src_get,
};
-struct snd_bebob_spec saffirepro_10_spec = {
+const struct snd_bebob_spec saffirepro_10_spec = {
.clock = &saffirepro_10_clk_spec,
.rate = &saffirepro_both_rate_spec,
.meter = NULL
};
-static struct snd_bebob_rate_spec saffire_both_rate_spec = {
+static const struct snd_bebob_rate_spec saffire_both_rate_spec = {
.get= &snd_bebob_stream_get_rate,
.set= &snd_bebob_stream_set_rate,
};
-static struct snd_bebob_clock_spec saffire_both_clk_spec = {
+static const struct snd_bebob_clock_spec saffire_both_clk_spec = {
.num= ARRAY_SIZE(saffire_both_clk_src_types),
.types = saffire_both_clk_src_types,
.get= &saffire_both_clk_src_get,
};
/* Saffire LE */
-static struct snd_bebob_meter_spec saffire_le_meter_spec = {
+static const struct snd_bebob_meter_spec saffire_le_meter_spec = {
.num= ARRAY_SIZE(saffire_le_meter_labels),
.labels = saffire_le_meter_labels,
.get= &saffire_meter_get,
};
-struct snd_bebob_spec saffire_le_spec = {
+const struct snd_bebob_spec saffire_le_spec = {
.clock = &saffire_both_clk_spec,
.rate = &saffire_both_rate_spec,
.meter = &saffire_le_meter_spec
};
/* Saffire */
-static struct snd_bebob_meter_spec saffire_meter_spec = {
+static const struct snd_bebob_meter_spec saffire_meter_spec = {
.num= ARRAY_SIZE(saffire_meter_labels),
.labels = saffire_meter_labels,
.get= &s
Re: [PATCH 5/5] arm: add missing of_node_put
On Saturday 10 October 2015 23:10:06 Julia Lawall wrote:
> On Sat, 10 Oct 2015, Arnd Bergmann wrote:
>
> > On Saturday 10 October 2015 14:30:54 Julia Lawall wrote:
> > > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > > index 11c54de..432ff34 100644
> > > --- a/arch/arm/kernel/devtree.c
> > > +++ b/arch/arm/kernel/devtree.c
> > > @@ -143,6 +143,7 @@ void __init arm_dt_init_cpu_maps(void)
> > >"max cores %u, capping
> > > them\n",
> > >cpuidx, nr_cpu_ids)) {
> > > cpuidx = nr_cpu_ids;
> > > + of_node_put(cpu);
> > > break;
> > > }
> > >
> >
> > The same for_each_child_of_node() loop has three 'return' statements'
> > aside from the 'break' statement here. I think you should change your
> > semantic patch to cover both cases.
>
> It was intended to,
Ok, I saw that just after replying...
> but it seems that it's not working on the case where
> there is no argument to return.
> In any case, it's an opportunity to ask a question. Would one want a
> of_node_put in front of every return, or should the returns become gotos,
> to a single of_node_put after the current end of the function?
The two styles that I see in code I consider particularly clean are:
- have only one return statement in the function and use goto for
error handling
- avoid the goto and have the early return.
Mixing the two tends to make the function less readable, so I'd only
change it to use gotos if it can be done nicely for all cases.
Arnd
--
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 5/5] arm: add missing of_node_put
On Sat, 10 Oct 2015, Thomas Petazzoni wrote: > Arnd, > > On Sat, 10 Oct 2015 23:02:15 +0200, Arnd Bergmann wrote: > > > The same for_each_child_of_node() loop has three 'return' statements' > > aside from the 'break' statement here. I think you should change your > > semantic patch to cover both cases. > > I think Julia's semantic patch covers both cases, but only the cases > where there is one break or return (though I have essentially zero > Coccinelle knowledge, this is all based on guessing looking at the > semantic patch in the cover letter). Normally, it should be OK with lots of returns. And contrary to my previous email, even with return;. Will check on it. julia -- 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 5/5] arm: add missing of_node_put
On Sat, 10 Oct 2015, Arnd Bergmann wrote:
> On Saturday 10 October 2015 14:30:54 Julia Lawall wrote:
> > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > index 11c54de..432ff34 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -143,6 +143,7 @@ void __init arm_dt_init_cpu_maps(void)
> >"max cores %u, capping
> > them\n",
> >cpuidx, nr_cpu_ids)) {
> > cpuidx = nr_cpu_ids;
> > + of_node_put(cpu);
> > break;
> > }
> >
>
> The same for_each_child_of_node() loop has three 'return' statements'
> aside from the 'break' statement here. I think you should change your
> semantic patch to cover both cases.
It was intended to, but it seems that it's not working on the case where
there is no argument to return.
In any case, it's an opportunity to ask a question. Would one want a
of_node_put in front of every return, or should the returns become gotos,
to a single of_node_put after the current end of the function?
julia
--
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 5/5] arm: add missing of_node_put
Arnd, On Sat, 10 Oct 2015 23:02:15 +0200, Arnd Bergmann wrote: > The same for_each_child_of_node() loop has three 'return' statements' > aside from the 'break' statement here. I think you should change your > semantic patch to cover both cases. I think Julia's semantic patch covers both cases, but only the cases where there is one break or return (though I have essentially zero Coccinelle knowledge, this is all based on guessing looking at the semantic patch in the cover letter). Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: add missing of_node_put
On Saturday 10 October 2015 14:30:54 Julia Lawall wrote:
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..432ff34 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -143,6 +143,7 @@ void __init arm_dt_init_cpu_maps(void)
>"max cores %u, capping them\n",
>cpuidx, nr_cpu_ids)) {
> cpuidx = nr_cpu_ids;
> + of_node_put(cpu);
> break;
> }
>
The same for_each_child_of_node() loop has three 'return' statements'
aside from the 'break' statement here. I think you should change your
semantic patch to cover both cases.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v3] drivers: staging: rtl8723au: Changed rssi_cmd to little-endian param
Jacob Kiefer writes:
> From: Jacob Kiefer
>
> Changed rssi_cmd interface to accept le32 param instead of
> unnecessary u8 * conversion. Updated existing calls to rssi_cmd.
> This patch pushes responsibility to caller to convert to
> le32. This cleans up the code quite a bit.
> Also removed magic numbers.
>
> This patch fixes the following sparse error:
>
> CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> ...
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
> warning: incorrect type in assignment (different base types)
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
> expected unsigned int [unsigned] [usertype]
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
> got restricted __le32 [usertype]
> ...
>
> Signed-off-by: Jacob Kiefer
> ---
> In v3, opted to change the interface rather than just the internal
> code to clear the sparse errors and make the code more sane.
I am fine with this code in principle, but has it been tested? This
stuff will break the driver miserably if it's wrong.
Thanks,
Jes
> ---
> drivers/staging/rtl8723au/hal/odm.c | 3 ++-
> drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 7 +++
> drivers/staging/rtl8723au/include/rtl8723a_cmd.h | 2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/rtl8723au/hal/odm.c
> b/drivers/staging/rtl8723au/hal/odm.c
> index 6b9dbef..c7f45c7 100644
> --- a/drivers/staging/rtl8723au/hal/odm.c
> +++ b/drivers/staging/rtl8723au/hal/odm.c
> @@ -1274,7 +1274,8 @@ static void odm_RSSIMonitorCheck(struct dm_odm_t
> *pDM_Odm)
>
> for (i = 0; i < sta_cnt; i++) {
> if (PWDB_rssi[i] != (0))
> - rtl8723a_set_rssi_cmd(Adapter, (u8 *)&PWDB_rssi[i]);
> + rtl8723a_set_rssi_cmd(Adapter,
> + cpu_to_le32(PWDB_rssi[i]));
> }
>
> pdmpriv->EntryMaxUndecoratedSmoothedPWDB = MaxDB;
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> index 9733aa6..97d23c3 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
> @@ -25,6 +25,7 @@
> #define RTL92C_MAX_CMD_LEN 5
> #define MESSAGE_BOX_SIZE 4
> #define EX_MESSAGE_BOX_SIZE 2
> +#define RSSI_CMD_LEN 3
>
> static u8 _is_fw_read_cmd_down(struct rtw_adapter *padapter, u8 msgbox_num)
> {
> @@ -113,11 +114,9 @@ exit:
> return ret;
> }
>
> -int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
> +int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param)
> {
> - *((u32 *)param) = cpu_to_le32(*((u32 *)param));
> -
> - FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
> + FillH2CCmd(padapter, RSSI_SETTING_EID, RSSI_CMD_LEN, (u8 *)¶m);
>
> return _SUCCESS;
> }
> diff --git a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
> b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
> index 014c02e..e281543 100644
> --- a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
> +++ b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
> @@ -149,7 +149,7 @@ void rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(struct
> rtw_adapter *padapter);
> #else
> #define rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(padapter) do {} while(0)
> #endif
> -int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param);
> +int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param);
> int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg);
> void rtl8723a_add_rateatid(struct rtw_adapter *padapter, u32 bitmap, u8 arg,
> u8 rssi_level);
>
> --
> 1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/20] kvm: rename pfn_t to kvm_pfn_t
On Sat, Oct 10, 2015 at 1:35 PM, Paolo Bonzini wrote: > On 10/10/2015 02:56, Dan Williams wrote: >> The core has developed a need for a "pfn_t" type [1]. Move the existing >> pfn_t in KVM to kvm_pfn_t [2]. >> >> [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002199.html >> [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002218.html > > Can you please change also the other types in include/linux/kvm_types.h? Hmm, all those seem kvm specific already. I'd only prefix them with kvm_ if they collided with a "core" type. -- 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/
[BUG] x86: apic: Possible null pointer dereference by apic_ack_edge
Hello, In mainline kernel version 4.3-rc4, the following line located in the apic_ack_edge function definition can result in a null pointer dereference: irq_complete_move(irqd_cfg(data)); The irqd_cfg function may return a value of NULL. If NULL is passed to the irq_complete_move function, then the struct apic_chip_data pointer 'data' of the __irq_complete_move function will be defined, and subsequently dereferenced, based on this incorrect NULL value passed through the 'cfg' parameter: data = container_of(cfg, struct apic_chip_data, cfg); if (likely(!data->move_in_progress)) Sincerely, William Breathitt Gray -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86, efi: Add "efi_fake_mem" boot option
On Wed, 30 Sep, at 11:01:56PM, Taku Izumi wrote: > This patch introduces new boot option named "efi_fake_mem". > By specifying this parameter, you can add arbitrary attribute > to specific memory range. > This is useful for debugging of Address Range Mirroring feature. > > For example, if "efi_fake_mem=2G@4G:0x1,2G@0x10a000:0x1" > is specified, the original (firmware provided) EFI memmap will be > updated so that the specified memory regions have > EFI_MEMORY_MORE_RELIABLE attribute (0x1): > > >efi: mem36: [Conventional Memory| | | | | | |WB|WT|WC|UC] > range=[0x0001-0x0020a000) (129536MB) > > >efi: mem36: [Conventional Memory| |MR| | | | |WB|WT|WC|UC] > range=[0x0001-0x00018000) (2048MB) >efi: mem37: [Conventional Memory| | | | | | |WB|WT|WC|UC] > range=[0x00018000-0x0010a000) (61952MB) >efi: mem38: [Conventional Memory| |MR| | | | |WB|WT|WC|UC] > range=[0x0010a000-0x00112000) (2048MB) >efi: mem39: [Conventional Memory| | | | | | |WB|WT|WC|UC] > range=[0x00112000-0x0020a000) (63488MB) > > And you will find that the following message is output: > >efi: Memory: 4096M/131455M mirrored memory > > Signed-off-by: Taku Izumi > --- > Documentation/kernel-parameters.txt | 15 +++ > arch/x86/kernel/setup.c | 4 +- > drivers/firmware/efi/Kconfig| 22 > drivers/firmware/efi/Makefile | 1 + > drivers/firmware/efi/fake_mem.c | 238 > > include/linux/efi.h | 6 + > 6 files changed, 285 insertions(+), 1 deletion(-) > create mode 100644 drivers/firmware/efi/fake_mem.c Looks good to me! I've queued this up with one minor change... > +config EFI_MAX_FAKE_MEM > + int "maximum allowable number of ranges in efi_fake_mem boot option" > + depends on EFI && X86 && EFI_FAKE_MEMMAP We can simplify this depends line since EFI_FAKE_MEMMAP itself is dependent on EFI and X86, and we should use that level of indirection to our advantage to save updating this line if/when arm64 support is added. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/20] kvm: rename pfn_t to kvm_pfn_t
On 10/10/2015 02:56, Dan Williams wrote:
> The core has developed a need for a "pfn_t" type [1]. Move the existing
> pfn_t in KVM to kvm_pfn_t [2].
>
> [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002199.html
> [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-September/002218.html
Can you please change also the other types in include/linux/kvm_types.h?
Thanks,
Paolo
> Cc: Dave Hansen
> Cc: Gleb Natapov
> Cc: Paolo Bonzini
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ralf Baechle
> Cc: Alexander Graf
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Signed-off-by: Dan Williams
> ---
> arch/arm/include/asm/kvm_mmu.h|5 ++--
> arch/arm/kvm/mmu.c| 10 ---
> arch/arm64/include/asm/kvm_mmu.h |3 +-
> arch/mips/include/asm/kvm_host.h |6 ++--
> arch/mips/kvm/emulate.c |2 +
> arch/mips/kvm/tlb.c | 14 +-
> arch/powerpc/include/asm/kvm_book3s.h |4 +--
> arch/powerpc/include/asm/kvm_ppc.h|2 +
> arch/powerpc/kvm/book3s.c |6 ++--
> arch/powerpc/kvm/book3s_32_mmu_host.c |2 +
> arch/powerpc/kvm/book3s_64_mmu_host.c |2 +
> arch/powerpc/kvm/e500.h |2 +
> arch/powerpc/kvm/e500_mmu_host.c |8 +++---
> arch/powerpc/kvm/trace_pr.h |2 +
> arch/x86/kvm/iommu.c | 11
> arch/x86/kvm/mmu.c| 37 +-
> arch/x86/kvm/mmu_audit.c |2 +
> arch/x86/kvm/paging_tmpl.h|6 ++--
> arch/x86/kvm/vmx.c|2 +
> arch/x86/kvm/x86.c|2 +
> include/linux/kvm_host.h | 37 +-
> include/linux/kvm_types.h |2 +
> virt/kvm/kvm_main.c | 47
> +
> 23 files changed, 110 insertions(+), 104 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 405aa1883307..8ebd282dfc2b 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -182,7 +182,8 @@ static inline bool vcpu_has_cache_enabled(struct kvm_vcpu
> *vcpu)
> return (vcpu->arch.cp15[c1_SCTLR] & 0b101) == 0b101;
> }
>
> -static inline void __coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t
> pfn,
> +static inline void __coherent_cache_guest_page(struct kvm_vcpu *vcpu,
> +kvm_pfn_t pfn,
> unsigned long size,
> bool ipa_uncached)
> {
> @@ -246,7 +247,7 @@ static inline void __kvm_flush_dcache_pte(pte_t pte)
> static inline void __kvm_flush_dcache_pmd(pmd_t pmd)
> {
> unsigned long size = PMD_SIZE;
> - pfn_t pfn = pmd_pfn(pmd);
> + kvm_pfn_t pfn = pmd_pfn(pmd);
>
> while (size) {
> void *va = kmap_atomic_pfn(pfn);
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 6984342da13d..e2dcbfdc4a8c 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -988,9 +988,9 @@ out:
> return ret;
> }
>
> -static bool transparent_hugepage_adjust(pfn_t *pfnp, phys_addr_t *ipap)
> +static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
> {
> - pfn_t pfn = *pfnp;
> + kvm_pfn_t pfn = *pfnp;
> gfn_t gfn = *ipap >> PAGE_SHIFT;
>
> if (PageTransCompound(pfn_to_page(pfn))) {
> @@ -1202,7 +1202,7 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm
> *kvm,
> kvm_mmu_write_protect_pt_masked(kvm, slot, gfn_offset, mask);
> }
>
> -static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, pfn_t pfn,
> +static void coherent_cache_guest_page(struct kvm_vcpu *vcpu, kvm_pfn_t pfn,
> unsigned long size, bool uncached)
> {
> __coherent_cache_guest_page(vcpu, pfn, size, uncached);
> @@ -1219,7 +1219,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa,
> struct kvm *kvm = vcpu->kvm;
> struct kvm_mmu_memory_cache *memcache = &vcpu->arch.mmu_page_cache;
> struct vm_area_struct *vma;
> - pfn_t pfn;
> + kvm_pfn_t pfn;
> pgprot_t mem_type = PAGE_S2;
> bool fault_ipa_uncached;
> bool logging_active = memslot_is_logging(memslot);
> @@ -1347,7 +1347,7 @@ static void handle_access_fault(struct kvm_vcpu *vcpu,
> phys_addr_t fault_ipa)
> {
> pmd_t *pmd;
> pte_t *pte;
> - pfn_t pfn;
> + kvm_pfn_t pfn;
> bool pfn_valid = false;
>
> trace_kvm_access_fault(fault_ipa);
> diff --git a/arch/arm64/include/asm/kvm_mmu.h
> b/arch/arm64/include/asm/kvm_mmu.h
> index 61505676d085..385fc8cef82d 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -230,7 +230,8 @@ static inline bool
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
On Sun, Oct 11, 2015 at 1:52 AM, punit vara wrote:
> On Sun, Oct 11, 2015 at 1:20 AM, Julia Lawall wrote:
>>
>>
>> On Sun, 11 Oct 2015, punit vara wrote:
>>
>>> On Sat, Oct 10, 2015 at 11:04 PM, Larry Finger
>>> wrote:
>>> > On 10/10/2015 11:58 AM, Punit Vara wrote:
>>> >>
>>> >> This patch is to the rtl871x_ioctl_linux.c file that fixes up following
>>> >> warning reported by checkpatch.pl :
>>> >>
>>> >> -Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
>>> >>
>>> >> bssid has datatype u8 and pnetwork->network.MacAddress has data type
>>> >> unsigned char.
>>> >>
>>> >> Signed-off-by: Punit Vara
>>> >> ---
>>> >> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
>>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>
>>> >> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>>> >> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>>> >> index 2ba055d..1c9092e 100644
>>> >> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>>> >> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>>> >> @@ -2007,7 +2007,7 @@ static int r871x_get_ap_info(struct net_device
>>> >> *dev,
>>> >> return -EINVAL;
>>> >> }
>>> >> netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
>>> >> - if (!memcmp(bssid, pnetwork->network.MacAddress,
>>> >> ETH_ALEN)) {
>>> >> + if (!ether_addr_equal(bssid, pnetwork->network)) {
>>> >> /* BSSID match, then check if supporting wpa/wpa2
>>> >> */
>>> >> pbuf =
>>> >> r8712_get_wpa_ie(&pnetwork->network.IEs[12],
>>> >>&wpa_ielen,
>>> >> pnetwork->network.IELength-12);
>>> >>
>>> >
>>> > The types of the variables are not what is important - it is the
>>> > alignment!
>>> >
>>> > I suggest that you read the definition of ether_addr_equal() and consider
>>> > what happens if either of the two addresses is not aligned to u16!
>>> >
>>> > You also have a logic error. Routine memcmp() returns zero when the two
>>> > arguments are equal. Thus !memcmp() will be true when they are equal.
>>> > Routine ether_addr_equal() returns true when the arguments are equal.
>>> > Whenever !memcmp() is correct and the arguments are aligned, then you need
>>> > to replace it with ether_addr_equal().
>>> >
>>> > The checkpatch script is a good tool for locating things to be changed;
>>> > however, if the change is other than cosmetic, you *MUST THINK* about what
>>> > is happening. Yes, rtl8712 is ugly code, but it works. Please do not break
>>> > it.
>>> >
>>> > NACK.
>>> >
>>> > Larry
>>> >
>>>
>>> @Larry I am thankful for your high quality feedback.
>>> if both address are aligned to u16 then we should use
>>> ether_addr_equal() if not then ether_addr_equal_unaligned().
>>>
>>> Both return true if addr1 and addr2 matches. If I am understand
>>> correctly bssid and MacAdress is not aligned to u16 .So right
>>> correction would be
>>> if(ether_addr_equal_unaligned(bssid, pnetwork->network))
>>>
>>> right ?
>>
>> You can use pahole to check the alignment. Use git log to find other
>> patches that mention the use of this tool to see what information to
>> provide in the commit message.
>>
>> julia
>
> Thanks Julia I didn't know about that dwarf utility I will go through
> it .sorry I have forgot to write MacAddress.
>
> So here solution could be either
>
> ether_addr_equal(bssid, pnetwork->network.MacAddress) or
> ether_addr_equal_unaligned(bssid->network.MacAddress)
>
> I will learn debugging with help of pahole and again send the patch.
Thanks Julia I didn't know about that dwarves utility I will go through
it .sorry I have forgot to write MacAddress.
So here solution could be either
ether_addr_equal(bssid, pnetwork->network.MacAddress) or
ether_addr_equal_unaligned(bssid, pnetwork->network.MacAddress)
I will learn debugging with help of pahole and again send the patch.
Sorry for inconvenience previous mail send before adding because my
laptop was hanged.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
On Sun, Oct 11, 2015 at 1:20 AM, Julia Lawall wrote:
>
>
> On Sun, 11 Oct 2015, punit vara wrote:
>
>> On Sat, Oct 10, 2015 at 11:04 PM, Larry Finger
>> wrote:
>> > On 10/10/2015 11:58 AM, Punit Vara wrote:
>> >>
>> >> This patch is to the rtl871x_ioctl_linux.c file that fixes up following
>> >> warning reported by checkpatch.pl :
>> >>
>> >> -Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
>> >>
>> >> bssid has datatype u8 and pnetwork->network.MacAddress has data type
>> >> unsigned char.
>> >>
>> >> Signed-off-by: Punit Vara
>> >> ---
>> >> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> >> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> >> index 2ba055d..1c9092e 100644
>> >> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> >> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> >> @@ -2007,7 +2007,7 @@ static int r871x_get_ap_info(struct net_device *dev,
>> >> return -EINVAL;
>> >> }
>> >> netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
>> >> - if (!memcmp(bssid, pnetwork->network.MacAddress,
>> >> ETH_ALEN)) {
>> >> + if (!ether_addr_equal(bssid, pnetwork->network)) {
>> >> /* BSSID match, then check if supporting wpa/wpa2
>> >> */
>> >> pbuf =
>> >> r8712_get_wpa_ie(&pnetwork->network.IEs[12],
>> >>&wpa_ielen, pnetwork->network.IELength-12);
>> >>
>> >
>> > The types of the variables are not what is important - it is the alignment!
>> >
>> > I suggest that you read the definition of ether_addr_equal() and consider
>> > what happens if either of the two addresses is not aligned to u16!
>> >
>> > You also have a logic error. Routine memcmp() returns zero when the two
>> > arguments are equal. Thus !memcmp() will be true when they are equal.
>> > Routine ether_addr_equal() returns true when the arguments are equal.
>> > Whenever !memcmp() is correct and the arguments are aligned, then you need
>> > to replace it with ether_addr_equal().
>> >
>> > The checkpatch script is a good tool for locating things to be changed;
>> > however, if the change is other than cosmetic, you *MUST THINK* about what
>> > is happening. Yes, rtl8712 is ugly code, but it works. Please do not break
>> > it.
>> >
>> > NACK.
>> >
>> > Larry
>> >
>>
>> @Larry I am thankful for your high quality feedback.
>> if both address are aligned to u16 then we should use
>> ether_addr_equal() if not then ether_addr_equal_unaligned().
>>
>> Both return true if addr1 and addr2 matches. If I am understand
>> correctly bssid and MacAdress is not aligned to u16 .So right
>> correction would be
>> if(ether_addr_equal_unaligned(bssid, pnetwork->network))
>>
>> right ?
>
> You can use pahole to check the alignment. Use git log to find other
> patches that mention the use of this tool to see what information to
> provide in the commit message.
>
> julia
Thanks Julia I didn't know about that dwarf utility I will go through
it .sorry I have forgot to write MacAddress.
So here solution could be either
ether_addr_equal(bssid, pnetwork->network.MacAddress) or
ether_addr_equal_unaligned(bssid->network.MacAddress)
I will learn debugging with help of pahole and again send the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: disable task group re-weighting on the desktop
Dear Mike, You CCed me on this patch. Is that because you expect this to solve "my" problem also? You had some measurements of many oinks vs many perts or vs "desktop", but not many oinks vs 1 or 2 perts as per my "complaint". You also changed the subject line, so maybe this is all un-related. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] usb: gadget: gserial: Privatize close_wait
[ forgot to addr Felipe here, sorry ]
On 10/10/2015 04:00 PM, Peter Hurley wrote:
> close_wait is no longer needed or provided by the tty core.
> Move close_wait to struct gs_port.
>
> Signed-off-by: Peter Hurley
> ---
> drivers/usb/gadget/function/u_serial.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c
> b/drivers/usb/gadget/function/u_serial.c
> index 7ee0579..42894f5 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -114,6 +114,7 @@ struct gs_port {
> struct gs_buf port_write_buf;
> wait_queue_head_t drain_wait; /* wait while writes drain */
> boolwrite_busy;
> + wait_queue_head_t close_wait;
>
> /* REVISIT this state ... */
> struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
> @@ -884,7 +885,7 @@ static void gs_close(struct tty_struct *tty, struct file
> *file)
> pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
> port->port_num, tty, file);
>
> - wake_up(&port->port.close_wait);
> + wake_up(&port->close_wait);
> exit:
> spin_unlock_irq(&port->port_lock);
> }
> @@ -1044,6 +1045,7 @@ gs_port_alloc(unsigned port_num, struct
> usb_cdc_line_coding *coding)
> tty_port_init(&port->port);
> spin_lock_init(&port->port_lock);
> init_waitqueue_head(&port->drain_wait);
> + init_waitqueue_head(&port->close_wait);
>
> tasklet_init(&port->push, gs_rx_push, (unsigned long) port);
>
> @@ -1074,7 +1076,7 @@ static void gserial_free_port(struct gs_port *port)
> {
> tasklet_kill(&port->push);
> /* wait for old opens to finish */
> - wait_event(port->port.close_wait, gs_closed(port));
> + wait_event(port->close_wait, gs_closed(port));
> WARN_ON(port->port_usb != NULL);
> tty_port_destroy(&port->port);
> kfree(port);
>
--
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/7] tty: Remove tty_wait_until_sent_from_close()
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
tty_wait_until_sent_from_close() was added by commit a57a7bf3fc7e
("TTY: define tty_wait_until_sent_from_close") to prevent the entire
tty subsystem from being unable to open new ttys while waiting for
one tty to close while output drained.
However, since commit 0911261d4cb6 ("tty: Don't take tty_mutex for tty
count changes"), holding a tty lock while closing does not prevent other
ttys from being opened/closed/hung up, but only prevents lifetime event
changes for the tty under lock.
Holding the tty lock while waiting for output to drain does prevent
parallel non-blocking opens (O_NONBLOCK) from advancing or returning
while the tty lock is held. However, all parallel opens _already_
block even if the tty lock is dropped while closing and the parallel
open advances. Blocking in open has been in mainline since at least 2.6.29
(see tty_port_block_til_ready(); note the test for O_NONBLOCK is _after_
the wait while ASYNC_CLOSING).
IOW, before this patch a non-blocking open will sleep anyway for the
_entire_ duration of a parallel hardware shutdown, and when it wakes, the
error return will cause a release of its tty, and it will restart with
a fresh attempt to open. Similarly with a blocking open that is already
waiting; when it's woken, the hardware shutdown has already completed
to ASYNC_INITIALIZED is not set, which forces a release and restart as
well.
So, holding the tty lock across the _entire_ close (which is what this
patch does), even while waiting for output to drain, is equivalent to
the current outcome wrt parallel opens.
Cc: Alan Cox
Cc: David Laight
CC: Arnd Bergmann
CC: Karsten Keil
CC: linuxppc-...@lists.ozlabs.org
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 2 +-
drivers/tty/hvc/hvc_console.c | 2 +-
drivers/tty/hvc/hvcs.c| 2 +-
drivers/tty/tty_port.c| 11 ++-
include/linux/tty.h | 18 --
5 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/drivers/isdn/i4l/isdn_tty.c b/drivers/isdn/i4l/isdn_tty.c
index bc91261..2175225 100644
--- a/drivers/isdn/i4l/isdn_tty.c
+++ b/drivers/isdn/i4l/isdn_tty.c
@@ -1582,7 +1582,7 @@ isdn_tty_close(struct tty_struct *tty, struct file *filp)
* line status register.
*/
if (port->flags & ASYNC_INITIALIZED) {
- tty_wait_until_sent_from_close(tty, 3000); /* 30 seconds
timeout */
+ tty_wait_until_sent(tty, 3000); /* 30 seconds timeout */
/*
* Before we drop DTR, make sure the UART transmitter
* has completely drained; this is especially
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 9c30f67..e46d628 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -418,7 +418,7 @@ static void hvc_close(struct tty_struct *tty, struct file *
filp)
* there is no buffered data otherwise sleeps on a wait queue
* waking periodically to check chars_in_buffer().
*/
- tty_wait_until_sent_from_close(tty, HVC_CLOSE_WAIT);
+ tty_wait_until_sent(tty, HVC_CLOSE_WAIT);
} else {
if (hp->port.count < 0)
printk(KERN_ERR "hvc_close %X: oops, count is %d\n",
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index f7ff97c..5997b17 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -1230,7 +1230,7 @@ static void hvcs_close(struct tty_struct *tty, struct
file *filp)
irq = hvcsd->vdev->irq;
spin_unlock_irqrestore(&hvcsd->lock, flags);
- tty_wait_until_sent_from_close(tty, HVCS_CLOSE_WAIT);
+ tty_wait_until_sent(tty, HVCS_CLOSE_WAIT);
/*
* This line is important because it tells hvcs_open that this
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 40b3183..d7d9f9c 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -463,10 +463,7 @@ static void tty_port_drain_delay(struct tty_port *port,
struct tty_struct *tty)
schedule_timeout_interruptible(timeout);
}
-/* Caller holds tty lock.
- * NB: may drop and reacquire tty lock (in tty_wait_until_sent_from_close())
- * so tty and tty port may have changed state (but not hung up or reopened).
- */
+/* Caller holds tty lock. */
int tty_port_close_start(struct tty_port *port,
struct tty_struct *tty, struct file *filp)
{
@@ -502,7 +499,7 @@ int tty_port_close_start(struct tty_port *port,
if (tty->flow_stopped)
tty_driver_flush_buffer(tty);
if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE)
- tty_wait_until_sent_from_
[PATCH 6/7] tty: r3964: Replace/remove bogus tty lock use
The tty lock is strictly for serializing tty lifetime events
(open/close/hangup), and not for line discipline serialization.
The tty core already provides serialization of concurrent writes
to the same tty, and line discipline lifetime management (by ldisc
references), so pinning the tty via tty_lock() is unnecessary and
counter-productive; remove tty lock use.
However, the line discipline is responsible for serializing reads
(if required by the line discipline); add read_lock mutex to
serialize calls of r3964_read().
Signed-off-by: Peter Hurley
---
drivers/tty/n_r3964.c | 20 +---
include/linux/n_r3964.h | 5 +++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/n_r3964.c b/drivers/tty/n_r3964.c
index 6fdef92..3451114 100644
--- a/drivers/tty/n_r3964.c
+++ b/drivers/tty/n_r3964.c
@@ -978,6 +978,7 @@ static int r3964_open(struct tty_struct *tty)
}
spin_lock_init(&pInfo->lock);
+ mutex_init(&pInfo->read_lock);
pInfo->tty = tty;
pInfo->priority = R3964_MASTER;
pInfo->rx_first = pInfo->rx_last = NULL;
@@ -1063,7 +1064,16 @@ static ssize_t r3964_read(struct tty_struct *tty, struct
file *file,
TRACE_L("read()");
- tty_lock(tty);
+ /*
+* Internal serialization of reads.
+*/
+ if (file->f_flags & O_NONBLOCK) {
+ if (!mutex_trylock(&pInfo->read_lock))
+ return -EAGAIN;
+ } else {
+ if (mutex_lock_interruptible(&pInfo->read_lock))
+ return -ERESTARTSYS;
+ }
pClient = findClient(pInfo, task_pid(current));
if (pClient) {
@@ -1075,7 +1085,7 @@ static ssize_t r3964_read(struct tty_struct *tty, struct
file *file,
goto unlock;
}
/* block until there is a message: */
- wait_event_interruptible_tty(tty, tty->read_wait,
+ wait_event_interruptible(tty->read_wait,
(pMsg = remove_msg(pInfo, pClient)));
}
@@ -1105,7 +1115,7 @@ static ssize_t r3964_read(struct tty_struct *tty, struct
file *file,
}
ret = -EPERM;
unlock:
- tty_unlock(tty);
+ mutex_unlock(&pInfo->read_lock);
return ret;
}
@@ -1154,8 +1164,6 @@ static ssize_t r3964_write(struct tty_struct *tty, struct
file *file,
pHeader->locks = 0;
pHeader->owner = NULL;
- tty_lock(tty);
-
pClient = findClient(pInfo, task_pid(current));
if (pClient) {
pHeader->owner = pClient;
@@ -1173,8 +1181,6 @@ static ssize_t r3964_write(struct tty_struct *tty, struct
file *file,
add_tx_queue(pInfo, pHeader);
trigger_transmit(pInfo);
- tty_unlock(tty);
-
return 0;
}
diff --git a/include/linux/n_r3964.h b/include/linux/n_r3964.h
index e9adb42..90a803a 100644
--- a/include/linux/n_r3964.h
+++ b/include/linux/n_r3964.h
@@ -161,8 +161,9 @@ struct r3964_info {
unsigned char last_rx;
unsigned char bcc;
unsigned int blocks_in_rx_queue;
-
-
+
+ struct mutex read_lock; /* serialize r3964_read */
+
struct r3964_client_info *firstClient;
unsigned int state;
unsigned int flags;
--
2.6.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 5/7] tty: r3964: Use tty->read_wait waitqueue
The tty core provides read_wait waitqueue specifically for line
disciplines to wait readers; otherwise, the line discipline may
miss wakeups generated by the tty core.
NB: The tty core already provides serialization for the line discipline's
close() method, and guarantees no readers or writers will be using the
closing instance of the line discipline. Completely remove that wakeup.
Signed-off-by: Peter Hurley
---
drivers/tty/n_r3964.c | 10 --
include/linux/n_r3964.h | 3 ---
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/n_r3964.c b/drivers/tty/n_r3964.c
index 8b157d6..6fdef92 100644
--- a/drivers/tty/n_r3964.c
+++ b/drivers/tty/n_r3964.c
@@ -276,7 +276,7 @@ static void remove_from_tx_queue(struct r3964_info *pInfo,
int error_code)
add_msg(pHeader->owner, R3964_MSG_ACK, pHeader->length,
error_code, NULL);
}
- wake_up_interruptible(&pInfo->read_wait);
+ wake_up_interruptible(&pInfo->tty->read_wait);
}
spin_lock_irqsave(&pInfo->lock, flags);
@@ -542,7 +542,7 @@ static void on_receive_block(struct r3964_info *pInfo)
pBlock);
}
}
- wake_up_interruptible(&pInfo->read_wait);
+ wake_up_interruptible(&pInfo->tty->read_wait);
pInfo->state = R3964_IDLE;
@@ -979,7 +979,6 @@ static int r3964_open(struct tty_struct *tty)
spin_lock_init(&pInfo->lock);
pInfo->tty = tty;
- init_waitqueue_head(&pInfo->read_wait);
pInfo->priority = R3964_MASTER;
pInfo->rx_first = pInfo->rx_last = NULL;
pInfo->tx_first = pInfo->tx_last = NULL;
@@ -1045,7 +1044,6 @@ static void r3964_close(struct tty_struct *tty)
}
/* Free buffers: */
- wake_up_interruptible(&pInfo->read_wait);
kfree(pInfo->rx_buf);
TRACE_M("r3964_close - rx_buf kfree %p", pInfo->rx_buf);
kfree(pInfo->tx_buf);
@@ -1077,7 +1075,7 @@ static ssize_t r3964_read(struct tty_struct *tty, struct
file *file,
goto unlock;
}
/* block until there is a message: */
- wait_event_interruptible_tty(tty, pInfo->read_wait,
+ wait_event_interruptible_tty(tty, tty->read_wait,
(pMsg = remove_msg(pInfo, pClient)));
}
@@ -1227,7 +1225,7 @@ static unsigned int r3964_poll(struct tty_struct *tty,
struct file *file,
pClient = findClient(pInfo, task_pid(current));
if (pClient) {
- poll_wait(file, &pInfo->read_wait, wait);
+ poll_wait(file, &tty->read_wait, wait);
spin_lock_irqsave(&pInfo->lock, flags);
pMsg = pClient->first_msg;
spin_unlock_irqrestore(&pInfo->lock, flags);
diff --git a/include/linux/n_r3964.h b/include/linux/n_r3964.h
index 5d0b2a1..e9adb42 100644
--- a/include/linux/n_r3964.h
+++ b/include/linux/n_r3964.h
@@ -152,9 +152,6 @@ struct r3964_info {
unsigned char *rx_buf;/* ring buffer */
unsigned char *tx_buf;
- wait_queue_head_t read_wait;
- //struct wait_queue *read_wait;
-
struct r3964_block_header *rx_first;
struct r3964_block_header *rx_last;
struct r3964_block_header *tx_first;
--
2.6.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 2/7] tty: Remove ASYNC_CLOSING checks in open()/hangup() methods
Since at least before 2.6.30, tty drivers that do not drop the tty lock
while closing cannot observe ASYNC_CLOSING set while holding the
tty lock; this includes the tty driver's open() and hangup() methods,
since the tty core calls these methods holding the tty lock.
For these drivers, waiting for ASYNC_CLOSING to clear while opening
is not required, since this condition cannot occur. Similarly, even
when the open() method drops and reacquires the tty lock after
blocking, ASYNC_CLOSING cannot be set (again, for drivers that
do not drop the tty lock while closing).
Now that tty port drivers no longer drop the tty lock while closing
(since 'tty: Remove tty_wait_until_sent_from_close()'), the same
conditions apply: waiting for ASYNC_CLOSING to clear while opening
is not required, nor is re-checking ASYNC_CLOSING after dropping and
reacquiring the tty lock while blocking (eg., in *_block_til_ready()).
Note: The ASYNC_CLOSING flag state is still maintained since several
bitrotting drivers use it for (dubious) other purposes.
Signed-off-by: Peter Hurley
---
drivers/char/pcmcia/synclink_cs.c | 9 -
drivers/tty/cyclades.c| 9 -
drivers/tty/rocket.c | 12
drivers/tty/serial/crisv10.c | 33 +
drivers/tty/synclink.c| 18 --
drivers/tty/synclink_gt.c | 14 ++
drivers/tty/synclinkmp.c | 14 ++
drivers/tty/tty_port.c| 13 +
net/irda/ircomm/ircomm_tty.c | 31 +--
9 files changed, 11 insertions(+), 142 deletions(-)
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 7680d52..45df4bf 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -2507,15 +2507,6 @@ static int mgslpc_open(struct tty_struct *tty, struct
file * filp)
printk("%s(%d):mgslpc_open(%s), old ref count = %d\n",
__FILE__, __LINE__, tty->driver->name, port->count);
- /* If port is closing, signal caller to try again */
- if (port->flags & ASYNC_CLOSING){
- wait_event_interruptible_tty(tty, port->close_wait,
-!(port->flags & ASYNC_CLOSING));
- retval = ((port->flags & ASYNC_HUP_NOTIFY) ?
- -EAGAIN : -ERESTARTSYS);
- goto cleanup;
- }
-
port->low_latency = (port->flags & ASYNC_LOW_LATENCY) ? 1 : 0;
spin_lock_irqsave(&info->netlock, flags);
diff --git a/drivers/tty/cyclades.c b/drivers/tty/cyclades.c
index 87f6578..d4a1331 100644
--- a/drivers/tty/cyclades.c
+++ b/drivers/tty/cyclades.c
@@ -1577,15 +1577,6 @@ static int cy_open(struct tty_struct *tty, struct file
*filp)
#endif
/*
-* If the port is the middle of closing, bail out now
-*/
- if (info->port.flags & ASYNC_CLOSING) {
- wait_event_interruptible_tty(tty, info->port.close_wait,
- !(info->port.flags & ASYNC_CLOSING));
- return (info->port.flags & ASYNC_HUP_NOTIFY) ? -EAGAIN:
-ERESTARTSYS;
- }
-
- /*
* Start up serial port
*/
retval = cy_startup(info, tty);
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index c8dd8dc..69c72d1 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -895,14 +895,6 @@ static int rp_open(struct tty_struct *tty, struct file
*filp)
if (!page)
return -ENOMEM;
- if (port->flags & ASYNC_CLOSING) {
- retval = wait_for_completion_interruptible(&info->close_wait);
- free_page(page);
- if (retval)
- return retval;
- return ((port->flags & ASYNC_HUP_NOTIFY) ? -EAGAIN :
-ERESTARTSYS);
- }
-
/*
* We must not sleep from here until the port is marked fully in use.
*/
@@ -1511,10 +1503,6 @@ static void rp_hangup(struct tty_struct *tty)
#endif
rp_flush_buffer(tty);
spin_lock_irqsave(&info->port.lock, flags);
- if (info->port.flags & ASYNC_CLOSING) {
- spin_unlock_irqrestore(&info->port.lock, flags);
- return;
- }
if (info->port.count)
atomic_dec(&rp_num_ports_open);
clear_bit((info->aiop * 8) + info->chan, (void *)
&xmit_flags[info->board]);
diff --git a/drivers/tty/serial/crisv10.c b/drivers/tty/serial/crisv10.c
index 3e4470a..06f4fe9 100644
--- a/drivers/tty/serial/crisv10.c
+++ b/drivers/tty/serial/crisv10.c
@@ -3759,23 +3759,6 @@ block_til_ready(struct tty_struct *tty, struct file *
filp,
int do_clocal = 0;
/*
-* If the device is in the middle of being closed, then block
-* until it's done, and then try again.
-*/
- if (info->port.flags & ASYNC_CLOSING) {
- wait
[PATCH 4/7] tty: Remove tty_port::close_wait
With the removal of tty_wait_until_sent_from_close(), tty drivers
no longer wait during open for parallel closes to complete (instead,
the tty core waits before calling the driver open() method). Thus,
the close_wait waitqueue is no longer used for waiting.
Remove struct tty_port::close_wait.
Signed-off-by: Peter Hurley
---
drivers/tty/rocket.c | 1 -
drivers/tty/serial/68328serial.c | 1 -
drivers/tty/serial/crisv10.c | 1 -
drivers/tty/serial/serial_core.c | 1 -
drivers/tty/tty_port.c | 2 --
include/linux/tty.h | 1 -
6 files changed, 7 deletions(-)
diff --git a/drivers/tty/rocket.c b/drivers/tty/rocket.c
index 69c72d1..802eac7 100644
--- a/drivers/tty/rocket.c
+++ b/drivers/tty/rocket.c
@@ -1049,7 +1049,6 @@ static void rp_close(struct tty_struct *tty, struct file
*filp)
mutex_unlock(&port->mutex);
tty_port_tty_set(port, NULL);
- wake_up_interruptible(&port->close_wait);
complete_all(&info->close_wait);
atomic_dec(&rp_num_ports_open);
diff --git a/drivers/tty/serial/68328serial.c b/drivers/tty/serial/68328serial.c
index 9ba0c93..0140ba4 100644
--- a/drivers/tty/serial/68328serial.c
+++ b/drivers/tty/serial/68328serial.c
@@ -1071,7 +1071,6 @@ static void rs_close(struct tty_struct *tty, struct file
* filp)
wake_up_interruptible(&port->open_wait);
}
port->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
- wake_up_interruptible(&port->close_wait);
local_irq_restore(flags);
}
diff --git a/drivers/tty/serial/crisv10.c b/drivers/tty/serial/crisv10.c
index 06f4fe9..f13f2eb 100644
--- a/drivers/tty/serial/crisv10.c
+++ b/drivers/tty/serial/crisv10.c
@@ -3655,7 +3655,6 @@ rs_close(struct tty_struct *tty, struct file * filp)
wake_up_interruptible(&info->port.open_wait);
}
info->port.flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
- wake_up_interruptible(&info->port.close_wait);
local_irq_restore(flags);
/* port closed */
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index df4271a..def5199 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1437,7 +1437,6 @@ static void uart_close(struct tty_struct *tty, struct
file *filp)
clear_bit(ASYNCB_CLOSING, &port->flags);
spin_unlock_irq(&port->lock);
wake_up_interruptible(&port->open_wait);
- wake_up_interruptible(&port->close_wait);
mutex_unlock(&port->mutex);
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 0e1cf04..e04a8cf 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -22,7 +22,6 @@ void tty_port_init(struct tty_port *port)
memset(port, 0, sizeof(*port));
tty_buffer_init(port);
init_waitqueue_head(&port->open_wait);
- init_waitqueue_head(&port->close_wait);
init_waitqueue_head(&port->delta_msr_wait);
mutex_init(&port->mutex);
mutex_init(&port->buf_mutex);
@@ -520,7 +519,6 @@ void tty_port_close_end(struct tty_port *port, struct
tty_struct *tty)
wake_up_interruptible(&port->open_wait);
}
port->flags &= ~(ASYNC_NORMAL_ACTIVE | ASYNC_CLOSING);
- wake_up_interruptible(&port->close_wait);
spin_unlock_irqrestore(&port->lock, flags);
}
EXPORT_SYMBOL(tty_port_close_end);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 614c822..090ce2a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -227,7 +227,6 @@ struct tty_port {
int blocked_open; /* Waiting to open */
int count; /* Usage count */
wait_queue_head_t open_wait; /* Open waiters */
- wait_queue_head_t close_wait; /* Close waiters */
wait_queue_head_t delta_msr_wait; /* Modem status change */
unsigned long flags; /* TTY flags ASY_*/
unsigned char console:1, /* port is a console */
--
2.6.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 7/7] tty: Remove wait_event_interruptible_tty()
In-tree users of wait_event_interruptible_tty() have been removed;
remove.
Signed-off-by: Peter Hurley
---
include/linux/tty.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 090ce2a..c2889f4 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -655,32 +655,6 @@ extern void __lockfunc tty_unlock(struct tty_struct *tty);
extern void __lockfunc tty_lock_slave(struct tty_struct *tty);
extern void __lockfunc tty_unlock_slave(struct tty_struct *tty);
extern void tty_set_lock_subclass(struct tty_struct *tty);
-/*
- * wait_event_interruptible_tty -- wait for a condition with the tty lock held
- *
- * The condition we are waiting for might take a long time to
- * become true, or might depend on another thread taking the
- * BTM. In either case, we need to drop the BTM to guarantee
- * forward progress. This is a leftover from the conversion
- * from the BKL and should eventually get removed as the BTM
- * falls out of use.
- *
- * Do not use in new code.
- */
-#define wait_event_interruptible_tty(tty, wq, condition) \
-({ \
- int __ret = 0; \
- if (!(condition)) \
- __ret = __wait_event_interruptible_tty(tty, wq, \
- condition); \
- __ret; \
-})
-
-#define __wait_event_interruptible_tty(tty, wq, condition) \
- ___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0, \
- tty_unlock(tty);\
- schedule(); \
- tty_lock(tty))
#ifdef CONFIG_PROC_FS
extern void proc_tty_register_driver(struct tty_driver *);
--
2.6.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 3/7] usb: gadget: gserial: Privatize close_wait
close_wait is no longer needed or provided by the tty core.
Move close_wait to struct gs_port.
Signed-off-by: Peter Hurley
---
drivers/usb/gadget/function/u_serial.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 7ee0579..42894f5 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -114,6 +114,7 @@ struct gs_port {
struct gs_buf port_write_buf;
wait_queue_head_t drain_wait; /* wait while writes drain */
boolwrite_busy;
+ wait_queue_head_t close_wait;
/* REVISIT this state ... */
struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
@@ -884,7 +885,7 @@ static void gs_close(struct tty_struct *tty, struct file
*file)
pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
port->port_num, tty, file);
- wake_up(&port->port.close_wait);
+ wake_up(&port->close_wait);
exit:
spin_unlock_irq(&port->port_lock);
}
@@ -1044,6 +1045,7 @@ gs_port_alloc(unsigned port_num, struct
usb_cdc_line_coding *coding)
tty_port_init(&port->port);
spin_lock_init(&port->port_lock);
init_waitqueue_head(&port->drain_wait);
+ init_waitqueue_head(&port->close_wait);
tasklet_init(&port->push, gs_rx_push, (unsigned long) port);
@@ -1074,7 +1076,7 @@ static void gserial_free_port(struct gs_port *port)
{
tasklet_kill(&port->push);
/* wait for old opens to finish */
- wait_event(port->port.close_wait, gs_closed(port));
+ wait_event(port->close_wait, gs_closed(port));
WARN_ON(port->port_usb != NULL);
tty_port_destroy(&port->port);
kfree(port);
--
2.6.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 0/7] tty close cleanup
Hi Greg,
This series is a redux of cleanup I originally submitted back in 2014;
the point is to remove the cruft which stems from dropping the tty lock
while waiting for output to drain before closing the tty.
Dropping the tty lock during close was added by "TTY: define
tty_wait_until_sent_from_close" to fix stalls on other parallel tty
operations while a tty was draining output while closing.
Since commit 89c8d91e31f2 ("tty: localise the lock") and commit
aa3cb814a8ef ("tty: Drop tty_mutex before tty reopen"), parallel tty
open/close/hangup on _other_ ttys no longer stall waiting for a tty
close to complete.
Continuing to hold the tty lock for the tty which is closing significantly
simplifies the state handling when opening a tty, since the tty cannot
have been closed concurrently. [Ideally, I would have liked to entirely
remove the TTY_CLOSING state flag, but unfortunately some older bit-rotting
drivers have co-opted it for dubious purposes].
In the previous series, David Laight had raised concerns about non-blocking
opens on the _same_ tty which is closing. However, as I pointed out in this
reply http://www.spinics.net/lists/linux-serial/msg14216.html, the outcome of
a parallel open while closing the same tty has not changed with this series,
since the existing code has blocked while ASYNC_CLOSING (and has done since at
least before 2.6.29).
I cc'd the commenters from the original series, Felipe Balbi for the gserial
usb gadget changes, and David Miller for the ISDN/IRDA changes.
Regards,
Peter Hurley (7):
tty: Remove tty_wait_until_sent_from_close()
tty: Remove ASYNC_CLOSING checks in open()/hangup() methods
usb: gadget: gserial: Privatize close_wait
tty: Remove tty_port::close_wait
tty: r3964: Use tty->read_wait waitqueue
tty: r3964: Replace/remove bogus tty lock use
tty: Remove wait_event_interruptible_tty()
drivers/char/pcmcia/synclink_cs.c | 9 ---
drivers/isdn/i4l/isdn_tty.c| 2 +-
drivers/tty/cyclades.c | 9 ---
drivers/tty/hvc/hvc_console.c | 2 +-
drivers/tty/hvc/hvcs.c | 2 +-
drivers/tty/n_r3964.c | 28 -
drivers/tty/rocket.c | 13 --
drivers/tty/serial/68328serial.c | 1 -
drivers/tty/serial/crisv10.c | 34 +
drivers/tty/serial/serial_core.c | 1 -
drivers/tty/synclink.c | 18 +++---
drivers/tty/synclink_gt.c | 14 ++-
drivers/tty/synclinkmp.c | 14 ++-
drivers/tty/tty_port.c | 26 +++-
drivers/usb/gadget/function/u_serial.c | 6 +++--
include/linux/n_r3964.h| 8 +++---
include/linux/tty.h| 45 --
net/irda/ircomm/ircomm_tty.c | 31 +--
18 files changed, 39 insertions(+), 224 deletions(-)
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix OpenFirmware support
On Sat, Oct 10, 2015 at 3:29 PM, Laurent Vivier wrote: > > > Le 10/10/2015 20:41, Ilia Mirkin a écrit : >> Hi Laurent, >> >> On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: >>> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() >>> returns NULL. But in fact the OpenFirmware has given us the size >>> we can store in image->size. >>> >>> This size is stored in bios->size by of_init() as there is no way >>> to retrieve it otherwise. And as we know the size, copy all data >>> to bios->data. >>> >>> Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). >> >> Can you give this patch a shot instead? >> >> http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63cc75eada9ad6b2a0275c1c8c4d3522864f > > Well, I think mine is also a good solution and it is much more simple. > ;) > > ... because it is useless to add a size() function if we can directly > copy the content/size of the bios in bios->data and bios->size. > We can do that because we have the size of the property, which is not > the case when we discover the BIOS directly from a PCI ROM or from ACPI > (this is why we need a shadow, I think). I'll let Ben rule on this. > > For pcir part, I think we can just ignore the result and take the size > from bios->size, as in the case of non openfirmware bios->size will be 4 > (we have only shadowed the first word to read the id, 0xaa55) and then > the checksum and others ID searches will fail. So I think the checksum > should not be ignored. Non-OF will still end up with a NVDA,BMP file? That seems surprising. My understanding is that if OF has it, it should be used. The problem is that e.g. on my GPU I have a perfectly valid PCI ROM, whose checksum matches and everything, but it contains who-knows-what apple happened to leave in there. So I still want OF. Ignoring checksum failures allows nouveau to always select the OF vbios. > > I've tried to restore behavior before commit: > > 7af4dec drm/nouveau/bios: use size/type from pci data structure > > and commit: > > ad4a362 drm/nouveau/bios: split out shadow methods > > Originally, openfirmware content was copied directly into bios->data: Yeah, but then the whole interface was redone. > > 77145f1 drm/nouveau: port remainder of drm code, and rip out compat layer > >> This resolved my issues on a PPC G5 + NV34. I think mine ran into a >> few additional problems that you didn't see -- no PCIR header and >> invalid checksum. > > I have no PCIR header too. Er right. I realized that shortly after I sent the email. However my bios isn't even 0x1000 in size, so the read would fail due to not enough length. (It's also an odd number in size, and your patch chops off the last few bytes.) The read could, of course, be reduced in size, but that whole logic is to deal with multiple parts in a vbios, which on GM20x contain some necessary blobs. I wasn't sure where the 0x1000 came from or whether it was significant. > > Could you send me the content of the file "NVDA,BMP" you can find > somewhere under /proc/device-tree/ ? http://filebin.ca/2Ib4SdDOAQqC/nv34-vbios.rom Note that it's a 2404 byte file as uploaded, but that was from an attempt to do something silly -- in reality it's 2403 bytes. > > Could you try my patch on your system, please ? My G5 is off for now, and the time I do spend with it goes towards working out mesa issues (it should kinda-sorta work with Mesa 11.0.3 again btw). If I have time, I'll try it out. -ilia -- 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] Staging: rtl8712: fix warning for placing constant on the right side of test
On Sat, Oct 10, 2015 at 10:37 PM, Julia Lawall wrote:
>
>
> On Sat, 10 Oct 2015, Punit Vara wrote:
>
>> This patch is to the rtl871x_ioctl_linux.c file that fixes up following
>
> The entire above line doesn't give any information (except the file name,
> but that can easily be seen from what comes just below). A commit message
> that would get to the point (what you did) more quickly could be something
> like: "Put constant on the right side of a test. Problem found using
> checkpatch."
>
> julia
>
>> warnings reported by checkpatch.pl:
>>
>> -Comparisons should place the constant on the right side of the test
>>
>> Signed-off-by: Punit Vara
>> ---
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> index fc1028a..e9852ae 100644
>> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> @@ -959,7 +959,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
>> if (IS_ERR(ext))
>> return PTR_ERR(ext);
>>
>> - if (0 == strcasecmp(ext, "RSSI")) {
>> + if (strcasecmp(ext, "RSSI") == 0) {
>> /*Return received signal strength indicator in -db for */
>> /* current AP */
>> /* Rssi xx */
>> @@ -976,7 +976,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
>> } else {
>> sprintf(ext, "OK");
>> }
>> - } else if (0 == strcasecmp(ext, "LINKSPEED")) {
>> + } else if (strcasecmp(ext, "LINKSPEED") == 0) {
>> /*Return link speed in MBPS */
>> /*LinkSpeed xx */
>> union iwreq_data wrqd;
>> @@ -984,30 +984,30 @@ static int r871x_wx_set_priv(struct net_device *dev,
>> int mbps;
>>
>> ret_inner = r8711_wx_get_rate(dev, info, &wrqd, extra);
>> - if (0 != ret_inner)
>> + if (ret_inner != 0)
>> mbps = 0;
>> else
>> mbps = wrqd.bitrate.value / 100;
>> sprintf(ext, "LINKSPEED %d", mbps);
>> - } else if (0 == strcasecmp(ext, "MACADDR")) {
>> + } else if (strcasecmp(ext, "MACADDR") == 0) {
>> /*Return mac address of the station */
>> /* Macaddr = xx:xx:xx:xx:xx:xx */
>> sprintf(ext, "MACADDR = %pM", dev->dev_addr);
>> - } else if (0 == strcasecmp(ext, "SCAN-ACTIVE")) {
>> + } else if (strcasecmp(ext, "SCAN-ACTIVE") == 0) {
>> /*Set scan type to active */
>> /*OK if successful */
>> struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
>>
>> pmlmepriv->passive_mode = 1;
>> sprintf(ext, "OK");
>> - } else if (0 == strcasecmp(ext, "SCAN-PASSIVE")) {
>> + } else if (strcasecmp(ext, "SCAN-PASSIVE") == 0) {
>> /*Set scan type to passive */
>> /*OK if successful */
>> struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
>>
>> pmlmepriv->passive_mode = 0;
>> sprintf(ext, "OK");
>> - } else if (0 == strncmp(ext, "DCE-E", 5)) {
>> + } else if (strncmp(ext, "DCE-E", 5) == 0) {
>> /*Set scan type to passive */
>> /*OK if successful */
>> r8712_disconnectCtrlEx_cmd(padapter
>> @@ -1017,7 +1017,7 @@ static int r871x_wx_set_priv(struct net_device *dev,
>> , 5000 /*u32 firstStageTO */
>> );
>> sprintf(ext, "OK");
>> - } else if (0 == strncmp(ext, "DCE-D", 5)) {
>> + } else if (strncmp(ext, "DCE-D", 5) == 0) {
>> /*Set scan type to passive */
>> /*OK if successfu */
>> r8712_disconnectCtrlEx_cmd(padapter
>> --
>> 2.5.3
>>
>>
I thought warning is clearly showing that constant should be on right
side that's why I did not include any extra detail just include one
warning in patch. But surely from next time I will follow your as per
your valuable feedback.
Thanks
Punit Vara
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
On Sun, 11 Oct 2015, punit vara wrote:
> On Sat, Oct 10, 2015 at 11:04 PM, Larry Finger
> wrote:
> > On 10/10/2015 11:58 AM, Punit Vara wrote:
> >>
> >> This patch is to the rtl871x_ioctl_linux.c file that fixes up following
> >> warning reported by checkpatch.pl :
> >>
> >> -Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
> >>
> >> bssid has datatype u8 and pnetwork->network.MacAddress has data type
> >> unsigned char.
> >>
> >> Signed-off-by: Punit Vara
> >> ---
> >> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> >> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> >> index 2ba055d..1c9092e 100644
> >> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> >> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> >> @@ -2007,7 +2007,7 @@ static int r871x_get_ap_info(struct net_device *dev,
> >> return -EINVAL;
> >> }
> >> netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
> >> - if (!memcmp(bssid, pnetwork->network.MacAddress,
> >> ETH_ALEN)) {
> >> + if (!ether_addr_equal(bssid, pnetwork->network)) {
> >> /* BSSID match, then check if supporting wpa/wpa2
> >> */
> >> pbuf =
> >> r8712_get_wpa_ie(&pnetwork->network.IEs[12],
> >>&wpa_ielen, pnetwork->network.IELength-12);
> >>
> >
> > The types of the variables are not what is important - it is the alignment!
> >
> > I suggest that you read the definition of ether_addr_equal() and consider
> > what happens if either of the two addresses is not aligned to u16!
> >
> > You also have a logic error. Routine memcmp() returns zero when the two
> > arguments are equal. Thus !memcmp() will be true when they are equal.
> > Routine ether_addr_equal() returns true when the arguments are equal.
> > Whenever !memcmp() is correct and the arguments are aligned, then you need
> > to replace it with ether_addr_equal().
> >
> > The checkpatch script is a good tool for locating things to be changed;
> > however, if the change is other than cosmetic, you *MUST THINK* about what
> > is happening. Yes, rtl8712 is ugly code, but it works. Please do not break
> > it.
> >
> > NACK.
> >
> > Larry
> >
>
> @Larry I am thankful for your high quality feedback.
> if both address are aligned to u16 then we should use
> ether_addr_equal() if not then ether_addr_equal_unaligned().
>
> Both return true if addr1 and addr2 matches. If I am understand
> correctly bssid and MacAdress is not aligned to u16 .So right
> correction would be
> if(ether_addr_equal_unaligned(bssid, pnetwork->network))
>
> right ?
You can use pahole to check the alignment. Use git log to find other
patches that mention the use of this tool to see what information to
provide in the commit message.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] Staging: rtl8712: Use ether_addr_equal() over memcmp()
On Sat, Oct 10, 2015 at 11:04 PM, Larry Finger
wrote:
> On 10/10/2015 11:58 AM, Punit Vara wrote:
>>
>> This patch is to the rtl871x_ioctl_linux.c file that fixes up following
>> warning reported by checkpatch.pl :
>>
>> -Prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()
>>
>> bssid has datatype u8 and pnetwork->network.MacAddress has data type
>> unsigned char.
>>
>> Signed-off-by: Punit Vara
>> ---
>> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> index 2ba055d..1c9092e 100644
>> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
>> @@ -2007,7 +2007,7 @@ static int r871x_get_ap_info(struct net_device *dev,
>> return -EINVAL;
>> }
>> netdev_info(dev, "r8712u: BSSID:%pM\n", bssid);
>> - if (!memcmp(bssid, pnetwork->network.MacAddress,
>> ETH_ALEN)) {
>> + if (!ether_addr_equal(bssid, pnetwork->network)) {
>> /* BSSID match, then check if supporting wpa/wpa2
>> */
>> pbuf =
>> r8712_get_wpa_ie(&pnetwork->network.IEs[12],
>>&wpa_ielen, pnetwork->network.IELength-12);
>>
>
> The types of the variables are not what is important - it is the alignment!
>
> I suggest that you read the definition of ether_addr_equal() and consider
> what happens if either of the two addresses is not aligned to u16!
>
> You also have a logic error. Routine memcmp() returns zero when the two
> arguments are equal. Thus !memcmp() will be true when they are equal.
> Routine ether_addr_equal() returns true when the arguments are equal.
> Whenever !memcmp() is correct and the arguments are aligned, then you need
> to replace it with ether_addr_equal().
>
> The checkpatch script is a good tool for locating things to be changed;
> however, if the change is other than cosmetic, you *MUST THINK* about what
> is happening. Yes, rtl8712 is ugly code, but it works. Please do not break
> it.
>
> NACK.
>
> Larry
>
@Larry I am thankful for your high quality feedback.
if both address are aligned to u16 then we should use
ether_addr_equal() if not then ether_addr_equal_unaligned().
Both return true if addr1 and addr2 matches. If I am understand
correctly bssid and MacAdress is not aligned to u16 .So right
correction would be
if(ether_addr_equal_unaligned(bssid, pnetwork->network))
right ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] atm: iphase: return -ENOMEM instead of -1 in case of failed kmalloc()
Smatch complains about returning hard coded error codes, silence this
warning.
drivers/atm/iphase.c:115 ia_enque_rtn_q() warn: returning -1 instead of -ENOMEM
is sloppy
Signed-off-by: Tillmann Heidsieck
---
drivers/atm/iphase.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 65e65903faa0..d5010d7a99c3 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -112,7 +112,8 @@ static void ia_enque_head_rtn_q (IARTN_Q *que, IARTN_Q *
data)
static int ia_enque_rtn_q (IARTN_Q *que, struct desc_tbl_t data) {
IARTN_Q *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
- if (!entry) return -1;
+ if (!entry)
+ return -ENOMEM;
entry->data = data;
entry->next = NULL;
if (que->next == NULL)
--
2.6.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 0/2] atm: iphase: Fix misleading indention and return -ENOMEM on error
OK here it goes ...
There are three non-indention specific smatch warnings in atm/iphase.c
drivers/atm/iphase.c:115 ia_enque_rtn_q() warn: returning -1 instead of -ENOMEM
is sloppy
drivers/atm/iphase.c:148 ia_hack_tcq() warn: if();
drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended?
this series fixes two of them. The if(); warning would require
restructuring the code to a larger extend. Beyond this there remains a
whooping number of > 2k checkpatch.pl warnings and errors each. Those
can be grouped into
- Direct usage of printk()
- Style issues concerning operators
- Style issues concerning {}
- Indention with spaces, mixed tabs and spaces etc
- Trailing white-spaces
Generally I would not mind cleaning all this up for those who have to
make functional changes to the driver. However, I would like to know
from the maintainers if such an afford would be welcome or not.
Regards,
Tillmann Heidsieck
Tillmann Heidsieck (2):
atm: iphase: return -ENOMEM instead of -1 in case of failed kmalloc()
atm: iphase: fix misleading indention
drivers/atm/iphase.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
2.6.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 2/2] atm: iphase: fix misleading indention
Fix a smatch warning:
drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended?
The code is correct, the indention is misleading. In case the allocation
of skb fails, we want to skip to the end.
Signed-off-by: Tillmann Heidsieck
---
drivers/atm/iphase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index d5010d7a99c3..7d00f2994738 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -1176,7 +1176,7 @@ static int rx_pkt(struct atm_dev *dev)
if (!(skb = atm_alloc_charge(vcc, len, GFP_ATOMIC))) {
if (vcc->vci < 32)
printk("Drop control packets\n");
- goto out_free_desc;
+ goto out_free_desc;
}
skb_put(skb,len);
// pwang_test
--
2.6.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] doc: Clarify that nmi_watchdog param is for hardlockups
The kernel NMI watchdog acts as both a hardlockup and softlockup detector. However, the kernel parameter nmi_watchdog can only enable or disable the hardlockup detector. Clarify that in the documentation. Signed-off-by: Pranith Kumar --- Documentation/kernel-parameters.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6fecc72..5b83279 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2329,11 +2329,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels Format: [panic,][nopanic,][num] Valid num: 0 or 1 - 0 - turn nmi_watchdog off - 1 - turn nmi_watchdog on + 0 - turn hardlockup detector in nmi_watchdog off + 1 - turn hardlockup detector in nmi_watchdog on When panic is specified, panic when an NMI watchdog timeout occurs (or 'nopanic' to override the opposite - default). + default). To disable both hard and soft lockup detectors, + please see 'nowatchdog'. This is useful when you use a panic=... timeout and need the box quickly up again. -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86, efi: rename print_efi_memmap() to efi_print_memmap()
On Wed, 30 Sep, at 07:20:00PM, Taku Izumi wrote: > This patch renames print_efi_memmap() to efi_print_memmap() and > make it global function so that we can invoke it outside of > arch/x86/platform/efi/efi.c > > Signed-off-by: Taku Izumi > --- > arch/x86/include/asm/efi.h | 1 + > arch/x86/platform/efi/efi.c | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) Thanks, applied. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix OpenFirmware support
Le 10/10/2015 20:41, Ilia Mirkin a écrit : > Hi Laurent, > > On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: >> On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() >> returns NULL. But in fact the OpenFirmware has given us the size >> we can store in image->size. >> >> This size is stored in bios->size by of_init() as there is no way >> to retrieve it otherwise. And as we know the size, copy all data >> to bios->data. >> >> Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). > > Can you give this patch a shot instead? > > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63cc75eada9ad6b2a0275c1c8c4d3522864f Well, I think mine is also a good solution and it is much more simple. ;) ... because it is useless to add a size() function if we can directly copy the content/size of the bios in bios->data and bios->size. We can do that because we have the size of the property, which is not the case when we discover the BIOS directly from a PCI ROM or from ACPI (this is why we need a shadow, I think). For pcir part, I think we can just ignore the result and take the size from bios->size, as in the case of non openfirmware bios->size will be 4 (we have only shadowed the first word to read the id, 0xaa55) and then the checksum and others ID searches will fail. So I think the checksum should not be ignored. I've tried to restore behavior before commit: 7af4dec drm/nouveau/bios: use size/type from pci data structure and commit: ad4a362 drm/nouveau/bios: split out shadow methods Originally, openfirmware content was copied directly into bios->data: 77145f1 drm/nouveau: port remainder of drm code, and rip out compat layer > This resolved my issues on a PPC G5 + NV34. I think mine ran into a > few additional problems that you didn't see -- no PCIR header and > invalid checksum. I have no PCIR header too. Could you send me the content of the file "NVDA,BMP" you can find somewhere under /proc/device-tree/ ? Could you try my patch on your system, please ? 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/
[PATCH 2/2 v3] drivers: staging: rtl8723au: Changed raid_cmd to little-endian mask
From: Jacob Kiefer
Changed raid_cmd interface to accept le32 mask instead of
u32 and converting internally. Updated existing calls to raid_cmd.
This patch pushes responsibility to the caller to convert
the mask to le32 and opts for a temp local struct instead of
memset/memcpy. This cleans up the code considerably.
Also removed magic numbers.
This patch fixes the following sparse error:
CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
...
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
expected unsigned int [unsigned] [usertype] mask
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
got restricted __le32 [usertype]
...
Signed-off-by: Jacob Kiefer
---
In v3, opted to change the interface rather than just the internal
code, and removed ugly memcpy/memset. This clears sparse errors
and makes the code more sane.
---
drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c| 17 -
drivers/staging/rtl8723au/hal/usb_halinit.c | 2 +-
drivers/staging/rtl8723au/include/rtl8723a_cmd.h| 2 +-
4 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
index cf15f80..2b369b6 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
@@ -5870,7 +5870,7 @@ btdm_1AntUpdateHalRAMask(struct rtw_adapter *padapter,
u32 mac_id, u32 filter)
("[BTCoex], Update FW RAID entry, MASK = 0x%08x, "
"arg = 0x%02x\n", mask, arg));
- rtl8723a_set_raid_cmd(padapter, mask, arg);
+ rtl8723a_set_raid_cmd(padapter, cpu_to_le32(mask), arg);
psta->init_rate = init_rate;
pdmpriv->INIDATA_RATE[mac_id] = init_rate;
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 97d23c3..0e0d3f1 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -26,6 +26,7 @@
#define MESSAGE_BOX_SIZE 4
#define EX_MESSAGE_BOX_SIZE2
#define RSSI_CMD_LEN 3
+#define RAID_CMD_LEN 5
static u8 _is_fw_read_cmd_down(struct rtw_adapter *padapter, u8 msgbox_num)
{
@@ -121,16 +122,14 @@ int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter,
__le32 param)
return _SUCCESS;
}
-int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg)
+int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, __le32 mask, u8 arg)
{
- u8 buf[5];
+ struct macid_config_eid {__le32 mask; u8 arg; } buf = {
+ .mask = mask,
+ .arg = arg
+ };
- memset(buf, 0, 5);
- mask = cpu_to_le32(mask);
- memcpy(buf, &mask, 4);
- buf[4] = arg;
-
- FillH2CCmd(padapter, MACID_CONFIG_EID, 5, buf);
+ FillH2CCmd(padapter, MACID_CONFIG_EID, RAID_CMD_LEN, (u8 *)&buf);
return _SUCCESS;
}
@@ -152,7 +151,7 @@ void rtl8723a_add_rateatid(struct rtw_adapter *pAdapter,
u32 bitmap, u8 arg, u8
bitmap |= raid;
- rtl8723a_set_raid_cmd(pAdapter, bitmap, arg);
+ rtl8723a_set_raid_cmd(pAdapter, cpu_to_le32(bitmap), arg);
}
void rtl8723a_set_FwPwrMode_cmd(struct rtw_adapter *padapter, u8 Mode)
diff --git a/drivers/staging/rtl8723au/hal/usb_halinit.c
b/drivers/staging/rtl8723au/hal/usb_halinit.c
index 68156a1..fb6f900 100644
--- a/drivers/staging/rtl8723au/hal/usb_halinit.c
+++ b/drivers/staging/rtl8723au/hal/usb_halinit.c
@@ -1262,7 +1262,7 @@ void rtl8723a_update_ramask(struct rtw_adapter *padapter,
DBG_8723A("update raid entry, mask = 0x%x, arg = 0x%x\n", mask, arg);
- rtl8723a_set_raid_cmd(padapter, mask, arg);
+ rtl8723a_set_raid_cmd(padapter, cpu_to_le32(mask), arg);
/* set ra_id */
psta->raid = raid;
diff --git a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
index e281543..a7f7921 100644
--- a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
+++ b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
@@ -150,7 +150,7 @@ void rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(struct
rtw_adapter *padapter);
#define rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(padapter) do {} while(0)
#endif
int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param);
-int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg);
+int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, __le32 mask, u8 arg);
void rtl8723a_add_rateatid(struct rtw_adapter *padapter, u32 bitmap, u8 arg,
u8 rssi_level);
int FillH2CCmd(struct rtw_adapter *padapter, u8 ElementID, u32 CmdLen, u8
*pCmdBuffer);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsub
[PATCH 1/2 v3] drivers: staging: rtl8723au: Changed rssi_cmd to little-endian param
From: Jacob Kiefer
Changed rssi_cmd interface to accept le32 param instead of
unnecessary u8 * conversion. Updated existing calls to rssi_cmd.
This patch pushes responsibility to caller to convert to
le32. This cleans up the code quite a bit.
Also removed magic numbers.
This patch fixes the following sparse error:
CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
...
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
expected unsigned int [unsigned] [usertype]
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
got restricted __le32 [usertype]
...
Signed-off-by: Jacob Kiefer
---
In v3, opted to change the interface rather than just the internal
code to clear the sparse errors and make the code more sane.
---
drivers/staging/rtl8723au/hal/odm.c | 3 ++-
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 7 +++
drivers/staging/rtl8723au/include/rtl8723a_cmd.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723au/hal/odm.c
b/drivers/staging/rtl8723au/hal/odm.c
index 6b9dbef..c7f45c7 100644
--- a/drivers/staging/rtl8723au/hal/odm.c
+++ b/drivers/staging/rtl8723au/hal/odm.c
@@ -1274,7 +1274,8 @@ static void odm_RSSIMonitorCheck(struct dm_odm_t *pDM_Odm)
for (i = 0; i < sta_cnt; i++) {
if (PWDB_rssi[i] != (0))
- rtl8723a_set_rssi_cmd(Adapter, (u8 *)&PWDB_rssi[i]);
+ rtl8723a_set_rssi_cmd(Adapter,
+ cpu_to_le32(PWDB_rssi[i]));
}
pdmpriv->EntryMaxUndecoratedSmoothedPWDB = MaxDB;
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 9733aa6..97d23c3 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -25,6 +25,7 @@
#define RTL92C_MAX_CMD_LEN 5
#define MESSAGE_BOX_SIZE 4
#define EX_MESSAGE_BOX_SIZE2
+#define RSSI_CMD_LEN 3
static u8 _is_fw_read_cmd_down(struct rtw_adapter *padapter, u8 msgbox_num)
{
@@ -113,11 +114,9 @@ exit:
return ret;
}
-int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
+int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param)
{
- *((u32 *)param) = cpu_to_le32(*((u32 *)param));
-
- FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
+ FillH2CCmd(padapter, RSSI_SETTING_EID, RSSI_CMD_LEN, (u8 *)¶m);
return _SUCCESS;
}
diff --git a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
index 014c02e..e281543 100644
--- a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
+++ b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
@@ -149,7 +149,7 @@ void rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(struct
rtw_adapter *padapter);
#else
#define rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(padapter) do {} while(0)
#endif
-int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param);
+int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param);
int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg);
void rtl8723a_add_rateatid(struct rtw_adapter *padapter, u32 bitmap, u8 arg,
u8 rssi_level);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 4.2: CONFIG_NO_HZ_FULL_ALL effectively disabling non-boot CPUs
On Sat, Oct 10, 2015 at 10:14:25PM +0300, Meelis Roos wrote:
> Short summary: turning on CONFIG_NO_HZ_FULL_ALL seems to disable all
> non-boot CPUs for scheduler.
>
> A couple of days ago I noticed that make -j8 on a 4-core i5 is very slow
> (with 4.3.0-rc4+git). Looking at top ('1' for per-cpu states), only
> first CPU is loaded and 3 other CPUs are 100% idle. This seems to be a
> problem on 3 of my desktop machines (different generation Intel: i5-660,
> i5-2400, i3-3220). All the computers run custom kernels.
>
> Further investigation showed that CPU affinity was set to 1 (CPU0 only)
> for init and all the children. Kernel threads had affinities 1,2,4,8
> and f (seems normal).
>
> Even more interesting was the behaviour after setting affinity to f for
> all userland processes and then running make -j4. The other cores were
> still idle!
>
> Switching back to 4.2.0 with my config, the problem persisted. 4.2.3 as
> packaged by Debian worked fine. 4.0.0 and 4.1.0 with my config worked
> also fine. systemd and sysvinit behaved the same and no affinity was
> configured for systemd.
>
> So did a kernel config bisection between my kernel config and Debian
> config and came to CONFIG_NO_HZ_FULL_ALL. Debian has it off, I had it
> on. Turning that off fixed the scheduling and the system spread the
> tasks to all the cores.
>
> I do not remember changing this value for a long time, I set them after
> the settings were introduced and used it. So it seems it broken in 4.2.0
> but was working in 4.1 but I do not have 4.1 config saved anywhere
> (many make oldconfigs since).
>
> Bisection between 4.1 and 4.2 is possible but not easy since the
> machines are usually actively used when I am near them.
This is expected and intended behavior. The whole point of
CONFIG_NO_HZ_FULL_ALL is to keep everything off of the non-boot CPUs
that is not explicitly placed there. Without CONFIG_NO_HZ_FULL_ALL,
you can use the nohz_full boot parameter to select exactly which
CPUs are to behave this way.
Thanx, Paul
--
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] mISDN: use kstrdup() in dsp_pipeline_build
On Sat, 2015-10-10 at 02:32 -0700, Geliang Tang wrote:
> Use kstrdup instead of strlen-kmalloc-strcpy.
Not the same code.
Instead of returning early, a 0 length string will
now set pipeline->inuse to 0.
Maybe that's OK, but you should state why in the
commit log.
> diff --git a/drivers/isdn/mISDN/dsp_pipeline.c
> b/drivers/isdn/mISDN/dsp_pipeline.c
[]
> @@ -250,14 +250,9 @@ int dsp_pipeline_build(struct dsp_pipeline *pipeline,
> const char *cfg)
> if (!cfg)
> return 0;
>
> - len = strlen(cfg);
> - if (!len)
> - return 0;
> -
> - dup = kmalloc(len + 1, GFP_ATOMIC);
> + dup = kstrdup(cfg, GFP_ATOMIC);
> if (!dup)
> return 0;
> - strcpy(dup, cfg);
> while ((tok = strsep(&dup, "|"))) {
> if (!strlen(tok))
> continue;
--
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/5] drivers/tty: make serial/mpsc.c driver explicitly non-modular
[Re: [PATCH 4/5] drivers/tty: make serial/mpsc.c driver explicitly non-modular]
On 09/10/2015 (Fri 15:38) Thierry Reding wrote:
> On Wed, Aug 19, 2015 at 05:48:08PM -0400, Paul Gortmaker wrote:
[...]
> > static struct platform_driver mpsc_driver = {
> > .probe = mpsc_drv_probe,
> > - .remove = mpsc_drv_remove,
> > .driver = {
> > .name = MPSC_CTLR_NAME,
> > },
>
> I don't think this is right. The driver can always be unbound from the
> device via sysfs, in which case it will now leak resources and leave
> behind a dangling UART port.
I suppose it does open the window for root to do something else stupid
he shouldn't be doing anyway...
I think the right thing to do here is for me to send a follow on patch
that does also set:
.suppress_bind_attrs = true
in the above block, since this is a console device used on 2005 vintage
74xx based powerpc embedded targets, and is essentially always used in
conjunction with SERIAL_MPSC_CONSOLE=y -- there is no sane reason anyone
would ever want to unbind the builtin driver and lose the console.
I'll send a follow on patch doing the above if folks are in agreement
with the above logic.
Thanks,
Paul.
--
>
> Thierry
--
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] misc: mic: use kstrdup() in cosm_sysfs
On Sat, 2015-10-10 at 04:46 -0700, Geliang Tang wrote: > Use kstrdup instead of kmalloc and strncpy. As count is a function argument, this isn't the same code. You should state why it's correct in the commit log. > diff --git a/drivers/misc/mic/cosm/cosm_sysfs.c > b/drivers/misc/mic/cosm/cosm_sysfs.c [] > @@ -211,18 +211,14 @@ cmdline_store(struct device *dev, struct > device_attribute *attr, > mutex_lock(&cdev->cosm_mutex); > kfree(cdev->cmdline); > > - cdev->cmdline = kmalloc(count + 1, GFP_KERNEL); > + cdev->cmdline = kstrdup(buf, GFP_KERNEL); -- 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/
4.2: CONFIG_NO_HZ_FULL_ALL effectively disabling non-boot CPUs
Short summary: turning on CONFIG_NO_HZ_FULL_ALL seems to disable all
non-boot CPUs for scheduler.
A couple of days ago I noticed that make -j8 on a 4-core i5 is very slow
(with 4.3.0-rc4+git). Looking at top ('1' for per-cpu states), only
first CPU is loaded and 3 other CPUs are 100% idle. This seems to be a
problem on 3 of my desktop machines (different generation Intel: i5-660,
i5-2400, i3-3220). All the computers run custom kernels.
Further investigation showed that CPU affinity was set to 1 (CPU0 only)
for init and all the children. Kernel threads had affinities 1,2,4,8
and f (seems normal).
Even more interesting was the behaviour after setting affinity to f for
all userland processes and then running make -j4. The other cores were
still idle!
Switching back to 4.2.0 with my config, the problem persisted. 4.2.3 as
packaged by Debian worked fine. 4.0.0 and 4.1.0 with my config worked
also fine. systemd and sysvinit behaved the same and no affinity was
configured for systemd.
So did a kernel config bisection between my kernel config and Debian
config and came to CONFIG_NO_HZ_FULL_ALL. Debian has it off, I had it
on. Turning that off fixed the scheduling and the system spread the
tasks to all the cores.
I do not remember changing this value for a long time, I set them after
the settings were introduced and used it. So it seems it broken in 4.2.0
but was working in 4.1 but I do not have 4.1 config saved anywhere
(many make oldconfigs since).
Bisection between 4.1 and 4.2 is possible but not easy since the
machines are usually actively used when I am near them.
--
Meelis Roos (mr...@linux.ee)
--
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] staging: rtl8723au: Fix sparse errors in rtl8723a_cmd.c
On Sat, Oct 10, 2015 at 02:50:44PM -0400, Jacob Kiefer wrote: > Hello > > This patch set fixes the same sparse errors as v2, taking Al's > advice into consideration and changing the interfaces to little-endian. Please resend these in a format that I can apply them in (i.e. one patch per email in a series, like you see on the mailing list.) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
The Debian 3.16.0 kernel does not emit the error, but I have not attempted a bisection. The warning was added by: 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) 2014-06-18 (1 year, 4 months ago), Oscar Mateo Follows: v3.15-rc8 Preceedes: 3.17-rc1 This is not present in v3.16, so perhaps not present in the Debian kernel and this is not a regression, but just reporting the condition as intended. Linux Version: v4.3-rc4 Platform: Lenovo ThinkPad Yoga 12 OS: Debian 8.2 $ dmesg | grep -i drm [ 10.918367] [drm] Initialized drm 1.1.0 20060810 [ 11.235005] [drm] Memory usable by graphics device = 4096M [ 11.235009] fb: switching to inteldrmfb from simple [ 11.235093] [drm] Replacing VGA console driver [ 11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 11.241162] [drm] Driver supports precise vblank timestamp query. [ 11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [ 11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [ 11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0 [ 11.344913] fbcon: inteldrmfb (fb0) is primary device [ 12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] sched: don't scan all-offline ->cpus_allowed twice if !CONFIG_CPUSETS
If CONFIG_CPUSETS=n then "case cpuset" changes the state and runs
the already failed for_each_cpu() loop again for no reason.
Signed-off-by: Oleg Nesterov
---
kernel/sched/core.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e4fa6be..b421e24 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1335,13 +1335,15 @@ static int select_fallback_rq(int cpu, struct
task_struct *p)
goto out;
}
+ /* No more Mr. Nice Guy. */
switch (state) {
case cpuset:
- /* No more Mr. Nice Guy. */
- cpuset_cpus_allowed_fallback(p);
- state = possible;
- break;
-
+ if (IS_ENABLED(CONFIG_CPUSETS)) {
+ cpuset_cpus_allowed_fallback(p);
+ state = possible;
+ break;
+ }
+ /* fall-through */
case possible:
do_set_cpus_allowed(p, cpu_possible_mask);
state = fail;
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] sched: select_task_rq() should check cpu_active() like select_fallback_rq()
I do not understand the cpu_active() check in select_fallback_rq().
x86 doesn't need it, and the recent commit dd9d3843755d "sched: Fix
cpu_active_mask/cpu_online_mask race" documents the fact that on any
architecture we can ignore !active starting from CPU_ONLINE stage.
But any possible reason why do we need this check in "fallback" must
equally apply to select_task_rq().
Signed-off-by: Oleg Nesterov
---
kernel/sched/core.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5fe9086..a2ef0cf 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1297,6 +1297,11 @@ void kick_process(struct task_struct *p)
}
EXPORT_SYMBOL_GPL(kick_process);
+static inline bool cpu_allowed(int cpu)
+{
+ return cpu_online(cpu) && cpu_active(cpu);
+}
+
/*
* ->cpus_allowed is protected by both rq->lock and p->pi_lock
*/
@@ -1317,9 +1322,7 @@ static int select_fallback_rq(int cpu, struct task_struct
*p)
/* Look for allowed, online CPU in same node. */
for_each_cpu(dest_cpu, nodemask) {
- if (!cpu_online(dest_cpu))
- continue;
- if (!cpu_active(dest_cpu))
+ if (!cpu_allowed(dest_cpu))
continue;
if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
return dest_cpu;
@@ -1329,9 +1332,7 @@ static int select_fallback_rq(int cpu, struct task_struct
*p)
for (;;) {
/* Any allowed, online CPU? */
for_each_cpu(dest_cpu, tsk_cpus_allowed(p)) {
- if (!cpu_online(dest_cpu))
- continue;
- if (!cpu_active(dest_cpu))
+ if (!cpu_allowed(dest_cpu))
continue;
goto out;
}
@@ -1390,7 +1391,7 @@ int select_task_rq(struct task_struct *p, int cpu, int
sd_flags, int wake_flags)
* not worry about this generic constraint ]
*/
if (unlikely(!cpumask_test_cpu(cpu, tsk_cpus_allowed(p)) ||
-!cpu_online(cpu)))
+!cpu_allowed(cpu)))
cpu = select_fallback_rq(task_cpu(p), p);
return cpu;
--
1.5.5.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 2/3] sched: change select_fallback_rq() to use for_each_cpu_and()
We can make "cpumask *nodemask" more local and use for_each_cpu_and()
to simplify this code a little bit.
And NUMA_NO_NODE looks better than "-1".
Signed-off-by: Oleg Nesterov
---
kernel/sched/core.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a2ef0cf..e4fa6be 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1308,24 +1308,22 @@ static inline bool cpu_allowed(int cpu)
static int select_fallback_rq(int cpu, struct task_struct *p)
{
int nid = cpu_to_node(cpu);
- const struct cpumask *nodemask = NULL;
enum { cpuset, possible, fail } state = cpuset;
int dest_cpu;
/*
* If the node that the cpu is on has been offlined, cpu_to_node()
-* will return -1. There is no cpu on the node, and we should
-* select the cpu on the other node.
+* will return NUMA_NO_NODE. There is no cpu on the node, and we
+* should select the cpu on the other node.
*/
- if (nid != -1) {
- nodemask = cpumask_of_node(nid);
+ if (nid != NUMA_NO_NODE) {
+ const struct cpumask *nodemask = cpumask_of_node(nid);
/* Look for allowed, online CPU in same node. */
- for_each_cpu(dest_cpu, nodemask) {
+ for_each_cpu_and(dest_cpu, nodemask, tsk_cpus_allowed(p)) {
if (!cpu_allowed(dest_cpu))
continue;
- if (cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
- return dest_cpu;
+ return dest_cpu;
}
}
--
1.5.5.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 0/3] (Was: sched: start stopper early)
To avoid the confusion, this has nothing to do with "stop_machine" changes we discuss in another thread, but On 10/09, Oleg Nesterov wrote: > > > case CPU_ONLINE: > > + stop_machine_unpark(cpu); > > /* > > * At this point a starting CPU has marked itself as online via > > * set_cpu_online(). But it might not yet have marked itself > > @@ -5337,7 +5340,7 @@ static int sched_cpu_active(struct notifier_block > > *nfb, > > * Thus, fall-through and help the starting CPU along. > > */ > > case CPU_DOWN_FAILED: > > - set_cpu_active((long)hcpu, true); > > + set_cpu_active(cpu, true); > > On a second thought, we can't do this (and your initial change has > the same problem). > > We can not wakeup it before set_cpu_active(). This can lead to the > same problem fixed by dd9d3843755da95f6 "sched: Fix cpu_active_mask/ > cpu_online_mask race". OTOH, I don't understand why do we actually need this fix... Or, iow I don't really understand the cpu_active() checks in select_fallback_rq(). Looks like we have some strange arch/ which has the "unsafe" online && !active window, but then it is not clear why it is safe to mark it active in sched_cpu_active(CPU_ONLINE). Confused. And I am even more confused by the fact that select_fallback_rq() checks cpu_active(), but select_task_rq() doesn't. This can't be right in any case. Oleg. kernel/sched/core.c | 41 + 1 files changed, 21 insertions(+), 20 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: Updated scalable urandom patchkit
I'm very very sorry to be so late to the party; I didn't see this thread
until the week-delayed LWN article on the subject drew my attention to it.
There's a fundamental design issue with this patch set that seems
unnecessary to me: multiple nonblocking pools.
I know, I know, that seems like the whole point of it, but hear me out.
Entropy is a holographic property of the pool, not located in any
particular bit position.
And the most basic operation, of reading from the pool, can easily be
done by multiple readers at the same time from the same bit pattern.
They just need to be salted with distinguishing nonces (CPU IDs will do
nicely) to ensure they all get different results. So a reader doesn't
just get hash(pool[]), but hash(unique_nonce, pool[]).
This in turn lets the spin_lock_irqsave() in extract_buf be moved to
after the sha_transform() calls.
I think the whole thing can be done, more elegantly, using a single pool
and judiciously relaxed locking rules. You don't even need reader-writer
locks; it's actually beneficial rather than harmful if there's a race
between a pool reader and writer.
In general, fewer larger pools is better for entropy storage. The only
reason for the current three-pool design is to achieve strict isolation
of the /dev/random pool.
The two operations that require locking are:
1. Entropy accounting. However, that only has to be strict
for /dev/random. For /dev/urandom, it can be late in various ways.
One possibility is to have separate entropy accounding per NUMA
node; only the pool proper has to be shared.
2. Add-back of the output to the pool. This involves writing to pool,
but for non-invertibility, it only has to be do ne byone of a number of
concurrent readers. I think significant cleverness can be applied
here.
There are a lot of things that can be done about this second point:
2a. The obvious one is to batch the add-back. For backtracking
protection, we only need to do one add-back per read, not one per
10 bytes of output. Combined with the above change that locks only
around the add-back and not the pool hashing, this greatly reduces
both the lock window and the number of times it's taken.
2b. Another idea would be to optimize for 16 bytes. I like the basic
concept of having a larger hash internal state than the output, but
would it be possible to output 16 of the 20 bytes of SHA-1 output
rather than the current 10? This is obviously a Ted question (the
current folding is his idea), but even 32 bits is enough to protect
against internal collisions in the hash state.
2c. Another possibility would be to add small separate "salt piles"
which are initialized to the CPU id, and stirred by reads. They only
need to be large enough to not experience birthsay collisions even
assuming a stupid number of reads between stirs of the main pool.
(So 128 bits would be more than ample.) A read would consist of:
hash[5] = { initial values }
sha1(hash, my_salt)
sha1(hash, main_pool)
if (spin_trylock(main_pool)) {
add_back(hash, main_pool);
spin_unlock(main_pool);
} else {
add_back(hash, my_salt);
}
2d. A more complete solution involves noting that, if there are multiple
concurrent readers, only one has to add back its output to prevent
backtracking, because all of the concurrent reads are equivalent
in that sense. (Even though, because they're salted with separate
nonces like the CPU id, they're not identical.)
I'm thinking in terms of a "generation counter" for the pool. (Perhaps
implemented as a seqlock.) The readers of the generation-n pool must
ensure that *someone* is responsible for bumping the generation to n+1
to prevent backtracking of the generation-n state, but only one.
A key point is that the add-back that bumps the generation to n+2 may
actaully be a hash of the generation-n pool state, the generation-n+1
state, or some transient intermedicate state due to races with the
generation-n+1 add-back. It is not necessary for readers to wait for
the pool to be stable, only that it's a non-invertible transformation
based on some earlier generation.
Now, to actually implement that, a "spin lock while checking extra
condition" would be ideal, but I do not want to add Yet Another Locking
Primitive to the kernel.
One possibility would be to accept the possibility of a race condition
breaking anti-backtracking. Another reader will come along soom enough
and fix it.
But if that's not okay, consider the following:
We add a second lock, the "responsibility lock", the holder of which
is responsible for doing anti-backtracking.
After hashing the pool, each reader does the following:
1. (Optional) trylock() the pool lock.
This is a low-load optimization. If it succeeds, go
directly to step 5.
2. Trylock() the responsibility lock.
If this fails, we're done; return.
Re: [PATCH v2] staging: rtl8723au: Fix sparse errors in rtl8723a_cmd.c
Hello
This patch set fixes the same sparse errors as v2, taking Al's
advice into consideration and changing the interfaces to little-endian.
Jake
>From 8c66f23a08417c59400a60c2dcf5a519795e401f Mon Sep 17 00:00:00 2001
From: Jacob Kiefer
Date: Sat, 10 Oct 2015 14:33:02 -0400
Subject: [PATCH 1/2 v3] drivers: staging: rtl8723au: Changed rssi_cmd to little-endian param
Changed rssi_cmd interface to accept le32 param instead of
unnecessary u8 * conversion. Updated existing calls to rssi_cmd.
This patch pushes responsibility to caller to convert to
le32. This cleans up the code quite a bit.
Also removed magic numbers.
This patch fixes the following sparse error:
CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
...
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
expected unsigned int [unsigned] [usertype]
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
got restricted __le32 [usertype]
...
Signed-off-by: Jacob Kiefer
---
In v3, opted to change the interface rather than just the internal
code to clear the sparse errors and make the code more sane.
---
drivers/staging/rtl8723au/hal/odm.c | 3 ++-
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 7 +++
drivers/staging/rtl8723au/include/rtl8723a_cmd.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723au/hal/odm.c b/drivers/staging/rtl8723au/hal/odm.c
index 6b9dbef..c7f45c7 100644
--- a/drivers/staging/rtl8723au/hal/odm.c
+++ b/drivers/staging/rtl8723au/hal/odm.c
@@ -1274,7 +1274,8 @@ static void odm_RSSIMonitorCheck(struct dm_odm_t *pDM_Odm)
for (i = 0; i < sta_cnt; i++) {
if (PWDB_rssi[i] != (0))
- rtl8723a_set_rssi_cmd(Adapter, (u8 *)&PWDB_rssi[i]);
+ rtl8723a_set_rssi_cmd(Adapter,
+ cpu_to_le32(PWDB_rssi[i]));
}
pdmpriv->EntryMaxUndecoratedSmoothedPWDB = MaxDB;
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 9733aa6..97d23c3 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -25,6 +25,7 @@
#define RTL92C_MAX_CMD_LEN 5
#define MESSAGE_BOX_SIZE 4
#define EX_MESSAGE_BOX_SIZE 2
+#define RSSI_CMD_LEN 3
static u8 _is_fw_read_cmd_down(struct rtw_adapter *padapter, u8 msgbox_num)
{
@@ -113,11 +114,9 @@ exit:
return ret;
}
-int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
+int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param)
{
- *((u32 *)param) = cpu_to_le32(*((u32 *)param));
-
- FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
+ FillH2CCmd(padapter, RSSI_SETTING_EID, RSSI_CMD_LEN, (u8 *)¶m);
return _SUCCESS;
}
diff --git a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
index 014c02e..e281543 100644
--- a/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
+++ b/drivers/staging/rtl8723au/include/rtl8723a_cmd.h
@@ -149,7 +149,7 @@ void rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(struct rtw_adapter *padapter);
#else
#define rtl8723a_set_BTCoex_AP_mode_FwRsvdPkt_cmd(padapter) do {} while(0)
#endif
-int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param);
+int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, __le32 param);
int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg);
void rtl8723a_add_rateatid(struct rtw_adapter *padapter, u32 bitmap, u8 arg, u8 rssi_level);
--
1.8.3.2
>From 27441199cc7c0a22c7eeebf74000571b1bcde26c Mon Sep 17 00:00:00 2001
From: Jacob Kiefer
Date: Sat, 10 Oct 2015 14:34:29 -0400
Subject: [PATCH 2/2 v3] drivers: staging: rtl8723au: Changed raid_cmd to little-endian mask
Changed raid_cmd interface to accept le32 mask instead of
u32 and converting internally. Updated existing calls to raid_cmd.
This patch pushes responsibility to the caller to convert
the mask to le32 and opts for a temp local struct instead of
memset/memcpy. This cleans up the code considerably.
Also removed magic numbers.
This patch fixes the following sparse error:
CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
...
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
expected unsigned int [unsigned] [usertype] mask
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
got restricted __le32 [usertype]
...
Signed-off-by: Jacob Kiefer
---
In v3, opted to change the interface rather than just the internal
code, and removed ugly memcpy/memset. This clears sparse errors
and makes the code more sane.
---
drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c | 2 +-
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c| 17 -
drivers/staging/rtl8723au/hal/usb_halinit.c | 2 +-
drivers/staging/rtl8723au/include/rtl8723a_cmd.h| 2 +-
Re: [PATCH] thinkpad_acpi: Add TP_HKEY_EV_SCREEN_FLIP (0x60c0) for Lenovo ThinkPad Yoga 12
On Sat, Oct 10, 2015 at 11:41:47AM -0700, Darren Hart wrote:
> From: Darren Hart
>
> thinkpad_acpi reports "unhandled HKEY event 0x60c0" when switching
> between laptop and tent/tablet mode on the ThinkPad Yoga 12. This key is
> reported by atkbd serio0 as e058 and e059.
>
> Add TP_HKEY_EV_SCREEN_FLIP to the list of ignored events and silence the
> warning.
>
> Cleanup whitespace on preceeding line for TP_HKEY_EV_KEY_FN_ESC.
>
> Signed-off-by: Darren Hart
> Cc: Henrique de Moraes Holschuh
> Cc: ibm-acpi-de...@lists.sourceforge.net
And Cc pdx86... oi. That's embarassing.
> ---
> drivers/platform/x86/thinkpad_acpi.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index 131dd74..d68143e 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -197,7 +197,8 @@ enum tpacpi_hkey_event_t {
> /* Key-related user-interface events */
> TP_HKEY_EV_KEY_NUMLOCK = 0x6000, /* NumLock key pressed */
> TP_HKEY_EV_KEY_FN = 0x6005, /* Fn key pressed? E420 */
> - TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
> + TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
> + TP_HKEY_EV_SCREEN_FLIP = 0x60c0, /* Screen flipped Yoga 12 */
>
> /* Thermal events */
> TP_HKEY_EV_ALARM_BAT_HOT= 0x6011, /* battery too hot */
> @@ -3849,7 +3850,9 @@ static bool hotkey_notify_6xxx(const u32 hkey,
>* unplugging AC adapter, docking or undocking. */
>
> /* fallthrough */
> -
> + case TP_HKEY_EV_SCREEN_FLIP:
> + /* Yoga 12: Screen toggled between laptop and tablet mode. */
> + /* fallthrough */
> case TP_HKEY_EV_KEY_NUMLOCK:
> case TP_HKEY_EV_KEY_FN:
> case TP_HKEY_EV_KEY_FN_ESC:
> --
> 2.1.4
>
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] thinkpad_acpi: Add TP_HKEY_EV_SCREEN_FLIP (0x60c0) for Lenovo ThinkPad Yoga 12
From: Darren Hart
thinkpad_acpi reports "unhandled HKEY event 0x60c0" when switching
between laptop and tent/tablet mode on the ThinkPad Yoga 12. This key is
reported by atkbd serio0 as e058 and e059.
Add TP_HKEY_EV_SCREEN_FLIP to the list of ignored events and silence the
warning.
Cleanup whitespace on preceeding line for TP_HKEY_EV_KEY_FN_ESC.
Signed-off-by: Darren Hart
Cc: Henrique de Moraes Holschuh
Cc: ibm-acpi-de...@lists.sourceforge.net
---
drivers/platform/x86/thinkpad_acpi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 131dd74..d68143e 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -197,7 +197,8 @@ enum tpacpi_hkey_event_t {
/* Key-related user-interface events */
TP_HKEY_EV_KEY_NUMLOCK = 0x6000, /* NumLock key pressed */
TP_HKEY_EV_KEY_FN = 0x6005, /* Fn key pressed? E420 */
- TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
+ TP_HKEY_EV_KEY_FN_ESC = 0x6060, /* Fn+Esc key pressed X240 */
+ TP_HKEY_EV_SCREEN_FLIP = 0x60c0, /* Screen flipped Yoga 12 */
/* Thermal events */
TP_HKEY_EV_ALARM_BAT_HOT= 0x6011, /* battery too hot */
@@ -3849,7 +3850,9 @@ static bool hotkey_notify_6xxx(const u32 hkey,
* unplugging AC adapter, docking or undocking. */
/* fallthrough */
-
+ case TP_HKEY_EV_SCREEN_FLIP:
+ /* Yoga 12: Screen toggled between laptop and tablet mode. */
+ /* fallthrough */
case TP_HKEY_EV_KEY_NUMLOCK:
case TP_HKEY_EV_KEY_FN:
case TP_HKEY_EV_KEY_FN_ESC:
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nouveau: fix OpenFirmware support
Hi Laurent, On Sat, Oct 10, 2015 at 9:27 AM, Laurent Vivier wrote: > On PowerMac G5 (and I think on all OpenFirmware platforms), nvbios_pcirTp() > returns NULL. But in fact the OpenFirmware has given us the size > we can store in image->size. > > This size is stored in bios->size by of_init() as there is no way > to retrieve it otherwise. And as we know the size, copy all data > to bios->data. > > Tested on PowerMac G5 with 64bit kernel and a NV43 card (GeForce 6600 LE). Can you give this patch a shot instead? http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=794a63cc75eada9ad6b2a0275c1c8c4d3522864f This resolved my issues on a PPC G5 + NV34. I think mine ran into a few additional problems that you didn't see -- no PCIR header and invalid checksum. -ilia -- 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/
