Re: [PATCH 3/5] ipc,msg: always respect MSG_NOERROR
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote: When specifying the MSG_NOERROR flag, receivers can avoid returning error (E2BIG) and just truncate the message text, if it is too large. Currently, this logic is only respected when there are already pending messages in the queue. Do you have a test case? The code should handle that (See below) Fix this for the case when there are only receivers waiting for a msg to be sent. In order for this to work, save the flags in the msg_receiver struct as it must be used later when doing the pipeline send. No, it is sufficient to set the message size to infinity. Also do some pipeline_send() cleanups while at it. No - please don't mix cleanups with bugfixes. long do_msgsnd(int msqid, long mtype, void __user *mtext, @@ -901,6 +907,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long msgtyp, int msgfl list_add_tail(_d.r_list, >q_receivers); msr_d.r_tsk = current; msr_d.r_msgtype = msgtyp; + msr_d.r_msgflg = msgflg; msr_d.r_mode = mode; if (msgflg & MSG_NOERROR) msr_d.r_maxsize = INT_MAX; ^^ This code should handle MSG_NOERROR: If MSG_NOERROR is set, then maxsize is set to INT_MAX, therefore -E2BIG should never be returned. -- Manfred -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/rt: don't try to balance rt_runtime when it is futile
On Sun, May 18, 2014 at 06:22:34AM +0200, Mike Galbraith wrote: > On Thu, 2014-05-15 at 05:18 +0200, Mike Galbraith wrote: > > On Wed, 2014-05-14 at 08:44 -0700, Paul E. McKenney wrote: > > > > > In practice, not sure how much testing CONFIG_NO_HZ_FULL=y has received > > > for -rt kernels in production environments. > > > > I took 3.14-rt out for a quick spin on my 64 core box, it didn't work at > > all with 60 cores isolated. I didn't have time to rummage, but it looks > > like there are still bugs to squash. > > I tested a bit more yesterday. With only NO_HZ_FULL (no all), it did go > tickless. A 10 second sample of perturbation numbers below. Pretty > noisy, but it does work in rt. > > Below that, some jitter numbers, using a simplified and imperfect model > of a high end rt video game (game over, insert 1 gold bar to continue > variety of high end) executive synchronizing a simple load on 60 cores. > Bottom line there was if user thinks booting nohz_full=set to get any > core quiescence provided by that should improve jitter for a threaded > load despite not being able to shut tick down, he's wrong. If you are saying that turning on nohz_full doesn't help unless you also ensure that there is only one runnable task per CPU, I completely agree. If you are saying something else, you lost me. ;-) Thanx, Paul > -Mike > > vogelweide:/abuild/mike/:[0]# head -180 xx|tail -60 > pert/s: 500 >14.10us:2 min: 1.90 max: 96.86 avg: 5.17 sum/s: > 2586us overhead: 0.26% > pert/s:1 >18.63us:0 min: 3.38 max: 8.37 avg: 4.71 sum/s: > 5us overhead: 0.00% > pert/s:1 >18.54us:0 min: 3.41 max: 8.51 avg: 4.61 sum/s: > 5us overhead: 0.00% > pert/s:1 >18.78us:0 min: 3.45 max: 8.67 avg: 4.41 sum/s: > 4us overhead: 0.00% > pert/s:1 >19.60us:0 min: 2.68 max: 7.47 avg: 4.30 sum/s: > 4us overhead: 0.00% > pert/s:1 >20.61us:0 min: 2.60 max: 7.54 avg: 3.94 sum/s: > 4us overhead: 0.00% > pert/s:1 >21.03us:0 min: 2.70 max: 7.81 avg: 3.91 sum/s: > 4us overhead: 0.00% > pert/s:1 >19.89us:0 min: 2.65 max: 7.83 avg: 3.98 sum/s: > 4us overhead: 0.00% > pert/s:1 >29.36us:0 min: 3.78 max: 9.82 avg: 6.10 sum/s: > 6us overhead: 0.00% > pert/s:1 >28.86us:0 min: 4.56 max: 10.12 avg: 6.36 sum/s: > 6us overhead: 0.00% > pert/s:1 >21.34us:0 min: 2.54 max: 7.79 avg: 3.38 sum/s: > 3us overhead: 0.00% > pert/s:1 >30.12us:0 min: 3.51 max: 8.41 avg: 4.47 sum/s: > 4us overhead: 0.00% > pert/s:1 >21.01us:0 min: 2.44 max: 7.36 avg: 3.33 sum/s: > 3us overhead: 0.00% > pert/s:1 >22.41us:0 min: 2.42 max: 7.71 avg: 3.60 sum/s: > 4us overhead: 0.00% > pert/s:1 >30.37us:0 min: 3.46 max: 8.62 avg: 4.49 sum/s: > 4us overhead: 0.00% > pert/s:1 >29.50us:0 min: 3.43 max: 9.23 avg: 4.13 sum/s: > 4us overhead: 0.00% > pert/s:1 >20.66us:0 min: 2.49 max: 7.73 avg: 4.24 sum/s: > 4us overhead: 0.00% > pert/s:1 >33.87us:0 min: 4.45 max: 9.59 avg: 5.63 sum/s: > 6us overhead: 0.00% > pert/s:1 >34.70us:0 min: 4.47 max: 10.15 avg: 6.41 sum/s: > 6us overhead: 0.00% > pert/s:1 >29.62us:0 min: 4.49 max: 9.87 avg: 5.69 sum/s: > 6us overhead: 0.00% > pert/s:1 >36.92us:0 min: 3.53 max: 9.41 avg: 4.48 sum/s: > 4us overhead: 0.00% > pert/s:1 >35.31us:0 min: 3.69 max: 9.00 avg: 5.30 sum/s: > 5us overhead: 0.00% > pert/s:1 >36.29us:0 min: 3.34 max: 8.48 avg: 4.48 sum/s: > 4us overhead: 0.00% > pert/s:1 >34.90us:0 min: 3.39 max: 9.21 avg: 4.45 sum/s: > 4us overhead: 0.00% > pert/s:1 >34.23us:0 min: 3.37 max: 8.44 avg: 4.54 sum/s: > 5us overhead: 0.00% > pert/s:1 >34.45us:0 min: 0.05 max: 9.41 avg: 4.40 sum/s: > 5us overhead: 0.00% > pert/s:1 >35.31us:0 min: 3.89 max: 9.18 avg: 4.30 sum/s: > 5us overhead: 0.00% > pert/s:1 >35.98us:0 min: 2.80 max: 9.28 avg: 4.74 sum/s: > 5us overhead: 0.00% > pert/s:1 >33.89us:0 min: 3.15 max: 9.67 avg: 5.07 sum/s: > 5us overhead: 0.00% > pert/s:1 >35.16us:0 min: 2.56 max: 9.40 avg: 4.84 sum/s: > 5us overhead: 0.00% > pert/s:1 >36.37us:0 min: 4.49 max: 9.48 avg: 6.12 sum/s: > 6us overhead: 0.00% > pert/s:1 >38.10us:0 min: 0.04 max: 34.86 avg: 6.62 sum/s: > 13us overhead: 0.00% > pert/s:1 >35.11us:0 min: 5.05 max: 11.56 avg: 5.88 sum/s: > 6us overhead: 0.00% > pert/s:1 >36.88us:0 min: 3.77 max: 12.37 avg: 6.13
Re: [PATCH RFC] Remove useless return variables
Peter Senna Tschudin writes: > This patch remove variables that are initialized with a constant, > are never updated, and are only used as parameter of return. > Return the constant instead of using a variable. This ret variable pattern is pretty standard in Linux, as it makes it easier to add new code that may trigger new errors (using the usual "goto forest" error handling pattern) I don't see any benefit in whole-sale removing it. The compiler doesn't care about it and will generate the same code in any case. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: slicoss: rewrite eeprom checksum code
On Sat, May 17, 2014 at 9:12 PM, Joe Perches wrote:
> On Sat, 2014-05-17 at 21:00 -0700, David Matlack wrote:
> []
>> diff --git a/drivers/staging/slicoss/slicoss.c
>> b/drivers/staging/slicoss/slicoss.c
> []
>> +static inline u16 __reduce(u32 checksum)
>> +{
>> + u16 lower_16 = checksum & 0x;
>> + u16 upper_16 = (checksum >> 16) & 0x;
>> +
>> + checksum = lower_16 + upper_16;
>> +
>> + if (checksum > 65535)
>> + checksum -= 65535;
>> +
>> + return checksum;
>> +}
>
> The if seems unnecessary.
>
> Perhaps declare a u16 return var or use
>
> return lower_16 + upper_16;
I agree it's fishy... but using overflow doesn't produce the same result:
(u16) 65536 == 0
65536 - 65535 == 1
Now which is the correct result, I have no idea. The eeprom on this device is
small (0x80 bytes max, not enough to trigger overflow) and I have no
documentation, so I don't know how to test :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/rt: don't try to balance rt_runtime when it is futile
On Thu, 2014-05-15 at 05:18 +0200, Mike Galbraith wrote: > On Wed, 2014-05-14 at 08:44 -0700, Paul E. McKenney wrote: > > > In practice, not sure how much testing CONFIG_NO_HZ_FULL=y has received > > for -rt kernels in production environments. > > I took 3.14-rt out for a quick spin on my 64 core box, it didn't work at > all with 60 cores isolated. I didn't have time to rummage, but it looks > like there are still bugs to squash. I tested a bit more yesterday. With only NO_HZ_FULL (no all), it did go tickless. A 10 second sample of perturbation numbers below. Pretty noisy, but it does work in rt. Below that, some jitter numbers, using a simplified and imperfect model of a high end rt video game (game over, insert 1 gold bar to continue variety of high end) executive synchronizing a simple load on 60 cores. Bottom line there was if user thinks booting nohz_full=set to get any core quiescence provided by that should improve jitter for a threaded load despite not being able to shut tick down, he's wrong. -Mike vogelweide:/abuild/mike/:[0]# head -180 xx|tail -60 pert/s: 500 >14.10us:2 min: 1.90 max: 96.86 avg: 5.17 sum/s: 2586us overhead: 0.26% pert/s:1 >18.63us:0 min: 3.38 max: 8.37 avg: 4.71 sum/s: 5us overhead: 0.00% pert/s:1 >18.54us:0 min: 3.41 max: 8.51 avg: 4.61 sum/s: 5us overhead: 0.00% pert/s:1 >18.78us:0 min: 3.45 max: 8.67 avg: 4.41 sum/s: 4us overhead: 0.00% pert/s:1 >19.60us:0 min: 2.68 max: 7.47 avg: 4.30 sum/s: 4us overhead: 0.00% pert/s:1 >20.61us:0 min: 2.60 max: 7.54 avg: 3.94 sum/s: 4us overhead: 0.00% pert/s:1 >21.03us:0 min: 2.70 max: 7.81 avg: 3.91 sum/s: 4us overhead: 0.00% pert/s:1 >19.89us:0 min: 2.65 max: 7.83 avg: 3.98 sum/s: 4us overhead: 0.00% pert/s:1 >29.36us:0 min: 3.78 max: 9.82 avg: 6.10 sum/s: 6us overhead: 0.00% pert/s:1 >28.86us:0 min: 4.56 max: 10.12 avg: 6.36 sum/s: 6us overhead: 0.00% pert/s:1 >21.34us:0 min: 2.54 max: 7.79 avg: 3.38 sum/s: 3us overhead: 0.00% pert/s:1 >30.12us:0 min: 3.51 max: 8.41 avg: 4.47 sum/s: 4us overhead: 0.00% pert/s:1 >21.01us:0 min: 2.44 max: 7.36 avg: 3.33 sum/s: 3us overhead: 0.00% pert/s:1 >22.41us:0 min: 2.42 max: 7.71 avg: 3.60 sum/s: 4us overhead: 0.00% pert/s:1 >30.37us:0 min: 3.46 max: 8.62 avg: 4.49 sum/s: 4us overhead: 0.00% pert/s:1 >29.50us:0 min: 3.43 max: 9.23 avg: 4.13 sum/s: 4us overhead: 0.00% pert/s:1 >20.66us:0 min: 2.49 max: 7.73 avg: 4.24 sum/s: 4us overhead: 0.00% pert/s:1 >33.87us:0 min: 4.45 max: 9.59 avg: 5.63 sum/s: 6us overhead: 0.00% pert/s:1 >34.70us:0 min: 4.47 max: 10.15 avg: 6.41 sum/s: 6us overhead: 0.00% pert/s:1 >29.62us:0 min: 4.49 max: 9.87 avg: 5.69 sum/s: 6us overhead: 0.00% pert/s:1 >36.92us:0 min: 3.53 max: 9.41 avg: 4.48 sum/s: 4us overhead: 0.00% pert/s:1 >35.31us:0 min: 3.69 max: 9.00 avg: 5.30 sum/s: 5us overhead: 0.00% pert/s:1 >36.29us:0 min: 3.34 max: 8.48 avg: 4.48 sum/s: 4us overhead: 0.00% pert/s:1 >34.90us:0 min: 3.39 max: 9.21 avg: 4.45 sum/s: 4us overhead: 0.00% pert/s:1 >34.23us:0 min: 3.37 max: 8.44 avg: 4.54 sum/s: 5us overhead: 0.00% pert/s:1 >34.45us:0 min: 0.05 max: 9.41 avg: 4.40 sum/s: 5us overhead: 0.00% pert/s:1 >35.31us:0 min: 3.89 max: 9.18 avg: 4.30 sum/s: 5us overhead: 0.00% pert/s:1 >35.98us:0 min: 2.80 max: 9.28 avg: 4.74 sum/s: 5us overhead: 0.00% pert/s:1 >33.89us:0 min: 3.15 max: 9.67 avg: 5.07 sum/s: 5us overhead: 0.00% pert/s:1 >35.16us:0 min: 2.56 max: 9.40 avg: 4.84 sum/s: 5us overhead: 0.00% pert/s:1 >36.37us:0 min: 4.49 max: 9.48 avg: 6.12 sum/s: 6us overhead: 0.00% pert/s:1 >38.10us:0 min: 0.04 max: 34.86 avg: 6.62 sum/s: 13us overhead: 0.00% pert/s:1 >35.11us:0 min: 5.05 max: 11.56 avg: 5.88 sum/s: 6us overhead: 0.00% pert/s:1 >36.88us:0 min: 3.77 max: 12.37 avg: 6.13 sum/s: 6us overhead: 0.00% pert/s:1 >34.37us:1 min: 2.08 max:199.64 avg: 20.67 sum/s: 25us overhead: 0.00% pert/s:1 >35.57us:1 min: 2.11 max:198.61 avg: 19.17 sum/s: 25us overhead: 0.00% pert/s:1 >33.89us:1 min: 2.46 max:199.49 avg: 19.85 sum/s: 26us overhead: 0.00% pert/s:1 >37.58us:1 min: 2.34 max:199.79 avg: 19.59 sum/s: 25us overhead: 0.00% pert/s:1 >34.57us:0 min: 3.43 max: 13.37 avg: 5.86
Re: [PATCH 1/2] staging: slicoss: rewrite eeprom checksum code
On Sat, 2014-05-17 at 21:00 -0700, David Matlack wrote:
[]
> diff --git a/drivers/staging/slicoss/slicoss.c
> b/drivers/staging/slicoss/slicoss.c
[]
> +static inline u16 __reduce(u32 checksum)
> +{
> + u16 lower_16 = checksum & 0x;
> + u16 upper_16 = (checksum >> 16) & 0x;
> +
> + checksum = lower_16 + upper_16;
> +
> + if (checksum > 65535)
> + checksum -= 65535;
> +
> + return checksum;
> +}
The if seems unnecessary.
Perhaps declare a u16 return var or use
return lower_16 + upper_16;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
remap_file_pages() use
I saw that remap_file_pages() was possibly going away to be replaced by some emulation. I've used this call in several projects over the years mostly as a way of mapping multiple virtual memory pages to alias the same private or shared memory region (to do things like circular buffers). mmap() in the case of anonymous memory doesn't work as well since there is not a file descriptor to reference. Would this sort of thing be supported in the emulation, or should I be planning on reimplementing/rewriting some things? thanks, -Kenny -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: slicoss: rewrite eeprom checksum code
Rewrite slic_eeprom_cksum() to fix bugs and make readable. The original
implementation had the following issues:
1. 2 of the 3 unrolled loops had the following bug:
while ((len -= 32) >= 0) {
[...]
sum += w[15];
w = (u16 *)((ulong) w + 16);/* verify */
}
This processes 32-bytes of data but only increments the word
pointer by 16 bytes. Fixing both of these bugs seems to fix
slic_eeprom_cksum().
2. Non-descriptive variable names, use of unions, and macros that
change local state make the code difficult to read.
3. The checksum loop is unrolled which makes the code harder to
reason about while providing small performance improvement:
- max eeprom length is 0x80 bytes (MAX_EECODE_SIZE), that's
only 0x40 iterations
- checksum is only computed during pci probe(), so not very
often
Tested on Mojave card. Also tested against the old implementation
(with the above bug fix applied) with test data.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slicoss.c | 137 +-
1 file changed, 46 insertions(+), 91 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index dba6a00..d3fe8a7 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1137,106 +1137,61 @@ static int slic_config_get(struct adapter *adapter,
u32 config, u32 config_h)
0, 0);
}
+static inline u16 __reduce(u32 checksum)
+{
+ u16 lower_16 = checksum & 0x;
+ u16 upper_16 = (checksum >> 16) & 0x;
+
+ checksum = lower_16 + upper_16;
+
+ if (checksum > 65535)
+ checksum -= 65535;
+
+ return checksum;
+}
+
/*
- * this is here to checksum the eeprom, there is some ucode bug
- * which prevens us from using the ucode result.
- * remove this once ucode is fixed.
+ * Compute a checksum of the eeprom. There is a firmware bug that prevents
+ * us from using the firmware result. Remove this once firmware is fixed.
+ *
+ * This function does not assume the eeprom begins at a word aligned address
+ * or that the length of the eeprom is a multiple of word size. These cases
+ * are handled by treating the leading and trailing byte specially and
+ * conditionally adding them to the checksum at the end.
*/
-static ushort slic_eeprom_cksum(char *m, int len)
+static u16 slic_eeprom_cksum(void *eeprom, unsigned len)
{
-#define ADDCARRY(x) (x > 65535 ? x -= 65535 : x)
-#define REDUCE {l_util.l = sum; sum = l_util.s[0] + l_util.s[1];
ADDCARRY(sum);\
- }
-
- u16 *w;
- u32 sum = 0;
- u32 byte_swapped = 0;
- u32 w_int;
-
- union {
- char c[2];
- ushort s;
- } s_util;
-
- union {
- ushort s[2];
- int l;
- } l_util;
-
- l_util.l = 0;
- s_util.s = 0;
-
- w = (u16 *)m;
-#if BITS_PER_LONG == 64
- w_int = (u32) ((ulong) w & 0x);
-#else
- w_int = (u32) (w);
-#endif
- if ((1 & w_int) && (len > 0)) {
- REDUCE;
- sum <<= 8;
- s_util.c[0] = *(unsigned char *)w;
- w = (u16 *)((char *)w + 1);
- len--;
- byte_swapped = 1;
+ u8 *bp = eeprom;
+ u8 *leading_byte = NULL;
+ u8 *trailing_byte = NULL;
+ u16 final_word = 0;
+ u32 checksum = 0;
+
+ if ((unsigned long) eeprom & 1) {
+ leading_byte = bp;
+ bp++;
}
- /* Unroll the loop to make overhead from branches small. */
- while ((len -= 32) >= 0) {
- sum += w[0];
- sum += w[1];
- sum += w[2];
- sum += w[3];
- sum += w[4];
- sum += w[5];
- sum += w[6];
- sum += w[7];
- sum += w[8];
- sum += w[9];
- sum += w[10];
- sum += w[11];
- sum += w[12];
- sum += w[13];
- sum += w[14];
- sum += w[15];
- w = (u16 *)((ulong) w + 16);/* verify */
- }
- len += 32;
- while ((len -= 8) >= 0) {
- sum += w[0];
- sum += w[1];
- sum += w[2];
- sum += w[3];
- w = (u16 *)((ulong) w + 4); /* verify */
+ while ((void *) (bp + 1) < eeprom + len) {
+ checksum += *((u16 *) bp);
+ bp += 2;
}
- len += 8;
- if (len != 0 || byte_swapped != 0) {
- REDUCE;
- while ((len -= 2) >= 0)
- sum += *w++;/* verify */
- if (byte_swapped) {
- REDUCE;
- sum <<= 8;
- byte_swapped = 0;
-
[PATCH 2/2] staging: slicoss: remove slic_reg_params struct
Remove uninitialized struct that is only used to regulate whether
incorrect eeprom checksums are ignored.
Signed-off-by: David Matlack
---
drivers/staging/slicoss/slic.h| 7 ---
drivers/staging/slicoss/slicoss.c | 3 +--
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 0dc73d5..3a5aa88 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -362,12 +362,6 @@ struct slic_shmem {
volatile struct slic_stats inicstats;
};
-struct slic_reg_params {
- u32 linkspeed;
- u32 linkduplex;
- u32 fail_on_bad_eeprom;
-};
-
struct slic_upr {
uint adapter;
u32upr_request;
@@ -492,7 +486,6 @@ struct adapter {
u32 intagg_period;
struct inicpm_state*inicpm_info;
void *pinicpm_info;
- struct slic_reg_params reg_params;
struct slic_ifevents if_events;
struct slic_statsinicstats_prev;
struct slicnet_stats slic_stats;
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index d3fe8a7..1dae641 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2876,8 +2876,7 @@ static int slic_card_init(struct sliccard *card, struct
adapter *adapter)
sizeof(struct slic_eeprom),
peeprom, phys_config);
- if ((!card->config.EepromValid) &&
- (adapter->reg_params.fail_on_bad_eeprom)) {
+ if (!card->config.EepromValid) {
slic_reg64_write(adapter, _regs->slic_isp, 0,
_regs->slic_addr_upper,
0, FLUSH);
--
1.9.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/
[PATCH 0/2] staging: slicoss: cleanup checksum computation
This patchset fixes a broken checksum function and removes a struct that was being used to ignore bad checksum values. David Matlack (2): staging: slicoss: rewrite eeprom checksum code staging: slicoss: remove slic_reg_params struct drivers/staging/slicoss/slic.h| 7 -- drivers/staging/slicoss/slicoss.c | 140 +- 2 files changed, 47 insertions(+), 100 deletions(-) -- 1.9.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 3/5] workqueue: Create low-level unbound workqueues cpumask
Hello, On Sat, May 17, 2014 at 05:45:40PM -0500, Christoph Lameter wrote: > On Fri, 16 May 2014, Tejun Heo wrote: > > > > Make the uevent stuff work on all of sysfs? > > > > I don't know. Maybe. Likely a lot more work involving user space > > changes tho. Also, it runs contrary to what we've been doing to other > > top-level cgroup directories. Any reason not to do, say, > > /sys/devices/kernel? > > The other kernel tunables are in /sys/kernel. Heh, we're talking past each other. I meant moving everything under /sys/kernel to /sys/devices/kernel and making /sys/kernel a symlink to /sys/devices/kernel. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Quoting Seth Forshee (seth.fors...@canonical.com): > On Fri, May 16, 2014 at 09:31:37PM -0700, Eric W. Biederman wrote: > > Greg Kroah-Hartman writes: > > > > > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > >> > I think having to pick and choose what device nodes you want in a > > >> > container is a good thing. Becides, you would have to do the same > > >> > thing > > >> > in the kernel anyway, what's wrong with userspace making the decision > > >> > here, especially as it knows exactly what it wants to do much more so > > >> > than the kernel ever can. > > >> > > >> For 'real' devices that sounds sensible. The thing about loop devices > > >> is that we simply want to allow a container to say "give me a loop > > >> device to use" and have it receive a unique loop device (or 3), without > > >> having to pre-assign them. I think that would be cleaner to do using > > >> a pseudofs and loop-control device, rather than having to have a > > >> daemon in userspace on the host farming those out in response to > > >> some, I don't know, dbus request? > > > > > > I agree that loop devices would be nice to have in a container, and that > > > the existing loop interface doesn't really lend itself to that. So > > > create a new type of thing that acts like a loop device in a container. > > > But don't try to mess with the whole driver core just for a single type > > > of device. > > > > Yes. Something like devpts (without the newinstance option). Built to > > allow unprivileged users to create loopback devices. > > That's where I started, and I've got code, so I guess I'll clean it up > and send patches. If the stance is that only system-wide CAP_SYS_ADMIN > gets to do privileged block device ioctls, including reading partitions Sorry, where did that come from? What Eric was referring to below is the fs superblock readers not being trusted. Maybe I glossed over another email where it was mentioned? > on a block device which has been assigned to a contiainer, then I guess > that approach works well enough. > > > There is still a huge kettle of fish in with verifying a filesystem is > > safe from a hostile user that has acess to the block device while the > > filesystem is mounted. > > > > Having a few filesystems that are robust enough to trust with arbitrary > > filesystem corruption would be very interesting. > > > > I assume unprivileged and hostile users because if you trusted the real > > root inside of your container this would not be an issue. > > > > Eric > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Quoting James Bottomley (james.bottom...@hansenpartnership.com): > On Fri, 2014-05-16 at 11:57 -0700, Greg Kroah-Hartman wrote: > > On Fri, May 16, 2014 at 09:06:07AM -0500, Seth Forshee wrote: > > > On Thu, May 15, 2014 at 09:35:32PM -0700, Greg Kroah-Hartman wrote: > > > > On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote: > > > > > > I think having to pick and choose what device nodes you want in a > > > > > > container is a good thing. Becides, you would have to do the same > > > > > > thing > > > > > > in the kernel anyway, what's wrong with userspace making the > > > > > > decision > > > > > > here, especially as it knows exactly what it wants to do much more > > > > > > so > > > > > > than the kernel ever can. > > > > > > > > > > For 'real' devices that sounds sensible. The thing about loop devices > > > > > is that we simply want to allow a container to say "give me a loop > > > > > device to use" and have it receive a unique loop device (or 3), > > > > > without > > > > > having to pre-assign them. I think that would be cleaner to do using > > > > > a pseudofs and loop-control device, rather than having to have a > > > > > daemon in userspace on the host farming those out in response to > > > > > some, I don't know, dbus request? > > > > > > > > I agree that loop devices would be nice to have in a container, and that > > > > the existing loop interface doesn't really lend itself to that. So > > > > create a new type of thing that acts like a loop device in a container. > > > > But don't try to mess with the whole driver core just for a single type > > > > of device. > > > > > > No matter what I don't think we get out of this without driver core > > > changes, whether this was done in loop or by creating something new. > > > Not unless the whole thing is punted to userspace, anyway. > > > > > > The first problem is that many block device ioctls check for > > > CAP_SYS_ADMIN. Most of these might not ever be used on loop devices, I'm > > > not really sure. But loop does at minimum support partitions, and to get > > > that functionality in an unprivileged container at least the block layer > > > needs to know the namespace which has privileges for that device. > > > > That's fine, you should have those permissions in a container if you > > want to do something like that on a loop device, right? > > Really, no. CAP_SYS_ADMIN is effectively a pseudo root security hole. > Any user possessing CAP_SYS_ADMIN can do about as much damage as real > root can, whether or not you use user namespaces, so it would compromise > a lot of the security we're just bringing to containers. > > > > The second is that all block devices automatically appear in devtmpfs. > > > The scenario I'm concerned about is that the host could unknowingly use > > > a loop device exposed to a container, then the container could see data > > > from the host. > > > > I don't think that's a real issue, the host should know not to do that. > > > > > So we either need a flag to tell the driver core not to create a node > > > in devtmpfs, or we need a privileged manager in userspace to remove > > > them (which kind of defeats the purpose). And it gets more complicated > > > when partition block devs are mixed in, because they can be created > > > without involvement from the driver - they would need to inherit the > > > "no devtmpfs node" property from their parent, and if the driver uses > > > a psuedo fs to create device nodes for userspace then it needs to be > > > informed about the partitions too so it can create those nodes. > > > > I don't think that will be needed. Root in a host can do whatever it > > wants in the containers, so mixing up block devices is the least of the > > issues involved :) > > > > > So maybe we could get by without the privileged ioctls, as long as it > > > was understood that unprivileged containers can't do partitioning. But I > > > do think the devtmpfs problem would need to be addressed. > > > > I don't think unpriviliged containers should be able to do partitioning. > > An unpriviliged user can't do that, so why should a container be any > > different? > > To make sure we're on the same page with terminology, there's an > unprivileged container and a secure container. In the former, there's Hm, that terminology (which isn't what we've been using) could be useful, but is still not quite precise enough if we're going down that road. > no root user (all the processes run as non-root), so the container isn't "there is no root user" and "all processes run as non-root" are not the same thing. Is it just that no processes are running as root? Or that uid 0 in the container is not mapped at all and hence not achievable? The former really isn't a function of the container itself, and depends on there really not being any setuid-root or capability-wielding files available in the container. If the latter, and you're hoping to claim that the host is saved from the container
[PATCH] drivers/gpu/drm/i915/intel_display: coding style fixes
Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: Robin Schroer
---
drivers/gpu/drm/i915/intel_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b9256aa..ff21924 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -962,7 +962,7 @@ bool ibx_digital_port_connected(struct drm_i915_private
*dev_priv,
u32 bit;
if (HAS_PCH_IBX(dev_priv->dev)) {
- switch(port->port) {
+ switch (port->port) {
case PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
@@ -976,7 +976,7 @@ bool ibx_digital_port_connected(struct drm_i915_private
*dev_priv,
return true;
}
} else {
- switch(port->port) {
+ switch (port->port) {
case PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
@@ -3221,9 +3221,8 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
udelay(100);
/* Ironlake workaround, disable clock pointer after downing FDI */
- if (HAS_PCH_IBX(dev)) {
+ if (HAS_PCH_IBX(dev))
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
- }
/* still set train pattern 1 */
reg = FDI_TX_CTL(pipe);
@@ -5844,7 +5843,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
} else {
i9xx_update_pll(intel_crtc,
has_reduced_clock ? _clock : NULL,
-num_connectors);
+ num_connectors);
}
skip_dpll:
@@ -6220,8 +6219,7 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
if (intel_panel_use_ssc(dev_priv) && can_ssc) {
DRM_DEBUG_KMS("Using SSC on eDP\n");
val |= DREF_CPU_SOURCE_OUTPUT_DOWNSPREAD;
- }
- else
+ } else
val |= DREF_CPU_SOURCE_OUTPUT_NONSPREAD;
} else
val |= DREF_CPU_SOURCE_OUTPUT_DISABLE;
@@ -8844,7 +8842,7 @@ void intel_prepare_page_flip(struct drm_device *dev, int
plane)
spin_unlock_irqrestore(>event_lock, flags);
}
-inline static void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
+static inline void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
{
/* Ensure that the work item is consistent when activating it ... */
smp_wmb();
@@ -9054,7 +9052,7 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
if (ret)
goto err;
- switch(intel_crtc->plane) {
+ switch (intel_crtc->plane) {
case PLANE_A:
plane_bit = MI_DISPLAY_FLIP_IVB_PLANE_A;
break;
@@ -9333,7 +9331,7 @@ static void intel_modeset_commit_output_state(struct
drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector * connector,
+connected_sink_compute_bpp(struct intel_connector *connector,
struct intel_crtc_config *pipe_config)
{
int bpp = pipe_config->pipe_bpp;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] ARM: dts: am33xx: Re-arrange the USB dt to reflect the h/w configuration
Hello Tony, On 14 May 02:50 PM, Tony Lindgren wrote: > * George Cherian [140508 23:34]: > > Re arrange the USB dt for AM33xx to take it a bit closer > > to the hardware configuration. > > [..] > > Is this just a cosmetic change or is this trying to workaround > some edma related init order issue? > This was an attempt from George to workaround an that happens when the musb_am335x module is removed. However, we've agreed to prevent the removal instead. I've just (re)sent a patch for it: See: [PATCH for v3.15] usb: musb: Fix panic upon musb_am335x module removal AFAIK, this fixes a serious problem so I've marked it for stable. For the DMA init order issue, I've done a new patch that forces the probe order in the driver. I'll post that soon. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] staging: dgnc: Put else statements on the right line
Fix indenting of if-else statement in dgnc_neo.c and dgnc_tty.c
so that following else-if or else statement meets coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c | 48 +--
drivers/staging/dgnc/dgnc_tty.c | 36 ++---
2 files changed, 28 insertions(+), 56 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index cf22c7b..e87cf49 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -485,8 +485,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_UNLOCK(ch->ch_lock, lock_flags);
}
DPR_INTR(("Port %d. XON detected in incoming
data\n", port));
- }
- else if (cause == UART_17158_XOFF_DETECT) {
+ } else if (cause == UART_17158_XOFF_DETECT) {
if (!(brd->channels[port]->ch_flags & CH_STOP))
{
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_flags |= CH_STOP;
@@ -511,8 +510,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat |= UART_MCR_RTS;
DGNC_UNLOCK(ch->ch_lock, lock_flags);
- }
- else {
+ } else {
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat &= ~(UART_MCR_RTS);
DGNC_UNLOCK(ch->ch_lock, lock_flags);
@@ -522,8 +520,7 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat |= UART_MCR_DTR;
DGNC_UNLOCK(ch->ch_lock, lock_flags);
- }
- else {
+ } else {
DGNC_LOCK(ch->ch_lock, lock_flags);
ch->ch_mostat &= ~(UART_MCR_DTR);
DGNC_UNLOCK(ch->ch_lock, lock_flags);
@@ -624,8 +621,7 @@ static inline void neo_parse_lsr(struct dgnc_board *brd,
uint port)
/* Transfer data (if any) from Write Queue -> UART. */
neo_copy_data_from_queue_to_uart(ch);
- }
- else if (linestatus & UART_17158_TX_AND_FIFO_CLR) {
+ } else if (linestatus & UART_17158_TX_AND_FIFO_CLR) {
brd->intr_tx++;
ch->ch_intr_tx++;
DGNC_LOCK(ch->ch_lock, lock_flags);
@@ -834,8 +830,7 @@ static void neo_param(struct tty_struct *tty)
if (ch->ch_c_cflag & CREAD) {
ier |= (UART_IER_RDI | UART_IER_RLSI);
- }
- else {
+ } else {
ier &= ~(UART_IER_RDI | UART_IER_RLSI);
}
@@ -848,8 +843,7 @@ static void neo_param(struct tty_struct *tty)
!(ch->ch_c_cflag & CLOCAL))
{
ier |= UART_IER_MSI;
- }
- else {
+ } else {
ier &= ~UART_IER_MSI;
}
@@ -863,29 +857,25 @@ static void neo_param(struct tty_struct *tty)
if (ch->ch_digi.digi_flags & CTSPACE || ch->ch_c_cflag & CRTSCTS) {
neo_set_cts_flow_control(ch);
- }
- else if (ch->ch_c_iflag & IXON) {
+ } else if (ch->ch_c_iflag & IXON) {
/* If start/stop is set to disable, then we should disable flow
control */
if ((ch->ch_startc == _POSIX_VDISABLE) || (ch->ch_stopc ==
_POSIX_VDISABLE))
neo_set_no_output_flow_control(ch);
else
neo_set_ixon_flow_control(ch);
- }
- else {
+ } else {
neo_set_no_output_flow_control(ch);
}
if (ch->ch_digi.digi_flags & RTSPACE || ch->ch_c_cflag & CRTSCTS) {
neo_set_rts_flow_control(ch);
- }
- else if (ch->ch_c_iflag & IXOFF) {
+ } else if (ch->ch_c_iflag & IXOFF) {
/* If start/stop is set to disable, then we should disable flow
control */
if ((ch->ch_startc == _POSIX_VDISABLE) || (ch->ch_stopc ==
_POSIX_VDISABLE))
neo_set_no_input_flow_control(ch);
else
neo_set_ixoff_flow_control(ch);
- }
- else {
+ } else {
neo_set_no_input_flow_control(ch);
}
@@ -1227,8 +1217,7 @@ static void neo_copy_data_from_uart_to_queue(struct
channel_t *ch)
[PATCH v2 0/3] Fix coding style of if statement
This is the modified patches of
[PATCH x/4] Fix coding style of if statment
The following pateches fix the errors and warnings below in
dgnc_neo.c and dgnc_tty.c to meet kernel coding style.
ERROR: else should follow close brace '}'
ERROR: that open brace { should be on the previous line
WARNING: line over 80 characters
WARNING: braces {} are not necessary for single statement blocks
Masaru Nomura (3):
staging: dgnc: Put else statements on the right line
staging: dgnc: dgnc_neo: Clean up if statement
staging: dgnc: Remove extra curly braces
drivers/staging/dgnc/dgnc_neo.c | 112 +++
drivers/staging/dgnc/dgnc_tty.c | 140 ++-
2 files changed, 88 insertions(+), 164 deletions(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] staging: dgnc: Remove extra curly braces
Remove unnecessary curly braces of if statements in dgnc_neo.c and
dgnc_tty.c to meet kernel coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c | 60 -
drivers/staging/dgnc/dgnc_tty.c | 110 ++-
2 files changed, 61 insertions(+), 109 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 10b6016..2d472e6 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -434,9 +434,8 @@ static inline void neo_parse_isr(struct dgnc_board *brd,
uint port)
isr = readb(>ch_neo_uart->isr_fcr);
/* Bail if no pending interrupt */
- if (isr & UART_IIR_NO_INT) {
+ if (isr & UART_IIR_NO_INT)
break;
- }
/*
* Yank off the upper 2 bits, which just show that the FIFO's
are enabled.
@@ -650,24 +649,20 @@ static void neo_param(struct tty_struct *tty)
struct channel_t *ch;
struct un_t *un;
- if (!tty || tty->magic != TTY_MAGIC) {
+ if (!tty || tty->magic != TTY_MAGIC)
return;
- }
un = (struct un_t *) tty->driver_data;
- if (!un || un->magic != DGNC_UNIT_MAGIC) {
+ if (!un || un->magic != DGNC_UNIT_MAGIC)
return;
- }
ch = un->un_ch;
- if (!ch || ch->magic != DGNC_CHANNEL_MAGIC) {
+ if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
return;
- }
bd = ch->ch_bd;
- if (!bd || bd->magic != DGNC_BOARD_MAGIC) {
+ if (!bd || bd->magic != DGNC_BOARD_MAGIC)
return;
- }
DPR_PARAM(("param start: tdev: %x cflags: %x oflags: %x iflags: %x\n",
ch->ch_tun.un_dev, ch->ch_c_cflag, ch->ch_c_oflag,
ch->ch_c_iflag));
@@ -773,13 +768,11 @@ static void neo_param(struct tty_struct *tty)
}
}
- if (ch->ch_c_cflag & PARENB) {
+ if (ch->ch_c_cflag & PARENB)
lcr |= UART_LCR_PARITY;
- }
- if (!(ch->ch_c_cflag & PARODD)) {
+ if (!(ch->ch_c_cflag & PARODD))
lcr |= UART_LCR_EPAR;
- }
/*
* Not all platforms support mark/space parity,
@@ -828,11 +821,10 @@ static void neo_param(struct tty_struct *tty)
if (uart_lcr != lcr)
writeb(lcr, >ch_neo_uart->lcr);
- if (ch->ch_c_cflag & CREAD) {
+ if (ch->ch_c_cflag & CREAD)
ier |= (UART_IER_RDI | UART_IER_RLSI);
- } else {
+ else
ier &= ~(UART_IER_RDI | UART_IER_RLSI);
- }
/*
* Have the UART interrupt on modem signal changes ONLY when
@@ -1215,11 +1207,10 @@ static void neo_copy_data_from_uart_to_queue(struct
channel_t *ch)
* The count can be any where from 0-3 bytes "off".
* Bizarre, but true.
*/
- if ((ch->ch_bd->dvid & 0xf0) >= UART_XR17E158_DVID) {
+ if ((ch->ch_bd->dvid & 0xf0) >= UART_XR17E158_DVID)
total -= 1;
- } else {
+ else
total -= 3;
- }
}
@@ -1263,9 +1254,8 @@ static void neo_copy_data_from_uart_to_queue(struct
channel_t *ch)
* will reset some bits after our read, we need to ensure
* we don't miss our TX FIFO emptys.
*/
- if (linestatus & (UART_LSR_THRE | UART_17158_TX_AND_FIFO_CLR)) {
+ if (linestatus & (UART_LSR_THRE | UART_17158_TX_AND_FIFO_CLR))
ch->ch_flags |= (CH_TX_FIFO_EMPTY | CH_TX_FIFO_LWM);
- }
linestatus = 0;
@@ -1393,19 +1383,16 @@ static int neo_drain(struct tty_struct *tty, uint
seconds)
struct un_t *un;
int rc = 0;
- if (!tty || tty->magic != TTY_MAGIC) {
+ if (!tty || tty->magic != TTY_MAGIC)
return -ENXIO;
- }
un = (struct un_t *) tty->driver_data;
- if (!un || un->magic != DGNC_UNIT_MAGIC) {
+ if (!un || un->magic != DGNC_UNIT_MAGIC)
return -ENXIO;
- }
ch = un->un_ch;
- if (!ch || ch->magic != DGNC_CHANNEL_MAGIC) {
+ if (!ch || ch->magic != DGNC_CHANNEL_MAGIC)
return -ENXIO;
- }
DPR_IOCTL(("%d Drain wait started.\n", __LINE__));
@@ -1422,11 +1409,10 @@ static int neo_drain(struct tty_struct *tty, uint
seconds)
rc = wait_event_interruptible(un->un_flags_wait, ((un->un_flags &
UN_EMPTY) == 0));
/* If ret is non-zero, user ctrl-c'ed us */
- if (rc) {
+ if (rc)
DPR_IOCTL(("%d Drain - User ctrl c'ed\n", __LINE__));
- } else {
+ else
DPR_IOCTL(("%d Drain wait finished.\n", __LINE__));
- }
return rc;
}
@@ -1442,9 +1428,8 @@ static
[PATCH v2 2/3] staging: dgnc: dgnc_neo: Clean up if statement
Fix line over 80 characters and indenting of condition part.
Also, remove unnecessary braces to meet coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/dgnc/dgnc_neo.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index e87cf49..10b6016 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -838,14 +838,14 @@ static void neo_param(struct tty_struct *tty)
* Have the UART interrupt on modem signal changes ONLY when
* we are in hardware flow control mode, or CLOCAL/FORCEDCD is not set.
*/
- if ((ch->ch_digi.digi_flags & CTSPACE) || (ch->ch_digi.digi_flags &
RTSPACE) ||
- (ch->ch_c_cflag & CRTSCTS) || !(ch->ch_digi.digi_flags &
DIGI_FORCEDCD) ||
- !(ch->ch_c_cflag & CLOCAL))
- {
+ if ((ch->ch_digi.digi_flags & CTSPACE) ||
+ (ch->ch_digi.digi_flags & RTSPACE) ||
+ (ch->ch_c_cflag & CRTSCTS) ||
+ !(ch->ch_digi.digi_flags & DIGI_FORCEDCD) ||
+ !(ch->ch_c_cflag & CLOCAL))
ier |= UART_IER_MSI;
- } else {
+ else
ier &= ~UART_IER_MSI;
- }
ier |= UART_IER_THRI;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Dell Latitude E6440 & i8k
On Saturday 17 May 2014 17:34:34 Guenter Roeck wrote: > On 05/16/2014 12:23 PM, Pali Rohár wrote: > > On Friday 16 May 2014 21:11:17 Jean Delvare wrote: > >> Hi Pali, > >> > >> On Fri, 16 May 2014 20:37:41 +0200, Pali Rohár wrote: > >>> Hello, > >>> > >>> on Dell Latitude E6440 driver i8k reporting total nonsense > >>> values > >> > >> That's kind of excessive wording, the output isn't that > >> bad. > > > > I mean fan RPM & temp4. Those are for sure incorrect. > > > >>> $ sensors > >>> i8k-virtual-0 > >>> Adapter: Virtual device > >>> Right Fan: 93450 RPM > >>> CPU: +57.0°C > >>> temp2:+57.0°C > >>> temp3:+40.0°C > >>> temp4: +127.0°C > >>> > >>> Right Fan and temp4 are for sure incorrect. > >> > >> Driver is reverse-engineered so this is best effort and > >> some tweaking may be needed. > > > > Ok, if driver is developed without any documentation, then > > it make sense that not working correctly on new machines... > > > > So is not there any documentation? I think that Dell > > released some SMM/BIOS code... But I'm not sure about it. > > If you find it, please let us know. > > Guenter Now I remembered... Dell has released info about their smbios extensions with example programs at: https://linux.dell.com/libsmbios/main/ https://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=libsmbios.git;a=summary But there is nothing about fan control or temperature. Also I found smbios specification: http://www.dmtf.org/standards/smbios There is something written about fan and temp, but no idea if it is usefull for something... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
Hello Russell, On Sat, May 17, 2014 at 11:35:55PM +0100, Russell King - ARM Linux wrote: > On Sun, May 18, 2014 at 01:08:36AM +0300, Dan Carpenter wrote: > > Let's look at that error handling again. > > > > err: <-- the name is not descriptive. the location is bad. > > kfree(pdev->dev.dma_mask); <- null dereference. > > platform_device_put(pdev); <- ok > > return ERR_PTR(-ENODEV);<- should be "return ERR_PTR(ret);" > > > > 3 out of 4 of the lines are bad. > > 2 out of 4. kfree(NULL) is perfectly legal. I believe pdev could potentially be NULL, so it's the dereference that is the problem. Best regards, Emil Goode -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] target fixes for v3.15-rc6
On Fri, 2014-05-16 at 14:32 -0700, Nicholas A. Bellinger wrote: > Hello Linus, > > Here are the target-pending fixes for v3.15-rc6. Please go ahead and > pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master > > This series include: > > - Close race between iser-target network portal shutdown + accepting > new connection logins (sagi) > - Fix free-after-use regression in tcm_fc post conversion to > percpu-ida pre-allocation (nab) > - Explicitly disable Immediate + Unsolicited Data for iser-target > connections when T10-PI is enabled (sagi + nab) > - Allow pi_prot_type + emulate_write_cache attributes to be set to > zero regardless of backend support (andy) > Hi Linus, One last minute bugfix from Mikulas has been included in this PULL request. Here is the updated short-log + diffstat. Thank you, --nab Andy Grover (2): target: Allow non-supporting backends to set pi_prot_type to 0 target: Don't allow setting WC emulation if device doesn't support Mikulas Patocka (1): target: fix memory leak on XCOPY Nicholas Bellinger (3): iscsi-target: Change BUG_ON to REJECT in iscsit_process_nop_out tcm_fc: Fix free-after-use regression in ft_free_cmd iscsi-target: Disable Immediate + Unsolicited Data with ISER Protection Sagi Grimberg (3): Target/iser: Fix wrong connection requests list addition Target/iser: Fix iscsit_accept_np and rdma_cm racy flow Target/iscsi,iser: Avoid accepting transport connections during stop stage drivers/infiniband/ulp/isert/ib_isert.c | 38 + drivers/infiniband/ulp/isert/ib_isert.h |2 +- drivers/target/iscsi/iscsi_target.c |4 ++- drivers/target/iscsi/iscsi_target_core.h |1 + drivers/target/iscsi/iscsi_target_login.c | 28 - drivers/target/iscsi/iscsi_target_tpg.c |1 + drivers/target/target_core_device.c | 12 ++--- drivers/target/target_core_transport.c|2 +- drivers/target/tcm_fc/tfc_cmd.c |8 +++--- 9 files changed, 63 insertions(+), 33 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
On Sat, May 17, 2014 at 11:35:55PM +0100, Russell King - ARM Linux wrote: > On Sun, May 18, 2014 at 01:08:36AM +0300, Dan Carpenter wrote: > > Let's look at that error handling again. > > > > err: <-- the name is not descriptive. the location is bad. > > kfree(pdev->dev.dma_mask); <- null dereference. > > platform_device_put(pdev); <- ok > > return ERR_PTR(-ENODEV);<- should be "return ERR_PTR(ret);" > > > > 3 out of 4 of the lines are bad. > > 2 out of 4. kfree(NULL) is perfectly legal. pdev was NULL though... The bug is *caused* by trying to use the same "err" label to do all error handling. This is a very common anti-patern, but if you follow canonical kernel style then your error handling is less buggy. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Dell Latitude E6440 & i8k
On Friday 16 May 2014 21:11:17 you wrote: > Hi Pali, > > On Fri, 16 May 2014 20:37:41 +0200, Pali Rohár wrote: > > Hello, > > > > on Dell Latitude E6440 driver i8k reporting total nonsense > > values > > That's kind of excessive wording, the output isn't that bad. > > > $ sensors > > i8k-virtual-0 > > Adapter: Virtual device > > Right Fan: 93450 RPM > > CPU: +57.0°C > > temp2:+57.0°C > > temp3:+40.0°C > > temp4: +127.0°C > > > > Right Fan and temp4 are for sure incorrect. > > Driver is reverse-engineered so this is best effort and some > tweaking may be needed. > > > Value temp4 is always 127 and is never changing, but value > > for Right Fan is increasing when fan is more noisy. So it > > looks like value for Right Fan is not correctly normalized > > or multiplier is incorrect. > > > > And name "Right" is incorrect too. Fan is on left side of > > this notebook, not right as reported by driver. > > > > It is possible to fix these problems? > > Load the i8k driver with fan_mult=1. > > Add the following to /etc/sensors.d/i8k.conf: > > chip "i8k-virtual-0" > >label fan2 "Left Fan" >ignore temp4 I have some new info about temp4. When I read value from temp4 for first time it reports (possible) correct value: $ cat /sys/class/hwmon/hwmon2/temp4_input 49000 But every next call it returns 127000 which is incorrect. So this looks like bug in BIOS or incorrect usage of SMM call... Do you know if there is any way to extract BIOS SMM code? Or it is something which is not possible to do from OS/kernel side? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] target: fix memory leak on XCOPY
On Sat, 2014-05-17 at 06:49 -0400, Mikulas Patocka wrote: > On each processed XCOPY command, two "kmalloc-512" memory objects are > leaked. These represent two allocations of struct xcopy_pt_cmd in > target_core_xcopy.c. > > The reason for the memory leak is that the cmd_kref field is not > initialized (thus, it is zero because the allocations were done with > kzalloc). When we decrement zero kref in target_put_sess_cmd, the result > is not zero, thus target_release_cmd_kref is not called. > > This patch fixes the bug by moving kref initialization from > target_get_sess_cmd to transport_init_se_cmd (this function is called from > target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be > easily verified that all code that calls target_get_sess_cmd also calls > transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce > any new problems. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org# 3.12+ > > --- > drivers/target/target_core_transport.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-3.15-rc5/drivers/target/target_core_transport.c > === > --- linux-3.15-rc5.orig/drivers/target/target_core_transport.c > 2014-04-14 16:08:15.0 +0200 > +++ linux-3.15-rc5/drivers/target/target_core_transport.c 2014-05-16 > 18:24:57.0 +0200 > @@ -1113,6 +1113,7 @@ void transport_init_se_cmd( > init_completion(>cmd_wait_comp); > init_completion(>task_stop_comp); > spin_lock_init(>t_state_lock); > + kref_init(>cmd_kref); > cmd->transport_state = CMD_T_DEV_ACTIVE; > > cmd->se_tfo = tfo; > @@ -2357,7 +2358,6 @@ int target_get_sess_cmd(struct se_sessio > unsigned long flags; > int ret = 0; > > - kref_init(_cmd->cmd_kref); > /* >* Add a second kref if the fabric caller is expecting to handle >* fabric acknowledgement that requires two target_put_sess_cmd() > -- Applied. Thanks alot Mikulas! --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
Hello Dan,
On Sun, May 18, 2014 at 01:08:36AM +0300, Dan Carpenter wrote:
> On Sat, May 17, 2014 at 09:18:21PM +0200, Uwe Kleine-König wrote:
> > diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > index fc4dd7cedc11..6bd7c3f37ac0 100644
> > --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > @@ -77,7 +77,7 @@ struct platform_device *__init imx_alloc_mx3_camera(
> >
> > pdev = platform_device_alloc("mx3-camera", 0);
> > if (!pdev)
> > - goto err;
> > + return ERR_PTR(-ENOMEM);
> >
> > pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
> > if (!pdev->dev.dma_mask)
>
> Emil, do this one, please and not the second suggestion.
Yes, I would pick this one to.
>
> Direct returns are more readable. Otherwise, you wonder what the goto
> is for and where it will take you and be annoyed to discover it is a
> waste of time, no-op goto. Also you will wonder if platform_device_put()
> accepts NULL pointers. Thirdly there is a small ugliness that the error
> code is not preserved. What is the point of setting the error code to
> -ENOMEM only to discard it?
>
> Let's look at that error handling again.
>
> err: <-- the name is not descriptive. the location is bad.
> kfree(pdev->dev.dma_mask); <- null dereference.
> platform_device_put(pdev); <- ok
> return ERR_PTR(-ENODEV);<- should be "return ERR_PTR(ret);"
>
> 3 out of 4 of the lines are bad.
I agree that it's not very pretty.
Now that Uwe solved the issue regarding converting the function to
platform_device_register_full(), I will look into sending a second patch
that would remove these lines.
Thank you!
Best regards,
Emil Goode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching
On Sat, May 17, 2014 at 03:09:57AM +0900, Masami Hiramatsu wrote:
> (2014/05/17 1:27), Jiri Kosina wrote:
> > On Tue, 6 May 2014, Steven Rostedt wrote:
> >
> >>> However, I also think if users can accept such freezing wait-time,
> >>> it means they can also accept kexec based "checkpoint-restart" patching.
> >>> So, I think the final goal of the kpatch will be live patching without
> >>> stopping the machine. I'm discussing the issue on github #138, but that is
> >>> off-topic. :)
> >>
> >> I agree with Ingo too. Being conservative at first is the right
> >> approach here. We should start out with a stop_machine making sure that
> >> everything is sane before we continue. Sure, that's not much different
> >> than a kexec, but lets take things one step at a time.
> >>
> >> ftrace did the stop_machine (and still does for some archs), and slowly
> >> moved to a more efficient method. kpatch/kgraft should follow suit.
> >
> > I don't really agree here.
> >
> > I actually believe that "lazy" switching kgraft is doing provides a little
> > bit more in the sense of consistency than stop_machine()-based aproach.
> >
> > Consider this scenario:
> >
> > void foo()
> > {
> > for (i=0; i<1; i++) {
> > bar(i);
> > something_else(i);
> > }
> > }
>
> In this case, I'd recommend you to add foo() to replacing target
> as dummy. Then, kpatch can ensure foo() is actually not running. :)
The problem is: Where do you stop?
Adding the whole list of functions that transitively may ever call bar()
can be pretty much the whole kernel. And given that you can be calling
via pointer, you can't often even tell who is calling bar().
So yes, a developer could manually include foo() in the to be patched
list, so that it is checked that foo() isn't being executed while
patching.
But that would have to be done entirely manually after thoroughly
understanding the implications of the patch.
> > Let's say you want to live-patch bar(). With stop_machine()-based aproach,
> > you can easily end-up with old bar() and new bar() being called in two
> > consecutive iterations before the loop is even exited, right? (especially
> > on preemptible kernel, or if something_else() goes to sleep).
> >
> > With lazy-switching implemented in kgraft, this can never happen.
>
> And I guess similar thing may happen with kgraft. If old function and
> new function share a non-auto variable and they modify it different way,
> the result will be unexpected by the mutual interference.
By non-auto I assume you mean globally accessible variable or data
structures.
Yes, with kGraft the new function has to be backward compatible with
pre-patch global data layout and semantics.
The parameters, return value and their semantics are free to change,
though, and kGraft guarantees consistency there.
--
Vojtech Pavlik
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] workqueue: Create low-level unbound workqueues cpumask
On Fri, 16 May 2014, Tejun Heo wrote: > > Make the uevent stuff work on all of sysfs? > > I don't know. Maybe. Likely a lot more work involving user space > changes tho. Also, it runs contrary to what we've been doing to other > top-level cgroup directories. Any reason not to do, say, > /sys/devices/kernel? The other kernel tunables are in /sys/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/
Re: [PATCH 2/4] cpupower: Remove redundant error check
On Sun, May 18, 2014 at 12:31:29AM +0200, Peter Senna Tschudin wrote: > > > > I am currently involved in a number of threads, not just yours, where I > > am encouraging people to replace ambiguous returns with "return 0;". > > This is my life now. > So maybe you like this list of 160 places in which the return variable > is initialized and only used as parameter to return(The list look > good, but I haven't reviewed all 160, so there could be problems): > http://pastebin.com/5kAbCP2e Fantastic! :) These things are easy to review because if it's wrong then the compile will break. > > Does it worth doing something about those trivial cases? > > Do you have more examples of ambiguous returns, so I can help you hunt them? The main thing is what your check finds. If you know that ret is zero then return zero. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
On Sun, May 18, 2014 at 01:08:36AM +0300, Dan Carpenter wrote: > Let's look at that error handling again. > > err: <-- the name is not descriptive. the location is bad. > kfree(pdev->dev.dma_mask); <- null dereference. > platform_device_put(pdev); <- ok > return ERR_PTR(-ENODEV);<- should be "return ERR_PTR(ret);" > > 3 out of 4 of the lines are bad. 2 out of 4. kfree(NULL) is perfectly legal. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] IB/mlx4: fix unitialised variable is_mcast
From: Colin Ian King
Commit 297e0dad7 introduced a bug where is_mcast is now
no longer initiialised on the non-multicast condition and so
it can be any random value from the stack. This issue was
detected by cppcheck:
[drivers/infiniband/hw/mlx4/ah.c:103]: (error) Uninitialized
variable: is_mcast
Simple fix is to initialise is_mcast to zero.
Signed-off-by: Colin Ian King
---
drivers/infiniband/hw/mlx4/ah.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx4/ah.c b/drivers/infiniband/hw/mlx4/ah.c
index 170dca6..2d8c339 100644
--- a/drivers/infiniband/hw/mlx4/ah.c
+++ b/drivers/infiniband/hw/mlx4/ah.c
@@ -73,7 +73,7 @@ static struct ib_ah *create_iboe_ah(struct ib_pd *pd, struct
ib_ah_attr *ah_attr
{
struct mlx4_ib_dev *ibdev = to_mdev(pd->device);
struct mlx4_dev *dev = ibdev->dev;
- int is_mcast;
+ int is_mcast = 0;
struct in6_addr in6;
u16 vlan_tag;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] cpupower: Remove redundant error check
On Sat, May 17, 2014 at 11:56 PM, Dan Carpenter
wrote:
> On Sat, May 17, 2014 at 11:34:46PM +0200, Peter Senna Tschudin wrote:
>> On Sat, May 17, 2014 at 10:22 PM, Dan Carpenter
>> wrote:
>> > On Sat, May 17, 2014 at 08:22:58PM +0200, Peter Senna Tschudin wrote:
>> >> diff --git a/tools/power/cpupower/utils/cpufreq-set.c
>> >> b/tools/power/cpupower/utils/cpufreq-set.c
>> >> index a416de8..4e2f35a 100644
>> >> --- a/tools/power/cpupower/utils/cpufreq-set.c
>> >> +++ b/tools/power/cpupower/utils/cpufreq-set.c
>> >> @@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
>> >>
>> >> printf(_("Setting cpu: %d\n"), cpu);
>> >> ret = do_one_cpu(cpu, _pol, freq, policychange);
>> >> - if (ret)
>> >> + if (ret) {
>> >> + print_error();
>> >> break;
>> >
>> > Just return directly instead of break return;
>> >
>> >> + }
>> >> }
>> >>
>> >> - if (ret)
>> >> - print_error();
>> >> -
>> >> return ret;
>> >
>> > Are you sure this patch is correct? Theoretically, it's possible to
>> > reach the end of this function without going hitting the
>> > "ret = do_one_cpu(...);" assignment.
>> >
>> > Don't be fooled by the "int ret = 0;" initialization, that is a trick
>> > initialization to mislead the unwary. By the end of the do while loop
>> > then "ret" is always -1.
>> I have missed that, thank you for pointing this out. This patch is
>> wrong and should not be applied, please ignore it.
>>
>> Dan, should I just leave this file as it is?
>
> I think in reality we should always hit the "ret = do_one_cpu()"
> assignment. But your static analysis tool should say that we don't know
> that, so that's why I brought it up.
>
> My guess is that the original code is bad and we should say:
>
> ret = do_one_cpu(cpu, _pol, freq, policychange);
> if (ret) {
> print_error();
> return ret;
> }
> }
>
> return 0;
Sent V2. Thank you for the help.
>
> I am currently involved in a number of threads, not just yours, where I
> am encouraging people to replace ambiguous returns with "return 0;".
> This is my life now.
So maybe you like this list of 160 places in which the return variable
is initialized and only used as parameter to return(The list look
good, but I haven't reviewed all 160, so there could be problems):
http://pastebin.com/5kAbCP2e
Does it worth doing something about those trivial cases?
Do you have more examples of ambiguous returns, so I can help you hunt them?
>
> regards,
> dan carpenter
>
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
Hello Uwe,
I was to quick to resend the patch, sorry.
On Sat, May 17, 2014 at 09:18:21PM +0200, Uwe Kleine-König wrote:
> Hello Emil,
>
> On Sat, May 17, 2014 at 08:40:33PM +0200, Emil Goode wrote:
> > If we fail to allocate struct platform_device pdev we
> > dereference it after the goto label err.
> >
> > I have rearranged the error handling a bit to fix the issue
> > and also make it more clear.
> >
> > Signed-off-by: Emil Goode
> > ---
> > v3: Made subject line more specific.
> > v2: Changed to return -ENOMEM instead of ret where possible and
> > updated the subject line.
> >
> > arch/arm/mach-imx/devices/platform-ipu-core.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> Considering that you can fix the issue also by just doing:
>
> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> index fc4dd7cedc11..6bd7c3f37ac0 100644
> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> @@ -77,7 +77,7 @@ struct platform_device *__init imx_alloc_mx3_camera(
>
> pdev = platform_device_alloc("mx3-camera", 0);
> if (!pdev)
> - goto err;
> + return ERR_PTR(-ENOMEM);
>
> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
> if (!pdev->dev.dma_mask)
>
> or
>
> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> index fc4dd7cedc11..c609f3667200 100644
> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> @@ -96,7 +96,8 @@ struct platform_device *__init imx_alloc_mx3_camera(
> ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> if (ret) {
> err:
> - kfree(pdev->dev.dma_mask);
> + if (pdev)
> + kfree(pdev->dev.dma_mask);
> platform_device_put(pdev);
> return ERR_PTR(-ENODEV);
> }
>
> I would prefer one of them as it is easier to justify and for the next
> cycle convert the function to platform_device_register_full.
Agreed, that makes sense considering the second patch that would convert to
platform_device_register_full().
>
> Also you should point out in the commit log that the issue was found by
> coccinelle.
Ok, will do that.
Thank you!
Best regards,
Emil Goode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Dell Latitude E6440 & i8k
On 05/17/2014 02:09 PM, Jean Delvare wrote: On Sat, 17 May 2014 08:25:38 -0700, Guenter Roeck wrote: On 05/16/2014 12:11 PM, Jean Delvare wrote: Load the i8k driver with fan_mult=1. Would it make sense to change the default multiplier to 1 ? Lots of people have problems with it, and trying to figure out affected machines one by one would be an all but impossible task. That would cause a regression on many (presumably older) machines. I doubt this is acceptable. One option would be to use the ACPI year to change the default, if indeed all new machines need fan_mult=1. I don't know if this is the case. One this I had in mind was auto-detecting the scaling factor. AFAIK only 30 and 1 are possible values, so any value above ~300 would imply scaling factor of 1 (30 would make it > 9000 RPM which is unrealistic.) But I don't know if we can actually do that, as such a simple heuristic could easily fail is the fan is stopped (30 * 0 == 1 * 0) or if the returned raw speed is temporarily unreliable for whatever reason. Sounds like an idea. We could make the cutoff higher, such as 500 or even 1000. I am not much concerned about 0 rpm - the code could simply check the returned rpm and adjust the scaling factor to 1 if the reading is too high. Since 30*0 is still 0, there is no problem if the fan is stopped. I have to admit that working on a reverse engineered driver for hardware I don't even have isn't quite at the top of my to-do list. ;-). We have several of those systems, so there is at least some interest on my side. If I have time, I'll play around with it. The driver does need major cleanup, though, so that may take a while. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4 V2] cpupower: Remove redundant error check
Remove double checks, and move the call to print_error to the
first check. Replace break by return, and return 0 on success.
The simplified version of the coccinelle semantic patch that
fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Untested.
Signed-off-by: Peter Senna Tschudin
---
Changes from V1:
- Replaced break with a return
- Return 0 instead of ret on success
tools/power/cpupower/utils/cpufreq-set.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/power/cpupower/utils/cpufreq-set.c
b/tools/power/cpupower/utils/cpufreq-set.c
index a416de8..f656e58 100644
--- a/tools/power/cpupower/utils/cpufreq-set.c
+++ b/tools/power/cpupower/utils/cpufreq-set.c
@@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
printf(_("Setting cpu: %d\n"), cpu);
ret = do_one_cpu(cpu, _pol, freq, policychange);
- if (ret)
- break;
+ if (ret) {
+ print_error();
+ return ret;
+ }
}
- if (ret)
- print_error();
-
- return ret;
+ return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: imx: fix error handling
Hello Uwe,
On Sat, May 17, 2014 at 09:05:46PM +0200, Uwe Kleine-König wrote:
> Hello Emil,
>
> On Sat, May 17, 2014 at 05:35:40PM +0200, Emil Goode wrote:
> > On Fri, May 16, 2014 at 09:31:39PM +0200, Uwe Kleine-König wrote:
> > > On Fri, May 16, 2014 at 01:49:10PM +0200, walter harms wrote:
> > > > Am 16.05.2014 13:16, schrieb Emil Goode:
> > > > > Hello Walter,
> > > > >
> > > > > On Fri, May 16, 2014 at 12:40:19PM +0200, walter harms wrote:
> > > > >>
> > > > >>
> > > > >> Am 16.05.2014 11:54, schrieb Emil Goode:
> > > > >>> If we fail to allocate struct platform_device pdev we
> > > > >>> dereference it after the goto label err.
> > > > >>>
> > > > >>> I have rearranged the error handling a bit to fix the issue
> > > > >>> and also make it more clear.
> > > > >>>
> > > > >>> Signed-off-by: Emil Goode
> > > > >>> ---
> > > > >>> v2: Changed to return -ENOMEM instead of ret where possible and
> > > > >>> updated the subject line.
> > > > >>>
> > > > >>> arch/arm/mach-imx/devices/platform-ipu-core.c | 22
> > > > >>> +-
> > > > >>> 1 file changed, 13 insertions(+), 9 deletions(-)
> > > > >>>
> > > > >>> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> index fc4dd7c..68f2a4a 100644
> > > > >>> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> @@ -77,34 +77,38 @@ struct platform_device *__init
> > > > >>> imx_alloc_mx3_camera(
> > > > >>>
> > > > >>> pdev = platform_device_alloc("mx3-camera", 0);
> > > > >>> if (!pdev)
> > > > >>> - goto err;
> > > > >>> + return ERR_PTR(-ENOMEM);
> > > > >>>
> > > > >>> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask),
> > > > >>> GFP_KERNEL);
> > > > >>> if (!pdev->dev.dma_mask)
> > > > >>> - goto err;
> > > > >>> + goto put_pdev;
> > > > >>>
> > > > >>> *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> > > > >>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > > > >>>
> > > > >>> ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> > > > >>> if (ret)
> > > > >>> - goto err;
> > > > >>> + goto free_dma_mask;
> > > > >>>
> > > > >>> if (pdata) {
> > > > >>> struct mx3_camera_pdata *copied_pdata;
> > > > >>>
> > > > >>> ret = platform_device_add_data(pdev, pdata,
> > > > >>> sizeof(*pdata));
> > > > >>> - if (ret) {
> > > > >>> -err:
> > > > >>> - kfree(pdev->dev.dma_mask);
> > > > >>> - platform_device_put(pdev);
> > > > >>> - return ERR_PTR(-ENODEV);
> > > > >>> - }
> > > > >>> + if (ret)
> > > > >>> + goto free_dma_mask;
> > > > >>> +
> > > > >>> copied_pdata = dev_get_platdata(>dev);
> > > > >>> copied_pdata->dma_dev = _ipu_coredev->dev;
> > > > >>
> > > > >>
> > > > >> the patch is fine, but what use is this copied_pdata ?
> > > > >> It scope ends next line ?
> > > > >>
> > > > >> re,
> > > > >> wh
> > > > >
> > > > > I also thought that looked a bit odd, but copied_pdata is a temporary
> > > > > pointer to platform_data of the dev struct.
> > > > >
> > > > > dev_get_platdata looks like this:
> > > > >
> > > > > static inline void *dev_get_platdata(const struct device *dev)
> > > > > {
> > > > > return dev->platform_data;
> > > > > }
> > > > >
> > > > > So I believe it's a more compact way of writing:
> > > > >
> > > > > pdev->dev->platform_data->dma_dev = _ipu_coredev->dev;
> > > It's not about compactness. The dev_get_platdata accessor exists to be
> > > used instead of directly accessing dev->platform_data. I admit a comment
> > > would be nice ...
> > >
> > > Anyhow this is all ugly, actually you'd want to have the dma_dev member
> > > already fixed when calling platform_device_add_data. But you cannot
> > > simply do
> > >
> > > pdata->dma_dev = _ipu_coredev->dev;
> > > ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> > >
> > > because *pdata is const.
> >
> > Thank you for the explanation. Regarding the possibility of using
> > platform_device_register_full() to simplify this function. It seem to
> > be possible, the following inline function is available to help with this.
> >
> > imx_add_platform_device_dmamask()
> I'd prefer to use platform_device_register_full directly (and let the
> wrapper die).
Ok, will skip the wrapper.
>
> > But as you mentioned above we need to allocate a new platform_device
> > struct before we can assign _ipu_coredev->dev to dma_dev, since
> > pdata is const. I guess this assignment could be done after calling
> > imx_add_platform_device_dmamask() but I don't think that makes the
> No, that won't work, because after platform_device_register_full returns
> you must assume that the device is already bound by a driver. And then
> you
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
On Sat, May 17, 2014 at 09:18:21PM +0200, Uwe Kleine-König wrote:
> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> index fc4dd7cedc11..6bd7c3f37ac0 100644
> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> @@ -77,7 +77,7 @@ struct platform_device *__init imx_alloc_mx3_camera(
>
> pdev = platform_device_alloc("mx3-camera", 0);
> if (!pdev)
> - goto err;
> + return ERR_PTR(-ENOMEM);
>
> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
> if (!pdev->dev.dma_mask)
Emil, do this one, please and not the second suggestion.
Direct returns are more readable. Otherwise, you wonder what the goto
is for and where it will take you and be annoyed to discover it is a
waste of time, no-op goto. Also you will wonder if platform_device_put()
accepts NULL pointers. Thirdly there is a small ugliness that the error
code is not preserved. What is the point of setting the error code to
-ENOMEM only to discard it?
Let's look at that error handling again.
err: <-- the name is not descriptive. the location is bad.
kfree(pdev->dev.dma_mask); <- null dereference.
platform_device_put(pdev); <- ok
return ERR_PTR(-ENODEV);<- should be "return ERR_PTR(ret);"
3 out of 4 of the lines are bad.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpupower: Remove redundant error check
On Sat, May 17, 2014 at 11:34:46PM +0200, Peter Senna Tschudin wrote:
> On Sat, May 17, 2014 at 10:22 PM, Dan Carpenter
> wrote:
> > On Sat, May 17, 2014 at 08:22:58PM +0200, Peter Senna Tschudin wrote:
> >> diff --git a/tools/power/cpupower/utils/cpufreq-set.c
> >> b/tools/power/cpupower/utils/cpufreq-set.c
> >> index a416de8..4e2f35a 100644
> >> --- a/tools/power/cpupower/utils/cpufreq-set.c
> >> +++ b/tools/power/cpupower/utils/cpufreq-set.c
> >> @@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
> >>
> >> printf(_("Setting cpu: %d\n"), cpu);
> >> ret = do_one_cpu(cpu, _pol, freq, policychange);
> >> - if (ret)
> >> + if (ret) {
> >> + print_error();
> >> break;
> >
> > Just return directly instead of break return;
> >
> >> + }
> >> }
> >>
> >> - if (ret)
> >> - print_error();
> >> -
> >> return ret;
> >
> > Are you sure this patch is correct? Theoretically, it's possible to
> > reach the end of this function without going hitting the
> > "ret = do_one_cpu(...);" assignment.
> >
> > Don't be fooled by the "int ret = 0;" initialization, that is a trick
> > initialization to mislead the unwary. By the end of the do while loop
> > then "ret" is always -1.
> I have missed that, thank you for pointing this out. This patch is
> wrong and should not be applied, please ignore it.
>
> Dan, should I just leave this file as it is?
I think in reality we should always hit the "ret = do_one_cpu()"
assignment. But your static analysis tool should say that we don't know
that, so that's why I brought it up.
My guess is that the original code is bad and we should say:
ret = do_one_cpu(cpu, _pol, freq, policychange);
if (ret) {
print_error();
return ret;
}
}
return 0;
I am currently involved in a number of threads, not just yours, where I
am encouraging people to replace ambiguous returns with "return 0;".
This is my life now.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net/mlx4_en: Fix uninitialized use of 'port_up' in mlx4_en_set_channels()
Function mlx4_en_set_channels() stops running ports before performing the
requested action. In that case local variable 'port_up' is set so that the
port is restarted at the end of the function, however, in case the port was
not stopped, variable 'port_up' is left uninitialized and the behaviour is
undetermined. Detected by Coverity - CID 751497.
Signed-off-by: Christian Engelmayer
---
Compile tested. Applies against branch master in tree
git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
---
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index a72d99f..7ba3df3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -1121,7 +1121,7 @@ static int mlx4_en_set_channels(struct net_device *dev,
{
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
- int port_up;
+ int port_up = 0;
int err = 0;
if (channel->other_count || channel->combined_count ||
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4 V2] IB: Remove redundant error check
Remove double checks, and move calls to pr_err and printk to the
first check. The simplified version of the coccinelle semantic
patch that fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Tested by compilation only.
Signed-off-by: Peter Senna Tschudin
---
Changes from V1:
- Replaced break with a return
- On success return 0 instead of status
drivers/infiniband/hw/ocrdma/ocrdma_hw.c |6 +++---
drivers/infiniband/ulp/srpt/ib_srpt.c|8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 3bbf201..62c2230 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1839,13 +1839,13 @@ int ocrdma_reg_mr(struct ocrdma_dev *dev,
status = ocrdma_mbx_reg_mr_cont(dev, hwmr, cur_pbl_cnt,
pbl_offset, last);
- if (status)
- break;
+ if (status) {
+ pr_err("%s() err. status=%d\n", __func__, status);
+ return status;
+ }
}
- if (status)
- pr_err("%s() err. status=%d\n", __func__, status);
- return status;
+ return 0;
}
bool ocrdma_is_qp_in_sq_flushlist(struct ocrdma_cq *cq, struct ocrdma_qp *qp)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index fe09f27..ab23b07 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2875,13 +2875,13 @@ static int srpt_perform_rdmas(struct srpt_rdma_ch *ch,
wr.send_flags = IB_SEND_SIGNALED;
ret = ib_post_send(ch->qp, , _wr);
- if (ret)
+ if (ret) {
+ printk(KERN_ERR "%s[%d]: ib_post_send() returned %d for
%d/%d",
+ __func__, __LINE__, ret, i, n_rdma);
break;
+ }
}
- if (ret)
- printk(KERN_ERR "%s[%d]: ib_post_send() returned %d for %d/%d",
-__func__, __LINE__, ret, i, n_rdma);
if (ret && i > 0) {
wr.num_sge = 0;
wr.wr_id = encode_wr_id(SRPT_RDMA_ABORT, ioctx->ioctx.index);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpupower: Remove redundant error check
On Sat, May 17, 2014 at 10:22 PM, Dan Carpenter
wrote:
> On Sat, May 17, 2014 at 08:22:58PM +0200, Peter Senna Tschudin wrote:
>> diff --git a/tools/power/cpupower/utils/cpufreq-set.c
>> b/tools/power/cpupower/utils/cpufreq-set.c
>> index a416de8..4e2f35a 100644
>> --- a/tools/power/cpupower/utils/cpufreq-set.c
>> +++ b/tools/power/cpupower/utils/cpufreq-set.c
>> @@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
>>
>> printf(_("Setting cpu: %d\n"), cpu);
>> ret = do_one_cpu(cpu, _pol, freq, policychange);
>> - if (ret)
>> + if (ret) {
>> + print_error();
>> break;
>
> Just return directly instead of break return;
>
>> + }
>> }
>>
>> - if (ret)
>> - print_error();
>> -
>> return ret;
>
> Are you sure this patch is correct? Theoretically, it's possible to
> reach the end of this function without going hitting the
> "ret = do_one_cpu(...);" assignment.
>
> Don't be fooled by the "int ret = 0;" initialization, that is a trick
> initialization to mislead the unwary. By the end of the do while loop
> then "ret" is always -1.
I have missed that, thank you for pointing this out. This patch is
wrong and should not be applied, please ignore it.
Dan, should I just leave this file as it is?
>
> regards,
> dan carpenter
>
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: Add keycodes for some missing Fn key combinations
On Sat, May 17, 2014 at 10:38:30PM +0200, Pali Rohár wrote:
> On Saturday 17 May 2014 22:30:54 Dmitry Torokhov wrote:
> > Hi Pali,
> >
> > On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> > > There are already defined some Fn key combinations, but not
> > > all. This patch adds missing combinations for support in
> > > dell-wmi driver.
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > >
> > > include/uapi/linux/input.h |6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/input.h
> > > b/include/uapi/linux/input.h index f484952..3a32799 100644
> > > --- a/include/uapi/linux/input.h
> > > +++ b/include/uapi/linux/input.h
> > > @@ -672,6 +672,12 @@ struct input_keymap_entry {
> > >
> > > #define KEY_FN_F 0x1e2
> > > #define KEY_FN_S 0x1e3
> > > #define KEY_FN_B 0x1e4
> > >
> > > +#define KEY_FN_Q 0x1e5
> > > +#define KEY_FN_W 0x1e6
> > > +#define KEY_FN_R 0x1e7
> > > +#define KEY_FN_T 0x1e8
> > > +#define KEY_FN_A 0x1e9
> > > +#define KEY_FN_G 0x1ea
> >
> > What do they actually do?
> >
> > Thanks.
>
> All 10 combinations Fn+Q ... Fn+T, Fn+A ... Fn+G are reported by
> WMI and I need to assign some keycodes for them in dell-wmi
> driver.
If they do not have a well-defined meaning then KEY_UNKNOWN is
appropriate and user later can redefine via EVIOCSKEYCODE to the code
they wish.
> And because More FN_* constants are already defined in
> input.h I added those which are missing.
I am not sure if adding existing generic KEY_FN_* was a good idea.
>
> With this patch series I'm able to use above Fn combinations for
> my own keyboard shortcuts. Before this patch all Fn combinations
> were one same keycode - which was useless.
Are there not enough key definitions already to accommodate actions you
want? dell-wmi supports changing keymap from usersopace so you should be
able to remap entries you want to the actions you need.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: Cleanup string initializations (char[] instead of char *)
On Sat, May 17, 2014 at 04:37:25PM +0200, Manuel Schölling wrote:
[...]
> diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
> index 6545809..43eeb1b 100644
> --- a/drivers/pinctrl/pinctrl-tegra.c
> +++ b/drivers/pinctrl/pinctrl-tegra.c
> @@ -576,7 +576,7 @@ static void tegra_pinconf_config_dbg_show(struct
> pinctrl_dev *pctldev,
> {
> enum tegra_pinconf_param param = TEGRA_PINCONF_UNPACK_PARAM(config);
> u16 arg = TEGRA_PINCONF_UNPACK_ARG(config);
> - const char *pname = "unknown";
> + const char pname[] = "unknown";
> int i;
>
> for (i = 0; i < ARRAY_SIZE(cfg_params); i++) {
When this hunk is applied, the build fails as follows:
CC drivers/pinctrl/pinctrl-tegra.o
drivers/pinctrl/pinctrl-tegra.c: In function 'tegra_pinconf_config_dbg_show':
drivers/pinctrl/pinctrl-tegra.c:589:4: warning: assignment of read-only
location 'pname' [enabled by default]
pname = cfg_params[i].property;
^
drivers/pinctrl/pinctrl-tegra.c:589:10: error: incompatible types when
assigning to type 'const char[8]' from type 'const char * const'
pname = cfg_params[i].property;
^
As you can see, pname is used to store a property name and the default
value is set to the static string "unknown" for cases where no matching
parameter is found in cfg_params. However, if a match is found the
default value will be overwritten, so you can't use const char [].
Thierry
pgppB5PygRrF5.pgp
Description: PGP signature
Re: [PATCH 3/4] staging: dgnc: dgnc_neo: Fix conditional part of if statement
On Sat, May 17, 2014 at 10:14:52PM +0100, Masaru Nomura wrote: > > Also just fold this patch and [patch 2/4] together into one patch. We > > don't need two patches to fix one if statement. > > > > The one thing per patch rule is a bit tricky. It means that you have to > > say which one thing you are fixing. Don't say "I am fixing three > > things." Say "I am fixing one if statement". > > So in this case, do you think I could fold all four patches into one? No. That would be more than one thing per patch. It looks like this: [patch 1/3] staging: dgnc: dgnc_neo: put else statements on the right line [patch 2/3] staging: dgnc: dgnc_neo: clean up ugly one very ugly condition [patch 3/3] staging: dgnc: dgnc_neo: remove extra curly braces Each patch does one thing. Cleaning up the whole file is too big so it doesn't count as doing one thing only. > As I just worked on the 'same' if statements and divided them into > four patches, this could be the case. (but I'm not sure yet...) > > Also, should I put v[number] for the modified patches? > Say [PATCH v2] staging: ... Yes. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] staging: dgnc: dgnc_neo: Fix conditional part of if statement
Hi Dan,
Thank you for your detailed explanation!
> This isn't the right way. Write it like this:
>
> if ((ch->ch_digi.digi_flags & CTSPACE) ||
> (ch->ch_digi.digi_flags & RTSPACE) ||
> (ch->ch_c_cflag & CRTSCTS) ||
> !(ch->ch_digi.digi_flags & DIGI_FORCEDCD) ||
> !(ch->ch_c_cflag & CLOCAL)) {
> ier |= UART_IER_MSI;
> else
> ier &= ~UART_IER_MSI;
>
> 1) The "||" operation goes at the end of the line.
> 2) The conditions are all in a line. The indenting is
>
> [tab][space][space][space][space](ch->ch_digi.digi_f...
Sure, I'll modify this.
> Also just fold this patch and [patch 2/4] together into one patch. We
> don't need two patches to fix one if statement.
>
> The one thing per patch rule is a bit tricky. It means that you have to
> say which one thing you are fixing. Don't say "I am fixing three
> things." Say "I am fixing one if statement".
So in this case, do you think I could fold all four patches into one?
As I just worked on the 'same' if statements and divided them into
four patches, this could be the case. (but I'm not sure yet...)
Also, should I put v[number] for the modified patches?
Say [PATCH v2] staging: ...
Thank you,
Masaru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4 V2] VMCI: Remove redundant error check and code cleanup
Remove double checks, and move the call to pr_devel. Remove the
initialization of the result variable, and return VMCI_SUCCESS on
success. Fix the condition of the for loop. Replace break with a
return. The simplified version of the coccinelle semantic patch
that find the redundant check issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Tested by compilation only.
Signed-off-by: Peter Senna Tschudin
---
Changes from V1:
- Removed initialization of result
- Return VMCI_SUCCESS instead of result on success
- Fixed the for loop condition
- Replaced break with a return
drivers/misc/vmw_vmci/vmci_context.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
index f866a4b..78c1165 100644
--- a/drivers/misc/vmw_vmci/vmci_context.c
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -816,7 +816,7 @@ int vmci_ctx_set_chkpt_state(u32 context_id,
{
u32 i;
u32 current_id;
- int result = VMCI_SUCCESS;
+ int result;
u32 num_ids = buf_size / sizeof(u32);
if (cpt_type == VMCI_WELLKNOWN_CPT_STATE && num_ids > 0) {
@@ -833,17 +833,17 @@ int vmci_ctx_set_chkpt_state(u32 context_id,
return VMCI_ERROR_INVALID_ARGS;
}
- for (i = 0; i < num_ids && result == VMCI_SUCCESS; i++) {
+ for (i = 0; i < num_ids; i++) {
current_id = ((u32 *)cpt_buf)[i];
result = vmci_ctx_add_notification(context_id, current_id);
- if (result != VMCI_SUCCESS)
- break;
+ if (result != VMCI_SUCCESS) {
+ pr_devel("Failed to set cpt state (type=%d)
(error=%d)\n",
+cpt_type, result);
+ return result;
+ }
}
- if (result != VMCI_SUCCESS)
- pr_devel("Failed to set cpt state (type=%d) (error=%d)\n",
-cpt_type, result);
- return result;
+ return VMCI_SUCCESS;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kref: warn on uninitialized kref
On Sat, 17 May 2014, Bart Van Assche wrote:
> On 05/17/14 14:38, Mikulas Patocka wrote:
> > I found a memory leak in iSCSI target that was caused by kref initialized
> > to zero (the memory object was allocated with kzalloc, kref_init was not
> > called and kref_put_spinlock_irqsave was called which changed "0" to "-1"
> > and didn't free the object).
> >
> > Similar bugs may exist in other kernel areas, so I submit this patch that
> > adds a check to kref.h. If the value is zero or negative, we can assume
> > that it is uninitialized and we warn about it.
> >
> > Signed-off-by: Mikulas Patocka
> >
> > ---
> > include/linux/kref.h |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > Index: linux-3.15-rc5/include/linux/kref.h
> > ===
> > --- linux-3.15-rc5.orig/include/linux/kref.h2014-05-16
> > 19:00:18.0 +0200
> > +++ linux-3.15-rc5/include/linux/kref.h 2014-05-17 13:19:31.0
> > +0200
> > @@ -69,7 +69,7 @@ static inline int kref_sub(struct kref *
> > void (*release)(struct kref *kref))
> > {
> > WARN_ON(release == NULL);
> > -
> > + WARN_ON_ONCE(atomic_read(>refcount) < (int)count);
> > if (atomic_sub_and_test((int) count, >refcount)) {
> > release(kref);
> > return 1;
> > @@ -119,6 +119,7 @@ static inline int kref_put_spinlock_irqs
> > unsigned long flags;
> >
> > WARN_ON(release == NULL);
> > + WARN_ON_ONCE(atomic_read(>refcount) <= 0);
> > if (atomic_add_unless(>refcount, -1, 1))
> > return 0;
> > spin_lock_irqsave(lock, flags);
> > @@ -136,6 +137,7 @@ static inline int kref_put_mutex(struct
> > struct mutex *lock)
> > {
> > WARN_ON(release == NULL);
> > + WARN_ON_ONCE(atomic_read(>refcount) <= 0);
> > if (unlikely(!atomic_add_unless(>refcount, -1, 1))) {
> > mutex_lock(lock);
> > if (unlikely(!atomic_dec_and_test(>refcount))) {
>
> This patch adds two conditional branches and one atomic read to
> kref_sub(). What is the performance impact of this patch on kernel code
> that uses kref_put() in the hot path ? Has it been considered to enable
> the newly added code only if a CONFIG_DEBUG_* macro has been set ?
>
> Bart.
The atomic modification takes several tens of ticks, the atomic read and
compare is just one tick. I don't exepct any performance problem with
this.
BTW. if we talk about performance - what about replacing:
if (atomic_dec_and_test()) {
... release(object);
}
with this:
if (atomic_read() == 1 || atomic_dec_and_test()) {
barrier();
... release(object);
}
It avoids the heavy atomic instruction if there is just one reference. Is
there any problem with this? At least on x86 we could do this always
(there is no read reordering in hardware, so barrier() is sufficient to
prevent reads from being reordered with atomic_read). On the architectures
that reorder reads, we could do it only if the release method doesn't
contain any reads of the object being released.
Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Dell Latitude E6440 & i8k
On Sat, 17 May 2014 08:25:38 -0700, Guenter Roeck wrote: > On 05/16/2014 12:11 PM, Jean Delvare wrote: > > Load the i8k driver with fan_mult=1. > > Would it make sense to change the default multiplier to 1 ? > Lots of people have problems with it, and trying to figure out > affected machines one by one would be an all but impossible task. That would cause a regression on many (presumably older) machines. I doubt this is acceptable. One option would be to use the ACPI year to change the default, if indeed all new machines need fan_mult=1. I don't know if this is the case. One this I had in mind was auto-detecting the scaling factor. AFAIK only 30 and 1 are possible values, so any value above ~300 would imply scaling factor of 1 (30 would make it > 9000 RPM which is unrealistic.) But I don't know if we can actually do that, as such a simple heuristic could easily fail is the fan is stopped (30 * 0 == 1 * 0) or if the returned raw speed is temporarily unreliable for whatever reason. I have to admit that working on a reverse engineered driver for hardware I don't even have isn't quite at the top of my to-do list. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: tegra: Fix wrong value written to PLLE_AUX
On Fri, May 16, 2014 at 10:05:18AM -0600, Stephen Warren wrote: > On 05/16/2014 08:31 AM, Thierry Reding wrote: > > On Fri, May 16, 2014 at 04:50:20PM +0300, Tuomas Tynkkynen wrote: > >> The value written to PLLE_AUX was incorrect due to a wrong variable > >> being used. > >> > >> Signed-off-by: Tuomas Tynkkynen > >> Tested-by: Mikko Perttunen > >> --- > >> This fix is required for the (upcoming) SATA support. > >> drivers/clk/tegra/clk-pll.c |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Thierry Reding > > Tested-by: Thierry Reding > > Acked-by: Thierry Reding > > > > Mike, Peter, it might be good to have this go into 3.16 as a > > prerequisite for the upcoming SATA driver (which presumably won't be > > ready until 3.17, but in that case it would be good to have this > > prerequisite merged already). > > Probably even Cc: stable since it's a fix for a bug that I assume has > been in a kernel release or two? Yeah, I guess that makes sense. The bug isn't visible yet, but back- porting to stable might save somebody else from chasing this if they ever decide to backport PCIe, SATA or XUSB. Thierry pgpOAlTYoSyn5.pgp Description: PGP signature
[GIT pull] timer fixes for 3.15
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
A single bug fix for a long standing issue:
* Updating the expiry value of a relative timer _after_ letting the
idle logic select a target cpu for the timer based on its stale
expiry value is outright stupid. Thanks to Viresh for spotting the
brainfart.
Thanks,
tglx
-->
Viresh Kumar (1):
hrtimer: Set expiry time before switch_hrtimer_base()
kernel/hrtimer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 6b715c0..e0501fe 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -990,11 +990,8 @@ int __hrtimer_start_range_ns(struct hrtimer *timer,
ktime_t tim,
/* Remove an active timer from the queue: */
ret = remove_hrtimer(timer, base);
- /* Switch the timer base, if necessary: */
- new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
-
if (mode & HRTIMER_MODE_REL) {
- tim = ktime_add_safe(tim, new_base->get_time());
+ tim = ktime_add_safe(tim, base->get_time());
/*
* CONFIG_TIME_LOW_RES is a temporary way for architectures
* to signal that they simply return xtime in
@@ -1009,6 +1006,9 @@ int __hrtimer_start_range_ns(struct hrtimer *timer,
ktime_t tim,
hrtimer_set_expires_range_ns(timer, tim, delta_ns);
+ /* Switch the timer base, if necessary: */
+ new_base = switch_hrtimer_base(timer, base, mode & HRTIMER_MODE_PINNED);
+
timer_stats_hrtimer_set_start_info(timer);
leftmost = enqueue_hrtimer(timer, new_base);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 for-next 0/3] IB: Use GFP_NOIO calls in IPoIB connected mode TX path
On Tue, May 13, 2014 at 2:38 PM, Jiri Kosina wrote: > On Sun, 11 May 2014, Or Gerlitz wrote: >> This series is a refactored form of the one posted by Jiri Kosina >> to LKML and netdev according to the discussion that followed >> and the guidelines you provided here https://lkml.org/lkml/2014/3/5/250 >> Basically, the functionality changes introduced by this series fully >> reside on the IB side of things, so I am only posting the actual patches >> to linux-rdma with CC on the cover-letter to the lists that were on V0. > Thanks, I am fine with my Signoff on that. > Roland, is this going to be merged by you, or should this go to DaveM > directly? Roland, we're soon on -rc6 and there's no reason for this to miss 3.16, could you please comment whether you want it to go through your tree or net-next? > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT pll] irq updates for 3.15
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
Two small updates from the irq departement:
* Provide missing inline stub for a SMP only function
* Add sub-maintainer for the drivers/irqchip/ part of the irq
subsystem. YAY!
Thanks,
tglx
-->
Arnd Bergmann (1):
genirq: Provide irq_force_affinity fallback for non-SMP
Jason Cooper (1):
MAINTAINERS: Add co-maintainer for drivers/irqchip
MAINTAINERS |8
include/linux/interrupt.h |5 +
2 files changed, 13 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6bef70b..4195801 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4818,6 +4818,14 @@ L: linux-kernel@vger.kernel.org
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
F: kernel/irq/
+
+IRQCHIP DRIVERS
+M: Thomas Gleixner
+M: Jason Cooper
+L: linux-kernel@vger.kernel.org
+S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
+T: git git://git.infradead.org/users/jcooper/linux.git irqchip/core
F: drivers/irqchip/
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 97ac926..051c850 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -272,6 +272,11 @@ static inline int irq_set_affinity(unsigned int irq, const
struct cpumask *m)
return -EINVAL;
}
+static inline int irq_force_affinity(unsigned int irq, const struct cpumask
*cpumask)
+{
+ return 0;
+}
+
static inline int irq_can_set_affinity(unsigned int irq)
{
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] devicetree: Add generic IOMMU device tree bindings
On Sat, May 17, 2014 at 05:04:55PM +0900, Cho KyongHo wrote:
> On Fri, 16 May 2014 14:23:18 +0200, Thierry Reding wrote:
[...]
> > +Examples:
> > +=
> > +
> > +Single-master IOMMU:
> > +
> > +
> > + iommu {
> > + #iommu-cells = <0>;
> > + };
> > +
> > + master {
> > + iommu = <&/iommu>;
> > + };
> > +
>
> Great work, Thierry.
>
> One simple comment.
>
> This should be also applicable to multi-master IOMMUs that the masters
> of an IOMMU is not configurable with ID or something.
> I think the title needs to be changed to cover such IOMMUs which always
> translate master's transactions and unable to change the configuration
> of the relationship between the masters and IOMMUs by S/W.
Agreed, how about we add a separate example for that case:
Multiple-master IOMMU with fixed associations:
--
/* multiple-master IOMMU */
iommu {
/*
* Masters are statically associated with this IOMMU and
* address translation is always enabled.
*/
#iommu-cells = <0>;
};
/* static association with IOMMU */
master@1 {
reg = <1>;
iommus = <&/iommu>;
};
/* static association with IOMMU */
master@2 {
reg = <2>;
iommus = <&/iommu>;
};
?
Thierry
pgp2jaWjahMrj.pgp
Description: PGP signature
Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
On Saturday 17 May 2014 22:30:54 Dmitry Torokhov wrote:
> Hi Pali,
>
> On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> > There are already defined some Fn key combinations, but not
> > all. This patch adds missing combinations for support in
> > dell-wmi driver.
> >
> > Signed-off-by: Pali Rohár
> > ---
> >
> > include/uapi/linux/input.h |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/include/uapi/linux/input.h
> > b/include/uapi/linux/input.h index f484952..3a32799 100644
> > --- a/include/uapi/linux/input.h
> > +++ b/include/uapi/linux/input.h
> > @@ -672,6 +672,12 @@ struct input_keymap_entry {
> >
> > #define KEY_FN_F 0x1e2
> > #define KEY_FN_S 0x1e3
> > #define KEY_FN_B 0x1e4
> >
> > +#define KEY_FN_Q 0x1e5
> > +#define KEY_FN_W 0x1e6
> > +#define KEY_FN_R 0x1e7
> > +#define KEY_FN_T 0x1e8
> > +#define KEY_FN_A 0x1e9
> > +#define KEY_FN_G 0x1ea
>
> What do they actually do?
>
> Thanks.
All 10 combinations Fn+Q ... Fn+T, Fn+A ... Fn+G are reported by
WMI and I need to assign some keycodes for them in dell-wmi
driver. And because More FN_* constants are already defined in
input.h I added those which are missing.
With this patch series I'm able to use above Fn combinations for
my own keyboard shortcuts. Before this patch all Fn combinations
were one same keycode - which was useless.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[PATCH] staging: unisys: visorutil: Add a blank line
Add a blank line after declarations to meet kernel coding style.
Signed-off-by: Masaru Nomura
---
drivers/staging/unisys/visorutil/charqueue.c |2 ++
drivers/staging/unisys/visorutil/easyproc.c |6 ++
drivers/staging/unisys/visorutil/periodic_work.c |1 +
drivers/staging/unisys/visorutil/procobjecttree.c |6 ++
4 files changed, 15 insertions(+)
diff --git a/drivers/staging/unisys/visorutil/charqueue.c
b/drivers/staging/unisys/visorutil/charqueue.c
index 61600e1..22241c7 100644
--- a/drivers/staging/unisys/visorutil/charqueue.c
+++ b/drivers/staging/unisys/visorutil/charqueue.c
@@ -41,6 +41,7 @@ CHARQUEUE *visor_charqueue_create(ulong nslots)
{
int alloc_size = sizeof(CHARQUEUE) + nslots + 1;
CHARQUEUE *cq = kmalloc(alloc_size, GFP_KERNEL|__GFP_NORETRY);
+
if (cq == NULL) {
ERRDRV("visor_charqueue_create allocation failed
(alloc_size=%d)",
alloc_size);
@@ -75,6 +76,7 @@ EXPORT_SYMBOL_GPL(visor_charqueue_enqueue);
BOOL visor_charqueue_is_empty(CHARQUEUE *charqueue)
{
BOOL b;
+
spin_lock(>lock);
b = IS_EMPTY(charqueue);
spin_unlock(>lock);
diff --git a/drivers/staging/unisys/visorutil/easyproc.c
b/drivers/staging/unisys/visorutil/easyproc.c
index 43df598..3b38849 100644
--- a/drivers/staging/unisys/visorutil/easyproc.c
+++ b/drivers/staging/unisys/visorutil/easyproc.c
@@ -61,6 +61,7 @@ static struct proc_dir_entry *
createProcDir(char *name, struct proc_dir_entry *parent)
{
struct proc_dir_entry *p = proc_mkdir_mode(name, S_IFDIR, parent);
+
if (p == NULL)
ERRDRV("failed to create /proc directory %s", name);
return p;
@@ -196,6 +197,7 @@ void visor_easyproc_InitDevice(struct easyproc_driver_info
*pdriver,
{
if ((pdriver->ProcDeviceDir != NULL) && (p->procDevicexDir == NULL)) {
char s[29];
+
sprintf(s, "%d", devno);
p->procDevicexDir = createProcDir(s, pdriver->ProcDeviceDir);
p->devno = devno;
@@ -267,6 +269,7 @@ void visor_easyproc_DeInitDevice(struct
easyproc_driver_info *pdriver,
struct easyproc_device_info *p, int devno)
{
size_t i;
+
for (i = 0; i < ARRAY_SIZE(p->device_property_info); i++) {
if (p->device_property_info[i].procEntry != NULL) {
struct easyproc_device_property_info *px =
@@ -281,6 +284,7 @@ void visor_easyproc_DeInitDevice(struct
easyproc_driver_info *pdriver,
}
if (p->procDevicexDir != NULL) {
char s[29];
+
sprintf(s, "%d", devno);
remove_proc_entry(s, pdriver->ProcDeviceDir);
p->procDevicexDir = NULL;
@@ -334,6 +338,7 @@ static ssize_t proc_write_driver(struct file *file, const
char __user *buffer,
struct seq_file *seq = (struct seq_file *)file->private_data;
struct easyproc_driver_info *p = NULL;
char local_buf[256];
+
if (seq == NULL)
return 0;
p = (struct easyproc_driver_info *)(seq->private);
@@ -356,6 +361,7 @@ static ssize_t proc_write_device(struct file *file, const
char __user *buffer,
struct seq_file *seq = (struct seq_file *)file->private_data;
struct easyproc_device_info *p = NULL;
char local_buf[256];
+
if (seq == NULL)
return 0;
p = (struct easyproc_device_info *)(seq->private);
diff --git a/drivers/staging/unisys/visorutil/periodic_work.c
b/drivers/staging/unisys/visorutil/periodic_work.c
index 0251b83..38a60ce 100644
--- a/drivers/staging/unisys/visorutil/periodic_work.c
+++ b/drivers/staging/unisys/visorutil/periodic_work.c
@@ -92,6 +92,7 @@ EXPORT_SYMBOL_GPL(visor_periodic_work_destroy);
BOOL visor_periodic_work_nextperiod(PERIODIC_WORK *periodic_work)
{
BOOL rc = FALSE;
+
write_lock(_work->lock);
if (periodic_work->want_to_stop) {
periodic_work->is_scheduled = FALSE;
diff --git a/drivers/staging/unisys/visorutil/procobjecttree.c
b/drivers/staging/unisys/visorutil/procobjecttree.c
index 2f874e0..5c8c95c 100644
--- a/drivers/staging/unisys/visorutil/procobjecttree.c
+++ b/drivers/staging/unisys/visorutil/procobjecttree.c
@@ -95,6 +95,7 @@ static struct proc_dir_entry *
createProcDir(const char *name, struct proc_dir_entry *parent)
{
struct proc_dir_entry *p = proc_mkdir_mode(name, S_IFDIR, parent);
+
if (p == NULL)
ERRDRV("failed to create /proc directory %s", name);
return p;
@@ -197,9 +198,11 @@ void visor_proc_DestroyType(MYPROCTYPE *type)
return;
if (type->procDirs != NULL) {
int i = type->nNames-1;
+
while (i >= 0) {
if (type->procDirs[i] != NULL) {
struct proc_dir_entry *parent = NULL;
+
if (i == 0)
Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
Hi Pali,
On Sat, May 17, 2014 at 04:43:36PM +0200, Pali Rohár wrote:
> There are already defined some Fn key combinations, but not all.
> This patch adds missing combinations for support in dell-wmi driver.
>
> Signed-off-by: Pali Rohár
> ---
> include/uapi/linux/input.h |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index f484952..3a32799 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -672,6 +672,12 @@ struct input_keymap_entry {
> #define KEY_FN_F 0x1e2
> #define KEY_FN_S 0x1e3
> #define KEY_FN_B 0x1e4
> +#define KEY_FN_Q 0x1e5
> +#define KEY_FN_W 0x1e6
> +#define KEY_FN_R 0x1e7
> +#define KEY_FN_T 0x1e8
> +#define KEY_FN_A 0x1e9
> +#define KEY_FN_G 0x1ea
What do they actually do?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] IB: Remove redundant error check
On Sat, May 17, 2014 at 08:23:00PM +0200, Peter Senna Tschudin wrote:
> ---
> drivers/infiniband/hw/ocrdma/ocrdma_hw.c |6 +++---
> drivers/infiniband/ulp/srpt/ib_srpt.c|8
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> index 3bbf201..f085a51 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> @@ -1839,11 +1839,11 @@ int ocrdma_reg_mr(struct ocrdma_dev *dev,
>
> status = ocrdma_mbx_reg_mr_cont(dev, hwmr, cur_pbl_cnt,
> pbl_offset, last);
> - if (status)
> + if (status) {
> + pr_err("%s() err. status=%d\n", __func__, status);
> break;
return status;
> + }
> }
> - if (status)
> - pr_err("%s() err. status=%d\n", __func__, status);
>
> return status;
return 0;
> }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpupower: Remove redundant error check
On Sat, May 17, 2014 at 08:22:58PM +0200, Peter Senna Tschudin wrote:
> diff --git a/tools/power/cpupower/utils/cpufreq-set.c
> b/tools/power/cpupower/utils/cpufreq-set.c
> index a416de8..4e2f35a 100644
> --- a/tools/power/cpupower/utils/cpufreq-set.c
> +++ b/tools/power/cpupower/utils/cpufreq-set.c
> @@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
>
> printf(_("Setting cpu: %d\n"), cpu);
> ret = do_one_cpu(cpu, _pol, freq, policychange);
> - if (ret)
> + if (ret) {
> + print_error();
> break;
Just return directly instead of break return;
> + }
> }
>
> - if (ret)
> - print_error();
> -
> return ret;
Are you sure this patch is correct? Theoretically, it's possible to
reach the end of this function without going hitting the
"ret = do_one_cpu(...);" assignment.
Don't be fooled by the "int ret = 0;" initialization, that is a trick
initialization to mislead the unwary. By the end of the do while loop
then "ret" is always -1.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.15-rc5 freeze after wakeup
Hi, I've upgraded kernel on my PC to 3.15-rc5 and I got today freeze (recovery possibly only by power off/on) when waking from suspend. There is only warning in log but system was completely dead (no keys reaction ). May 14 15:53:15 nb kernel: [30404.485085] PM: Syncing filesystems ... done. May 14 15:53:15 nb kernel: [30404.711342] PM: Preparing system for mem sleep May 14 15:53:15 nb kernel: [30404.711610] Freezing user space processes ... (elapsed 0.001 seconds) done. May 14 15:53:15 nb kernel: [30404.713305] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. May 14 15:53:15 nb kernel: [30404.714431] PM: Entering mem sleep May 14 15:53:15 nb kernel: [30404.714881] Suspending console(s) (use no_console_suspend to debug) May 14 15:53:15 nb kernel: [30405.338766] sd 4:0:0:0: [sda] Synchronizing SCSI cache May 14 15:53:15 nb kernel: [30405.338893] sd 4:0:0:0: [sda] Stopping disk May 14 15:53:15 nb kernel: [30405.361653] nouveau [ DRM] evicting buffers... May 14 15:53:15 nb kernel: [30405.361654] nouveau [ DRM] waiting for kernel channels to go idle... May 14 15:53:15 nb kernel: [30405.361679] nouveau [ DRM] suspending client object trees... May 14 15:53:15 nb kernel: [30405.365746] [ cut here ] May 14 15:53:15 nb kernel: [30405.365765] WARNING: CPU: 1 PID: 21060 at drivers/gpu/drm/i915/intel_uncore.c:125 gen6_gt_check_fifodbg.isra.9+0x38/0x50 [i915]() May 14 15:53:15 nb kernel: [30405.365765] MMIO read or write has been dropped May 14 15:53:15 nb kernel: [30405.365782] Modules linked in: cdc_acm(F) mmc_block(F) pl2303(F) usbserial(F) usblp(F) usb_storage(F) ctr(F) ccm(F) rfcomm(F) bnep(F) snd_hda_codec_hdmi(F) x86_pkg_temp_thermal(F) intel_powerclamp(F) coretemp(F) kvm(F) uvcvideo(F) arc4(F) videobuf2_vmalloc(F) videobuf2_memops(F) videobuf2_core(F) crct10dif_pclmul(F) crc32_pclmul(F) ghash_clmulni_intel(F) nfsd(F) aesni_intel(F) iwlmvm(F) videodev(F) i915(F) aes_x86_64(F) lrw(F) gf128mul(F) glue_helper(F) mac80211(F) auth_rpcgss(F) nfs_acl(F) ablk_helper(F) cryptd(F) nouveau(F) snd_hda_codec_realtek(F) snd_hda_intel(F) joydev(F) snd_hda_codec(F) ttm(F) drm_kms_helper(F) snd_hwdep(F) snd_pcm(F) snd_page_alloc(F) snd_seq_midi(F) asus_nb_wmi(F) iwlwifi(F) drm(F) snd_seq_midi_event(F) nfs(F) snd_rawmidi(F) snd_seq(F) asus_wmi(F) sparse_keymap(F) mxm_wmi(F) snd_seq_device(F) btusb(F) i2c_algo_bit(F) mei_me(F) snd_timer(F) bluetooth(F) snd(F) cfg80211(F) lockd(F) sunrpc(F) mei(F) soundcore(F) microcode(F) rtsx_pci_ms(F) memstick(F) binfmt_misc(F) lpc_ich(F) fscache(F) psmouse(F) video(F) wmi(F) mac_hid(F) serio_raw(F) nls_iso8859_1(F) parport_pc(F) ppdev(F) lp(F) parport(F) rtsx_pci_sdmmc(F) ahci(F) r8169(F) libahci(F) rtsx_pci(F) mii(F) May 14 15:53:15 nb kernel: [30405.365795] CPU: 1 PID: 21060 Comm: kworker/u16:16 Tainted: GF W3.13.2 #5 May 14 15:53:15 nb kernel: [30405.365796] Hardware name: ASUSTeK COMPUTER INC. N56JR/N56JR, BIOS N56JR.204 10/31/2013 May 14 15:53:15 nb kernel: [30405.365804] Workqueue: i915 gen6_force_wake_work [i915] May 14 15:53:15 nb kernel: [30405.365806] 0009 88032964bd38 81715b4e 88032964bd80 May 14 15:53:15 nb kernel: [30405.365807] 88032964bd70 8106420d 8800363c8020 8800363c8028 May 14 15:53:15 nb kernel: [30405.365809] 0246 0200 88032964bdd0 May 14 15:53:15 nb kernel: [30405.365809] Call Trace: May 14 15:53:15 nb kernel: [30405.365813] [] dump_stack+0x45/0x56 May 14 15:53:15 nb kernel: [30405.365815] [] warn_slowpath_common+0x7d/0xa0 May 14 15:53:15 nb kernel: [30405.365817] [] warn_slowpath_fmt+0x4c/0x50 May 14 15:53:15 nb kernel: [30405.365820] [] ? __switch_to+0x126/0x4c0 May 14 15:53:15 nb kernel: [30405.365827] [] gen6_gt_check_fifodbg.isra.9+0x38/0x50 [i915] May 14 15:53:15 nb kernel: [30405.365834] [] __gen6_gt_force_wake_mt_put+0x2b/0x30 [i915] May 14 15:53:15 nb kernel: [30405.365840] [] gen6_force_wake_work+0x37/0x50 [i915] May 14 15:53:15 nb kernel: [30405.365842] [] process_one_work+0x182/0x450 May 14 15:53:15 nb kernel: [30405.365843] [] worker_thread+0x121/0x410 May 14 15:53:15 nb kernel: [30405.365845] [] ? rescuer_thread+0x3e0/0x3e0 May 14 15:53:15 nb kernel: [30405.365846] [] kthread+0xd2/0xf0 May 14 15:53:15 nb kernel: [30405.365847] [] ? kthread_create_on_node+0x190/0x190 May 14 15:53:15 nb kernel: [30405.365849] [] ret_from_fork+0x7c/0xb0 May 14 15:53:15 nb kernel: [30405.365850] [] ? kthread_create_on_node+0x190/0x190 May 14 15:53:15 nb kernel: [30405.365851] ---[ end trace 19ed8523f865bf12 ]--- May 14 15:53:15 nb kernel: [30405.370091] nouveau [ DRM] suspending kernel object tree... May 14 15:53:15 nb kernel: [30405.666015] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c7204 May 14 15:53:15 nb kernel: [30405.666018] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to c7204 May 14 15:53:15 nb kernel: [30406.422806] PM:
Re: [PATCH] drivers: net: ethernet: mellanox: mlx4: let mlx4 depend on SMP
On Sat, May 17, 2014 at 8:36 AM, David Miller wrote: > > From: Chen Gang > Date: Sat, 17 May 2014 13:26:16 +0800 > > > 'struct irq_affinity_notify' and the related functions are only defined > > when SMP enabled, so at present, mlx4 has to only run under SMP. > > > > The related error (allmodconfig under unicore32): > > Making the entire driver depend upon SMP is not the answer, Indeed, we would do that just for the relevant portion, > > other Mellanox developers said that a proper fix is pending > so please be patient. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] VMCI: Remove redundant error check
I like this. There is way too much code where it sets a variable and
then checks it again a couple lines down instead of just handling it
immediately so that every line is clear without having to keep track
so many variables.
But the automated patch doesn't really go far enough in cleaning up this
function.
On Sat, May 17, 2014 at 08:22:57PM +0200, Peter Senna Tschudin wrote:
> drivers/misc/vmw_vmci/vmci_context.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/vmw_vmci/vmci_context.c
> b/drivers/misc/vmw_vmci/vmci_context.c
> index f866a4b..3995e64 100644
> --- a/drivers/misc/vmw_vmci/vmci_context.c
> +++ b/drivers/misc/vmw_vmci/vmci_context.c
> @@ -836,12 +836,12 @@ int vmci_ctx_set_chkpt_state(u32 context_id,
> for (i = 0; i < num_ids && result == VMCI_SUCCESS; i++) {
This for loop is nonsense. Probably it was left over cruft. It should
be:
for (i = 0; i < num_ids; i++) {
> current_id = ((u32 *)cpt_buf)[i];
> result = vmci_ctx_add_notification(context_id, current_id);
> - if (result != VMCI_SUCCESS)
> + if (result != VMCI_SUCCESS) {
> + pr_devel("Failed to set cpt state (type=%d)
> (error=%d)\n",
> + cpt_type, result);
> break;
return result;
Why break when it's just going to return? Eliminate the need to track
this error.
> + }
> }
> - if (result != VMCI_SUCCESS)
> - pr_devel("Failed to set cpt state (type=%d) (error=%d)\n",
> - cpt_type, result);
>
> return result;
return VMCI_SUCCESS;
Then we can remove the initialization for "result" as well to eliminate
another forced look up to the start of the function and down.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xhci dmesg flood on short packet
I see a continuous flood of below messages on plugging in/using my USB token. (The comp code wasn't in the original message - I added it.) From what I can tell the device continues to work as expected. Should the warning be disabled for COMP_SHORT_TX like it is for COMP_STOP and COMP_STOP_INVAL? Parag [104692.771649] xhci_hcd :00:14.0: WARN Event TRB comp code 13 for slot 2 ep 10 with no TDs queued? [104692.777279] xhci_hcd :00:14.0: WARN Event TRB comp code 13 for slot 2 ep 10 with no TDs queued? [104692.793894] xhci_hcd :00:14.0: WARN Event TRB comp code 13 for slot 2 ep 10 with no TDs queued? [104692.813033] xhci_hcd :00:14.0: WARN Event TRB comp code 13 for slot 2 ep 10 with no TDs queued? [104692.823476] xhci_hcd :00:14.0: WARN Event TRB comp code 13 for slot 2 ep 10 with no TDs queued? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] staging: dgnc: dgnc_neo: Fix conditional part of if statement
On Sat, May 17, 2014 at 05:30:53PM +0100, Masaru Nomura wrote:
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
> index 8988346..c211f9f 100644
> --- a/drivers/staging/dgnc/dgnc_neo.c
> +++ b/drivers/staging/dgnc/dgnc_neo.c
> @@ -838,9 +838,11 @@ static void neo_param(struct tty_struct *tty)
>* Have the UART interrupt on modem signal changes ONLY when
>* we are in hardware flow control mode, or CLOCAL/FORCEDCD is not set.
>*/
> - if ((ch->ch_digi.digi_flags & CTSPACE) || (ch->ch_digi.digi_flags &
> RTSPACE) ||
> - (ch->ch_c_cflag & CRTSCTS) || !(ch->ch_digi.digi_flags &
> DIGI_FORCEDCD) ||
> - !(ch->ch_c_cflag & CLOCAL)) {
> + if ((ch->ch_digi.digi_flags & CTSPACE)
> + || (ch->ch_digi.digi_flags & RTSPACE)
> + || (ch->ch_c_cflag & CRTSCTS)
> + || !(ch->ch_digi.digi_flags & DIGI_FORCEDCD)
> + || !(ch->ch_c_cflag & CLOCAL)) {
This isn't the right way. Write it like this:
if ((ch->ch_digi.digi_flags & CTSPACE) ||
(ch->ch_digi.digi_flags & RTSPACE) ||
(ch->ch_c_cflag & CRTSCTS) ||
!(ch->ch_digi.digi_flags & DIGI_FORCEDCD) ||
!(ch->ch_c_cflag & CLOCAL)) {
ier |= UART_IER_MSI;
else
ier &= ~UART_IER_MSI;
1) The "||" operation goes at the end of the line.
2) The conditions are all in a line. The indenting is
[tab][space][space][space][space](ch->ch_digi.digi_f...
Also just fold this patch and [patch 2/4] together into one patch. We
don't need two patches to fix one if statement.
The one thing per patch rule is a bit tricky. It means that you have to
say which one thing you are fixing. Don't say "I am fixing three
things." Say "I am fixing one if statement".
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] m32r: remove check for CONFIG_MEMHOLE
There's been a check for CONFIG_MEMHOLE in m32r's code ever since it was
added in v2.6.9. But there has never been a Kconfig symbol MEMHOLE.
(Neither have there been Kconfig symbols MEMHOLE_START and
MEMHOLE_SIZE, by the way.) Remove this check.
Signed-off-by: Paul Bolle
---
Untested.
arch/m32r/kernel/setup.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/m32r/kernel/setup.c b/arch/m32r/kernel/setup.c
index 0392112a5d70..4975c4555fe8 100644
--- a/arch/m32r/kernel/setup.c
+++ b/arch/m32r/kernel/setup.c
@@ -186,14 +186,6 @@ static unsigned long __init setup_memory(void)
*/
reserve_bootmem(CONFIG_MEMORY_START, PAGE_SIZE, BOOTMEM_DEFAULT);
- /*
-* reserve memory hole
-*/
-#ifdef CONFIG_MEMHOLE
- reserve_bootmem(CONFIG_MEMHOLE_START, CONFIG_MEMHOLE_SIZE,
- BOOTMEM_DEFAULT);
-#endif
-
#ifdef CONFIG_BLK_DEV_INITRD
if (LOADER_TYPE && INITRD_START) {
if (INITRD_START + INITRD_SIZE <= (max_low_pfn << PAGE_SHIFT)) {
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init()
On Sat, May 17, 2014 at 08:56:35PM +0200, Christian Engelmayer wrote: > On Sat, 17 May 2014 17:44:23 +0300, Dan Carpenter > wrote: > > On Sat, May 17, 2014 at 12:38:57PM +0200, Christian Engelmayer wrote: > > > Function rtw_drv_init() is written in a way that assumes 'status' != > > > _SUCCESS > > > as long as not explicitly set. Thus initialize 'status' to FAIL, in order > > > to > > > prevent undefined behaviour if going through the exit paths. Detected by > > > Coverity - CID 1077832. > > > > > > Signed-off-by: Christian Engelmayer > > > > This is a bugfix and we like to merge bugfixes without asking redo > > things, so don't redo. But really the better fix is to get rid of the > > status variable completely. Just return directly on the success path. > > > > If we were to do that, then both patches would be merged together and > > called: [patch] Staging: rtl8188eu: fix error handling in rtw_drv_init() > > > > But this patch is also acceptable as-is. Thanks for fixing the bug. :) > > I agree with You Dan. I'm no big fan of that status variable either. In this > case I was already tempted, but saw it as a recurring pattern in that file > in case cleanup is done. So I decided to just attack the bug in a small change > and leave the cleanup of the error handling pattern for a later, consistent > sweep over the whole file if that's wanted. It's a mistake to try be consistent with the crap code in the rest of this file. ;) Next time just fix it so at least a couple lines in here are not terrible. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: rtl8821ae: fix double const in sw.c
This commit fixes the following sparse warning: drivers/staging/rtl8821ae/rtl8821ae/sw.c: - 449:14: warning: duplicate const Signed-off-by: Konrad Zapalowicz --- drivers/staging/rtl8821ae/rtl8821ae/sw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8821ae/rtl8821ae/sw.c b/drivers/staging/rtl8821ae/rtl8821ae/sw.c index a8d1755..c24d426 100644 --- a/drivers/staging/rtl8821ae/rtl8821ae/sw.c +++ b/drivers/staging/rtl8821ae/rtl8821ae/sw.c @@ -446,7 +446,7 @@ MODULE_PARM_DESC(ips, "using no link power save (default 1 is open)\n"); MODULE_PARM_DESC(fwlps, "using linked fw control power save (default 1 is open)\n"); #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,29)) -static const SIMPLE_DEV_PM_OPS(rtlwifi_pm_ops, rtl_pci_suspend, rtl_pci_resume); +static SIMPLE_DEV_PM_OPS(rtlwifi_pm_ops, rtl_pci_suspend, rtl_pci_resume); #endif #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()
On Sat, May 17, 2014 at 08:21:03PM +0300, Antti Palosaari wrote: > On 05/17/2014 07:05 PM, Martin Kepplinger wrote: > >don't reinvent dev_dbg(). remove dprintk() in as102_drv.c. > >use the common kernel coding style. > > > >Signed-off-by: Martin Kepplinger > > Reviewed-by: Antti Palosaari > > >--- > >this applies to next-20140516. any more suggestions? > >more cleanup can be done when dprintk() is completely gone. > > Do you have the device? I am a bit reluctant patching that driver > without any testing as it has happened too many times something has > gone totally broken. Looking through the log the only time I see breakage is build breakage on allyesconfig. 1ec9a35 [media] staging: as102: Add missing function argument This was a compile warning and it definitely should have been caught before the code was submitted or merged, but it wasn't something people would hit in real life. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: rtl8821ae: fix sparse warnings in sw.c
This patch set fixes sparse warnings in sw.c file of rtl8821ae driver. In particular it deals with: 1) double const definition 2) missing 'static' for a few local symbols Konrad Zapalowicz (2): staging: rtl8821ae: fix double const in sw.c staging: rtl8821ae: fix not declared symbols should be static in sw.c drivers/staging/rtl8821ae/rtl8821ae/sw.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: rtl8821ae: fix not declared symbols should be static in sw.c
This commit fixes the following sparse warnings:
drivers/staging/rtl8821ae/rtl8821ae/sw.c:
- 48:6: warning: symbol 'rtl8821ae_init_aspm_vars' was not declared.
Should it be static?
- 228:5: warning: symbol 'rtl8812ae_rx_command_packet_handler' was
not declared. Should it be static?
- 263:20: warning: symbol 'rtl8821ae_hal_ops' was not declared.
Should it be static?
- 314:23: warning: symbol 'rtl8821ae_mod_params' was not declared.
Should it be static?
- 321:20: warning: symbol 'rtl8821ae_hal_cfg' was not declared.
Should it be static?
All of this symbols are local, that is there are no references to them
in the other files from this driver.
Signed-off-by: Konrad Zapalowicz
---
drivers/staging/rtl8821ae/rtl8821ae/sw.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/sw.c
b/drivers/staging/rtl8821ae/rtl8821ae/sw.c
index c24d426..e90806e 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/sw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/sw.c
@@ -45,7 +45,7 @@
#include "hal_btc.h"
#include "../btcoexist/rtl_btc.h"
-void rtl8821ae_init_aspm_vars(struct ieee80211_hw *hw)
+static void rtl8821ae_init_aspm_vars(struct ieee80211_hw *hw)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
@@ -225,7 +225,7 @@ void rtl8821ae_deinit_sw_vars(struct ieee80211_hw *hw)
//printk("<=rtl8821ae_deinit_sw_vars().\n");
}
-u32 rtl8812ae_rx_command_packet_handler(
+static u32 rtl8812ae_rx_command_packet_handler(
struct ieee80211_hw *hw,
struct rtl_stats status,
struct sk_buff *skb
@@ -260,7 +260,7 @@ bool rtl8821ae_get_btc_status(void)
return true;
}
-struct rtl_hal_ops rtl8821ae_hal_ops = {
+static struct rtl_hal_ops rtl8821ae_hal_ops = {
.init_sw_vars = rtl8821ae_init_sw_vars,
.deinit_sw_vars = rtl8821ae_deinit_sw_vars,
.read_eeprom_info = rtl8821ae_read_eeprom_info,
@@ -311,14 +311,14 @@ struct rtl_hal_ops rtl8821ae_hal_ops = {
.rx_command_packet_handler = rtl8812ae_rx_command_packet_handler,
};
-struct rtl_mod_params rtl8821ae_mod_params = {
+static struct rtl_mod_params rtl8821ae_mod_params = {
.sw_crypto = false,
.b_inactiveps = false,//true,
.b_swctrl_lps = false,
.b_fwctrl_lps = false, //true,
};
-struct rtl_hal_cfg rtl8821ae_hal_cfg = {
+static struct rtl_hal_cfg rtl8821ae_hal_cfg = {
.bar_id = 2,
.write_readback = true,
.name = "rtl8821ae_pci",
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: imx: fix error handling in ipu device registration
Hello Emil,
On Sat, May 17, 2014 at 08:40:33PM +0200, Emil Goode wrote:
> If we fail to allocate struct platform_device pdev we
> dereference it after the goto label err.
>
> I have rearranged the error handling a bit to fix the issue
> and also make it more clear.
>
> Signed-off-by: Emil Goode
> ---
> v3: Made subject line more specific.
> v2: Changed to return -ENOMEM instead of ret where possible and
> updated the subject line.
>
> arch/arm/mach-imx/devices/platform-ipu-core.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
Considering that you can fix the issue also by just doing:
diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
b/arch/arm/mach-imx/devices/platform-ipu-core.c
index fc4dd7cedc11..6bd7c3f37ac0 100644
--- a/arch/arm/mach-imx/devices/platform-ipu-core.c
+++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
@@ -77,7 +77,7 @@ struct platform_device *__init imx_alloc_mx3_camera(
pdev = platform_device_alloc("mx3-camera", 0);
if (!pdev)
- goto err;
+ return ERR_PTR(-ENOMEM);
pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
if (!pdev->dev.dma_mask)
or
diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
b/arch/arm/mach-imx/devices/platform-ipu-core.c
index fc4dd7cedc11..c609f3667200 100644
--- a/arch/arm/mach-imx/devices/platform-ipu-core.c
+++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
@@ -96,7 +96,8 @@ struct platform_device *__init imx_alloc_mx3_camera(
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (ret) {
err:
- kfree(pdev->dev.dma_mask);
+ if (pdev)
+ kfree(pdev->dev.dma_mask);
platform_device_put(pdev);
return ERR_PTR(-ENODEV);
}
I would prefer one of them as it is easier to justify and for the next
cycle convert the function to platform_device_register_full.
Also you should point out in the commit log that the issue was found by
coccinelle.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: imx: fix error handling
Hello Emil,
On Sat, May 17, 2014 at 05:35:40PM +0200, Emil Goode wrote:
> On Fri, May 16, 2014 at 09:31:39PM +0200, Uwe Kleine-König wrote:
> > On Fri, May 16, 2014 at 01:49:10PM +0200, walter harms wrote:
> > > Am 16.05.2014 13:16, schrieb Emil Goode:
> > > > Hello Walter,
> > > >
> > > > On Fri, May 16, 2014 at 12:40:19PM +0200, walter harms wrote:
> > > >>
> > > >>
> > > >> Am 16.05.2014 11:54, schrieb Emil Goode:
> > > >>> If we fail to allocate struct platform_device pdev we
> > > >>> dereference it after the goto label err.
> > > >>>
> > > >>> I have rearranged the error handling a bit to fix the issue
> > > >>> and also make it more clear.
> > > >>>
> > > >>> Signed-off-by: Emil Goode
> > > >>> ---
> > > >>> v2: Changed to return -ENOMEM instead of ret where possible and
> > > >>> updated the subject line.
> > > >>>
> > > >>> arch/arm/mach-imx/devices/platform-ipu-core.c | 22
> > > >>> +-
> > > >>> 1 file changed, 13 insertions(+), 9 deletions(-)
> > > >>>
> > > >>> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > >>> b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > >>> index fc4dd7c..68f2a4a 100644
> > > >>> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > >>> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > >>> @@ -77,34 +77,38 @@ struct platform_device *__init
> > > >>> imx_alloc_mx3_camera(
> > > >>>
> > > >>> pdev = platform_device_alloc("mx3-camera", 0);
> > > >>> if (!pdev)
> > > >>> - goto err;
> > > >>> + return ERR_PTR(-ENOMEM);
> > > >>>
> > > >>> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask),
> > > >>> GFP_KERNEL);
> > > >>> if (!pdev->dev.dma_mask)
> > > >>> - goto err;
> > > >>> + goto put_pdev;
> > > >>>
> > > >>> *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> > > >>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > > >>>
> > > >>> ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> > > >>> if (ret)
> > > >>> - goto err;
> > > >>> + goto free_dma_mask;
> > > >>>
> > > >>> if (pdata) {
> > > >>> struct mx3_camera_pdata *copied_pdata;
> > > >>>
> > > >>> ret = platform_device_add_data(pdev, pdata,
> > > >>> sizeof(*pdata));
> > > >>> - if (ret) {
> > > >>> -err:
> > > >>> - kfree(pdev->dev.dma_mask);
> > > >>> - platform_device_put(pdev);
> > > >>> - return ERR_PTR(-ENODEV);
> > > >>> - }
> > > >>> + if (ret)
> > > >>> + goto free_dma_mask;
> > > >>> +
> > > >>> copied_pdata = dev_get_platdata(>dev);
> > > >>> copied_pdata->dma_dev = _ipu_coredev->dev;
> > > >>
> > > >>
> > > >> the patch is fine, but what use is this copied_pdata ?
> > > >> It scope ends next line ?
> > > >>
> > > >> re,
> > > >> wh
> > > >
> > > > I also thought that looked a bit odd, but copied_pdata is a temporary
> > > > pointer to platform_data of the dev struct.
> > > >
> > > > dev_get_platdata looks like this:
> > > >
> > > > static inline void *dev_get_platdata(const struct device *dev)
> > > > {
> > > > return dev->platform_data;
> > > > }
> > > >
> > > > So I believe it's a more compact way of writing:
> > > >
> > > > pdev->dev->platform_data->dma_dev = _ipu_coredev->dev;
> > It's not about compactness. The dev_get_platdata accessor exists to be
> > used instead of directly accessing dev->platform_data. I admit a comment
> > would be nice ...
> >
> > Anyhow this is all ugly, actually you'd want to have the dma_dev member
> > already fixed when calling platform_device_add_data. But you cannot
> > simply do
> >
> > pdata->dma_dev = _ipu_coredev->dev;
> > ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> >
> > because *pdata is const.
>
> Thank you for the explanation. Regarding the possibility of using
> platform_device_register_full() to simplify this function. It seem to
> be possible, the following inline function is available to help with this.
>
> imx_add_platform_device_dmamask()
I'd prefer to use platform_device_register_full directly (and let the
wrapper die).
> But as you mentioned above we need to allocate a new platform_device
> struct before we can assign _ipu_coredev->dev to dma_dev, since
> pdata is const. I guess this assignment could be done after calling
> imx_add_platform_device_dmamask() but I don't think that makes the
No, that won't work, because after platform_device_register_full returns
you must assume that the device is already bound by a driver. And then
you must not change platform_data anymore.
The only thing that would work is:
struct mx3_camera_pdata tmppdata;
if (pdata) {
tmppdata = *pdata;
tmppdata.dma_dev = _ipu_coredev->dev;
pdata =
}
i8042 error
I have this old dell inspiron 2600 laptop with dual boot XP and Fedora 12 running some version of the 2.6 kernel and the keyboard and the mousepad are dead in linux. When I boot linux I get this error message: Can't read CTR while initializing i8042 which is in i8042.c. Past that point, I can't interact with the laptop in any way. The keyboard and mouse work fine in linux in the past and work now in XP so it's not (entirely) a hardware problem. I have not used the laptop in a while so I don't know if it ever worked in F12 but I was obviously able to install it. Now if I try to install the latest Fedora 20 with the 3.6 kernel I have the exact problem upon install. I did do a memory upgrade which involved some work under the keyboard, and that may have something to do with this problem, but - again - it works in XP. Is there any hope? I'll provide any info necessary if someone can help, although not sure what I can do if I can't type anything. I'm not subscribed to the list, so please CC me when necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1 linux-next] kernel/events/core.c: remove unused variable tmp
tmp is no longer used in perf_event_exit_task_context since
3a497f48637e2a
"perf: Simplify perf_event_exit_task_context()"
Cc: Peter Zijlstra
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
kernel/events/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 49ac18c..244d70a 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7432,7 +7432,7 @@ __perf_event_exit_task(struct perf_event *child_event,
static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
{
- struct perf_event *child_event, *tmp;
+ struct perf_event *child_event;
struct perf_event_context *child_ctx;
unsigned long flags;
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: rtl8188eu: fix usage of uninit scalar in rtw_drv_init()
On Sat, 17 May 2014 17:44:23 +0300, Dan Carpenter wrote: > On Sat, May 17, 2014 at 12:38:57PM +0200, Christian Engelmayer wrote: > > Function rtw_drv_init() is written in a way that assumes 'status' != > > _SUCCESS > > as long as not explicitly set. Thus initialize 'status' to FAIL, in order to > > prevent undefined behaviour if going through the exit paths. Detected by > > Coverity - CID 1077832. > > > > Signed-off-by: Christian Engelmayer > > This is a bugfix and we like to merge bugfixes without asking redo > things, so don't redo. But really the better fix is to get rid of the > status variable completely. Just return directly on the success path. > > If we were to do that, then both patches would be merged together and > called: [patch] Staging: rtl8188eu: fix error handling in rtw_drv_init() > > But this patch is also acceptable as-is. Thanks for fixing the bug. :) I agree with You Dan. I'm no big fan of that status variable either. In this case I was already tempted, but saw it as a recurring pattern in that file in case cleanup is done. So I decided to just attack the bug in a small change and leave the cleanup of the error handling pattern for a later, consistent sweep over the whole file if that's wanted. Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Fix for possible null pointer dereference in node.c
On Sat, May 17, 2014 at 03:21:56PM +0200, Rickard Strandqvist wrote: > Okay, everyone agrees with Dan..? > You can audit it yourself, there are only 4 callers. The node_allocate() is total garbage so the second delete_node() is a bit complicated to read but it's not that hard. > I have made a new patch, which does not check if hnode is NULL. Send it inline so we can use our normal scripts. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI/shpchp: fix a bus speed issue on hotplug
On Thu, May 15, 2014 at 12:41:46PM -0600, Bjorn Helgaas wrote:
> On Thu, May 01, 2014 at 05:35:48PM +0300, Marcel Apfelbaum wrote:
> > When a board is added, the shpchp driver checks if there
> > is a mismatch between the bridge's adapter and the bus speed.
> > If there is, it sets the subordinate speed (if there is no device on it).
> >
> > However, it takes the reference of the board speed from the primary bus
> > and not from the subordinate. If the primary bus is PCI and not PCIX/PCIe,
> > its speed is not updated and remains 0xff. As a result hotplug fails
> > with error: "Speed of bus ff and adapter 0 mismatch".
> >
> > Fixed that by checking the speed against the subordinate bus.
> >
> > Signed-off-by: Marcel Apfelbaum
> > Acked-by: Michael S. Tsirkin
>
> I think cpqphp has similar issues. But I can't test it and I don't know if
> anybody even uses it any more, so I'm just going to leave it alone.
>
> I reworked the changelog because I got confused about the bridge, adapter,
> board, and what was what. Let me know if the one below is inaccurate.
It's accurate I think. I only wish someone reworked the actual
shpchp code to avoid the confusing adapter/board terminology.
> I'll include this for v3.15 since it's a regression fix.
>
> Thanks,
> Bjorn
>
> commit be219b7f518a36f62d67f057e9d31ebe9674814f
> Author: Marcel Apfelbaum
> Date: Thu May 1 17:35:48 2014 +0300
>
> PCI: shpchp: Check bridge's secondary (not primary) bus speed
>
> When a new device is added below a hotplug bridge, the bridge's secondary
> bus speed and the device's bus speed must match. The shpchp driver
> previously checked the bridge's *primary* bus speed, not the secondary bus
> speed.
>
> This caused hot-add errors like:
>
> shpchp :00:03.0: Speed of bus ff and adapter 0 mismatch
>
> Check the secondary bus speed instead.
>
> [bhelgaas: changelog]
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
> Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of
> the PCI core")
> Signed-off-by: Marcel Apfelbaum
> Signed-off-by: Bjorn Helgaas
> Acked-by: Michael S. Tsirkin
> CC: sta...@vger.kernel.org# v2.6.34+
>
> diff --git a/drivers/pci/hotplug/shpchp_ctrl.c
> b/drivers/pci/hotplug/shpchp_ctrl.c
> index 58499277903a..6efc2ec5e4db 100644
> --- a/drivers/pci/hotplug/shpchp_ctrl.c
> +++ b/drivers/pci/hotplug/shpchp_ctrl.c
> @@ -282,8 +282,8 @@ static int board_added(struct slot *p_slot)
> return WRONG_BUS_FREQUENCY;
> }
>
> - bsp = ctrl->pci_dev->bus->cur_bus_speed;
> - msp = ctrl->pci_dev->bus->max_bus_speed;
> + bsp = ctrl->pci_dev->subordinate->cur_bus_speed;
> + msp = ctrl->pci_dev->subordinate->max_bus_speed;
>
> /* Check if there are other slots or devices on the same bus */
> if (!list_empty(>pci_dev->subordinate->devices))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()
Il 17/05/2014 19:52, Martin Kepplinger ha scritto: > Am 2014-05-17 19:21, schrieb Antti Palosaari: >> On 05/17/2014 07:05 PM, Martin Kepplinger wrote: >>> don't reinvent dev_dbg(). remove dprintk() in as102_drv.c. >>> use the common kernel coding style. >>> >>> Signed-off-by: Martin Kepplinger >> >> Reviewed-by: Antti Palosaari >> >>> --- >>> this applies to next-20140516. any more suggestions? >>> more cleanup can be done when dprintk() is completely gone. >> >> Do you have the device? I am a bit reluctant patching that driver >> without any testing as it has happened too many times something has gone >> totally broken. > I don't have the device and will, at most, change such style issues. > >> >> IIRC Devin said it is in staging because of style issues and nothing >> more. Is that correct? > I haven't heard anything. A TODO file would help. Hi Antti, Martin, if I remember correctly, the main issue with this driver is that the device does not work anymore after a reboot: it needs a power cycle to start working again. Probably this issue is enough to keep the driver in staging. Regards, Gianluca > >> >> regards >> Antti >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] ARM: imx: fix error handling in ipu device registration
If we fail to allocate struct platform_device pdev we
dereference it after the goto label err.
I have rearranged the error handling a bit to fix the issue
and also make it more clear.
Signed-off-by: Emil Goode
---
v3: Made subject line more specific.
v2: Changed to return -ENOMEM instead of ret where possible and
updated the subject line.
arch/arm/mach-imx/devices/platform-ipu-core.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c
b/arch/arm/mach-imx/devices/platform-ipu-core.c
index fc4dd7c..68f2a4a 100644
--- a/arch/arm/mach-imx/devices/platform-ipu-core.c
+++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
@@ -77,34 +77,38 @@ struct platform_device *__init imx_alloc_mx3_camera(
pdev = platform_device_alloc("mx3-camera", 0);
if (!pdev)
- goto err;
+ return ERR_PTR(-ENOMEM);
pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
if (!pdev->dev.dma_mask)
- goto err;
+ goto put_pdev;
*pdev->dev.dma_mask = DMA_BIT_MASK(32);
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
if (ret)
- goto err;
+ goto free_dma_mask;
if (pdata) {
struct mx3_camera_pdata *copied_pdata;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
- if (ret) {
-err:
- kfree(pdev->dev.dma_mask);
- platform_device_put(pdev);
- return ERR_PTR(-ENODEV);
- }
+ if (ret)
+ goto free_dma_mask;
+
copied_pdata = dev_get_platdata(>dev);
copied_pdata->dma_dev = _ipu_coredev->dev;
}
return pdev;
+
+free_dma_mask:
+ kfree(pdev->dev.dma_mask);
+put_pdev:
+ platform_device_put(pdev);
+
+ return ERR_PTR(ret);
}
struct platform_device *__init imx_add_mx3_sdc_fb(
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] Machine freeze on latest Linus kernel, seems related to nouveau
On Sat, May 17, 2014 at 2:13 PM, Damien Wyart wrote: > Hi; > > After further tests, I can reproduce the problem on 3.14.4 also, > mainly by visiting the following URL with Firefox (29.0.1) : > http://lavieestmaloptimisee.blogspot.fr/ Amazing. I get the same thing in chrome on my setup (G96). [235255.701101] BUG: unable to handle kernel paging request at c90013d0 [235255.701119] IP: [] iowrite32+0xe/0x31 [235255.701130] PGD 1a880e067 PUD 1a880f067 PMD 1a7533067 PTE 0 [235255.701221] CPU: 0 PID: 22304 Comm: chrome Not tainted 3.15.0-rc5+ #83 and a slightly different backtrace, although both eventually try to create a gpuobj: [235255.701381] [] ? nouveau_barobj_wr32+0x14/0x16 [nouveau] [235255.701400] [] _nouveau_gpuobj_wr32+0x2a/0x2c [nouveau] [235255.701418] [] nouveau_gpuobj_create_+0x1f7/0x247 [nouveau] [235255.701437] [] _nouveau_gpuobj_ctor+0x3d/0x4b [nouveau] [235255.701457] [] nouveau_object_ctor+0x32/0xaf [nouveau] [235255.701475] [] nouveau_gpuobj_new+0x4e/0x50 [nouveau] [235255.701504] [] nouveau_vm_get+0x151/0x27a [nouveau] [235255.701545] [] ? nouveau_gem_object_open+0x7a/0xbe [nouveau] [235255.701585] [] nouveau_bo_vma_add+0x36/0x9f [nouveau] [235255.701624] [] nouveau_gem_object_open+0x94/0xbe [nouveau] [235255.701640] [] drm_gem_handle_create_tail+0xe0/0x106 [drm] [235255.701654] [] drm_gem_handle_create+0x39/0x40 [drm] [235255.701693] [] nouveau_gem_ioctl_new+0xc9/0x117 [nouveau] [235255.701707] [] drm_ioctl+0x2ae/0x416 [drm] [235255.701745] [] ? nouveau_gem_new+0xe9/0xe9 [nouveau] [235255.701755] [] ? __pm_runtime_resume+0x6b/0x7a [235255.701793] [] nouveau_drm_ioctl+0x5d/0x92 [nouveau] [235255.701803] [] do_vfs_ioctl+0x3f7/0x441 [235255.701811] [] ? fput+0x17/0x8d [235255.701820] [] ? SyS_mmap_pgoff+0x1a2/0x1d4 [235255.701827] [] SyS_ioctl+0x3e/0x67 [235255.701837] [] system_call_fastpath+0x16/0x1b This is on top of a 3.15-rc5+ kernel. Normally these things are very hard to debug because they're ~impossible to reproduce. However this website seems to do the trick (I'm guessing with the help of the youtube embeds). Ben, any advice on debugging? (Or even better, an idea as to what's wrong... I seem to recall this happening a lot a while back and then it magically fixed itself for a while...) > > Firefox becomes unresponsive and I get some messages in the kernel log : > > May 17 20:01:36 brouette kernel: BUG: unable to handle kernel paging > request at c9001530 > May 17 20:01:36 brouette kernel: IP: [] iowrite32+0x38/0x40 > May 17 20:01:36 brouette kernel: PGD 1b880f067 PUD 1b8850067 PMD 1b6cfd067 > PTE 0 > May 17 20:01:36 brouette kernel: Oops: 0002 [#1] PREEMPT SMP > May 17 20:01:36 brouette kernel: Modules linked in: usb_storage > nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 > xt_dscp xt_mark cls_flow cls_fw sch_sfq sch_htb xt_helper xt_length > nf_conntrack_ftp nf_conntrack ip6table_mangle ip6_tables > iptable_mangle ip_tables x_tables cpufreq_powersave cpufreq_userspace > cpufreq_conservative deadline_iosched binfmt_misc hid_roccat_konepure > hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib > usbhid snd_hwdep nouveau snd_hda_codec_realtek snd_hda_codec_generic > wmi snd_ca0106 video i2c_algo_bit snd_ac97_codec ac97_bus > snd_seq_dummy snd_seq_midi snd_seq_oss ttm snd_seq_midi_event > drm_kms_helper snd_seq drm i2c_core backlight snd_rawmidi > snd_hda_intel snd_hda_codec snd_seq_device sr_mod snd_pcm_oss pcspkr > cdrom nvidiafb snd_mixer_oss vgastate snd_pcm snd_timer ehci_pci > uhci_hcd ehci_hcd usbcore evdev usb_common acpi_cpufreq loop fuse > autofs4 > May 17 20:01:36 brouette kernel: CPU: 1 PID: 12671 Comm: > plugin-containe Tainted: P O 3.14.4 #1 > May 17 20:01:36 brouette kernel: Hardware name: System manufacturer > System Product Name/P6T SE, BIOS 080803/08/2010 > May 17 20:01:36 brouette kernel: task: 8800ba42a160 ti: > 8801ac584000 task.ti: 8801ac584000 > May 17 20:01:36 brouette kernel: RIP: 0010:[] > [] iowrite32+0x38/0x40 > May 17 20:01:36 brouette kernel: RSP: 0018:8801ac585b90 EFLAGS: 00010292 > May 17 20:01:36 brouette kernel: RAX: 8800813e65a0 RBX: > 8801b5aed600 RCX: > May 17 20:01:36 brouette kernel: RDX: c9001530 RSI: > c9001530 RDI: > May 17 20:01:36 brouette kernel: RBP: 8801ac585b98 R08: > a0423100 R09: > May 17 20:01:36 brouette kernel: R10: R11: > 000f R12: 00060004 > May 17 20:01:36 brouette kernel: R13: R14: > 8801ac585bd8 R15: > May 17 20:01:36 brouette kernel: FS: 7f1767d15a40() > GS:8801bfc2() knlGS: > May 17 20:01:36 brouette kernel: CS: 0010 DS: ES: CR0: > 80050033 > May 17 20:01:36 brouette kernel: CR2: c9001530 CR3: > 00019d752000 CR4: 07e0 > May 17 20:01:36 brouette kernel: Stack: > May 17 20:01:36
[PATCH 3/4] atm: idt77252: Remove redundant error check
Remove double checks, and move the call to printk to the
first check. Also adds KERN_WARNING to printk. The simplified version
of the coccinelle semantic patch that fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
while(...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Tested by compilation only.
Signed-off-by: Peter Senna Tschudin
---
drivers/atm/idt77252.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 1bdf104..a8b6402 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -2551,12 +2551,12 @@ done:
timeout = 5 * 1000;
while (atomic_read(>scq->used) > 0) {
timeout = msleep_interruptible(timeout);
- if (!timeout)
+ if (!timeout) {
+ printk(KERN_WARNING "%s: SCQ drain timeout: %u
used\n",
+ card->name, atomic_read(>scq->used));
break;
+ }
}
- if (!timeout)
- printk("%s: SCQ drain timeout: %u used\n",
- card->name, atomic_read(>scq->used));
writel(TCMDQ_HALT | vc->index, SAR_REG_TCMDQ);
clear_scd(card, vc->scq, vc->class);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] VMCI: Remove redundant error check
Remove double checks, and move the call to pr_devel to the
first check. The simplified version of the coccinelle semantic
patch that fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Tested by compilation only.
Signed-off-by: Peter Senna Tschudin
---
drivers/misc/vmw_vmci/vmci_context.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_context.c
b/drivers/misc/vmw_vmci/vmci_context.c
index f866a4b..3995e64 100644
--- a/drivers/misc/vmw_vmci/vmci_context.c
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -836,12 +836,12 @@ int vmci_ctx_set_chkpt_state(u32 context_id,
for (i = 0; i < num_ids && result == VMCI_SUCCESS; i++) {
current_id = ((u32 *)cpt_buf)[i];
result = vmci_ctx_add_notification(context_id, current_id);
- if (result != VMCI_SUCCESS)
+ if (result != VMCI_SUCCESS) {
+ pr_devel("Failed to set cpt state (type=%d)
(error=%d)\n",
+cpt_type, result);
break;
+ }
}
- if (result != VMCI_SUCCESS)
- pr_devel("Failed to set cpt state (type=%d) (error=%d)\n",
-cpt_type, result);
return result;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] cpupower: Remove redundant error check
Remove double checks, and move the call to print_error to the
first check. The simplified version of the coccinelle semantic
patch that fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Untested.
Signed-off-by: Peter Senna Tschudin
---
tools/power/cpupower/utils/cpufreq-set.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/power/cpupower/utils/cpufreq-set.c
b/tools/power/cpupower/utils/cpufreq-set.c
index a416de8..4e2f35a 100644
--- a/tools/power/cpupower/utils/cpufreq-set.c
+++ b/tools/power/cpupower/utils/cpufreq-set.c
@@ -320,12 +320,11 @@ int cmd_freq_set(int argc, char **argv)
printf(_("Setting cpu: %d\n"), cpu);
ret = do_one_cpu(cpu, _pol, freq, policychange);
- if (ret)
+ if (ret) {
+ print_error();
break;
+ }
}
- if (ret)
- print_error();
-
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] IB: Remove redundant error check
Remove double checks, and move calls to pr_err and printk to the
first check. The simplified version of the coccinelle semantic
patch that fixes this issue is as follows:
//
@@
expression E; identifier pr; expression list es;
@@
for(...;...;...){
...
- if (E) break;
+ if (E){
+ pr(es);
+ break;
+ }
...
}
- if(E) pr(es);
//
Tested by compilation only.
Signed-off-by: Peter Senna Tschudin
---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c |6 +++---
drivers/infiniband/ulp/srpt/ib_srpt.c|8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index 3bbf201..f085a51 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1839,11 +1839,11 @@ int ocrdma_reg_mr(struct ocrdma_dev *dev,
status = ocrdma_mbx_reg_mr_cont(dev, hwmr, cur_pbl_cnt,
pbl_offset, last);
- if (status)
+ if (status) {
+ pr_err("%s() err. status=%d\n", __func__, status);
break;
+ }
}
- if (status)
- pr_err("%s() err. status=%d\n", __func__, status);
return status;
}
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index fe09f27..ab23b07 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2875,13 +2875,13 @@ static int srpt_perform_rdmas(struct srpt_rdma_ch *ch,
wr.send_flags = IB_SEND_SIGNALED;
ret = ib_post_send(ch->qp, , _wr);
- if (ret)
+ if (ret) {
+ printk(KERN_ERR "%s[%d]: ib_post_send() returned %d for
%d/%d",
+ __func__, __LINE__, ret, i, n_rdma);
break;
+ }
}
- if (ret)
- printk(KERN_ERR "%s[%d]: ib_post_send() returned %d for %d/%d",
-__func__, __LINE__, ret, i, n_rdma);
if (ret && i > 0) {
wr.num_sge = 0;
wr.wr_id = encode_wr_id(SRPT_RDMA_ABORT, ioctx->ioctx.index);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Machine freeze on latest Linus kernel, seems related to nouveau
Hi; After further tests, I can reproduce the problem on 3.14.4 also, mainly by visiting the following URL with Firefox (29.0.1) : http://lavieestmaloptimisee.blogspot.fr/ Firefox becomes unresponsive and I get some messages in the kernel log : May 17 20:01:36 brouette kernel: BUG: unable to handle kernel paging request at c9001530 May 17 20:01:36 brouette kernel: IP: [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: PGD 1b880f067 PUD 1b8850067 PMD 1b6cfd067 PTE 0 May 17 20:01:36 brouette kernel: Oops: 0002 [#1] PREEMPT SMP May 17 20:01:36 brouette kernel: Modules linked in: usb_storage nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_dscp xt_mark cls_flow cls_fw sch_sfq sch_htb xt_helper xt_length nf_conntrack_ftp nf_conntrack ip6table_mangle ip6_tables iptable_mangle ip_tables x_tables cpufreq_powersave cpufreq_userspace cpufreq_conservative deadline_iosched binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep nouveau snd_hda_codec_realtek snd_hda_codec_generic wmi snd_ca0106 video i2c_algo_bit snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_midi snd_seq_oss ttm snd_seq_midi_event drm_kms_helper snd_seq drm i2c_core backlight snd_rawmidi snd_hda_intel snd_hda_codec snd_seq_device sr_mod snd_pcm_oss pcspkr cdrom nvidiafb snd_mixer_oss vgastate snd_pcm snd_timer ehci_pci uhci_hcd ehci_hcd usbcore evdev usb_common acpi_cpufreq loop fuse autofs4 May 17 20:01:36 brouette kernel: CPU: 1 PID: 12671 Comm: plugin-containe Tainted: P O 3.14.4 #1 May 17 20:01:36 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 May 17 20:01:36 brouette kernel: task: 8800ba42a160 ti: 8801ac584000 task.ti: 8801ac584000 May 17 20:01:36 brouette kernel: RIP: 0010:[] [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: RSP: 0018:8801ac585b90 EFLAGS: 00010292 May 17 20:01:36 brouette kernel: RAX: 8800813e65a0 RBX: 8801b5aed600 RCX: May 17 20:01:36 brouette kernel: RDX: c9001530 RSI: c9001530 RDI: May 17 20:01:36 brouette kernel: RBP: 8801ac585b98 R08: a0423100 R09: May 17 20:01:36 brouette kernel: R10: R11: 000f R12: 00060004 May 17 20:01:36 brouette kernel: R13: R14: 8801ac585bd8 R15: May 17 20:01:36 brouette kernel: FS: 7f1767d15a40() GS:8801bfc2() knlGS: May 17 20:01:36 brouette kernel: CS: 0010 DS: ES: CR0: 80050033 May 17 20:01:36 brouette kernel: CR2: c9001530 CR3: 00019d752000 CR4: 07e0 May 17 20:01:36 brouette kernel: Stack: May 17 20:01:36 brouette kernel: a036be6f 8801ac585ba8 a0368f25 8801ac585c08 May 17 20:01:36 brouette kernel: a03691c6 010077359400 a0443ff0 1de8d000 May 17 20:01:36 brouette kernel: 8800813e65a0 8801b5aed700 880165e83740 May 17 20:01:36 brouette kernel: Call Trace: May 17 20:01:36 brouette kernel: [] ? nouveau_barobj_wr32+0xf/0x20 [nouveau] May 17 20:01:36 brouette kernel: [] _nouveau_gpuobj_wr32+0x25/0x30 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_gpuobj_create_+0x1c6/0x2c0 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_engctx_create_+0x24f/0x2a0 [nouveau] May 17 20:01:36 brouette kernel: [] nv50_graph_context_ctor+0x3c/0x80 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_object_ctor+0x2d/0xc0 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_object_new+0xeb/0x200 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_abi16_ioctl_grobj_alloc+0x6b/0xe0 [nouveau] May 17 20:01:36 brouette kernel: [] drm_ioctl+0x4c2/0x5f0 [drm] May 17 20:01:36 brouette kernel: [] ? do_mmap_pgoff+0x2c2/0x380 May 17 20:01:36 brouette kernel: [] nouveau_drm_ioctl+0x9/0x10 [nouveau] May 17 20:01:36 brouette kernel: [] do_vfs_ioctl+0x2e0/0x4c0 May 17 20:01:36 brouette kernel: [] ? __fget+0x69/0xb0 May 17 20:01:36 brouette kernel: [] SyS_ioctl+0x81/0xa0 May 17 20:01:36 brouette kernel: [] system_call_fastpath+0x16/0x1b May 17 20:01:36 brouette kernel: Code: 81 fe 00 00 01 00 76 0b 0f b7 d6 89 f8 ef c3 0f 1f 40 00 55 48 c7 c6 e1 9e 58 81 48 89 d7 48 89 e5 e8 1d fe ff ff 5d c3 0f 1f 00 <89> 3e c3 0f 1f 44 00 00 48 81 ff ff ff 03 00 77 37 48 81 ff 00 May 17 20:01:36 brouette kernel: RIP [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: RSP May 17 20:01:36 brouette kernel: CR2: c9001530 May 17 20:01:36 brouette kernel: ---[ end trace e4c3bdfb0b08f505 ]--- Thanks in advance for any help. Best Damien Wyart On Fri, May 16, 2014 at 10:05 AM, Damien Wyart wrote: > Hi, > > I am running the latest kernel from Linus. Once yesterday and once > today, I got a freeze of my machine. The first time, I could reboot > with sysrq, but not the second one (completely unresponsive). The > first time,, there
Re: [PATCH 2/5] ipc,msg: move some msgq ns code around
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Nothing big and no logical changes, just get rid of some
redundant function declarations. Move msg_[init/exit]_ns
down the end of the file.
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 132 ++
1 file changed, 63 insertions(+), 69 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 5a8489b..6d33e30 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -70,75 +70,6 @@ struct msg_sender {
#define msg_ids(ns) ((ns)->ids[IPC_MSG_IDS])
-static void freeque(struct ipc_namespace *, struct kern_ipc_perm *);
-static int newque(struct ipc_namespace *, struct ipc_params *);
-#ifdef CONFIG_PROC_FS
-static int sysvipc_msg_proc_show(struct seq_file *s, void *it);
-#endif
-
-/*
- * Scale msgmni with the available lowmem size: the memory dedicated to msg
- * queues should occupy at most 1/MSG_MEM_SCALE of lowmem.
- * Also take into account the number of nsproxies created so far.
- * This should be done staying within the (MSGMNI , IPCMNI/nr_ipc_ns) range.
- */
-void recompute_msgmni(struct ipc_namespace *ns)
-{
- struct sysinfo i;
- unsigned long allowed;
- int nb_ns;
-
- si_meminfo();
- allowed = (((i.totalram - i.totalhigh) / MSG_MEM_SCALE) * i.mem_unit)
- / MSGMNB;
- nb_ns = atomic_read(_ipc_ns);
- allowed /= nb_ns;
-
- if (allowed < MSGMNI) {
- ns->msg_ctlmni = MSGMNI;
- return;
- }
-
- if (allowed > IPCMNI / nb_ns) {
- ns->msg_ctlmni = IPCMNI / nb_ns;
- return;
- }
-
- ns->msg_ctlmni = allowed;
-}
-
-void msg_init_ns(struct ipc_namespace *ns)
-{
- ns->msg_ctlmax = MSGMAX;
- ns->msg_ctlmnb = MSGMNB;
-
- recompute_msgmni(ns);
-
- atomic_set(>msg_bytes, 0);
- atomic_set(>msg_hdrs, 0);
- ipc_init_ids(>ids[IPC_MSG_IDS]);
-}
-
-#ifdef CONFIG_IPC_NS
-void msg_exit_ns(struct ipc_namespace *ns)
-{
- free_ipcs(ns, _ids(ns), freeque);
- idr_destroy(>ids[IPC_MSG_IDS].ipcs_idr);
-}
-#endif
-
-void __init msg_init(void)
-{
- msg_init_ns(_ipc_ns);
-
- printk(KERN_INFO "msgmni has been set to %d\n",
- init_ipc_ns.msg_ctlmni);
-
- ipc_init_proc_interface("sysvipc/msg",
- " key msqid perms cbytes qnum
lspid lrpid uid gid cuid cgid stime rtime ctime\n",
- IPC_MSG_IDS, sysvipc_msg_proc_show);
-}
-
static inline struct msg_queue *msq_obtain_object(struct ipc_namespace *ns,
int id)
{
struct kern_ipc_perm *ipcp = ipc_obtain_object(_ids(ns), id);
@@ -1054,6 +985,57 @@ SYSCALL_DEFINE5(msgrcv, int, msqid, struct msgbuf __user
*, msgp, size_t, msgsz,
return do_msgrcv(msqid, msgp, msgsz, msgtyp, msgflg, do_msg_fill);
}
+/*
+ * Scale msgmni with the available lowmem size: the memory dedicated to msg
+ * queues should occupy at most 1/MSG_MEM_SCALE of lowmem.
+ * Also take into account the number of nsproxies created so far.
+ * This should be done staying within the (MSGMNI , IPCMNI/nr_ipc_ns) range.
+ */
+void recompute_msgmni(struct ipc_namespace *ns)
+{
+ struct sysinfo i;
+ unsigned long allowed;
+ int nb_ns;
+
+ si_meminfo();
+ allowed = (((i.totalram - i.totalhigh) / MSG_MEM_SCALE) * i.mem_unit)
+ / MSGMNB;
+ nb_ns = atomic_read(_ipc_ns);
+ allowed /= nb_ns;
+
+ if (allowed < MSGMNI) {
+ ns->msg_ctlmni = MSGMNI;
+ return;
+ }
+
+ if (allowed > IPCMNI / nb_ns) {
+ ns->msg_ctlmni = IPCMNI / nb_ns;
+ return;
+ }
+
+ ns->msg_ctlmni = allowed;
+}
+
+void msg_init_ns(struct ipc_namespace *ns)
+{
+ ns->msg_ctlmax = MSGMAX;
+ ns->msg_ctlmnb = MSGMNB;
+
+ recompute_msgmni(ns);
+
+ atomic_set(>msg_bytes, 0);
+ atomic_set(>msg_hdrs, 0);
+ ipc_init_ids(>ids[IPC_MSG_IDS]);
+}
+
+#ifdef CONFIG_IPC_NS
+void msg_exit_ns(struct ipc_namespace *ns)
+{
+ free_ipcs(ns, _ids(ns), freeque);
+ idr_destroy(>ids[IPC_MSG_IDS].ipcs_idr);
+}
+#endif
+
#ifdef CONFIG_PROC_FS
static int sysvipc_msg_proc_show(struct seq_file *s, void *it)
{
@@ -1078,3 +1060,15 @@ static int sysvipc_msg_proc_show(struct seq_file *s,
void *it)
msq->q_ctime);
}
#endif
+
+void __init msg_init(void)
+{
+ msg_init_ns(_ipc_ns);
+
+ printk(KERN_INFO "msgmni has been set to %d\n",
+ init_ipc_ns.msg_ctlmni);
+
+ ipc_init_proc_interface("sysvipc/msg",
+ " key msqid perms cbytes qnum
lspid lrpid uid gid cuid cgid stime rtime ctime\n",
+ IPC_MSG_IDS, sysvipc_msg_proc_show);
+}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: [PATCH] fs: Cleanup string initializations (char[] instead of char *)
On Sat, May 17, 2014 at 06:21:09PM +0100, Al Viro wrote: > On Sat, May 17, 2014 at 05:44:28PM +0200, Mateusz Guzik wrote: > > This particular function would be better of with removing this variable > > and replacing all pairs like: > > sprintf(dp, ...); > > dp += strlen(...) > > > > with: > > dp += sprintf(dp, ...); > > Sigh... Premature optimisation and all such... (..) Well, I was interested in getting rid of this error-prone style, which results in stuff like: sprintf(dp, "\nmask "); dp += 6; ... and cleaning up the rest for consistency, will note next time. I'm new to linux and didn't know about seq_ thingy, will grep some more next time. -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] ipc,msg: use current->state helpers
On 05/13/2014 10:27 PM, Davidlohr Bueso wrote:
Call __set_current_state() instead of assigning
the new state directly.
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 7ed1ef3..5a8489b 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -227,7 +227,7 @@ static int newque(struct ipc_namespace *ns, struct
ipc_params *params)
static inline void ss_add(struct msg_queue *msq, struct msg_sender *mss)
{
mss->tsk = current;
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
list_add_tail(>list, >q_senders);
}
@@ -976,7 +976,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long msgtyp, int msgfl
else
msr_d.r_maxsize = bufsz;
msr_d.r_msg = ERR_PTR(-EAGAIN);
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
ipc_unlock_object(>q_perm);
rcu_read_unlock();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] irqchip: add Broadcom Set Top Box Level-2 interrupt controller
This patch adds support for the Level-2 interrupt controller hardware
found in Broadcom Set Top Box System-on-a-Chip devices. This interrupt
controller is implemented using the generic IRQ chip driver with
separate enable and disable registers.
Signed-off-by: Brian Norris
Signed-off-by: Florian Fainelli
---
drivers/irqchip/Kconfig | 6 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-brcmstb-l2.c | 200 +++
3 files changed, 207 insertions(+)
create mode 100644 drivers/irqchip/irq-brcmstb-l2.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d770f7406631..bbb746e35500 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,12 @@ config ARM_VIC_NR
The maximum number of VICs available in the system, for
power management.
+config BRCMSTB_L2_IRQ
+ bool
+ depends on ARM
+ select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
+
config DW_APB_ICTL
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index f180f8d5fb7b..62a13e5ef98f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
new file mode 100644
index ..336f0ae5591a
--- /dev/null
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -0,0 +1,200 @@
+/*
+ * Generic Broadcom Set Top Box Level 2 Interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "irqchip.h"
+
+/* Register offsets in the L2 interrupt controller */
+#define CPU_STATUS 0x00
+#define CPU_SET0x04
+#define CPU_CLEAR 0x08
+#define CPU_MASK_STATUS0x0c
+#define CPU_MASK_SET 0x10
+#define CPU_MASK_CLEAR 0x14
+
+/* L2 intc private data structure */
+struct brcmstb_l2_intc_data {
+ int parent_irq;
+ void __iomem *base;
+ struct irq_domain *domain;
+ bool can_wake;
+ u32 saved_mask; /* for suspend/resume */
+};
+
+static void brcmstb_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
+{
+ struct brcmstb_l2_intc_data *b = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_get_chip(irq);
+ u32 status;
+
+ chained_irq_enter(chip, desc);
+
+ status = __raw_readl(b->base + CPU_STATUS) &
+ ~(__raw_readl(b->base + CPU_MASK_STATUS));
+
+ if (status == 0) {
+ do_bad_IRQ(irq, desc);
+ goto out;
+ }
+
+ do {
+ irq = ffs(status) - 1;
+ /* ack at our level */
+ __raw_writel(1 << irq, b->base + CPU_CLEAR);
+ status &= ~(1 << irq);
+ generic_handle_irq(irq_find_mapping(b->domain, irq));
+ } while (status);
+out:
+ chained_irq_exit(chip, desc);
+}
+
+static void brcmstb_l2_intc_suspend(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct brcmstb_l2_intc_data *b = gc->private;
+
+ irq_gc_lock(gc);
+ /* Save the current mask */
+ b->saved_mask = __raw_readl(b->base + CPU_MASK_STATUS);
+
+ if (b->can_wake) {
+ /* Program the wakeup mask */
+ __raw_writel(~gc->wake_active, b->base + CPU_MASK_SET);
+ __raw_writel(gc->wake_active, b->base + CPU_MASK_CLEAR);
+ }
+ irq_gc_unlock(gc);
+}
+
+static void brcmstb_l2_intc_resume(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct brcmstb_l2_intc_data *b = gc->private;
+
+ irq_gc_lock(gc);
+ /* Clear unmasked non-wakeup interrupts */
+ __raw_writel(~b->saved_mask & ~gc->wake_active, b->base + CPU_CLEAR);
+
+ /* Restore the saved mask */
+ __raw_writel(b->saved_mask, b->base + CPU_MASK_SET);
+ __raw_writel(~b->saved_mask, b->base + CPU_MASK_CLEAR);
+ irq_gc_unlock(gc);
+}
+
+int __init
[PATCH 2/2] Documentation: add Broadcom STB Level-2 interrupt controller binding
This patch adds the Device Tree binding document for the Broadcom
Set-top-box Level 2 interrupt controller hardware.
Signed-off-by: Brian Norris
Signed-off-by: Florian Fainelli
---
.../bindings/interrupt-controller/brcm,l2-intc.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
new file mode 100644
index ..448273a30a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
@@ -0,0 +1,29 @@
+Broadcom Generic Level 2 Interrupt Controller
+
+Required properties:
+
+- compatible: should be "brcm,l2-intc"
+- reg: specifies the base physical address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. Should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+ this controller is cacaded from
+- interrupts: specifies the interrupt line in the interrupt-parent irq space
+ to be used for cascading
+
+Optional properties:
+
+- brcm,irq-can-wake: If present, this means the L2 controller can be used as a
+ wakeup source for system suspend/resume.
+
+Example:
+
+hif_intr2_intc: interrupt-controller@f0441000 {
+ compatible = "brcm,l2-intc";
+ reg = <0xf0441000 0x30>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0x0 0x20 0x0>;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] irqchip: Broadcom Set Top Box Level-2 interrupt controller
Hi Thomas, This patch set adds an irqchip driver for the Broadcom Set Top Box Level-2 interrupt controller hardware, as well as a corresponding Device Tree binding document. Thanks! Florian Fainelli (2): irqchip: add Broadcom Set Top Box Level-2 interrupt controller Documentation: add Broadcom STB Level-2 interrupt controller binding .../bindings/interrupt-controller/brcm,l2-intc.txt | 29 +++ drivers/irqchip/Kconfig| 6 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-brcmstb-l2.c | 231 + 4 files changed, 267 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt create mode 100644 drivers/irqchip/irq-brcmstb-l2.c -- 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: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()
Am 2014-05-17 19:21, schrieb Antti Palosaari: > On 05/17/2014 07:05 PM, Martin Kepplinger wrote: >> don't reinvent dev_dbg(). remove dprintk() in as102_drv.c. >> use the common kernel coding style. >> >> Signed-off-by: Martin Kepplinger > > Reviewed-by: Antti Palosaari > >> --- >> this applies to next-20140516. any more suggestions? >> more cleanup can be done when dprintk() is completely gone. > > Do you have the device? I am a bit reluctant patching that driver > without any testing as it has happened too many times something has gone > totally broken. I don't have the device and will, at most, change such style issues. > > IIRC Devin said it is in staging because of style issues and nothing > more. Is that correct? I haven't heard anything. A TODO file would help. > > regards > Antti > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 9/9] I2C/ACPI: Add CONFIG_I2C_ACPI config
On Tue, Apr 29, 2014 at 11:16:09AM +0300, Mika Westerberg wrote:
> On Mon, Apr 28, 2014 at 10:27:48PM +0800, Lan Tianyu wrote:
> > This patch is to add CONFIG_I2C_ACPI. Current there is a race between
> > removing I2C ACPI operation region and ACPI AML code accessing.
> > So make i2c core built-in if CONFIG_I2C_ACPI is set.
> >
> > Signed-off-by: Lan Tianyu
> > ---
> > drivers/i2c/Kconfig | 17 -
> > drivers/i2c/Makefile | 2 +-
> > include/linux/i2c.h | 2 +-
> > 3 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> > index 7b7ea32..c670d49 100644
> > --- a/drivers/i2c/Kconfig
> > +++ b/drivers/i2c/Kconfig
> > @@ -2,7 +2,9 @@
> > # I2C subsystem configuration
> > #
> >
> > -menuconfig I2C
> > +menu "I2C support"
> > +
> > +config I2C
> > tristate "I2C support"
> > select RT_MUTEXES
> > ---help---
> > @@ -21,6 +23,17 @@ menuconfig I2C
> > This I2C support can also be built as a module. If so, the module
> > will be called i2c-core.
> >
> > +config I2C_ACPI
> > + bool "I2C ACPI support"
> > + select I2C
> > + depends on ACPI
> > + default y
> > + help
> > + Say Y here if you want to enable I2C ACPI function. ACPI table
> > + provides I2C slave devices' information to enumerate these devices.
> > + This option also allows ACPI AML code to access I2C slave devices
> > + via I2C ACPI operation region to fulfill ACPI method.
>
> I would prefer something like:
>
> Say Y here if you want to enable ACPI I2C support. This includes support
> for automatic enumeration of I2C slave devices and support for ACPI I2C
> Operation Regions. Operation Regions allow firmware (BIOS) code to
> access I2C slave devices, such as smart batteries through an I2C host
> controller driver.
>
> But it is really up to you so,
>
> Reviewed-by: Mika Westerberg
How does this fit into the context of
55e71edb81b2b45273e7b284cce13ff24bde846f ("i2c: move ACPI helpers into
the core")?
signature.asc
Description: Digital signature
[PATCH 3/3] staging: rtl8712: fix unnecessary line continuations
This commit fixes the following checkpatch warning:
rtl8712/rtl871x_security.c
- 1178: WARNING: Avoid unnecessary line continuations
Signed-off-by: Marcus Farkas
---
drivers/staging/rtl8712/rtl871x_security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 1f2e197..0912f52 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -1178,7 +1178,7 @@ u32 r8712_aes_encrypt(struct _adapter *padapter, u8
*pxmitframe)
prwskeylen = 16;
for (curfragnum = 0; curfragnum < pattrib->nr_frags;
curfragnum++) {
- if ((curfragnum + 1) == pattrib->nr_frags) {\
+ if ((curfragnum + 1) == pattrib->nr_frags) {
length = pattrib->last_txcmdsz -
pattrib->hdrlen -
pattrib->iv_len -
--
1.9.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/
[PATCH 2/3] staging: rtl8712: fix unnecessary parentheses
This commit fixes the following checkpatch warnings:
rtl8712/rtl871x_security.c
- 1167: WARNING: Unnecessary parentheses - maybe == should be = ?
- 1374: WARNING: Unnecessary parentheses - maybe == should be = ?
Signed-off-by: Marcus Farkas
---
drivers/staging/rtl8712/rtl871x_security.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index b053a4d..1f2e197 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -1167,7 +1167,7 @@ u32 r8712_aes_encrypt(struct _adapter *padapter, u8
*pxmitframe)
return _FAIL;
pframe = ((struct xmit_frame *)pxmitframe)->buf_addr + TXDESC_OFFSET;
/* 4 start to encrypt each fragment */
- if ((pattrib->encrypt == _AES_)) {
+ if (pattrib->encrypt == _AES_) {
if (pattrib->psta)
stainfo = pattrib->psta;
else
@@ -1374,7 +1374,7 @@ u32 r8712_aes_decrypt(struct _adapter *padapter, u8
*precvframe)
pframe = (unsigned char *)((union recv_frame *)precvframe)->
u.hdr.rx_data;
/* 4 start to encrypt each fragment */
- if ((prxattrib->encrypt == _AES_)) {
+ if (prxattrib->encrypt == _AES_) {
stainfo = r8712_get_stainfo(>stapriv,
>ta[0]);
if (stainfo != NULL) {
--
1.9.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/
[PATCH 1/3] staging: rtl8712: fix missing blank lines after declarations
This commit fixes the following checkpatch warnings:
rtl8712/rtl871x_security.c
- 275: WARNING: Missing a blank line after declarations
- 768: WARNING: Missing a blank line after declarations
- 801: WARNING: Missing a blank line after declarations
Signed-off-by: Marcus Farkas
---
drivers/staging/rtl8712/rtl871x_security.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/rtl8712/rtl871x_security.c
b/drivers/staging/rtl8712/rtl871x_security.c
index 5ffc489..b053a4d 100644
--- a/drivers/staging/rtl8712/rtl871x_security.c
+++ b/drivers/staging/rtl8712/rtl871x_security.c
@@ -272,6 +272,7 @@ static void secmicputuint32(u8 *p, u32 val)
/* Convert from Us4Byte32 to Byte[] in a portable way */
{
long i;
+
for (i = 0; i < 4; i++) {
*p++ = (u8) (val & 0xff);
val >>= 8;
@@ -765,6 +766,7 @@ static void xor_128(u8 *a, u8 *b, u8 *out)
static void xor_32(u8 *a, u8 *b, u8 *out)
{
sint i;
+
for (i = 0; i < 4; i++)
out[i] = a[i] ^ b[i];
}
@@ -798,6 +800,7 @@ static void next_key(u8 *key, sint round)
static void byte_sub(u8 *in, u8 *out)
{
sint i;
+
for (i = 0; i < 16; i++)
out[i] = sbox(in[i]);
}
--
1.9.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: [Intel-gfx] 3.15-rc5: Regression in i915 driver?
3.15-rc2 seems to be good, 3.15-rc5 seems to be bad. Bisecting this the next days. Am 12.05.2014 18:54 schrieb Daniel Vetter : > > On Mon, May 12, 2014 at 10:09:54AM +0300, Jani Nikula wrote: > > On Sun, 11 May 2014, Daniel Vetter wrote: > > > On Sun, May 11, 2014 at 11:02 AM, Dave Airlie wrote: > > >> On 11 May 2014 18:28, Thomas Meyer wrote: > > >>> Hi, > > >>> > > >>> 3.14.3 works as expected. > > >>> 3.15-rc5 shows a strange behaviour: When resuming from ram the X server > > >>> seems to be disfunctional. > > >>> > > >>> I see this WARNING in the kernel log before suspend to ram in the early > > >>> boot process: > > > > > > Doesn't ring a bell really. > > > - Is there anything in dmesg after resume? > > > - How exactly does X misbehave? Is fbcon still working? Does X > > > behaviour get restored if you restart X? > > > - Can you please try to bisect this issue? Note that the backlight > > > issue might be unrelated to the issues with X misbehaving after > > > resume. You might need to do a bisect for both if the symptoms don't > > > agree. > > > > I agree the WARNING from i965_enable_backlight() is unrelated. Focus on > > the other symptoms first. > > The backlight backtrace seems to be a genuine new bug. Bisecting it would > be highly appreciated. Bisecting on the other issue and appending the > result to the bug Chris quoated should also really be useful - atm we > don't have any reported who can reproduce this clearly enough to do a > bisect. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [PATCH] PM / OPP: discard duplicate OPP additions
Hi! > And both these doesn't happen in this case. OPP tables can be used > by any other framework and is more or less a core thing.. > > Now, with this discussion I have another idea here.. > > Why don't we build these tables automatically on boot from some core > code, rather than asking drivers to do it ? That will get rid of duplication > from all drivers and would also reduce confusion Yes please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ntfs: Cleanup string initializations (char[] instead of char *)
Hi,
NAK.
As Al Viro said in reply to one of your other patches, if you look at the
assembler output you will see that the 'char te[] = "string"' generates
dreadful code whilst the 'char *te = "string"' generates much better code thus
if anything we should change all occurrences of 'char (.*)\[\] =' to "char *\1"
instead...
If you think about it logically it actually makes sense, too. In the 'char
te[] = "string"' case we are telling the compiler to take a constant string
"string" which will be stored both in the binary and once loaded in memory,
then make a copy of it into the array "te" and that is exactly what the
compiler does (if the string is short enough the compiler actually copies
immediate values instead of storing the string elsewhere but that is still
worse than just pointing to constant memory). Whilst in the 'char *te =
"string"' case we are telling the compiler to take a constant string (as
previous case) and then assign the address of that string to the pointer
variable "te". Thus no copying takes place. Thus one should never use the
'char te[] = "string"' form UNLESS you want to then mess about with the
contents of the string in which case modifying "te[]" will work as it is a
local copy but modifying "*te" will cause a crash or be ignored depending on
whether you are programming in the kernel or user space because you are trying
to modify a read-only memory segment...
Best regards,
Anton
On 17 May 2014, at 13:25, Manuel Schölling wrote:
> Initializations like 'char *foo = "bar"' will create two variables: a static
> string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
> will allocate only a declare a single variable and will end up in shorter
> assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
>
> Signed-off-by: Manuel Schölling
> ---
> fs/ntfs/inode.c |2 +-
> fs/ntfs/super.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index f47af5e..3975798 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -2368,7 +2368,7 @@ int ntfs_truncate(struct inode *vi)
> ntfs_attr_search_ctx *ctx;
> MFT_RECORD *m;
> ATTR_RECORD *a;
> - const char *te = " Leaving file length out of sync with i_size.";
> + const char te[] = " Leaving file length out of sync with i_size.";
> int err, mp_size, size_change, alloc_change;
> u32 attr_len;
>
> diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c
> index 9de2491..eb2c195 100644
> --- a/fs/ntfs/super.c
> +++ b/fs/ntfs/super.c
> @@ -676,7 +676,7 @@ not_ntfs:
> static struct buffer_head *read_ntfs_boot_sector(struct super_block *sb,
> const int silent)
> {
> - const char *read_err_str = "Unable to read %s boot sector.";
> + const char read_err_str[] = "Unable to read %s boot sector.";
> struct buffer_head *bh_primary, *bh_backup;
> sector_t nr_blocks = NTFS_SB(sb)->nr_blocks;
>
> --
> 1.7.10.4
--
Anton Altaparmakov (replace at with @)
University of Cambridge Information Services, Roger Needham Building
7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 0/9] 3.4.91-stable review
On Sat, May 17, 2014 at 08:44:45AM -0700, Guenter Roeck wrote: > On 05/16/2014 03:55 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.4.91 release. > >There are 9 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Sun May 18 22:54:50 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 134 pass: 109 skipped: 18 fail: 7 > > Qemu tests all passed. > > There are two new build failures, powerpc:ppc64e_defconfig and > powerpc:chroma_defconfig. > Those are not due to source code changes, but due to added builds. > Failures are seen if the images are built with binutils 2.24, and are caused > by a > changed assembler ABI. A patch to fix the problem has been submitted but is > not yet > upstream. > > Detailed results are available at http://server.roeck-us.net:8010/builders. > powerpc builds with binutils 2.24 are shown as 'powerpc_24' architecture. Thanks for testing and letting me know. 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/
Re: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()
On 05/17/2014 07:05 PM, Martin Kepplinger wrote: don't reinvent dev_dbg(). remove dprintk() in as102_drv.c. use the common kernel coding style. Signed-off-by: Martin Kepplinger Reviewed-by: Antti Palosaari --- this applies to next-20140516. any more suggestions? more cleanup can be done when dprintk() is completely gone. Do you have the device? I am a bit reluctant patching that driver without any testing as it has happened too many times something has gone totally broken. IIRC Devin said it is in staging because of style issues and nothing more. Is that correct? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
