Re: [PATCH] extcon-gpio: add devicetree support.
On 11/01/2013 04:33 PM, NeilBrown wrote: On Fri, 1 Nov 2013 10:16:44 -0700 Mark Rutland wrote: Hi Neil, While I'm not fundamentally opposed to this binding, I have some issues with its current form and would not want to see this version hit mainline. Thanks for the review. On Fri, Nov 01, 2013 at 09:50:05AM +, NeilBrown wrote: As this device is not vendor specific, I haven't included any "vendor," prefixes. For my model I used "regulator-gpio" which takes a similar approach. Signed-off-by: NeilBrown diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt new file mode 100644 index ..2346b61cc620 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt @@ -0,0 +1,26 @@ +* EXTCON detector using GPIO EXTCON is _extremely_ Linux-specific. The binding document needs a description of the class of device it's inteded to describe that does not just refer to Linux internals. I would prefer if we could have a better name for this that was not tied to the Linux driver name. Perhaps "gpio-presence-detector"? Maybe "cable-presence-detector" as in this case the GPIO is just an implementation detail. Which isn't much different from "external-connector" which is where "extcon" comes from... I propose "external-connector" if you don't like "extcon". + +Required Properties: + - compatible: "extcon-gpio" + - gpios: gpio line that detects connector + - interrupts: interrupt generated by that gpio We don't need this. If we need the interrupt a gpio generates, we should ask the gpio controller driver to map the gpio to an interrupt. We have gpiod_to_irq for this in Linux. The reason I did this was that the pre-existing platform_data wants 'irq_flags'. I could have an 'irq-flags' property, but it seems to make more sense to use "interrupts" as that already provides a way to pass irq-flags to a device. On reflection though, I cannot imagine why any extcon-gpio would use anything other than IRQ_TYPE_EDGE_BOTH. Maybe MyungJoo Ham can explain that??? If there is no need for specifying irq-flags per-platform, the "interrupts" property can definitely go. When I tried to add DT support to extcon-pio, I used IRQ_TYPE_EDGE_BOTH. See [1]. A useful fallback for 'label' - if not specified - may be np->name, to match LED functionality. A patch to add 'active low' to the platform data for extcon-gpio is pending in linux-next. It might make sense to extract this flag from the gpio flags and add it as well. Again see [1] for an example how this could be implemented. Guenter [1] https://lkml.org/lkml/2013/8/30/26 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sg: O_EXCL and other lock handling
On 2013年11月03日 02:22, Douglas Gilbert wrote: On 13-11-01 01:16 AM, vaughan wrote: I do not follow the last point but that is not important. For reasons that I listed in a private post I think that my patch presented in this thread is closer to our goals than your patch (2013/6/17/319). Timing is important as well since we are approaching the lk 3.13 merge window. Regressions are what will set us back. Yes, I agree with you. My v2 patch lacks much consideration on release/detach cases, which is a very significant issue we should address along with o_excl bug. Thanks, Vaughan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: ft1000: fixed coding style issues
On Sat, Nov 02, 2013 at 11:18:20PM +0200, Aldo Iljazi wrote: > Aldo Iljazi wrote: > > > Fixed a few coding style issues that checkpatch reported. > > > > Specifically: > > > > 1. line over 80 characters issue on the lines 9 and 10. > > 2. space prohibited before open square bracket '[' issue on the lines > > 31. > > 3. inserted space after comma on lines 32 to 156. > > > > Signed-off-by: Aldo Iljazi This file is easy to review so you may as well fix all the issues. Clean up the license block so it's in the normal format. Put the commas at the end of the line instead of the beginning. 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] HID: roccat: Fixed Coverity CID 141438
Signed-off-by: Stefan Achatz --- drivers/hid/hid-roccat-kovaplus.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/hid/hid-roccat-kovaplus.c b/drivers/hid/hid-roccat-kovaplus.c index 0c8e1ef..9660477 100644 --- a/drivers/hid/hid-roccat-kovaplus.c +++ b/drivers/hid/hid-roccat-kovaplus.c @@ -554,9 +554,13 @@ static void kovaplus_keep_values_up_to_date(struct kovaplus_device *kovaplus, break; case KOVAPLUS_MOUSE_REPORT_BUTTON_TYPE_CPI: kovaplus->actual_cpi = kovaplus_convert_event_cpi(button_report->data1); + break; case KOVAPLUS_MOUSE_REPORT_BUTTON_TYPE_SENSITIVITY: kovaplus->actual_x_sensitivity = button_report->data1; kovaplus->actual_y_sensitivity = button_report->data2; + break; + default: + break; } } -- 1.7.3.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: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 06:06:58PM +0200, Victor Kaplansky wrote: > "Paul E. McKenney" wrote on 10/31/2013 > 05:25:43 PM: > > > I really don't care about "fair" -- I care instead about the kernel > > working reliably. > > Though I don't see how putting a memory barrier without deep understanding > why it is needed helps kernel reliability, I do agree that reliability > is more important than performance. True enough. Of course, the same applies to removing memory barriers. > > And it should also be easy for proponents of removing memory barriers to > > clearly articulate what orderings their code does and does not need. > > I intentionally took a simplified example of circle buffer from > Documentation/circular-buffers.txt. I think both sides agree about > memory ordering requirements in the example. At least I didn't see anyone > argued about them. Hard to say. No one has actually stated them clearly, so how could we know whether or not we agree. > > You are assuming control dependencies that the C language does not > > provide. Now, for all I know right now, there might well be some other > > reason why a full barrier is not required, but the "if" statement cannot > > be that reason. > > > > Please review section 1.10 of the C++11 standard (or the corresponding > > section of the C11 standard, if you prefer). The point is that the > > C/C++11 covers only data dependencies, not control dependencies. > > I feel you made a wrong assumption about my expertise in compilers. I don't > need to reread section 1.10 of the C++11 standard, because I do agree that > potentially compiler can break the code in our case. And I do agree that > a compiler barrier() or some other means (including a change of the > standard) > can be required in future to prevent a compiler from moving memory accesses > around. I was simply reacting to what seemed to me to be your statement that control dependencies affect ordering. They don't. The C/C++ standard does not in any way respect control dependencies. In fact, there are implementations that do not respect control dependencies. But don't take my word for it, actually try it out on a weakly ordered system. Or try out either ppcmem or armmem, which does a full state-space search. Here is the paper: http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/pldi105-sarkar.pdf And here is the web-based tool: http://www.cl.cam.ac.uk/~pes20/ppcmem/ And here is a much faster version that you can run locally: http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html > But "broken" compiler is much wider issue to be deeply discussed in this > thread. I'm pretty sure that kernel have tons of very subtle > code that actually creates locks and memory ordering. Such code > usually just use the "barrier()" approach to tell gcc not to combine > or move memory accesses around it. > > Let's just agree for the sake of this memory barrier discussion that we > *do* need compiler barrier to tell gcc not to combine or move memory > accesses around it. Sometimes barrier() is indeed all you need, other times more is needed. > > Glad we agree on something! > > I'm glad too! > > > Did you miss the following passage in the paragraph you quoted? > > > >"... likewise, your consumer must issue a memory barrier > >instruction after removing an item from the queue and before > >reading from its memory." > > > > That is why DEC Alpha readers need a read-side memory barrier -- it says > > so right there. And as either you or Peter noted earlier in this thread, > > this barrier can be supplied by smp_read_barrier_depends(). > > I did not miss that passage. That passage explains why consumer on Alpha > processor after reading @head is required to execute an additional > smp_read_barrier_depends() before it can *read* from memory pointed by > @tail. And I think that I understand why - because the reader have to wait > till local caches are fully updated and only then it can read data from > the data buffer. > > But on the producer side, after we read @tail, we don't need to wait for > update of local caches before we start *write* data to the buffer, since > the > producer is the only one who write data there! Well, we cannot allow the producer to clobber data while the consumer is reading it out. That said, I do agree that we should get some help from the fact that one element of the array is left empty, so that the producer goes through a full write before clobbering the cell that the consumer just vacated. > > I can sympathize if you are having trouble believing this. After all, > > it took the DEC Alpha architects a full hour to convince me, and that was > > in a face-to-face meeting instead of over email. (Just for the record, > > it took me even longer to convince them that their earlier documentation > > did not clearly indicate the need for these read-side barriers.) But > > regardless of whether or not I sympathize, DEC Alpha is what it is. > > Ag
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote: > On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > > Now the whole crux of the question is if we need barrier A at all, since > > > the STORES issued by the @buf writes are dependent on the ubuf->tail > > > read. > > > > The dependency you are talking about is via the "if" statement? > > Even C/C++11 is not required to respect control dependencies. > > > > This one is a bit annoying. The x86 TSO means that you really only > > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > > barrier, and so on -- but smp_mb() emits a full barrier. > > > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > > before reads, writes before writes, and reads before writes, but not > > writes before reads? Another approach would be to define a per-arch > > barrier for this particular case. > > I suppose we can only introduce new barrier primitives if there's more > than 1 use-case. There probably are others. > > > If the read shows no available space, we simply will not issue those > > > writes -- therefore we could argue we can avoid the memory barrier. > > > > Proving that means iterating through the permitted combinations of > > compilers and architectures... There is always hand-coded assembly > > language, I suppose. > > I'm starting to think that while the C/C++ language spec says they can > wreck the world by doing these silly optimization, real world users will > push back for breaking their existing code. > > I'm fairly sure the GCC people _will_ get shouted at _loudly_ when they > break the kernel by doing crazy shit like that. > > Given its near impossible to write a correct program in C/C++ and > tagging the entire kernel with __atomic is equally not going to happen, > I think we must find a practical solution. > > Either that, or we really need to consider forking the language and > compiler :-( Depends on how much benefit the optimizations provide. If they provide little or no benefit, I am with you, otherwise we will need to bit some bullet or another. Keep in mind that there is a lot of code in the kernel that runs sequentially (e.g., due to being fully protected by locks), and aggressive optimizations for that sort of code are harmless. Can't say I know the answer at the moment, though. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" wrote on 10/31/2013
> 08:16:02 AM:
>
> > > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > > around
> > > @head read.
>
> Just to be sure, that we are talking about the same code - I was
> considering
> ACCESS_ONCE() around @tail in point AAA in the following example from
> Documentation/circular-buffers.txt for CONSUMER:
>
> unsigned long head = ACCESS_ONCE(buffer->head);
> unsigned long tail = buffer->tail; /* AAA */
>
> if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> /* read index before reading contents at that index */
> smp_read_barrier_depends();
>
> /* extract one item from the buffer */
> struct item *item = buffer[tail];
>
> consume_item(item);
>
> smp_mb(); /* finish reading descriptor before incrementing
> tail */
>
> buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */
> }
Hmmm... I believe that we need to go back to the original code in
Documentation/circular-buffers.txt. I do so at the bottom of this email.
> > If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> > its rights to combine adjacent operations and also to invent loads and
> > stores, for example, in cases of register pressure.
>
> Right. And I was completely aware about these possible transformations when
> said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
> even
> completely dismissed reads of @tail in consumer code, are not a problem at
> all,
> since @tail is written exclusively by CONSUMER side.
I believe that the lack of ACCESS_ONCE() around the consumer's store
to buffer->tail is at least a documentation problem. In the original
consumer code, it is trapped between an smp_mb() and a spin_unlock(),
but it is updating something that is read without synchronization by
some other thread.
> > It is also within
> > its rights to do piece-at-a-time loads and stores, which might sound
> > unlikely, but which can actually has happened when the compiler figures
> > out exactly what is to be stored at compile time, especially on hardware
> > that only allows small immediate values.
>
> As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
> doesn't prevent in any way an imaginary super-optimizing compiler
> from moving around the store to @tail (which appears in the code at point
> BBB).
>
> It is why ACCESS_ONCE at point AAA is completely redundant.
Agreed, it is under the lock that guards modifications, so AAA does not
need ACCESS_ONCE().
OK, here is the producer from Documentation/circular-buffers.txt, with
some comments added:
spin_lock(&producer_lock);
unsigned long head = buffer->head;
unsigned long tail = ACCESS_ONCE(buffer->tail); /* PT */
if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
/* insert one item into the buffer */
struct item *item = buffer[head];
produce_item(item); /* PD */
smp_wmb(); /* commit the item before incrementing the head */
buffer->head = (head + 1) & (buffer->size - 1); /* PH */
/* wake_up() will make sure that the head is committed before
* waking anyone up */
wake_up(consumer);
}
spin_unlock(&producer_lock);
And here is the consumer, also from Documentation/circular-buffers.txt:
spin_lock(&consumer_lock);
unsigned long head = ACCESS_ONCE(buffer->head); /* CH */
unsigned long tail = buffer->tail;
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */
smp_read_barrier_depends();
/* extract one item from the buffer */
struct item *item = buffer[tail]; /* CD */
consume_item(item);
smp_mb(); /* finish reading descriptor before incrementing tail
*/
buffer->tail = (tail + 1) & (buffer->size - 1); /* CT */
}
spin_unlock(&consumer_lock);
Here are the ordering requirements as I see them:
1. The producer is not allowed to clobber a location that the
consumer is in the process of reading from.
2. The consumer is not allowed to read from a location that the
producer has not yet completed writing to.
#1 is helped out by the fact that there is always an empty element in
the array, so that the producer will need to produce twice in a row
to catch up to where the consumer is currently consuming. #2 has no
such benefit: The consumer can consume an item that has just now been
produced.
#1 requires that CD is ordered before CT in a way that pairs with the
ordering of PT and PD. There is of course no effective ordering between
PT and PD within a giv
Re: perf events ring buffer memory barrier on powerpc
[ Adding David Howells, Lech Fomicki, and Mark Batty on CC for their
thoughts given previous discussions. ]
On Sat, Nov 02, 2013 at 09:36:18AM -0700, Paul E. McKenney wrote:
> On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
> > "Paul E. McKenney" wrote on 10/31/2013
> > 08:16:02 AM:
> >
> > > > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > > > around
> > > > @head read.
> >
> > Just to be sure, that we are talking about the same code - I was
> > considering
> > ACCESS_ONCE() around @tail in point AAA in the following example from
> > Documentation/circular-buffers.txt for CONSUMER:
> >
> > unsigned long head = ACCESS_ONCE(buffer->head);
> > unsigned long tail = buffer->tail; /* AAA */
> >
> > if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> > /* read index before reading contents at that index */
> > smp_read_barrier_depends();
> >
> > /* extract one item from the buffer */
> > struct item *item = buffer[tail];
> >
> > consume_item(item);
> >
> > smp_mb(); /* finish reading descriptor before incrementing
> > tail */
> >
> > buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */
> > }
>
> Hmmm... I believe that we need to go back to the original code in
> Documentation/circular-buffers.txt. I do so at the bottom of this email.
>
> > > If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> > > its rights to combine adjacent operations and also to invent loads and
> > > stores, for example, in cases of register pressure.
> >
> > Right. And I was completely aware about these possible transformations when
> > said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
> > even
> > completely dismissed reads of @tail in consumer code, are not a problem at
> > all,
> > since @tail is written exclusively by CONSUMER side.
>
> I believe that the lack of ACCESS_ONCE() around the consumer's store
> to buffer->tail is at least a documentation problem. In the original
> consumer code, it is trapped between an smp_mb() and a spin_unlock(),
> but it is updating something that is read without synchronization by
> some other thread.
>
> > > It is also within
> > > its rights to do piece-at-a-time loads and stores, which might sound
> > > unlikely, but which can actually has happened when the compiler figures
> > > out exactly what is to be stored at compile time, especially on hardware
> > > that only allows small immediate values.
> >
> > As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
> > doesn't prevent in any way an imaginary super-optimizing compiler
> > from moving around the store to @tail (which appears in the code at point
> > BBB).
> >
> > It is why ACCESS_ONCE at point AAA is completely redundant.
>
> Agreed, it is under the lock that guards modifications, so AAA does not
> need ACCESS_ONCE().
>
> OK, here is the producer from Documentation/circular-buffers.txt, with
> some comments added:
>
> spin_lock(&producer_lock);
>
> unsigned long head = buffer->head;
The above is updated only under producer_lock, which we hold, so no
ACCESS_ONCE() is needed for buffer->head.
> unsigned long tail = ACCESS_ONCE(buffer->tail); /* PT */
>
> if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
> /* insert one item into the buffer */
> struct item *item = buffer[head];
>
> produce_item(item); /* PD */
>
> smp_wmb(); /* commit the item before incrementing the head */
>
> buffer->head = (head + 1) & (buffer->size - 1); /* PH */
The above needs to be something like:
ACCESS_ONCE(buffer->head) = (head + 1) & (buffer->size - 1);
This is because we are writing to a shared variable that might be being
read concurrently.
> /* wake_up() will make sure that the head is committed before
>* waking anyone up */
> wake_up(consumer);
> }
>
> spin_unlock(&producer_lock);
>
> And here is the consumer, also from Documentation/circular-buffers.txt:
>
> spin_lock(&consumer_lock);
>
> unsigned long head = ACCESS_ONCE(buffer->head); /* CH */
> unsigned long tail = buffer->tail;
The above is updated only under consumer_lock, which we hold, so no
ACCESS_ONCE() is needed for buffer->tail.
>
> if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> /* read index before reading contents at that index */
> smp_read_barrier_depends();
>
> /* extract one item from the buffer */
> struct item *item = buffer[tail]; /* CD */
>
> consume_item(item);
>
> smp_mb(); /* finish reading descriptor before incrementing tail
> */
>
> buffer->tail = (tail + 1) & (buffer->size - 1); /* CT */
And here, f
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote:
> > > This is a completely untenable position.
> >
> > Indeed it is!
> >
> > C/C++ never was intended to be used for parallel programming,
>
> And yet pretty much all kernels ever written for SMP systems are written
> in it; what drugs are those people smoking?
There was a time when I wished that the C/C++ standards people had added
concurrency to the language 30 years ago, but I eventually realized that
any attempt at that time would have been totally broken.
> Furthermore there's a gazillion parallel userspace programs.
Most of which have very unaggressive concurrency designs.
> > and this is
> > but one of the problems that can arise when we nevertheless use it for
> > parallel programming. As compilers get smarter (for some definition of
> > "smarter") and as more systems have special-purpose hardware (such as
> > vector units) that are visible to the compiler, we can expect more of
> > this kind of trouble.
> >
> > This was one of many reasons that I decided to help with the C/C++11
> > effort, whatever anyone might think about the results.
>
> Well, I applaud your efforts, but given the results I think the C/C++
> people are all completely insane.
If it makes you feel any better, they have the same opinion of all of
us who use C/C++ for concurrency given that the standard provides no
guarantee.
> > > How do the C/C++ people propose to deal with this?
> >
> > By marking "ptr" as atomic, thus telling the compiler not to mess with it.
> > And thus requiring that all accesses to it be decorated, which in the
> > case of RCU could be buried in the RCU accessors.
>
> This seems contradictory; marking it atomic would look like:
>
> struct foo {
> unsigned long value;
> __atomic void *ptr;
> unsigned long value1;
> };
>
> Clearly we cannot hide this definition in accessors, because then
> accesses to value* won't see the annotation.
#define __rcu __atomic
Though there are probably placement restrictions for __atomic that
current use of __rcu doesn't pay attention to.
> That said; mandating we mark all 'shared' data with __atomic is
> completely untenable and is not backwards compatible.
>
> To be safe we must assume all data shared unless indicated otherwise.
Something similar to the compiler directives forcing twos-complement
interpretation of signed overflow could be attractive. Not sure what
it would do to code generation, though.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 05:11:29PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > > void kbuf_write(int sz, void *buf)
> > > {
> > > u64 tail = ACCESS_ONCE(ubuf->tail); /* last location userspace read */
> > > u64 offset = kbuf->head; /* we already know where we last wrote */
> > > u64 head = offset + sz;
> > >
> > > if (!space(tail, offset, head)) {
> > > /* discard @buf */
> > > return;
> > > }
> > >
> > > /*
> > >* Ensure that if we see the userspace tail (ubuf->tail) such
> > >* that there is space to write @buf without overwriting data
> > >* userspace hasn't seen yet, we won't in fact store data before
> > >* that read completes.
> > >*/
> > >
> > > smp_mb(); /* A, matches with D */
> > >
> > > write(kbuf->data + offset, buf, sz);
> > > kbuf->head = head % kbuf->size;
> > >
> > > /*
> > >* Ensure that we write all the @buf data before we update the
> > >* userspace visible ubuf->head pointer.
> > >*/
> > > smp_wmb(); /* B, matches with C */
> > >
> > > ubuf->head = kbuf->head;
> > > }
>
> > > Now the whole crux of the question is if we need barrier A at all, since
> > > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > > read.
> >
> > The dependency you are talking about is via the "if" statement?
> > Even C/C++11 is not required to respect control dependencies.
>
> But surely we must be able to make it so; otherwise you'd never be able
> to write:
>
> void *ptr = obj1;
>
> void foo(void)
> {
>
> /* create obj2, obj3 */
>
> smp_wmb(); /* ensure the objs are complete */
>
> /* expose either obj2 or obj3 */
> if (x)
> ptr = obj2;
> else
> ptr = obj3;
OK, the smp_wmb() orders the creation and the exposing. But the
compiler can do this:
ptr = obj3;
if (x)
ptr = obj2;
And that could momentarily expose obj3 to readers, and these readers
might be fatally disappointed by the free() below. If you instead said:
if (x)
ACCESS_ONCE(ptr) = obj2;
else
ACCESS_ONCE(ptr) = obj3;
then the general consensus appears to be that the compiler would not
be permitted to carry out the above optimization. Since you have
the smp_wmb(), readers that are properly ordered (e.g., smp_rmb() or
rcu_dereference()) would be prevented from seeing pre-initialization
state.
> /* free the unused one */
> if (x)
> free(obj3);
> else
> free(obj2);
> }
>
> Earlier you said that 'volatile' or '__atomic' avoids speculative
> writes; so would:
>
> volatile void *ptr = obj1;
>
> Make the compiler respect control dependencies again? If so, could we
> somehow mark that !space() condition volatile?
The compiler should, but the CPU is still free to ignore the control
dependencies in the general case.
We might be able to rely on weakly ordered hardware refraining
from speculating stores, but not sure that this applies across all
architectures of interest. We definitely can -not- rely on weakly
ordered hardware refraining from speculating loads.
> Currently the above would be considered a valid pattern. But you're
> saying its not because the compiler is free to expose both obj2 and obj3
> (for however short a time) and thus the free of the 'unused' object is
> incorrect and can cause use-after-free.
Yes, it is definitely unsafe and invalid in absence of ACCESS_ONCE().
> In fact; how can we be sure that:
>
> void *ptr = NULL;
>
> void bar(void)
> {
> void *obj = malloc(...);
>
> /* fill obj */
>
> if (!err)
> rcu_assign_pointer(ptr, obj);
> else
> free(obj);
> }
>
> Does not get 'optimized' into:
>
> void bar(void)
> {
> void *obj = malloc(...);
> void *old_ptr = ptr;
>
> /* fill obj */
>
> rcu_assign_pointer(ptr, obj);
> if (err) { /* because runtime profile data says this is unlikely */
> ptr = old_ptr;
> free(obj);
> }
> }
In this particular case, the barrier() implied by the smp_wmb() in
rcu_assign_pointer() will prevent this "optimization". However, other
"optimizations" are the reason why I am working to introduce ACCESS_ONCE()
into rcu_assign_pointer.
> We _MUST_ be able to rely on control flow, otherwise me might as well
> all go back to writing kernels in asm.
It isn't -that- bad! ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 04:25:42PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" wrote on 10/31/2013
> 08:40:15 AM:
>
> > > void ubuf_read(void)
> > > {
> > >u64 head, tail;
> > >
> > >tail = ACCESS_ONCE(ubuf->tail);
> > >head = ACCESS_ONCE(ubuf->head);
> > >
> > >/*
> > > * Ensure we read the buffer boundaries before the actual buffer
> > > * data...
> > > */
> > >smp_rmb(); /* C, matches with B */
> > >
> > >while (tail != head) {
> > > obj = ubuf->data + tail;
> > > /* process obj */
> > > tail += obj->size;
> > > tail %= ubuf->size;
> > >}
> > >
> > >/*
> > > * Ensure all data reads are complete before we issue the
> > > * ubuf->tail update; once that update hits, kbuf_write() can
> > > * observe and overwrite data.
> > > */
> > >smp_mb(); /* D, matches with A */
> > >
> > >ubuf->tail = tail;
> > > }
>
> > > Could we replace A and C with an smp_read_barrier_depends()?
> >
> > C, yes, given that you have ACCESS_ONCE() on the fetch from ->tail
> > and that the value fetch from ->tail feeds into the address used for
> > the "obj =" assignment.
>
> No! You must to have a full smp_rmb() at C. The race on the reader side
> is not between fetch of @tail and read from address pointed by @tail.
> The real race here is between a fetch of @head and read of obj from
> memory pointed by @tail.
I believe you are in fact correct, good catch.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf events ring buffer memory barrier on powerpc
On Fri, Nov 01, 2013 at 05:18:19PM +0100, Peter Zijlstra wrote: > On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote: > > The dependency you are talking about is via the "if" statement? > > Even C/C++11 is not required to respect control dependencies. > > > > This one is a bit annoying. The x86 TSO means that you really only > > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker > > barrier, and so on -- but smp_mb() emits a full barrier. > > > > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered > > before reads, writes before writes, and reads before writes, but not > > writes before reads? Another approach would be to define a per-arch > > barrier for this particular case. > > Supposing a sane language where we can rely on control flow; would that > change the story? > > I'm afraid I'm now terminally confused between actual proper memory > model issues and fucked compilers. Power and ARM won't speculate stores, but they will happily speculate loads. Not sure about Itanium, perhaps Tony knows. And yes, reordering by the compilers and CPUs does sometimes seem a bit intertwined. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REVIEW][PATCH 1/4] vfs: Don't allow overwriting mounts in the current mount namespace
On Tue, Oct 15, 2013 at 01:16:48PM -0700, Eric W. Biederman wrote:
> int vfs_rmdir(struct inode *dir, struct dentry *dentry)
> {
> int error = may_delete(dir, dentry, 1);
> @@ -3622,6 +3636,9 @@ retry:
> error = -ENOENT;
> goto exit3;
> }
> + error = -EBUSY;
> + if (covered(nd.path.mnt, dentry))
> + goto exit3;
Ugh... And it's not racy because of...? IOW, what's to keep the return
value of covered() from getting obsolete just as it's being calculated,
let alone returned?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ceph: Write through cache support based on fscache
Hi Milosz,
Thanks for your comments.
We think SSD and fscache based write cache is definitely useful for
Ceph, since to some extent, write amplification slow down the write
performance of Ceph. Lustre has already introduced SSD based write
cache. SSD can be treated as an outer big cache for page cache. It can
reduce the requirement of network and OSD bandwidth. Write back cache is
more performance useful, but more complicated to implement to meet the
consistence and other correctness semantic demands of Ceph and POSIX,
such as sync(). Write through cache is much simpler, which will not
bother too much. So our goal is to implement both, we plan to submit it
as a blueprint at the incoming CDS.
It would be great if you could help review and give comments on our
codes during the development. Again, thanks very much.
Cheers,
Li Wang
On 11/02/2013 12:51 AM, Milosz Tanski wrote:
Li,
I think it would be fantastic to see a write cache. In many workloads
you ended up writing out a file and then turning around and reading it
right back in on the same node.
There's a few things that I would like to see. First, an mount option
to turn on/off write through caching. There are some workloads / user
hardware configurations that will not benefit from this (it might be a
net negative). Also, I think it's nice to have a fallback to disable
it it's miss behaving.
Second, for correctness I think you should only do write-through
caching if you have an exclusive cap on the file. Currently as the
code is written it only reads from fscache if the file is open in read
only mode and has the cache cap. This would also have to change.
Thanks,
- Milosz
P.S: Sorry for the second message Li, I fail at email and forgot to reply-all.
On Fri, Nov 1, 2013 at 9:49 AM, Li Wang wrote:
Currently, fscache only plays as read cache for ceph, this patch
enables it plays as the write through cache as well.
A small trick to be discussed: if the writing to OSD finishes before
the writing to fscache, the fscache writing is cancelled to avoid
slow down the writepages() process.
Signed-off-by: Min Chen
Signed-off-by: Li Wang
Signed-off-by: Yunchuan Wen
---
fs/ceph/addr.c | 10 +++---
fs/ceph/cache.c | 29 +
fs/ceph/cache.h | 13 +
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 6df8bd4..2465c49 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -506,7 +506,7 @@ static int writepage_nounlock(struct page *page, struct
writeback_control *wbc)
CONGESTION_ON_THRESH(fsc->mount_options->congestion_kb))
set_bdi_congested(&fsc->backing_dev_info, BLK_RW_ASYNC);
- ceph_readpage_to_fscache(inode, page);
+ ceph_writepage_to_fscache(inode, page);
set_page_writeback(page);
err = ceph_osdc_writepages(osdc, ceph_vino(inode),
@@ -634,6 +634,7 @@ static void writepages_finish(struct ceph_osd_request *req,
if ((issued & (CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO)) == 0)
generic_error_remove_page(inode->i_mapping, page);
+ ceph_maybe_release_fscache_page(inode, page);
unlock_page(page);
}
dout("%p wrote+cleaned %d pages\n", inode, wrote);
@@ -746,7 +747,7 @@ retry:
while (!done && index <= end) {
int num_ops = do_sync ? 2 : 1;
- unsigned i;
+ unsigned i, j;
int first;
pgoff_t next;
int pvec_pages, locked_pages;
@@ -894,7 +895,6 @@ get_more_pages:
if (!locked_pages)
goto release_pvec_pages;
if (i) {
- int j;
BUG_ON(!locked_pages || first < 0);
if (pvec_pages && i == pvec_pages &&
@@ -924,6 +924,10 @@ get_more_pages:
osd_req_op_extent_osd_data_pages(req, 0, pages, len, 0,
!!pool, false);
+ for (j = 0; j < locked_pages; j++) {
+ struct page *page = pages[j];
+ ceph_writepage_to_fscache(inode, page);
+ }
pages = NULL; /* request message now owns the pages array */
pool = NULL;
diff --git a/fs/ceph/cache.c b/fs/ceph/cache.c
index 6bfe65e..6f928c4 100644
--- a/fs/ceph/cache.c
+++ b/fs/ceph/cache.c
@@ -320,6 +320,24 @@ void ceph_readpage_to_fscache(struct inode *inode, struct
page *page)
fscache_uncache_page(ci->fscache, page);
}
+void ceph_writepage_to_fscache(struct inode *inode, struct page *page)
+{
+ struct ceph_inode_info *ci = ceph_inode(inode);
+ int ret;
+
+ if (!cache_valid(ci))
+ return;
+
+ if (!PageFsCache(page)) {
+ if (fscache_alloc_page(ci->fscache, page, GFP_KERNEL))
+
[git pull] fixes for 3.12-final
Exportfs fix from bfields. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: J. Bruce Fields (2): vfs: split out vfs_getattr_nosec exportfs: fix 32-bit nfsd handling of 64-bit inode numbers Diffstat: fs/exportfs/expfs.c | 18 -- fs/stat.c | 31 +-- include/linux/fs.h |1 + 3 files changed, 42 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: et131x: drop packet when error occurs in et131x_tx()
Drop packet instead of return NETDEV_TX_BUSY when tx failed.
Signed-off-by: ZHAO Gang
---
move function send_packet's work directly to et131x_tx(), also make
some changes to improve readability.
drivers/staging/et131x/et131x.c | 84 +++--
1 file changed, 22 insertions(+), 62 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index d9446c4..ca3332e 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -3125,55 +3125,6 @@ static int send_packet(struct sk_buff *skb, struct
et131x_adapter *adapter)
return 0;
}
-/* et131x_send_packets - This function is called by the OS to send packets
- * @skb: the packet(s) to send
- * @netdev:device on which to TX the above packet(s)
- *
- * Return 0 in almost all cases; non-zero value in extreme hard failure only
- */
-static int et131x_send_packets(struct sk_buff *skb, struct net_device *netdev)
-{
- int status = 0;
- struct et131x_adapter *adapter = netdev_priv(netdev);
-
- /* Send these packets
-*
-* NOTE: The Linux Tx entry point is only given one packet at a time
-* to Tx, so the PacketCount and it's array used makes no sense here
-*/
-
- /* TCB is not available */
- if (adapter->tx_ring.used >= NUM_TCB) {
- /* NOTE: If there's an error on send, no need to queue the
-* packet under Linux; if we just send an error up to the
-* netif layer, it will resend the skb to us.
-*/
- status = -ENOMEM;
- } else {
- /* We need to see if the link is up; if it's not, make the
-* netif layer think we're good and drop the packet
-*/
- if ((adapter->flags & FMP_ADAPTER_FAIL_SEND_MASK) ||
- !netif_carrier_ok(netdev)) {
- dev_kfree_skb_any(skb);
- skb = NULL;
-
- adapter->net_stats.tx_dropped++;
- } else {
- status = send_packet(skb, adapter);
- if (status != 0 && status != -ENOMEM) {
- /* On any other error, make netif think we're
-* OK and drop the packet
-*/
- dev_kfree_skb_any(skb);
- skb = NULL;
- adapter->net_stats.tx_dropped++;
- }
- }
- }
- return status;
-}
-
/* free_send_packet - Recycle a struct tcb
* @adapter: pointer to our adapter
* @tcb: pointer to struct tcb
@@ -4540,12 +4491,9 @@ static void et131x_multicast(struct net_device *netdev)
/* et131x_tx - The handler to tx a packet on the device
* @skb: data to be Tx'd
* @netdev: device on which data is to be Tx'd
- *
- * Returns 0 on success, errno on failure (as defined in errno.h)
*/
-static int et131x_tx(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t et131x_tx(struct sk_buff *skb, struct net_device *netdev)
{
- int status = 0;
struct et131x_adapter *adapter = netdev_priv(netdev);
/* stop the queue if it's getting full */
@@ -4556,17 +4504,29 @@ static int et131x_tx(struct sk_buff *skb, struct
net_device *netdev)
/* Save the timestamp for the TX timeout watchdog */
netdev->trans_start = jiffies;
- /* Call the device-specific data Tx routine */
- status = et131x_send_packets(skb, netdev);
+ /* TCB is not available */
+ if (adapter->tx_ring.used >= NUM_TCB)
+ goto drop;
- /* Check status and manage the netif queue if necessary */
- if (status != 0) {
- if (status == -ENOMEM)
- status = NETDEV_TX_BUSY;
- else
- status = NETDEV_TX_OK;
+ /* We need to see if the link is up; if it's not, make the
+* netif layer think we're good and drop the packet
+*/
+ if ((adapter->flags & FMP_ADAPTER_FAIL_SEND_MASK) ||
+ !netif_carrier_ok(netdev)) {
+ goto drop;
+ } else {
+ if (!send_packet(skb, adapter))
+ goto out;
+ /* On error (send_packet returns != 0), make netif
+* think we're OK and drop the packet
+*/
}
- return status;
+
+drop:
+ dev_kfree_skb_any(skb);
+ adapter->net_stats.tx_dropped++;
+out:
+ return NETDEV_TX_OK;
}
/* et131x_tx_timeout - Timeout handler
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: et131x: improve code readability
Signed-off-by: ZHAO Gang
---
drivers/staging/et131x/et131x.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index ca3332e..8c2a4a5 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -1822,6 +1822,9 @@ static void et131x_config_rx_dma_regs(struct
et131x_adapter *adapter)
u32 __iomem *base_hi;
u32 __iomem *base_lo;
+ struct fbr_lookup *fbr;
+ fbr = rx_local->fbr[id];
+
if (id == 0) {
num_des = &rx_dma->fbr0_num_des;
full_offset = &rx_dma->fbr0_full_offset;
@@ -1837,12 +1840,10 @@ static void et131x_config_rx_dma_regs(struct
et131x_adapter *adapter)
}
/* Now's the best time to initialize FBR contents */
- fbr_entry =
- (struct fbr_desc *) rx_local->fbr[id]->ring_virtaddr;
- for (entry = 0;
-entry < rx_local->fbr[id]->num_entries; entry++) {
- fbr_entry->addr_hi = rx_local->fbr[id]->bus_high[entry];
- fbr_entry->addr_lo = rx_local->fbr[id]->bus_low[entry];
+ fbr_entry = (struct fbr_desc *)fbr->ring_virtaddr;
+ for (entry = 0; entry < fbr->num_entries; entry++) {
+ fbr_entry->addr_hi = fbr->bus_high[entry];
+ fbr_entry->addr_lo = fbr->bus_low[entry];
fbr_entry->word2 = entry;
fbr_entry++;
}
@@ -1850,19 +1851,16 @@ static void et131x_config_rx_dma_regs(struct
et131x_adapter *adapter)
/* Set the address and parameters of Free buffer ring 1 and 0
* into the 1310's registers
*/
- writel(upper_32_bits(rx_local->fbr[id]->ring_physaddr),
- base_hi);
- writel(lower_32_bits(rx_local->fbr[id]->ring_physaddr),
- base_lo);
- writel(rx_local->fbr[id]->num_entries - 1, num_des);
+ writel(upper_32_bits(fbr->ring_physaddr), base_hi);
+ writel(lower_32_bits(fbr->ring_physaddr), base_lo);
+ writel(fbr->num_entries - 1, num_des);
writel(ET_DMA10_WRAP, full_offset);
/* This variable tracks the free buffer ring 1 full position,
* so it has to match the above.
*/
- rx_local->fbr[id]->local_full = ET_DMA10_WRAP;
- writel(((rx_local->fbr[id]->num_entries *
- LO_MARK_PERCENT_FOR_RX) / 100) - 1,
+ fbr->local_full = ET_DMA10_WRAP;
+ writel((fbr->num_entries * LO_MARK_PERCENT_FOR_RX / 100) - 1,
min_des);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ipc, msg: fix message length check for negative values
On Sat, Nov 2, 2013 at 2:26 PM, Mathias Krause wrote:
> On 64 bit systems the test for negative message sizes is bogus as the
> size, which may be positive when evaluated as a long, will get truncated
> to an int when passed to load_msg().
Quite frankly, wouldn't it be much nicer to just fix "load_msg()" instead?
Using "size_t" also gets rid of the games we play with DATALEN_MSG/SEG.
IOW, something like the attached..
Of course, we *also* should fix ns->msg_ctlmax to make clear you can't
use negative numbers there. No question about that. I think it would
be better to even avoid INT_MAX, because there are memory use concerns
and CPU usage ones too (we generate that list of
smaller-than-page-size fragments).
Hmm?
Linus
include/linux/ipc_namespace.h | 6 +++---
ipc/msgutil.c | 14 +++---
ipc/util.h| 4 ++--
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h
index 19c19a5eee29..f6c82de12541 100644
--- a/include/linux/ipc_namespace.h
+++ b/include/linux/ipc_namespace.h
@@ -34,9 +34,9 @@ struct ipc_namespace {
int sem_ctls[4];
int used_sems;
- int msg_ctlmax;
- int msg_ctlmnb;
- int msg_ctlmni;
+ unsigned int msg_ctlmax;
+ unsigned int msg_ctlmnb;
+ unsigned int msg_ctlmni;
atomic_t msg_bytes;
atomic_t msg_hdrs;
int auto_msgmni;
diff --git a/ipc/msgutil.c b/ipc/msgutil.c
index 491e71f2a1b8..3cd9cb959c74 100644
--- a/ipc/msgutil.c
+++ b/ipc/msgutil.c
@@ -41,15 +41,15 @@ struct msg_msgseg {
/* the next part of the message follows immediately */
};
-#define DATALEN_MSG (int)(PAGE_SIZE-sizeof(struct msg_msg))
-#define DATALEN_SEG (int)(PAGE_SIZE-sizeof(struct msg_msgseg))
+#define DATALEN_MSG (PAGE_SIZE-sizeof(struct msg_msg))
+#define DATALEN_SEG (PAGE_SIZE-sizeof(struct msg_msgseg))
-static struct msg_msg *alloc_msg(int len)
+static struct msg_msg *alloc_msg(size_t len)
{
struct msg_msg *msg;
struct msg_msgseg **pseg;
- int alen;
+ size_t alen;
alen = min(len, DATALEN_MSG);
msg = kmalloc(sizeof(*msg) + alen, GFP_KERNEL);
@@ -80,7 +80,7 @@ out_err:
return NULL;
}
-struct msg_msg *load_msg(const void __user *src, int len)
+struct msg_msg *load_msg(const void __user *src, size_t len)
{
struct msg_msg *msg;
struct msg_msgseg *seg;
@@ -147,9 +147,9 @@ struct msg_msg *copy_msg(struct msg_msg *src, struct msg_msg *dst)
return ERR_PTR(-ENOSYS);
}
#endif
-int store_msg(void __user *dest, struct msg_msg *msg, int len)
+int store_msg(void __user *dest, struct msg_msg *msg, size_t len)
{
- int alen;
+ size_t alen;
struct msg_msgseg *seg;
alen = min(len, DATALEN_MSG);
diff --git a/ipc/util.h b/ipc/util.h
index f2f5036f2eed..59d78aa94987 100644
--- a/ipc/util.h
+++ b/ipc/util.h
@@ -148,9 +148,9 @@ int ipc_parse_version (int *cmd);
#endif
extern void free_msg(struct msg_msg *msg);
-extern struct msg_msg *load_msg(const void __user *src, int len);
+extern struct msg_msg *load_msg(const void __user *src, size_t len);
extern struct msg_msg *copy_msg(struct msg_msg *src, struct msg_msg *dst);
-extern int store_msg(void __user *dest, struct msg_msg *msg, int len);
+extern int store_msg(void __user *dest, struct msg_msg *msg, size_t len);
extern void recompute_msgmni(struct ipc_namespace *);
Re: Correct parameter size for BLKSSZGET ioctl.
On Fri, Nov 01, 2013 at 08:29:26PM -0400, Jason Cipriani wrote: > In blkdiscard in util-linux, at least since version 2.23, the > following code is used to retrieve a device's physical sector size: > > uint64_t secsize; > ioctl(fd, BLKSSZGET, &secsize); > > On my machine (Ubuntu 12.04 -- 3.2.0-55-generic-pae #85-Ubuntu SMP Wed > Oct 2 14:03:15 UTC 2013 i686 i686 i386 GNU/Linux) this yields > incorrect results as it seems a 32-bit int is expected, this causes > subsequent sector alignment calculations in blkdiscard to be > incorrect, which in turn causes blkdiscards trim ioctl's to fail in > certain situations (or even worse, to trim the wrong blocks). BLKSSZGET returns an int. If you look at the sources of util-linux v2.23, you'll see it passes an int to BLKSSZGET in sys-utils/blkdiscard.c lib/blkdev.c E2fsprogs also expects BLKSSZGET to return an int, and if you look at the kernel sources, it very clearly returns an int. The one place it doesn't is in sys-utils/blkdiscard.c, where as you have noted, it is passing in a uint64 to BLKSSZGET. This looks like it's a bug in sys-util/blkdiscard.c. I'll send a proposed patch in the next e-mail message. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memstick: fix unreachable state in h_msb_read_page() in ms_block.c
On Wed, 2013-10-30 at 15:54 +0800, rogera...@realtek.com wrote: > From: Roger Tseng > > In h_msb_read_page() in ms_block.c, flow never reaches case > MSB_RP_RECIVE_STATUS_REG. This causes error when MEMSTICK_INT_ERR is > encountered and status error bits are going to be examined, but the status > will > never be copied back. > > Fix it by transiting to MSB_RP_RECIVE_STATUS_REG right after > MSB_RP_SEND_READ_STATUS_REG. > > Signed-off-by: Roger Tseng > --- > drivers/memstick/core/ms_block.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/memstick/core/ms_block.c > b/drivers/memstick/core/ms_block.c > index 08e7023..9188ef5 100644 > --- a/drivers/memstick/core/ms_block.c > +++ b/drivers/memstick/core/ms_block.c > @@ -401,7 +401,7 @@ again: > sizeof(struct ms_status_register))) > return 0; > > - msb->state = MSB_RP_RECEIVE_OOB_READ; > + msb->state = MSB_RP_RECIVE_STATUS_REG; > return 0; > > case MSB_RP_RECIVE_STATUS_REG: This is indeed a bug here. Probably added when I converted to use #defines for states. So, Signed-off-by: Maxim Levitsky Btw, there is another minor or major (pun inteded) bug out there in this driver, which I still have no time to send patch for yet :-( I accidentally didn't set the major and minor for the disk. It happens to work as usually there is just one card reader out there, and major is allocated dynamically. The two lines in msb_init_disk, msb->disk->major = major; msb->disk->first_minor = disk_id << MS_BLOCK_PART_SHIFT; Somehow fell through the cracks. I had this in older revision. Feel free to add it, or maybe I find time to compile and test this and send a patch. You also welcome to write a driver for xD portion of the card reader too. I back then implemented all the generic support, and you only need to expose an NAND driver (look at r852.c for my code). -- Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] of/irq: Bugfixes for linux-next branch
A couple of patches I'm about to push onto my linux-next branch. They are bug fixes to patches I've already applied instead of rebasing the branch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] of/irq: Fix potential buffer overflow
Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" introduced
a potential buffer overflow bug because it doesn't do sufficient range
checking on the input data. This patch adds the appropriate checking and
buffer size adjustments. If the bounds are out of range then warn
loudly. MAX_PHANDLE_ARGS should be sufficient. If it is not then the
value can be increased.
Signed-off-by: Grant Likely
Cc: Rob Herring
---
drivers/of/irq.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 52dba6a01423..d385bb824772 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -95,9 +95,9 @@ struct device_node *of_irq_find_parent(struct device_node
*child)
int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
{
struct device_node *ipar, *tnode, *old = NULL, *newpar = NULL;
- __be32 initial_match_array[8];
+ __be32 initial_match_array[MAX_PHANDLE_ARGS];
const __be32 *match_array = initial_match_array;
- const __be32 *tmp, *imap, *imask, dummy_imask[] = { ~0, ~0, ~0, ~0, ~0
};
+ const __be32 *tmp, *imap, *imask, dummy_imask[] = { [0 ...
MAX_PHANDLE_ARGS] = ~0 };
u32 intsize = 1, addrsize, newintsize = 0, newaddrsize = 0;
int imaplen, match, i;
@@ -147,6 +147,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> addrsize=%d\n", addrsize);
+ /* Range check so that the temporary buffer doesn't overflow */
+ if (WARN_ON(addrsize + intsize > MAX_PHANDLE_ARGS))
+ goto fail;
+
/* Precalculate the match array - this simplifies match loop */
for (i = 0; i < addrsize; i++)
initial_match_array[i] = addr ? addr[i] : 0;
@@ -229,6 +233,8 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
newintsize, newaddrsize);
/* Check for malformed properties */
+ if (WARN_ON(newaddrsize + newintsize >
MAX_PHANDLE_ARGS))
+ goto fail;
if (imaplen < (newaddrsize + newintsize))
goto fail;
--
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] phy: Add MOXA RTL8201CP PHY support
On Fri, 1 Nov 2013 15:54:33 +0100, Jonas Jensen wrote:
> The MOXA UC-711X hardware(s) has an ethernet controller that seem
> to be developed internally. The IC used is "RTL8201CP".
>
> This patch adds an MDIO driver and also patches realtek to include
> RTL8201CP PHY driver.
>
> Signed-off-by: Jonas Jensen
> ---
>
> Notes:
> The hardware does not use a separate IRQ for PHY.
>
> The link state change interrupt can instead be caught by MAC but the
> current drivers/of/of_mdio.c does not allow it to be handled in MAC.
>
> Applies to next-20131031
>
> .../devicetree/bindings/net/moxa,moxart-mdio.txt | 19 ++
> drivers/net/phy/Kconfig| 7 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-moxart.c | 201
> +
> drivers/net/phy/realtek.c | 15 ++
> 5 files changed, 243 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> create mode 100644 drivers/net/phy/mdio-moxart.c
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> new file mode 100644
> index 000..de0b90c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/moxa,moxart-mdio.txt
> @@ -0,0 +1,19 @@
> +* MOXA ART MDIO Ethernet Controller interface
> +
> +Required properties:
> +- compatible: should be "moxa,moxart-mdio".
> +- reg: address and length of the register set for the device.
> +
> +Example:
> +mdio1: mdio@9290 {
> + compatible = "moxa,moxart-mdio";
> + reg = <0x9290 0x8>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy1: ethernet-phy@1 {
> + device_type = "ethernet-phy";
> + compatible = "moxa,moxart-rtl8201cp";
> + reg = <1>;
> + };
> +};
Given that the binding is trivial and doesn't add any custom properties,
and it really looks like the MDIO block is part of the moxa,moxart-mac
device, why not merely add the following blub to
Documentation/devicetree/bindings/net/moxa,moxart-mac.txt:
---
Integrated MDIO bus node:
- compatible: "moxa,moxart-mdio"
- Inherets from MDIO bus node binding[1]
[1] Documentation/devicetree/bindings/net/phy.txt
---
And at the same time add the following blurb to the top of
Documentation/devicetree/bindings/net/phy.txt:
---
MDIO Bus Nodes
MDIO bus nodes describe an MDIO bus. It is a container for PHY nodes as
described below.
Required properties:
- #address-cells = <1>;
- #size-cells = <0>;
And then update the example to read:
---
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethernet-phy@0 {
compatible = "...", "ethernet-phy-ieee802.3-c22";
reg = <0>;
interrupts = <24 0>;
}
ethernet-phy@1 {
compatible = "...";
reg = <1>;
interrupts = <35 1>;
}
}
---
That will break out a lot of the boilerplate that we don't really need
in every single binding file.
g.
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 342561a..9b5d46c 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -154,6 +154,13 @@ config MDIO_SUN4I
> interface units of the Allwinner SoC that have an EMAC (A10,
> A12, A10s, etc.)
>
> +config MDIO_MOXART
> +tristate "MOXA ART MDIO interface support"
> +depends on ARCH_MOXART
> +help
> + This driver supports the MDIO interface found in the network
> + interface units of the MOXA ART SoC
> +
> config MDIO_BUS_MUX
> tristate
> depends on OF_MDIO
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 23a2ab2..9013dfa 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
> obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
> obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
> obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
> +obj-$(CONFIG_MDIO_MOXART)+= mdio-moxart.o
> diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio-moxart.c
> new file mode 100644
> index 000..ad5d0f8
> --- /dev/null
> +++ b/drivers/net/phy/mdio-moxart.c
> @@ -0,0 +1,201 @@
> +/* MOXA ART Ethernet (RTL8201CP) MDIO interface driver
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define REG_PHY_CTRL0
> +#define REG_PHY_WRITE_DATA 4
> +
> +/* REG_PHY_CTRL */
> +#define MIIWR
[PATCH 1/2] of/irq: Fix bug in interrupt parsing refactor.
Commit 2361613206e6, "of/irq: Refactor interrupt-map parsing" introduced
a bug. The irq parsing will fail for some nodes that don't have a reg
property. It is fixed by deferring the check for reg until it is
actually needed. Also adjust the testcase data to catch the bug.
Signed-off-by: Grant Likely
Tested-by: Stephen Warren
Cc: Rob Herring
---
arch/arm/boot/dts/testcases/tests-interrupts.dtsi | 6 +++---
drivers/of/irq.c | 20 ++--
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/testcases/tests-interrupts.dtsi
b/arch/arm/boot/dts/testcases/tests-interrupts.dtsi
index 560d6bf680b6..94cd511a1f64 100644
--- a/arch/arm/boot/dts/testcases/tests-interrupts.dtsi
+++ b/arch/arm/boot/dts/testcases/tests-interrupts.dtsi
@@ -2,7 +2,7 @@
/ {
testcase-data {
interrupts {
- #address-cells = <0>;
+ #address-cells = <1>;
test_intc0: intc0 {
interrupt-controller;
#interrupt-cells = <1>;
@@ -29,8 +29,7 @@
test_intmap1: intmap1 {
#interrupt-cells = <2>;
- #address-cells = <0>;
- interrupt-map = <1 2 &test_intc0 15>;
+ interrupt-map = <0x5000 1 2 &test_intc0 15>;
};
interrupts0 {
@@ -44,6 +43,7 @@
};
interrupts-extended0 {
+ reg = <0x5000>;
interrupts-extended = <&test_intc0 1>,
<&test_intc1 2 3 4>,
<&test_intc2 5 6>,
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 8cc62b4a7988..52dba6a01423 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -147,18 +147,9 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> addrsize=%d\n", addrsize);
- /* If we were passed no "reg" property and we attempt to parse
-* an interrupt-map, then #address-cells must be 0.
-* Fail if it's not.
-*/
- if (addr == NULL && addrsize != 0) {
- pr_debug(" -> no reg passed in when needed !\n");
- return -EINVAL;
- }
-
/* Precalculate the match array - this simplifies match loop */
for (i = 0; i < addrsize; i++)
- initial_match_array[i] = addr[i];
+ initial_match_array[i] = addr ? addr[i] : 0;
for (i = 0; i < intsize; i++)
initial_match_array[addrsize + i] =
cpu_to_be32(out_irq->args[i]);
@@ -174,6 +165,15 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
return 0;
}
+ /*
+* interrupt-map parsing does not work without a reg
+* property when #address-cells != 0
+*/
+ if (addrsize && !addr) {
+ pr_debug(" -> no reg passed in when needed !\n");
+ goto fail;
+ }
+
/* Now look for an interrupt-map */
imap = of_get_property(ipar, "interrupt-map", &imaplen);
/* No interrupt map, check for an interrupt parent */
--
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] of: set dma_mask to point to coherent_dma_mask
On Wed, 30 Oct 2013 00:05:22 -0500, Rob Herring wrote: > From: Rob Herring > > Platform devices created by DT code don't initialize dma_mask pointer to > anything. Set it to coherent_dma_mask by default if the architecture > code has not set it. > > Signed-off-by: Rob Herring I believe this is okay. I haven't done any testing to back up that opinion though. g. > --- > I think this is at least part of what is needed to fix dma_mask issue > raised by Stefano [1]. Things should work AFAICT with just this, but > I suppose the xgmac driver needs to set the mask as well (not relying > on the default), but some pointing the dma_mask to a valid value is > needed first. > > Rob > > [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg528236.html > > drivers/of/platform.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c > index f6dcde2..fce088e 100644 > --- a/drivers/of/platform.c > +++ b/drivers/of/platform.c > @@ -215,6 +215,8 @@ static struct platform_device > *of_platform_device_create_pdata( > dev->archdata.dma_mask = 0xUL; > #endif > dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > + if (!dev->dev.dma_mask) > + dev->dev.dma_mask = &dev->dev.coherent_dma_mask; > dev->dev.bus = &platform_bus_type; > dev->dev.platform_data = platform_data; > > -- > 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 2/4] perf tools: relate 'start' & 'end' to perf_session
On 11/1/13, 3:29 AM, Chenggang Qin wrote: Copy the value to start and end to struct perf_session. Why put the times in the session? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: record min_timestamp of samples queue in ordered_samples
On 11/1/13, 3:29 AM, Chenggang Qin wrote: Add a field 'min_timestamp' in struct ordered_samples to record the minimial timestamp of the samples in ordered_samples->samples. why? How do you intend to use the field? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] WAN: Adding support for Infineon PEF2256 E1 chipset (FALC56)
Christophe Leroy :
> The patch adds WAN support for Infineon FALC56 - PEF2256 E1 Chipset.
>
> Signed-off-by: Jerome Chantelauze
> Acked-by: Christophe Leroy
>
> diff -urN a/drivers/net/wan/pef2256.c b/drivers/net/wan/pef2256.c
> --- a/drivers/net/wan/pef2256.c 1970-01-01 01:00:00.0 +0100
> +++ b/drivers/net/wan/pef2256.c 2013-10-13 13:05:01.0 +0200
[...]
> +static irqreturn_t pef2256_irq(int irq, void *dev_priv);
> +static int Config_HDLC(struct pef2256_dev_priv *priv);
> +static int init_FALC(struct pef2256_dev_priv *priv);
> +static int pef2256_open(struct net_device *netdev);
> +static int pef2256_close(struct net_device *netdev);
You should avoid mixed case function names.
You can reorder and remove the forward declarations: none of pef2256_irq,
Config_HDLC, init_FALC or pef2256_close exhibits any external dependency.
pef2256_open only needs the three former.
> +void print_regs(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + unsigned char *base_addr = priv->base_addr;
> +
> + netdev_info(ndev, " MODE = 0x%02x\n", readb(base_addr + MODE));
[...]
> +static DEVICE_ATTR(regs, S_IRUGO, fs_attr_regs_show, NULL);
It duplicates an existing API. See ETHTOOL_GREGS in net/core/ethtool.c.
[...]
> +static ssize_t fs_attr_mode_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct pef2256_dev_priv *priv = dev_to_hdlc(ndev)->priv;
> + long int value;
> + int ret = kstrtol(buf, 10, &value);
> + int reconfigure = (value != priv->mode);
> +
> + if (value != MASTER_MODE && value != SLAVE_MODE)
> + ret = -EINVAL;
> +
> + if (ret < 0)
> + netdev_info(ndev, "Invalid mode (0 or 1 expected\n");
> + else {
> + priv->mode = value;
> + if (reconfigure && priv->init_done) {
> + pef2256_close(ndev);
> + init_FALC(priv);
> + pef2256_open(ndev);
*ouch*
This code badly races with normal uses of ndev->{open / close}. You can't
do that.
You may split the pef2256_open function in several parts and share the
relevant one with the sysfs functions (assuming some extra mutex based
locking).
You want to update the hardware configuration. You don't need any software
data housekeeping and you don't want a complete close (free_irq, hdlc unreg,
etc.) / open cycle. It seems simple but most of time it's a pain to get the
error processing part right and once you get there one realizes that it
does a lot of useless work.
[...]
> +/* Setting up HDLC channel */
> +int Config_HDLC(struct pef2256_dev_priv *priv)
Missing 'static'.
> +{
> + int i;
Excess scope.
> + int TS_idx;
> + unsigned char *base_addr;
> + u8 dummy;
> +
> + /* Set framer E1 address */
> + base_addr = priv->base_addr;
Usually done in a single line:
unsigned char *base_addr = priv->base_addr;
> +
> + /* Read to remove pending IT */
> + dummy = readb(base_addr + ISR0);
> + dummy = readb(base_addr + ISR1);
> +
> + /* Mask HDLC 1 Transmit IT */
> + writeb(readb(base_addr + IMR1) | 1, base_addr + IMR1);
> + writeb(readb(base_addr + IMR1) | (1 << 4), base_addr + IMR1);
> + writeb(readb(base_addr + IMR1) | (1 << 5), base_addr + IMR1);
Two points:
1.
#define IMR1... (ok, you did it in the .h file)
#define IMR1_XDU ...
#define IMR1_ALLS ...
Please use more #define and remove the redundant part in the comments
(the "Receiver inactive", "CRC on", etc. is imho welcome though).
2.
You may consider adding a few functions / define
static u8 pef_r8(struct pef2256 *pp, u32 offset)
static void pef_w8(struct pef2256 *pp, u32 offset, u8 val)
static void pef_rwm8(struct pef2256 *pp, u32 offset, u8 val)
> +
> + /* Mask HDLC 1 Receive IT */
> + writeb(readb(base_addr + IMR0) | 1, base_addr + IMR0);
> + writeb(readb(base_addr + IMR0) | (1 << 7), base_addr + IMR0);
> + writeb(readb(base_addr + IMR1) | (1 << 6), base_addr + IMR1);
> +
> + /* The hardware requires a delay up to 2*32*125 usec to take commands
> + * into account
> + */
> + udelay((2 * 32) * 125);
> +
> + /* MODE.HRAC = 0 (Receiver inactive)
> + * MODE.DIV = 0 (Data normal operation)
> + * for FALC V2.2 : MODE.HDLCI = 0 (normal operation)
> + * MODE.MDS2:0 = 100 (No address comparison)
> + * MODE.HRAC = 1 (Receiver active)
> + */
> + writeb(1 << 3, base_addr + MODE);
> + /* CCR1.EITS = 1 (Enable internal Time Slot 31:0 Signaling)
> + * CCR1.XMFA = 0 (No transmit multiframe alignment)
> + * CCR1.RFT1:0 = 00 (RFIFO is 32 bytes)
> + * setting up Interframe Time Fill
> + * CCR1.ITF = 1 (Interframe Time Fill Continuous flag)
> +
Re: [PATCH 3.11 00/66] 3.11.7-stable review
On Sat, Nov 02, 2013 at 03:30:57PM -0600, Shuah Khan wrote: > On 11/01/2013 04:06 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.7 release. > > There are 66 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 Nov 3 22:04:49 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.7-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Release 3.11.7 > > Patch applied cleanly yes > Compile test passed > Boot test passed > dmesg regression test passed > Cross-compile testpassed > > Architecture Config 3.11.7 > alpha defconfig Passed > arm defconfig Passed > arm64 defconfig Passed > blackfin defconfig Passed > c6x defconfig Passed > mips defconfig Passed > mipseldefconfig Passed > powerpc wii_defconfig Passed > shdefconfig Passed > sparc defconfig Passed > tile defconfig Passed Thanks for testing all three releases and letting me know it all works properly. 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: [ 00/32] 3.4.68-stable review
On 11/01/2013 03:43 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.68 release. There are 32 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 Nov 3 21:41:40 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.68-rc1.gz and the diffstat can be found below. thanks, greg k-h Release 3.4.68 Patch applied cleanly yes Compile testpassed Boot test passed dmesg regression test passed Cross-compile test passed dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. ArchitectureConfig 3.4.68 alpha defconfig Passed arm defconfig Passed arm64 defconfig Passed blackfindefconfig Passed c6x dsk6455_defconfig Passed mipsdefconfig Passed mipsel defconfig Passed powerpc wii_defconfig Passed sh defconfig Passed sparc defconfig Passed tiletilegx_defconfigPassed -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.10 00/54] 3.10.18-stable review
On 11/01/2013 04:03 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.18 release. There are 54 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 Nov 3 22:00:53 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.18-rc1.gz and the diffstat can be found below. thanks, greg k-h Release 3.10.18 Patch applied cleanly yes Compile testpassed Boot test passed dmesg regression test passed Cross-compile test passed dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. ArchitectureConfig 3.10.18 alpha defconfig Passed arm defconfig Passed arm64 defconfig Passed blackfindefconfig Passed c6x defconfig Passed mipsdefconfig Passed mipsel defconfig Passed powerpc wii_defconfig Passed sh defconfig Passed sparc defconfig Passed tiledefconfig Passed -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.11 00/66] 3.11.7-stable review
On 11/01/2013 04:06 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.11.7 release. There are 66 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 Nov 3 22:04:49 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.7-rc1.gz and the diffstat can be found below. thanks, greg k-h Release 3.11.7 Patch applied cleanly yes Compile testpassed Boot test passed dmesg regression test passed Cross-compile test passed ArchitectureConfig 3.11.7 alpha defconfig Passed arm defconfig Passed arm64 defconfig Passed blackfindefconfig Passed c6x defconfig Passed mipsdefconfig Passed mipsel defconfig Passed powerpc wii_defconfig Passed sh defconfig Passed sparc defconfig Passed tiledefconfig Passed -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] IPC DoS fix
Hi Linus, this series fixes a bug in the IPC code that allows root to instantly crash the system. The first patch fixes the bug, the second one prevents msgmax from getting negative in the first place. As that *might* break existing userspace (for good?!) it's a separate patch. The cc list is quite randomly choosen as there seem to be no maintainer for ipc/. :/ Please apply! Mathias Krause (2): ipc, msg: fix message length check for negative values ipc, msg: forbid negative values for "msgmax" ipc/ipc_sysctl.c |6 +++--- ipc/msg.c|2 +- 2 files changed, 4 insertions(+), 4 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/
[PATCH 2/2] ipc, msg: forbid negative values for "msgmax"
Negative message lengths make no sense, prevent them from being set.
They do more harm than gain.
In case a user wants to have "unlimited" message sizes she should
just use INT_MAX instead.
Signed-off-by: Mathias Krause
Cc: Andrew Morton
---
ipc/ipc_sysctl.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c
index 130dfec..76823b8 100644
--- a/ipc/ipc_sysctl.c
+++ b/ipc/ipc_sysctl.c
@@ -158,9 +158,7 @@ static int proc_ipcauto_dointvec_minmax(ctl_table *table,
int write,
static int zero;
static int one = 1;
-#ifdef CONFIG_CHECKPOINT_RESTORE
static int int_max = INT_MAX;
-#endif
static struct ctl_table ipc_kern_table[] = {
{
@@ -198,7 +196,9 @@ static struct ctl_table ipc_kern_table[] = {
.data = &init_ipc_ns.msg_ctlmax,
.maxlen = sizeof (init_ipc_ns.msg_ctlmax),
.mode = 0644,
- .proc_handler = proc_ipc_dointvec,
+ .proc_handler = proc_ipc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &int_max,
},
{
.procname = "msgmni",
--
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/
[PATCH 1/2] ipc, msg: fix message length check for negative values
On 64 bit systems the test for negative message sizes is bogus as the
size, which may be positive when evaluated as a long, will get truncated
to an int when passed to load_msg(). So a long might very well contain a
positive value but when truncated to an int it would become negative.
That in combination with a small negative value of msg_ctlmax (which will
be promoted to an unsigned type for the comparison against msgsz, making
it a big positive value and therefore make it pass the check) will lead
to two problems: 1/ The kmalloc() call in alloc_msg() will allocate a
too small buffer as the addition of alen is effectively a subtraction.
2/ The copy_from_user() call in load_msg() will first overflow the
buffer with userland data and then, when the userland access generates
an access violation, the fixup handler copy_user_handle_tail() will try
to fill the remainder with zeros -- roughly 4GB. That almost instantly
results in a system crash or reset.
,-[ Reproducer (needs to be run as root) ]--
| #include
| #include
| #include
| #include
|
| int main(void) {
| long msg = 1;
| int fd;
|
| fd = open("/proc/sys/kernel/msgmax", O_WRONLY);
| write(fd, "-1", 2);
| close(fd);
|
| msgsnd(0, &msg, 0xfff0, IPC_NOWAIT);
|
| return 0;
| }
'---
Fix the issue by checking for negative values the way they're used by
casting msgsz to int.
Hardening mechanisms for user copy operations would have catched that
bug early -- e.g. checking slab object sizes on user copy operations as
the usercopy feature of the PaX patch does. Or, for that matter, detect
the long vs. int sign change due to truncation, as the size overflow
plugin of the very same patch does.
Signed-off-by: Mathias Krause
Cc: Andrew Morton
Cc: Pax Team
Cc: # v2.3.27+ -- yes, that old ;)
---
ipc/msg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 558aa91..d139b1e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -667,7 +667,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext,
ns = current->nsproxy->ipc_ns;
- if (msgsz > ns->msg_ctlmax || (long) msgsz < 0 || msqid < 0)
+ if (msgsz > ns->msg_ctlmax || (int) msgsz < 0 || msqid < 0)
return -EINVAL;
if (mtype < 1)
return -EINVAL;
--
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] Staging: ft1000: fixed coding style issues
Aldo Iljazi wrote:
> Fixed a few coding style issues that checkpatch reported.
>
> Specifically:
>
> 1. line over 80 characters issue on the lines 9 and 10.
> 2. space prohibited before open square bracket '[' issue on the lines
> 31.
> 3. inserted space after comma on lines 32 to 156.
>
> Signed-off-by: Aldo Iljazi
> ---
> drivers/staging/ft1000/ft1000-pcmcia/boot.h | 263
> ++--
> 1 file changed, 132 insertions(+), 131 deletions(-)
>
> diff --git a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
> b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
> index 9dce54e..f384bc2 100644
> --- a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
> +++ b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
> @@ -6,11 +6,12 @@
> // This program is free software; you can redistribute it and/or modify it
> // under the terms of the GNU General Public License as published by the Free
> // Software Foundation; either version 2 of the License, or (at your option)
> any
> -// later version. 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. You should have received a copy of the GNU General Public
> -// License along with this program; if not, write to the
> +// later version. 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.
> +// You should have received a copy of the GNU General Public License
> +// along with this program; if not, write to the
> // Free Software Foundation, Inc., 59 Temple Place -
> // Suite 330, Boston, MA 02111-1307, USA.
> //---
> @@ -27,132 +28,132 @@
> #define _BOOTH_
>
> // Official bootloader
> -static unsigned char bootimage [] = {
> -0x00,0x00,0x01,0x5E,0x00,0x00
> -,0x00,0x00,0x00,0x00,0x02,0xD7
> -,0x00,0x00,0x01,0x5E,0x46,0xB3
> -,0xE6,0x02,0x00,0x98,0xE6,0x8C
> -,0x00,0x98,0xFB,0x92,0xFF,0xFF
> -,0x98,0xFB,0x94,0xFF,0xFF,0x98
> -,0xFB,0x06,0x08,0x00,0x98,0xFB
> -,0x96,0x84,0x00,0x98,0xFB,0x08
> -,0x1C,0x00,0x98,0xFB,0x51,0x25
> -,0x10,0x1C,0x00,0xE6,0x51,0x01
> -,0x07,0xFD,0x4C,0xFF,0x20,0xF5
> -,0x51,0x02,0x20,0x08,0x00,0x4C
> -,0xFF,0x20,0x3C,0x00,0xC0,0x64
> -,0x98,0xC0,0x66,0x98,0xC0,0x68
> -,0x98,0xC0,0x6A,0x98,0xC0,0x6C
> -,0x98,0x90,0x08,0x90,0x09,0x90
> -,0x0A,0x90,0x0B,0x90,0x0C,0x90
> -,0x0D,0x90,0x0E,0x90,0x0F,0x90
> -,0x04,0x90,0x06,0xFB,0x51,0x22
> -,0x16,0x08,0x03,0xFB,0x51,0x52
> -,0x16,0x08,0x04,0xFB,0x51,0x24
> -,0x2B,0x08,0x06,0xFB,0x51,0x54
> -,0x2B,0x08,0x07,0xFB,0x51,0x24
> -,0x2B,0x08,0x09,0xFB,0x51,0x54
> -,0x2B,0x08,0x0A,0xFB,0x51,0x12
> -,0x16,0x08,0x0C,0xFB,0x51,0x52
> -,0x16,0x08,0x0D,0x78,0x00,0x00
> -,0x00,0x16,0x00,0x00,0xEC,0x31
> -,0xAE,0x00,0x00,0x81,0x4C,0x0F
> -,0xE6,0x43,0xFF,0xEC,0x31,0x4E
> -,0x00,0x00,0x91,0xEC,0x31,0xAE
> -,0x00,0x00,0x91,0x4C,0x0F,0xE6
> -,0x43,0xFF,0xEC,0x31,0x5E,0x00
> -,0x00,0xA1,0xEB,0x31,0x08,0x00
> -,0x00,0xA6,0xEB,0x31,0x08,0x00
> -,0x00,0xAC,0x3C,0x00,0xEB,0x31
> -,0x08,0x00,0x00,0xA8,0x76,0xFE
> -,0xFE,0x08,0xEB,0x31,0x08,0x20
> -,0x00,0x00,0x76,0xFF,0xFF,0x18
> -,0xED,0x31,0x08,0x20,0x00,0x00
> -,0x26,0x10,0x04,0x10,0xF5,0x3C
> -,0x01,0x3C,0x00,0x08,0x01,0x12
> -,0x3C,0x11,0x3C,0x00,0x08,0x01
> -,0x0B,0x08,0x00,0x6D,0xEC,0x31
> -,0xAE,0x20,0x00,0x06,0xED,0x4D
> -,0x08,0x00,0x00,0x67,0x80,0x6F
> -,0x00,0x01,0x0B,0x6F,0x00,0x02
> -,0x2E,0x76,0xEE,0x01,0x48,0x06
> -,0x01,0x39,0xED,0x4D,0x18,0x00
> -,0x02,0xED,0x4D,0x08,0x00,0x04
> -,0x14,0x06,0xA4,0xED,0x31,0x22
> -,0x00,0x00,0xAC,0x76,0xEE,0x07
> -,0x48,0x6D,0x22,0x01,0x1E,0x08
> -,0x01,0x58,0xEB,0x31,0x08,0x00
> -,0x00,0xAC,0x06,0xFF,0xBA,0x3C
> -,0x00,0xEB,0x31,0x08,0x20,0x00
> -,0x04,0x3C,0x30,0xEB,0x31,0x08
> -,0x20,0x00,0x02,0x3C,0x10,0xEB
> -,0x31,0x08,0x20,0x00,0x00,0xED
> -,0x31,0x08,0x20,0x00,0x00,0x04
> -,0x10,0xF7,0xED,0x31,0x08,0x00
> -,0x00,0xA2,0x91,0x00,0x9C,0x3C
> -,0x80,0xEB,0x31,0x08,0x20,0x00
> -,0x04,0x3C,0x20,0xEB,0x31,0x08
> -,0x20,0x00,0x02,0x3C,0x10,0xEB
> -,0x31,0x08,0x20,0x00,0x00,0xED
> -,0x31,0x08,0x20,0x00,0x00,0x04
> -,0x10,0xF7,0xED,0x31,0x08,0x20
> -,0x00,0x04,0x42,0x10,0x90,0x08
> -,0xEC,0x31,0xAE,0x20,0x00,0x06
> -,0xA4,0x41,0x08,0x00,0xB6,0xED
> -,0x41,0x28,0x7D,0xFF,0xFF,0x22
> -,0xB3,0x40,0x98,0x2A,0x32,0xEB
> -,0x41,0x28,0xB4,0x43,0xFC,0x05
> -,0xFF,0xE6,0xA0,0x31,0x20,0x00
> -,0x06,0xEB,0x31,0x08,0x20,0x00
> -,0x04,0x3C,0x20,0xEB,0x31,0x08
> -,0x20,0x00,0x02,0x3C,0x10,0xEB
> -,0x31,0x08,0x20,0x00,0x00,0xED
> -,0x31,0x08,0x20,0x00,0x00,0x04
> -,0x10,0xF7,0xED,0x31,0x08,0x20
> -,0x00,0x04,0x42,0x10,0x90,0x08
> -,0xEC,0x31,0xAE,0x20,0x00,0x06
> -,0xA4,0x41,0x08,0x00,0x68,0xED
> -,0x41,0x28,0x7D,0xFF,0xFF,0x22
> -,0xB3,0x40,0x98,0x2A,0x32,0xEB
>
[PATCH] Staging: ft1000: fixed coding style issues
Fixed a few coding style issues that checkpatch reported.
Specifically:
1. line over 80 characters issue on the lines 9 and 10.
2. space prohibited before open square bracket '[' issue on the lines
31.
3. inserted space after comma on lines 32 to 156.
Signed-off-by: Aldo Iljazi
---
drivers/staging/ft1000/ft1000-pcmcia/boot.h | 263 ++--
1 file changed, 132 insertions(+), 131 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
index 9dce54e..f384bc2 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
+++ b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
@@ -6,11 +6,12 @@
// This program is free software; you can redistribute it and/or modify it
// under the terms of the GNU General Public License as published by the Free
// Software Foundation; either version 2 of the License, or (at your option)
any
-// later version. 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. You should have received a copy of the GNU General Public
-// License along with this program; if not, write to the
+// later version. 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.
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the
// Free Software Foundation, Inc., 59 Temple Place -
// Suite 330, Boston, MA 02111-1307, USA.
//---
@@ -27,132 +28,132 @@
#define _BOOTH_
// Official bootloader
-static unsigned char bootimage [] = {
-0x00,0x00,0x01,0x5E,0x00,0x00
-,0x00,0x00,0x00,0x00,0x02,0xD7
-,0x00,0x00,0x01,0x5E,0x46,0xB3
-,0xE6,0x02,0x00,0x98,0xE6,0x8C
-,0x00,0x98,0xFB,0x92,0xFF,0xFF
-,0x98,0xFB,0x94,0xFF,0xFF,0x98
-,0xFB,0x06,0x08,0x00,0x98,0xFB
-,0x96,0x84,0x00,0x98,0xFB,0x08
-,0x1C,0x00,0x98,0xFB,0x51,0x25
-,0x10,0x1C,0x00,0xE6,0x51,0x01
-,0x07,0xFD,0x4C,0xFF,0x20,0xF5
-,0x51,0x02,0x20,0x08,0x00,0x4C
-,0xFF,0x20,0x3C,0x00,0xC0,0x64
-,0x98,0xC0,0x66,0x98,0xC0,0x68
-,0x98,0xC0,0x6A,0x98,0xC0,0x6C
-,0x98,0x90,0x08,0x90,0x09,0x90
-,0x0A,0x90,0x0B,0x90,0x0C,0x90
-,0x0D,0x90,0x0E,0x90,0x0F,0x90
-,0x04,0x90,0x06,0xFB,0x51,0x22
-,0x16,0x08,0x03,0xFB,0x51,0x52
-,0x16,0x08,0x04,0xFB,0x51,0x24
-,0x2B,0x08,0x06,0xFB,0x51,0x54
-,0x2B,0x08,0x07,0xFB,0x51,0x24
-,0x2B,0x08,0x09,0xFB,0x51,0x54
-,0x2B,0x08,0x0A,0xFB,0x51,0x12
-,0x16,0x08,0x0C,0xFB,0x51,0x52
-,0x16,0x08,0x0D,0x78,0x00,0x00
-,0x00,0x16,0x00,0x00,0xEC,0x31
-,0xAE,0x00,0x00,0x81,0x4C,0x0F
-,0xE6,0x43,0xFF,0xEC,0x31,0x4E
-,0x00,0x00,0x91,0xEC,0x31,0xAE
-,0x00,0x00,0x91,0x4C,0x0F,0xE6
-,0x43,0xFF,0xEC,0x31,0x5E,0x00
-,0x00,0xA1,0xEB,0x31,0x08,0x00
-,0x00,0xA6,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x3C,0x00,0xEB,0x31
-,0x08,0x00,0x00,0xA8,0x76,0xFE
-,0xFE,0x08,0xEB,0x31,0x08,0x20
-,0x00,0x00,0x76,0xFF,0xFF,0x18
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x26,0x10,0x04,0x10,0xF5,0x3C
-,0x01,0x3C,0x00,0x08,0x01,0x12
-,0x3C,0x11,0x3C,0x00,0x08,0x01
-,0x0B,0x08,0x00,0x6D,0xEC,0x31
-,0xAE,0x20,0x00,0x06,0xED,0x4D
-,0x08,0x00,0x00,0x67,0x80,0x6F
-,0x00,0x01,0x0B,0x6F,0x00,0x02
-,0x2E,0x76,0xEE,0x01,0x48,0x06
-,0x01,0x39,0xED,0x4D,0x18,0x00
-,0x02,0xED,0x4D,0x08,0x00,0x04
-,0x14,0x06,0xA4,0xED,0x31,0x22
-,0x00,0x00,0xAC,0x76,0xEE,0x07
-,0x48,0x6D,0x22,0x01,0x1E,0x08
-,0x01,0x58,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x06,0xFF,0xBA,0x3C
-,0x00,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x30,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x00
-,0x00,0xA2,0x91,0x00,0x9C,0x3C
-,0x80,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0xB6,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0xA0,0x31,0x20,0x00
-,0x06,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0x68,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0x48,0x04,0xEB,0x31
-,0x08,0x20,0x00,0x04,0xEB,0x31
-,0x18,0x20,0x00,0x02,0x3C,0x11
-,0xEB,0x31,0x18,0x20,0x00,0x00
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x04,0x10,0xF7,0xED,0x31,0x08
-,0x20,0x00,0x02,0x66,0x00,0x6F
-,0x00,0x01,0x16,0x76,0xEE,0x06
-,
[PATCH] Staging: ft1000: fixed coding style issues
Fixed a few coding style issues that checkpatch reported.
Specifically:
1. line over 80 characters issue on the lines 9 and 10.
2. space prohibited before open square bracket '[' issue on the lines
31.
3. iserted space after comma on lines to 156
Signed-off-by: Aldo Iljazi
---
drivers/staging/ft1000/ft1000-pcmcia/boot.h | 263 ++--
1 file changed, 132 insertions(+), 131 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
index 9dce54e..f384bc2 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
+++ b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
@@ -6,11 +6,12 @@
// This program is free software; you can redistribute it and/or modify it
// under the terms of the GNU General Public License as published by the Free
// Software Foundation; either version 2 of the License, or (at your option)
any
-// later version. 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. You should have received a copy of the GNU General Public
-// License along with this program; if not, write to the
+// later version. 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.
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the
// Free Software Foundation, Inc., 59 Temple Place -
// Suite 330, Boston, MA 02111-1307, USA.
//---
@@ -27,132 +28,132 @@
#define _BOOTH_
// Official bootloader
-static unsigned char bootimage [] = {
-0x00,0x00,0x01,0x5E,0x00,0x00
-,0x00,0x00,0x00,0x00,0x02,0xD7
-,0x00,0x00,0x01,0x5E,0x46,0xB3
-,0xE6,0x02,0x00,0x98,0xE6,0x8C
-,0x00,0x98,0xFB,0x92,0xFF,0xFF
-,0x98,0xFB,0x94,0xFF,0xFF,0x98
-,0xFB,0x06,0x08,0x00,0x98,0xFB
-,0x96,0x84,0x00,0x98,0xFB,0x08
-,0x1C,0x00,0x98,0xFB,0x51,0x25
-,0x10,0x1C,0x00,0xE6,0x51,0x01
-,0x07,0xFD,0x4C,0xFF,0x20,0xF5
-,0x51,0x02,0x20,0x08,0x00,0x4C
-,0xFF,0x20,0x3C,0x00,0xC0,0x64
-,0x98,0xC0,0x66,0x98,0xC0,0x68
-,0x98,0xC0,0x6A,0x98,0xC0,0x6C
-,0x98,0x90,0x08,0x90,0x09,0x90
-,0x0A,0x90,0x0B,0x90,0x0C,0x90
-,0x0D,0x90,0x0E,0x90,0x0F,0x90
-,0x04,0x90,0x06,0xFB,0x51,0x22
-,0x16,0x08,0x03,0xFB,0x51,0x52
-,0x16,0x08,0x04,0xFB,0x51,0x24
-,0x2B,0x08,0x06,0xFB,0x51,0x54
-,0x2B,0x08,0x07,0xFB,0x51,0x24
-,0x2B,0x08,0x09,0xFB,0x51,0x54
-,0x2B,0x08,0x0A,0xFB,0x51,0x12
-,0x16,0x08,0x0C,0xFB,0x51,0x52
-,0x16,0x08,0x0D,0x78,0x00,0x00
-,0x00,0x16,0x00,0x00,0xEC,0x31
-,0xAE,0x00,0x00,0x81,0x4C,0x0F
-,0xE6,0x43,0xFF,0xEC,0x31,0x4E
-,0x00,0x00,0x91,0xEC,0x31,0xAE
-,0x00,0x00,0x91,0x4C,0x0F,0xE6
-,0x43,0xFF,0xEC,0x31,0x5E,0x00
-,0x00,0xA1,0xEB,0x31,0x08,0x00
-,0x00,0xA6,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x3C,0x00,0xEB,0x31
-,0x08,0x00,0x00,0xA8,0x76,0xFE
-,0xFE,0x08,0xEB,0x31,0x08,0x20
-,0x00,0x00,0x76,0xFF,0xFF,0x18
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x26,0x10,0x04,0x10,0xF5,0x3C
-,0x01,0x3C,0x00,0x08,0x01,0x12
-,0x3C,0x11,0x3C,0x00,0x08,0x01
-,0x0B,0x08,0x00,0x6D,0xEC,0x31
-,0xAE,0x20,0x00,0x06,0xED,0x4D
-,0x08,0x00,0x00,0x67,0x80,0x6F
-,0x00,0x01,0x0B,0x6F,0x00,0x02
-,0x2E,0x76,0xEE,0x01,0x48,0x06
-,0x01,0x39,0xED,0x4D,0x18,0x00
-,0x02,0xED,0x4D,0x08,0x00,0x04
-,0x14,0x06,0xA4,0xED,0x31,0x22
-,0x00,0x00,0xAC,0x76,0xEE,0x07
-,0x48,0x6D,0x22,0x01,0x1E,0x08
-,0x01,0x58,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x06,0xFF,0xBA,0x3C
-,0x00,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x30,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x00
-,0x00,0xA2,0x91,0x00,0x9C,0x3C
-,0x80,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0xB6,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0xA0,0x31,0x20,0x00
-,0x06,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0x68,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0x48,0x04,0xEB,0x31
-,0x08,0x20,0x00,0x04,0xEB,0x31
-,0x18,0x20,0x00,0x02,0x3C,0x11
-,0xEB,0x31,0x18,0x20,0x00,0x00
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x04,0x10,0xF7,0xED,0x31,0x08
-,0x20,0x00,0x02,0x66,0x00,0x6F
-,0x00,0x01,0x16,0x76,0xEE,0x06
-,0x48,
[PATCH] Staging: ft1000: fixed coding style issues
Fixed a few coding style issues that checkpatch reported.
Specifically:
1. line over 80 characters issue on the lines 9 and 10.
2. space prohibited before open square bracket '[' issue on the lines
30 to 155.
Signed-off-by: Aldo Iljazi
---
drivers/staging/ft1000/ft1000-pcmcia/boot.h | 263 ++--
1 file changed, 132 insertions(+), 131 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
index 9dce54e..f384bc2 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/boot.h
+++ b/drivers/staging/ft1000/ft1000-pcmcia/boot.h
@@ -6,11 +6,12 @@
// This program is free software; you can redistribute it and/or modify it
// under the terms of the GNU General Public License as published by the Free
// Software Foundation; either version 2 of the License, or (at your option)
any
-// later version. 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. You should have received a copy of the GNU General Public
-// License along with this program; if not, write to the
+// later version. 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.
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the
// Free Software Foundation, Inc., 59 Temple Place -
// Suite 330, Boston, MA 02111-1307, USA.
//---
@@ -27,132 +28,132 @@
#define _BOOTH_
// Official bootloader
-static unsigned char bootimage [] = {
-0x00,0x00,0x01,0x5E,0x00,0x00
-,0x00,0x00,0x00,0x00,0x02,0xD7
-,0x00,0x00,0x01,0x5E,0x46,0xB3
-,0xE6,0x02,0x00,0x98,0xE6,0x8C
-,0x00,0x98,0xFB,0x92,0xFF,0xFF
-,0x98,0xFB,0x94,0xFF,0xFF,0x98
-,0xFB,0x06,0x08,0x00,0x98,0xFB
-,0x96,0x84,0x00,0x98,0xFB,0x08
-,0x1C,0x00,0x98,0xFB,0x51,0x25
-,0x10,0x1C,0x00,0xE6,0x51,0x01
-,0x07,0xFD,0x4C,0xFF,0x20,0xF5
-,0x51,0x02,0x20,0x08,0x00,0x4C
-,0xFF,0x20,0x3C,0x00,0xC0,0x64
-,0x98,0xC0,0x66,0x98,0xC0,0x68
-,0x98,0xC0,0x6A,0x98,0xC0,0x6C
-,0x98,0x90,0x08,0x90,0x09,0x90
-,0x0A,0x90,0x0B,0x90,0x0C,0x90
-,0x0D,0x90,0x0E,0x90,0x0F,0x90
-,0x04,0x90,0x06,0xFB,0x51,0x22
-,0x16,0x08,0x03,0xFB,0x51,0x52
-,0x16,0x08,0x04,0xFB,0x51,0x24
-,0x2B,0x08,0x06,0xFB,0x51,0x54
-,0x2B,0x08,0x07,0xFB,0x51,0x24
-,0x2B,0x08,0x09,0xFB,0x51,0x54
-,0x2B,0x08,0x0A,0xFB,0x51,0x12
-,0x16,0x08,0x0C,0xFB,0x51,0x52
-,0x16,0x08,0x0D,0x78,0x00,0x00
-,0x00,0x16,0x00,0x00,0xEC,0x31
-,0xAE,0x00,0x00,0x81,0x4C,0x0F
-,0xE6,0x43,0xFF,0xEC,0x31,0x4E
-,0x00,0x00,0x91,0xEC,0x31,0xAE
-,0x00,0x00,0x91,0x4C,0x0F,0xE6
-,0x43,0xFF,0xEC,0x31,0x5E,0x00
-,0x00,0xA1,0xEB,0x31,0x08,0x00
-,0x00,0xA6,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x3C,0x00,0xEB,0x31
-,0x08,0x00,0x00,0xA8,0x76,0xFE
-,0xFE,0x08,0xEB,0x31,0x08,0x20
-,0x00,0x00,0x76,0xFF,0xFF,0x18
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x26,0x10,0x04,0x10,0xF5,0x3C
-,0x01,0x3C,0x00,0x08,0x01,0x12
-,0x3C,0x11,0x3C,0x00,0x08,0x01
-,0x0B,0x08,0x00,0x6D,0xEC,0x31
-,0xAE,0x20,0x00,0x06,0xED,0x4D
-,0x08,0x00,0x00,0x67,0x80,0x6F
-,0x00,0x01,0x0B,0x6F,0x00,0x02
-,0x2E,0x76,0xEE,0x01,0x48,0x06
-,0x01,0x39,0xED,0x4D,0x18,0x00
-,0x02,0xED,0x4D,0x08,0x00,0x04
-,0x14,0x06,0xA4,0xED,0x31,0x22
-,0x00,0x00,0xAC,0x76,0xEE,0x07
-,0x48,0x6D,0x22,0x01,0x1E,0x08
-,0x01,0x58,0xEB,0x31,0x08,0x00
-,0x00,0xAC,0x06,0xFF,0xBA,0x3C
-,0x00,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x30,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x00
-,0x00,0xA2,0x91,0x00,0x9C,0x3C
-,0x80,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0xB6,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0xA0,0x31,0x20,0x00
-,0x06,0xEB,0x31,0x08,0x20,0x00
-,0x04,0x3C,0x20,0xEB,0x31,0x08
-,0x20,0x00,0x02,0x3C,0x10,0xEB
-,0x31,0x08,0x20,0x00,0x00,0xED
-,0x31,0x08,0x20,0x00,0x00,0x04
-,0x10,0xF7,0xED,0x31,0x08,0x20
-,0x00,0x04,0x42,0x10,0x90,0x08
-,0xEC,0x31,0xAE,0x20,0x00,0x06
-,0xA4,0x41,0x08,0x00,0x68,0xED
-,0x41,0x28,0x7D,0xFF,0xFF,0x22
-,0xB3,0x40,0x98,0x2A,0x32,0xEB
-,0x41,0x28,0xB4,0x43,0xFC,0x05
-,0xFF,0xE6,0x48,0x04,0xEB,0x31
-,0x08,0x20,0x00,0x04,0xEB,0x31
-,0x18,0x20,0x00,0x02,0x3C,0x11
-,0xEB,0x31,0x18,0x20,0x00,0x00
-,0xED,0x31,0x08,0x20,0x00,0x00
-,0x04,0x10,0xF7,0xED,0x31,0x08
-,0x20,0x00,0x02,0x66,0x00,0x6F
-,0x00,0x01,0x16,0x76,0xEE,0x06
-,0x48,0x4A,0x1E,0x48,0x04,0xED
-,0x31,0x08,0
Re: [PATCH] extcon-gpio: add devicetree support.
On Sat, 2 Nov 2013 10:33:23 +1100 NeilBrown wrote: > On Fri, 1 Nov 2013 10:16:44 -0700 Mark Rutland wrote: > > > Hi Neil, > > > > While I'm not fundamentally opposed to this binding, I have some issues with > > its current form and would not want to see this version hit mainline. > > > > Thanks for the review. > > > On Fri, Nov 01, 2013 at 09:50:05AM +, NeilBrown wrote: > > > > > > As this device is not vendor specific, I haven't included any "vendor," > > > prefixes. For my model I used "regulator-gpio" which takes a similar > > > approach. > > > > > > Signed-off-by: NeilBrown > > > > > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > > > b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > > > new file mode 100644 > > > index ..2346b61cc620 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt > > > @@ -0,0 +1,26 @@ > > > +* EXTCON detector using GPIO > > > > EXTCON is _extremely_ Linux-specific. The binding document needs a > > description > > of the class of device it's inteded to describe that does not just refer to > > Linux internals. > > > > I would prefer if we could have a better name for this that was not tied to > > the > > Linux driver name. Perhaps "gpio-presence-detector"? > > Maybe "cable-presence-detector" as in this case the GPIO is just an > implementation detail. Which isn't much different from "external-connector" > which is where "extcon" comes from... > > I propose "external-connector" if you don't like "extcon". Uhm.. I just realised that what I said here doesn't make any sense - sorry. I was thinking that you were suggesting "gpio-presence-detector" as a replacement for "extcon", but of course you weren't. It is a possible replacement for "extcon-gpio", which makes lots of sense. The "Extcon" driver works in two modes. One in which is can detect which of several possible cables is inserted, and one in which is simply detects if any cable is inserted at all. extcon-gpio only supports the second. And for the second, I'm beginning to think that "presence-detector" is quite a good name. So yes: unless some serious objection arises, gpio-presence-detector is what I'll use in my next patch. Thanks, NeilBrown signature.asc Description: PGP signature
Re: Strange location and name for platform devices when device-tree is used.
On Sun, Nov 03, 2013 at 07:22:10AM +1100, Benjamin Herrenschmidt wrote: > On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote: > > Just loop through all the platform devices before registering it to > > determine if you need to do this, the platform code can do this just > > fine. If you try to register a duplicate name with the driver core, > > odds are it will complain loudly, so don't do that. > > But that loop + registration is racy ... oh well, we might do something > better with Neil's idea of labels instead. How is it racy? Only one platform device should be allowed to be registered at a time, there is a per-bus lock that should be used to enforce this, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange location and name for platform devices when device-tree is used.
On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote: > Just loop through all the platform devices before registering it to > determine if you need to do this, the platform code can do this just > fine. If you try to register a duplicate name with the driver core, > odds are it will complain loudly, so don't do that. But that loop + registration is racy ... oh well, we might do something better with Neil's idea of labels instead. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] net: flow_dissector: fail on evil iph->ihl
On Fri, Nov 01, 2013 at 03:01:10PM +0800, Jason Wang wrote: > We don't validate iph->ihl which may lead a dead loop if we meet a IPIP > skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl > is evil (less than 5). > > This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae > (rps: support IPIP encapsulation). > > Cc: Eric Dumazet > Cc: Petr Matousek > Cc: Michael S. Tsirkin > Cc: Daniel Borkmann > Signed-off-by: Jason Wang Acked-by: Michael S. Tsirkin > --- > This patch is needed for stable. > --- > net/core/flow_dissector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c > index 8d7d0dd..143b6fd 100644 > --- a/net/core/flow_dissector.c > +++ b/net/core/flow_dissector.c > @@ -40,7 +40,7 @@ again: > struct iphdr _iph; > ip: > iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph); > - if (!iph) > + if (!iph || iph->ihl < 5) > return false; > > if (ip_is_fragment(iph)) > -- > 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: [kconfig] update: results of some syntactical checks
On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote: > Em Sat, 02 Nov 2013 20:20:54 +0100 > Paul Bolle escreveu: > > Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like > > to send the trivial patch to fix this? > > Yes, it is a typo... > > > > Probably, it was meant to say something like > > > > depends on SMS_USB_DRV = SMS_SDIO_DRV > > But this is not the right thing to do. The Kconfig logic here is that it > should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. For the record: my reason for suggesting to Martin to send patches is that sending a (trivial) patch often turns out to be a quick way to get issues like that resolved. Maintainers seem to react quite quickly on patches. Perhaps even faster if a patch is not solving the issue at hand entirely correct! Messages like Martin's, that basically state that there are one or more tree-wide problems, seem to be overlooked easily. > I remember I made a patch like that while testing some things with this > driver, but it seems that I forgot to push. I might have it somewhere on > my test machine. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] LSM: ModPin LSM for module loading restrictions
On 10/26/2013 6:51 AM, Tetsuo Handa wrote: > Tetsuo Handa wrote: >> I would send another one which uses only security_file_alloc/free . > I sent it to James, Casey and Kees on "Fri, 18 Oct 2013 22:56:19 +0900" and > waiting for your response. How long are we expected to remain vulnerable due > to > lack of multiple concurrent LSM support? Having just spent a good chunk of the past year on the technical issues, and having participated in the LSM development process since its inception, I'd say there's at least a year before the dust settles. Having a wad of code that works is one thing. Breaking it into chunks that are both useful and small enough for the community to swallow is another. Transforming a collection of clever hacks into an infrastructure is a third. Once that's done we can deal with the naysayers. Fortunately, we have a wad of code that works. Nobody seems to think that taking that code as is is a great idea. Nobody has this as their first priority, either. We're making progress, but we know we need to be careful. I seriously doubt we'll get more than one shot at it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kconfig] update: results of some syntactical checks
Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle escreveu: > On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: > > drivers/media/common/siano/Kconfig:21-26 > > > config SMS_SIANO_DEBUGFS > > > bool "Enable debugfs for smsdvb" > > > depends on SMS_SIANO_MDTV > > > depends on DEBUG_FS > > > depends on SMS_USB_DRV > > > depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV > > > > The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. > > This expression does not look sound as those two symbols are not declared > > anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV > > are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never > > be enabled. > > Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like > to send the trivial patch to fix this? Yes, it is a typo... > > > Probably, it was meant to say something like > > > depends on SMS_USB_DRV = SMS_SDIO_DRV But this is not the right thing to do. The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [kconfig] update: results of some syntactical checks
On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: > drivers/media/common/siano/Kconfig:21-26 > > config SMS_SIANO_DEBUGFS > > bool "Enable debugfs for smsdvb" > > depends on SMS_SIANO_MDTV > > depends on DEBUG_FS > > depends on SMS_USB_DRV > > depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV > > The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. > This expression does not look sound as those two symbols are not declared > anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV > are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never > be enabled. Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? > Probably, it was meant to say something like > > depends on SMS_USB_DRV = SMS_SDIO_DRV > > Two other config sections that probably behave differently than expected: > > drivers/staging/rtl8188eu/Kconfig: 13-15 > > config 88EU_AP_MODE > > bool "Realtek RTL8188EU AP mode" > > default Y > > drivers/staging/rtl8188eu/Kconfig: 21-23 > > config 88EU_P2P > > bool "Realtek RTL8188EU Peer-to-peer mode" > > default Y > > The capital Y is different from the lowercase y. While y is an actually > hard coded constant symbol, Y is undeclared and evaluates to n. > The default values are probably only for convenience, so 88EU_AP_MODE and > 88EU_P2P are activated together with 8188EU. They still can be turned off. > Anyway, it should probably say "default y" in both cases. Ditto. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] INPUT: wacom: Added definition for Wacom CTH680 The Wacom Creative Pen & Touch Tablet M (CTH680, 056A:0303) is a newer revision of the Bamboo series. This patch adds product 0303 to wacom.ko.
From: Matthew Geddes
Signed-off-by: Matthew Geddes
---
drivers/input/tablet/wacom_wac.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index c59b797..5015269 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -2128,6 +2128,9 @@ static const struct wacom_features wacom_features_0x300 =
static const struct wacom_features wacom_features_0x301 =
{ "Wacom Bamboo One M",WACOM_PKGLEN_BBPEN,21648, 13530, 1023,
31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x303 =
+ { "Wacom Creative Touch & Pen M", WACOM_PKGLEN_BBPEN, 21648, 13530,
+ 1023, 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0x6004 =
{ "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
@@ -2258,6 +2261,7 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0x10F) },
{ USB_DEVICE_WACOM(0x300) },
{ USB_DEVICE_WACOM(0x301) },
+ { USB_DEVICE_WACOM(0x303) },
{ USB_DEVICE_WACOM(0x304) },
{ USB_DEVICE_WACOM(0x4001) },
{ USB_DEVICE_WACOM(0x47) },
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sg: O_EXCL and other lock handling
On 13-11-01 01:16 AM, vaughan wrote:
On 11/01/2013 03:20 AM, Douglas Gilbert wrote:
On 13-10-31 11:56 AM, Christoph Hellwig wrote:
+struct semaphore or_sem; /* protect co-incident opens and
releases */
Seems like this should be a mutex.
Yes, it is being used as a mutex. However looking at
their semantics (mutex.h versus semaphore.h), a mutex
takes into account the task owner. If the user space
wants to pass around a sg file descriptor in a Unix
domain socket (see TLPI, Kerrisk) I don't see why the
sg driver should object (and pay the small performance
hit for each check).
A nasty side effect of a mutex taking into account the
task owner is that it can't be used in interrupt
context. My patch does not try to do that yet (see next
section) but why bother. Give me a simple mutex and
I'll use it.
sfds_list_empty(Sg_device *sdp)
{
unsigned long flags;
int ret;
+spin_lock_irqsave(&sdp->sfd_lock, flags);
+ret = list_empty(&sdp->sfds);
+spin_unlock_irqrestore(&sdp->sfd_lock, flags);
return ret;
Protecting just a list_empty check with a local will give you racy
results. Seems like you should take the look over the check and the
resulting action that modifies the list. That'd also mean replacing the
wait_event* calls with open coded prepare_wait / finish_wait loops.
Not (usually) in this case. The sdp->sfds list can only
be expanded by another sg_open(same_dev) but this has
been excluded by taking down(&sdp->or_sem) prior to that
call. The sdp->sfds list is only normally decreased by
sg_release() which is also excluded by down(&sdp->or_sem).
The abnormal case is device removal (detaching). Now an
open(same_dev, O_EXCL) may start waiting just after a
detach but miss the wake up on open_wait. That suggests
the wake_up(open_wait) in sg_remove() should also
take the sdp->or_sem semaphore.
Ah, and if sg_remove() can be called from an interrupt
context then that takes out using mutexes :-)
The two level of locks in sg_remove() is already making me
uncomfortable, adding the sdp->or_sem semaphore to the
mix calls for more analysis.
CCed to Jörn Engel.
I feel the same regarding the many locks. After reviewing patches I
wrote these days, I suppose the version 2
(https://lkml.org/lkml/2013/6/17/319) may worth a re-consideration somehow.
The purpose of or_sem is to mutex co-incident open and allow only one
thread to be processing since it completes checking condition to really
linking a new sfd into sfd_siblings list. My v2 re-implement a sem using
sfd_lock and toopen. But as Jörn pointed out in the following mail, what
I implemented is a rw_sem and that is weird and made him "having trouble
wrapping my head around the semantics of this variable"...
With wait_event involved, it's indeed no sense to use a rw_sem here.
However, if we restrict toopen in [0, 1], not [0, INT_MAX] as I did in
v2, it will act in the same way as or_sem does. Beside the same affect
as or_sem, this implement avoids the problem using in interrupt context
and more readable for me, rather than twisting my head among many
spinlocks and semaphores.
Although v2 seems attractive to me, things would be more complicated
when detached comes in...
The following is a thought I presented previously:
Is it possible to split the sg_add_sfp() into two
functions, sg_init_sfp() and sg_add_sfp2(). We can do all initialize
work in sg_init_sfp()
without any lock and let sg_add_sfp2() only serve lock-check-add in one
place. It is less flaky.
I do not follow the last point but that is not important.
For reasons that I listed in a private post I think
that my patch presented in this thread is closer to
our goals than your patch (2013/6/17/319). Timing is
important as well since we are approaching the lk 3.13
merge window. Regressions are what will set us back.
The remaining flaws are in the detach device area
which always seems to be the last one worked on,
probably because it is uncommon and the hardest :-)
My test code hasn't broken this area with my latest
patch (but that may be just luck or not good enough
test strategies).
Also the ULDs should get some basic guarantees from
the mid-level about the attach and remove/detach
device functions. I was thinking along the lines of
"called once and only once" per removed device; won't
overlap with an attach for the same device; may be
called from an interrupt context; should not wait,
etc.
Also note that sdp->detached is only protected by a
volatile type modifier and checks on it are sprinkled
around the code in a rather unscientific way.
As you are no doubt aware, handling the "surprise" device
removal case safely is hard, very hard. And I have tried
to test this, loading up 4 processes with 100 tasks each,
some with asynchronous queueing requests but most hanging
on an open_wait then remove the device. So far I have not
seen a hang. Again, somebody with a big machine and
patience might like to try a scaled up device removal test
to see what breaks.
+d
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
On Saturday 02 of November 2013 13:47:09 Matt Porter wrote:
> On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Tomasz,
> >
> > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote:
> > >Hi Matt,
> > >
> > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote:
> > >>This adds a pair of APIs that allows the generic PHY subsystem to
> > >>provide information on the PHY bus width. The PHY provider driver
> > >>may
> > >>use phy_set_bus_width() to set the bus width that the PHY supports.
> > >>The controller driver may then use phy_get_bus_width() to fetch the
> > >>PHY bus width in order to properly configure the controller.
> > >
> > >I somehow does not like this. If we take this path for any further
> > >properties that we may need, we will end up with a lot of consumer
> > >specific properties stored in a PHY object having their own accessor
> > >functions.
> >
> > Only after all of us feel that a property is *generic* enough, we
> > allow it to be added in the PHY object.
>
> I also want to note that this was discussed over in another thread [2]
> where you did consider my rough stab at a more generic attribute
> accessor. It was definitely my first reaction as the way to do it like
> Tomasz has said. The specific accessors are more readable to me besides
> the justification you mention above.
>
> [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html
Personally I like that version much better, but still it would need to be
polished a bit.
How I imagine such interface to be implemented:
phy.h:
struct phy {
// ...
const struct phy_attrs *attrs;
// ...
};
static inline const struct phy_attrs *phy_get_attrs(struct phy *phy) {
return phy->attrs;
};
phy driver:
static const struct phy_attrs my_phy_attrs = {
// ...
};
static int my_phy_probe(...)
{
// ...
phy = devm_phy_create_attrs(dev, &ops, &my_phy_attrs, NULL);
// ...
}
phy consumer:
// ...
const struct phy_attrs *phy_attrs;
phy_attrs = phy_get_attrs(phy);
// ...
Why I think it is better than what I've seen in this and previous instance
of this thread? (in random order)
a) Only the PHY driver can set the attrs.
b) PHY consumer has access only to a const pointer.
c) PHY attributes can be placed in a static struct inside a driver file,
without the need to call any functions to set particular attributes.
d) Can be extended with more attributes easily.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/9] usb: gadget: s3c-hsotg: enable generic phy support
On Sat, Nov 02, 2013 at 02:09:21PM +0100, Tomasz Figa wrote: > Hi Matt. > > On Friday 01 of November 2013 15:45:54 Matt Porter wrote: > > Adds support for the generic PHY subsystem. Generic PHY > > support is probed and then the driver falls back to checking > > for an old style USB PHY and pdata if not found. > > > > Signed-off-by: Matt Porter > > --- > > drivers/usb/gadget/s3c-hsotg.c | 54 > > -- 1 file changed, 36 > > insertions(+), 18 deletions(-) > > Patches that convert the driver to generic PHY have been already posted by > Kamil Debski, as a part of a series[1] adding generic PHY drivers for S5P > and Exynos SoCs. After that series, there will be no need to support the > usb_phy subsystem in this driver anymore. > > [1] http://www.mail-archive.com/linux-usb@vger.kernel.org/msg31189.html Very nice...embarassing I somehow missed that last week. I deliberately avoided removing that USB PHY support simply because I wanted to leave the Samsung phy conversions to somebody else with hardware to test. ;) I'll drop this patch and rebase on top of that series...thanks for pointing it out. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
On Sat, Nov 02, 2013 at 10:46:55PM +0530, Kishon Vijay Abraham I wrote: > Hi Tomasz, > > On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote: > >Hi Matt, > > > >On Friday 01 of November 2013 15:45:50 Matt Porter wrote: > >>This adds a pair of APIs that allows the generic PHY subsystem to > >>provide information on the PHY bus width. The PHY provider driver may > >>use phy_set_bus_width() to set the bus width that the PHY supports. > >>The controller driver may then use phy_get_bus_width() to fetch the > >>PHY bus width in order to properly configure the controller. > > > >I somehow does not like this. If we take this path for any further > >properties that we may need, we will end up with a lot of consumer > >specific properties stored in a PHY object having their own accessor > >functions. > > Only after all of us feel that a property is *generic* enough, we > allow it to be added in the PHY object. I also want to note that this was discussed over in another thread [2] where you did consider my rough stab at a more generic attribute accessor. It was definitely my first reaction as the way to do it like Tomasz has said. The specific accessors are more readable to me besides the justification you mention above. [2] http://lkml.indiana.edu/hypermail/linux/kernel/1310.3/00673.html -Matt > >Since this is just an integration detail, what about simply adding this as > >a property in device tree node of the OTG controller (and pdata if > >considering non-DT support)? > > We already had a discussion about this and the dt maintainers > suggested the property should be in the PHY. [1] > > [1] -> http://www.spinics.net/lists/devicetree/msg08851.html > > Thanks > Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/6] tpm: MAINTAINERS: Cleanup TPM Maintainers file
From: Peter Huewe - removing stale/inactive maintainers - removing stale/outdated website - regrouped maintainers Signed-off-by: Peter Huewe --- MAINTAINERS |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 936adb4..0f42b97 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8473,14 +8473,10 @@ S: Odd fixes F: drivers/media/usb/tm6000/ TPM DEVICE DRIVER -M: Leonidas Da Silva Barbosa -M: Ashley Lai M: Peter Huewe -M: Rajiv Andrade -W: http://tpmdd.sourceforge.net +M: Ashley Lai M: Marcel Selhorst -M: Sirrix AG -W: http://www.sirrix.com +W: http://tpmdd.sourceforge.net L: tpmdd-de...@lists.sourceforge.net (moderated for non-subscribers) S: Maintained F: drivers/char/tpm/ -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] tpm/tpm_ppi: Check return value of acpi_get_name
From: Peter Huewe
If
status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
fails for whatever reason and does not return AE_OK
if (strstr(buffer.pointer, context) != NULL) {
does dereference a null pointer.
-> Check the return value and return the status to the caller
Found by coverity
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ppi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index 18c5810..6ac9d27 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -30,6 +30,9 @@ static acpi_status ppi_callback(acpi_handle handle, u32
level, void *context,
acpi_status status;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer);
+ if (ACPI_FAILURE(status))
+ return status;
+
if (strstr(buffer.pointer, context) != NULL) {
*return_value = handle;
kfree(buffer.pointer);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] tpm/tpm_ibmvtpm: fix unreachable code warning (smatch warning)
From: Peter Huewe
smatch complains:
/data/data-old/linux-2.6/drivers/char/tpm/tpm_ibmvtpm.c:510
ibmvtpm_crq_process() info: ignoring unreachable code.
-> The return is not necessary here, remove it
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ibmvtpm.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 2783a42..cab8d09 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -507,7 +507,6 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
dev_err(ibmvtpm->dev, "Unknown crq message type: %d\n",
crq->msg);
return;
}
- return;
case IBMVTPM_VALID_CMD:
switch (crq->msg) {
case VTPM_GET_RTCE_BUFFER_SIZE_RES:
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] tpm/tpm_i2c_atmel: fix coccinelle warnings
From: Fengguang Wu
drivers/char/tpm/tpm_i2c_atmel.c:178:8-9: WARNING: return of 0/1 in function
'i2c_atmel_req_canceled' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: coccinelle/misc/boolreturn.cocci
CC: Jason Gunthorpe
CC: Peter Huewe
Acked-By: Jason Gunthorpe
Signed-off-by: Fengguang Wu
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_i2c_atmel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index c3cd7fe..af6805b 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -175,7 +175,7 @@ static struct attribute_group i2c_atmel_attr_grp = {
static bool i2c_atmel_req_canceled(struct tpm_chip *chip, u8 status)
{
- return 0;
+ return false;
}
static const struct tpm_vendor_specific i2c_atmel = {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] tpm/tpm_i2c_stm_st33: Check return code of get_burstcount
From: Peter Huewe
The 'get_burstcount' function can in some circumstances 'return -EBUSY' which
in tpm_stm_i2c_send is stored in an 'u32 burstcnt'
thus converting the signed value into an unsigned value, resulting
in 'burstcnt' being huge.
Changing the type to u32 only does not solve the problem as the signed
value is converted to an unsigned in I2C_WRITE_DATA, resulting in the
same effect.
Thus
-> Change type of burstcnt to u32 (the return type of get_burstcount)
-> Add a check for the return value of 'get_burstcount' and propagate a
potential error.
This makes also sense in the 'I2C_READ_DATA' case, where the there is no
signed/unsigned conversion.
found by coverity
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_i2c_stm_st33.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index a0d6ceb5..cf68403 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -410,6 +410,8 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t
count)
&chip->vendor.read_queue)
== 0) {
burstcnt = get_burstcount(chip);
+ if (burstcnt < 0)
+ return burstcnt;
len = min_t(int, burstcnt, count - size);
I2C_READ_DATA(client, TPM_DATA_FIFO, buf + size, len);
size += len;
@@ -451,7 +453,8 @@ static irqreturn_t tpm_ioserirq_handler(int irq, void
*dev_id)
static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned char *buf,
size_t len)
{
- u32 status, burstcnt = 0, i, size;
+ u32 status, i, size;
+ int burstcnt = 0;
int ret;
u8 data;
struct i2c_client *client;
@@ -482,6 +485,8 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned
char *buf,
for (i = 0; i < len - 1;) {
burstcnt = get_burstcount(chip);
+ if (burstcnt < 0)
+ return burstcnt;
size = min_t(int, len - i - 1, burstcnt);
ret = I2C_WRITE_DATA(client, TPM_DATA_FIFO, buf, size);
if (ret < 0)
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1
From: Peter Huewe
Depending on the implementation strcmp might return the difference between
two strings not only -1,0,1 consequently
if (strcmp (a,b) == -1)
might lead to taking the wrong branch
-> compare with < 0 instead,
which in any case is more canonical.
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ppi.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index 8e562dc..18c5810 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -169,7 +169,7 @@ static ssize_t tpm_store_ppi_request(struct device *dev,
* is updated with function index from SUBREQ to SUBREQ2 since PPI
* version 1.1
*/
- if (strcmp(version, "1.1") == -1)
+ if (strcmp(version, "1.1") < 0)
params[2].integer.value = TPM_PPI_FN_SUBREQ;
else
params[2].integer.value = TPM_PPI_FN_SUBREQ2;
@@ -179,7 +179,7 @@ static ssize_t tpm_store_ppi_request(struct device *dev,
* string/package type. For PPI version 1.0 and 1.1, use buffer type
* for compatibility, and use package type since 1.2 according to spec.
*/
- if (strcmp(version, "1.2") == -1) {
+ if (strcmp(version, "1.2") < 0) {
params[3].type = ACPI_TYPE_BUFFER;
params[3].buffer.length = sizeof(req);
sscanf(buf, "%d", &req);
@@ -245,7 +245,7 @@ static ssize_t tpm_show_ppi_transition_action(struct device
*dev,
* (e.g. Capella with PPI 1.0) need integer/string/buffer type, so for
* compatibility, define params[3].type as buffer, if PPI version < 1.2
*/
- if (strcmp(version, "1.2") == -1) {
+ if (strcmp(version, "1.2") < 0) {
params[3].type = ACPI_TYPE_BUFFER;
params[3].buffer.length = 0;
params[3].buffer.pointer = NULL;
@@ -387,7 +387,7 @@ static ssize_t show_ppi_operations(char *buf, u32 start,
u32 end)
kfree(output.pointer);
output.length = ACPI_ALLOCATE_BUFFER;
output.pointer = NULL;
- if (strcmp(version, "1.2") == -1)
+ if (strcmp(version, "1.2") < 0)
return -EPERM;
params[2].integer.value = TPM_PPI_FN_GETOPR;
--
1.7.5.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] drivers: w1: make w1_slave::flags long to avoid casts
Hi 02.11.2013, 20:59, "Michal Nazarewicz" : >> Argh, why would we just don't do that? Its in-memory field, it can be >> anything, I wouldn't be surprised if it even can be non-atomic because >> of proper locks already being held > > If the driver does not require an atomic set_bit operation for setting > and testing the flag, feel free to prepare a patch replacing the whole > thing with a plain bool. Please make sure it is properly protected if it is ever required -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
Hi Tomasz, On Saturday 02 November 2013 06:44 PM, Tomasz Figa wrote: Hi Matt, On Friday 01 of November 2013 15:45:50 Matt Porter wrote: This adds a pair of APIs that allows the generic PHY subsystem to provide information on the PHY bus width. The PHY provider driver may use phy_set_bus_width() to set the bus width that the PHY supports. The controller driver may then use phy_get_bus_width() to fetch the PHY bus width in order to properly configure the controller. I somehow does not like this. If we take this path for any further properties that we may need, we will end up with a lot of consumer specific properties stored in a PHY object having their own accessor functions. Only after all of us feel that a property is *generic* enough, we allow it to be added in the PHY object. Since this is just an integration detail, what about simply adding this as a property in device tree node of the OTG controller (and pdata if considering non-DT support)? We already had a discussion about this and the dt maintainers suggested the property should be in the PHY. [1] [1] -> http://www.spinics.net/lists/devicetree/msg08851.html Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers: w1: make w1_slave::flags long to avoid casts
> 01.11.2013, 23:30, "Andrew Morton" :
>> set_bit() operates on longs. So if we do
>>
>> struct foo { u32 a; u32 b; } f;
>> set_bit(0, (long *)&f.a);
>>
>> then we'll scribble on f.b on a big-endian 64-bit machine.
On Sat, Nov 02 2013, Рустафа Джамурахметов wrote:
> Argh, why would we just don't do that? Its in-memory field, it can be
> anything, I wouldn't be surprised if it even can be non-atomic because
> of proper locks already being held
If the driver does not require an atomic set_bit operation for setting
and testing the flag, feel free to prepare a patch replacing the whole
thing with a plain bool.
signature.asc
Description: PGP signature
Re: [PATCHv2] coccinelle: Add a script to find unnecessary ifs with no body
> +@r depends on report || context@
> +expression E;
> +position p;
> +@@
> +if@p (E) {}
There should be a * in front of the if, to support context mode.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/befs/linuxvfs.c: need signed cast for variable 'block'
On Sat, Nov 02, 2013 at 08:44:46AM -0700, Greg KH wrote: > > Oh, for me, it is not suitable to move a file system sub-directory to > > "drivers/*/" sub-directory. And I can not find any sub-directory like > > 'staging' under "fs" sub-directory, either. > > > > Do we have any sub-directory like "staging" in "fs" sub-directory? if > > no, do we have to create it or have to use another ways instead of? > > Just move the filesystem to drivers/staging/befs. Actually, having read through that code... It's not too scary; r/w support would've been much more hairy, but this is just r/o. We probably don't need to move that sucker at all. As for befs_get_block(), I'd suggest * taking the range checks for block number into its ->bmap() (just check against the file size and return 0 if it doesn't fit) * turning the check for create != 0 into BUG_ON(create) * making the befs_fblock2brun() failure quiet - the sucker will complain itself, just return that -EFBIG and be done with that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: scsi-mq + open-iscsi support patches..?
-Original Message- From: open-is...@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Nicholas A. Bellinger Sent: Friday, November 01, 2013 1:37 PM To: Mike Christie Cc: open-is...@googlegroups.com; linux-scsi; LKML; target-devel; Or Gerlitz Subject: Re: scsi-mq + open-iscsi support patches..? On Fri, 2013-11-01 at 09:46 -0500, Mike Christie wrote: > On 10/28/13 5:03 PM, Nicholas A. Bellinger wrote: > > Hi Mike, > > > > Just curious as to the status of the scsi-mq conversion patches for > > open-iscsi that you where working on a while back..? > > > > I'm asking because recently I've been spending alot of time with > > scsi-mq > > + virtio-scsi, and would really to start banging on iser-target > > + ports > > using an scsi-mq enabled iser-initiator as well.. > > > > So that said, are there any blockers holding things up towards > > getting a working prototype..? > > > > Just time. Just finished a release at work and just got back from > vacation so hoping to work on this some more in the next weeks. > >Btw, I'm happy to help move things along here too, and have a few extra cycles >to spare.. >> On a related note, some iscsi vendor has been hitting a crash with >> your tree. >I got an email from Jayamohan recently, but the OOPs did not appear to be >scsi-mq related.. I do see the crash on my Ubuntu VM running on VirtualBox but don't see the crash on a Standalone system. Attaching the screenshot > Have you rebased it it to take in Christoph's changes and fixes that > are in Jens's tree? The code here > > https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/lo > g/?h=scsi-mq > > looks ok. That is the current code right? > It's current as of a few weeks ago, but does not include the very latest blk-mq code that's now in next from Jens. I'll be rebasing once blk-mq hits mainline over the next weeks.. ;) --nab -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-is...@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out. <>
Re: Strange location and name for platform devices when device-tree is used.
On Sat, Nov 02, 2013 at 10:09:59AM +1100, Benjamin Herrenschmidt wrote: > On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote: > > > > > On my device I seem to have some platform devices registered through > > > > device-tree, and some registered through platform_device_add (e.g. > > > > 'alarmtimer'). Guaranteeing they remain disjoint sets if the kernel is > > > > allowed to evolve independently of the devicetree might be tricky > > > > Maybe we need "/sys/devices/platform" and "/sys/devices/dt_platform" ?? > > > > > > No, I think device-tree created platform devices should go > > > to /sys/devices/platform like the "classic" ones. > > > > > > The problem is really how to deal with potential name duplication. We > > > could try to register, if we get -EEXIST (assuming sysfs returns the > > > right stuff), try again with ".1" etc... > > > > How can there be device name collisions? All platform devices _should_ > > be named uniquely, if not, you have bigger problems... > > The problem is how to create a unique name from a platform device > created from a device-tree node. I have no idea, and frankly, I don't care, I leave that to the device-tree maintainers, as they are the ones that are using platform devices for this type of kernel interaction. So go blame them for this, not me, remember, I'm the one who _hates_ platform devices and wish they had never been created... > Device tree nodes aren't necessarily uniquely named. They are unique > under a given parent but that hierarchy isn't preserved when creating > corresponding platform devices (and it would be very tricky to do so). > > Currently, we simply append a number to the name when creating them, > which is obtained from a global counter. That's the best solution, you can't rely on device ids being the same for any type of bus, that's just life. > Neil is unhappy about that because on his specific hardware, the device > has a unique name and thus we introduce a naming difference between > device-tree usage and old-style "hard coded" board file usage. > > It would be nice if we could do something that only appends the "global > number" at the end of the name if the name isn't already unique. Thus my > proposal of trying first with the base name, and trying again if that > returns -EEXIST in some kind of loop. Just loop through all the platform devices before registering it to determine if you need to do this, the platform code can do this just fine. If you try to register a duplicate name with the driver core, odds are it will complain loudly, so don't do that. good luck, 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: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
Hello,
Let me first apologize again if this was already discussed. And I also
need to mention that I know almost nothing about elf/randomization/etc.
However,
On 10/29, Namhyung Kim wrote:
>
> # nm foo | grep -e glob$ -e str -e foo
> 006008bc D foo
> 006008a8 D glob
> 006008ac D str
>
> # perf probe -x /home/namhyung/tmp/foo -a 'foo=main+0x13 glob=@0x8a8:s32 \
This does not look right to me.
- get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
->i_mmap_mutex.
- this only allows to read the data from the same binary.
- in particular, you can't read the data from bss
- get_user_vaddr() looks simply wrong. I blindly applied the whole series
and did the test to ensure.
Test-case:
#include
#include
#include
unsigned int global = 0x1234;
void func(void)
{
}
int main(void)
{
char cmd[64];
global = 0x4321;
func();
printf("addr = %p\n", &global);
sprintf(cmd, "cat /proc/%d/maps", getpid());
system(cmd);
return 0;
}
# nm foo | grep -w global
00600a04 D global
# perf probe -x ./foo -a "func var=@0xa04:u32"
# perf record -e probe_foo:func ./foo
addr = 0x600a04
0040-00401000 r-xp fe:01 20958
/root/foo
0060-00601000 rw-p fe:01 20958
/root/foo
...
# perf script | tail -1
foo 555 [000] 1302.345642: probe_foo:func: (40059c) var=1234
Note that it reports "1234", not "4321". This is because
get_user_vaddr() finds another (1st) read-only mapping, and
prints the initial value of "global".
IOW, it reads the memory from 0x400a04, not from 0x600a04.
---
Can't we simply implement get_user_vaddr() as
static void __user *get_user_vaddr(unsigned long addr, struct
trace_uprobe *tu)
{
void __user *vaddr = (void __force __user *)addr;
/* A NULL tu means that we already got the vaddr */
if (tu)
vaddr += (current->mm->start_data & PAGE_MASK);
return vaddr;
}
?
I did this change, and now the test-case above works. And it also works
with "cc -pie -fPIC",
# nm foo | grep -w global
00200c9c D global
# perf probe -x ./foo -a "func var=@0xc9c:u32"
# perf record -e probe_foo:func ./foo
...
# perf script | tail -1
foo 576 [001] 475.519940: probe_foo:func: (7ffe95ca3814)
var=4321
What do you think?
---
Note:
- I think that /* A NULL tu means that we already got the vaddr */
needs more discussion... IOW, I am not sure about 11/13.
- Perhaps it also makes sense to allow to pass the absolute address
(iow, += start_data should be conditional)
but lets ignore this for now.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] gpio: davinci: add OF support
Hi Grygorii, On Mon, Oct 14, 2013 at 5:55 PM, Grygorii Strashko wrote: > Hi Prabhakar Lad, > > On 10/11/2013 07:18 PM, Prabhakar Lad wrote: >> Hi Linus, >> >> On 10/11/13, Linus Walleij wrote: >>> On Fri, Oct 11, 2013 at 4:59 PM, Prabhakar Lad >>> wrote: On 10/11/13, Linus Walleij wrote: > On Fri, Oct 4, 2013 at 6:03 PM, Prabhakar Lad > wrote: >>> >> +- ti,davinci-gpio-irq-base: Base from where GPIO interrupt numbering >> starts. > > What is this? > > If I have ever ACKed this I have been drunk. I take it back. > here is the ACK https://patchwork.kernel.org/patch/2721181/ >>> >>> And as suspected that version of the patch did not contain >>> this strange node property. >>> >> The property did exist in the patch 'intc_irq_num', I just renamed >> it and gave a proper description to it. >> >>> Don't keep my ACK on patches if you change basic stuff like >>> that, they need to be re-acked, this runs the risk of abusing >>> my trust amongst other subsystem maintainers who might >>> go and merge this because "aha the GPIO maintainer >>> thinks that this is OK". >>> >> Agreed, I carry forwarded the ACK since it had minor changes. >> > This "base" is a Linux-specific thing and has no place in the > device tree, and shall not be there. You have to find some way to > avoid this, what do you think some other OS should do with > this value... > > All IRQs in Linux are assumed to be dynamically assigned numbers > nowadays, with a property like this you can never switch on > SPARSE_IRQ for the DaVinci. > Can you point to any alternative solution if you have any ? >>> >>> First convert this GPIO driver to use an irqdomain to map >>> HW IRQs to Linux IRQs, and grab a few IRQ descriptors >>> dynamically off the irq descriptor heap. >>> Example: commit >>> a6c45b99a658521291cfb66ecf035cc58b38f206 >>> "pinctrl/coh901: use irqdomain, allocate irqdescs" >>> >>> Then on a longer term convert DaVinci to use dynamically >>> allocated IRQs for all interrupt controllers, and move it over >>> to SPARSE_IRQ so you know this works. >>> >> Thanks for the pointers. >> > > Could it be possible to use "interrupts" and "interrupt-names" to identify > assigned banked & unbanked IRQs? > I did give thought for it but found out its taken as a single interrupt, and comparing the names in the driver would be tedious. so as of now I have kept as is for this. > For example DM646x (http://www.ti.com/lit/ug/sprueq8a/sprueq8a.pdf): > > interrupts = <48 IRQ_TYPE_EDGE_BOTH>, > <49 IRQ_TYPE_EDGE_BOTH>, > <50 IRQ_TYPE_EDGE_BOTH>, > <51 IRQ_TYPE_EDGE_BOTH>, > <52 IRQ_TYPE_EDGE_BOTH>, > <53 IRQ_TYPE_EDGE_BOTH>, > <54 IRQ_TYPE_EDGE_BOTH>, > <55 IRQ_TYPE_EDGE_BOTH>, > <56 IRQ_TYPE_EDGE_BOTH>, > <57 IRQ_TYPE_EDGE_BOTH>, > <58 IRQ_TYPE_EDGE_BOTH>; > interrupt-names = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4", "gpio5", > "gpio6", "gpio7", "bank0", "bank1", "bank2"; > > For example OMAP-L138 (http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf): > > interrupts = <42 IRQ_TYPE_EDGE_BOTH>, > <43 IRQ_TYPE_EDGE_BOTH>, > <44 IRQ_TYPE_EDGE_BOTH>, > <45 IRQ_TYPE_EDGE_BOTH>, > <46 IRQ_TYPE_EDGE_BOTH>, > <47 IRQ_TYPE_EDGE_BOTH>, > <48 IRQ_TYPE_EDGE_BOTH>, > <49 IRQ_TYPE_EDGE_BOTH>, > <50 IRQ_TYPE_EDGE_BOTH>; > > interrupt-names = "bank0", "bank1", "bank2", "bank3", "bank4", "bank5", > "bank6", "bank7", "bank8"; > > For example Keystone 66AK2E05/02 > (http://www.ti.com/lit/ds/sprs865a/sprs865a.pdf and > http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf): > > interrupts = , > , > [..] > , > ; > > > interrupt-names = "gpio0", "gpio1", [...], "gpio30", "gpio31"; > > So then, following properties would not be needed at all, because all inf. > can be > taken from interrupt's properties: > +- ti,davinci-gpio-irq-base: Base from where GPIO interrupt numbering starts. Yeah dropped this. > +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual > interrupt line to processor. > Kept as is > It should work good if Davinci-gpio driver will be converted to use > linear IRQ domains for banked irqs. > Yeah migrated it to use IRQ domains. I have posted the updated patch series at [1], please have a look at it. [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2013-November/028220.html Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PCI: export MSI mode using attributes, not kobjects
On Fri, Nov 01, 2013 at 05:40:02PM -0600, Bjorn Helgaas wrote: > On Tue, Oct 29, 2013 at 3:46 PM, Greg Kroah-Hartman > wrote: > > From: Greg Kroah-Hartman > > > > The PCI MSI sysfs code is a mess with kobjects for things that don't > > really need to be kobjects. This patch creates attributes dynamically > > for the MSI interrupts instead of using kobjects. > > > > Note, this does not delete the existing sysfs MSI code, but puts the > > attributes under a "msi_irqs_2" directory for testing / example. > > > > Also note, this removes a directory from the current MSI interrupt sysfs > > code: > > > > old MSI kobjects: > > pci_device > >└── msi_irqs > >└── 40 > >└── mode > > > > new MSI attributes: > > pci_device > >└── msi_irqs_2 > >└── 40 > > > > As there was only one file "mode" with the kobject model, the interrupt > > number is now a file that returns the "mode" of the interrupt (msi vs. > > msix). > > > > Signed-off-by: Greg Kroah-Hartman > > --- > > > > Bjorn, I can make up a patch that rips out the existing kobject code > > here, but I figured this patch would make things easier to follow > > instead of having to dig through the removed logic at the same time. > > > > I'll clean up the error handling path for the create attribute logic as > > well, this was just a proof of concept that this could be done. > > > > Do you think that anyone cares about the current mode files in sysfs to > > move things in this manner? > > I like this a lot better than trying to fix all the holes in the > current kobject code. Great. > I have no idea who, if anybody, cares about the "mode" files. I > assume there's a way to create the "mode" files with attributes, too? > If so, we could replicate the existing structure with one patch, and > simplify it with a second patch, so it would be easier to revert the > directory change while keeping the fix. No, we can't create a 2-level deep attribute at the moment, only one level, like the patch does. Based on Neil's comments, I think we should be fine with this as-is as no one is messing with these files directly (which implies that we could possibly just remove them entirely to save us the overall pain...) Want me to redo this in a way that is acceptable (i.e. remove the existing code at the same time?) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/6] ARM: davinci: da850: add GPIO DT node
From: KV Sujith
Add DT node for Davinci GPIO driver.
Signed-off-by: KV Sujith
Signed-off-by: Philip Avinash
Signed-off-by: Lad, Prabhakar
---
arch/arm/boot/dts/da850.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8d17346..d7b4cd6 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -8,6 +8,7 @@
* option) any later version.
*/
#include "skeleton.dtsi"
+#include
/ {
arm {
@@ -256,6 +257,20 @@
36
>;
};
+ gpio: gpio@1e26000 {
+ compatible = "ti,dm6441-gpio";
+ gpio-controller;
+ reg = <0x226000 0x1000>;
+ interrupts = <42 IRQ_TYPE_EDGE_BOTH
+ 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
+ 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
+ 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
+ 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH>;
+ ti,ngpio = <144>;
+ ti,davinci-gpio-irq-base = <101>;
+ ti,davinci-gpio-unbanked = <0>;
+ status = "disabled";
+ };
};
nand_cs3@6200 {
compatible = "ti,davinci-nand";
--
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] fs/befs/linuxvfs.c: need signed cast for variable 'block'
On Sat, Nov 02, 2013 at 09:46:31PM +0800, Chen Gang wrote:
> On 11/01/2013 10:41 AM, Chen Gang wrote:
> > On 11/01/2013 04:45 AM, Greg KH wrote:
> >> On Thu, Oct 31, 2013 at 12:08:33PM -0700, Kees Cook wrote:
> >>> On Thu, Oct 31, 2013 at 12:06 PM, Al Viro wrote:
> On Thu, Oct 31, 2013 at 09:53:59AM -0700, Kees Cook wrote:
>
> > If block (type sector_t) is unsigned, we shouldn't cast it signed.
> > This entire code path should be removed. What is BEFS's expected
> > maximum block size? (Looks like even befs_blocknr_t is u64, so nothing
> > seems trivially in danger of wrapping.) I would also note that all the
> > format strings are wrong too (%ld instead of %lu).
>
> FWIW, this
> res = befs_fblock2brun(sb, ds, block, &run);
> if (res != BEFS_OK) {
> befs_error(sb,
> "<--- befs_get_block() for inode %lu, block "
> "%ld ERROR", inode->i_ino, block);
> return -EFBIG;
> }
> also looks wrong - ioctl(..., FIBMAP, ...) shouldn't be able to spew
> printks on a valid fs and hitting it with block number greater than
> file length will, AFAICS, trigger that.
>
> I agree that this code needs fixing, but just making gcc STFU about the
> comparison would only serve to hide the problem. Anybody familiar with
> befs or willing to learn it?
> >>>
> >>> Agreed. MAINTAINERS shows it as orphaned. Perhaps it should be moved
> >>> into staging?
> >>
> >> Only if we want to delete the thing. I'll be glad to take it there, and
> >> remove it in 2 releases and then if anyone complains, we can add it back
> >> easily. Just let me know.
> >>
> >
> > Excuse me, I am not quite familiar with BEFS, I guess your meaning is:
> >
> > "if it is no further more discussion (e.g. within 1 week, no members
> > reply), you will remove it (take it to "drivers/staging" sub-directory)".
> >
>
> Oh, for me, it is not suitable to move a file system sub-directory to
> "drivers/*/" sub-directory. And I can not find any sub-directory like
> 'staging' under "fs" sub-directory, either.
>
> Do we have any sub-directory like "staging" in "fs" sub-directory? if
> no, do we have to create it or have to use another ways instead of?
Just move the filesystem to drivers/staging/befs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/6] gpio: davinci: Fixed a check for unbanked gpio
From: "Lad, Prabhakar" This patch fixes the check for the offset in gpio_to_irq_unbanked() function. Signed-off-by: Lad, Prabhakar --- drivers/gpio/gpio-davinci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c index 8847adf..6c90cfb 100644 --- a/drivers/gpio/gpio-davinci.c +++ b/drivers/gpio/gpio-davinci.c @@ -327,7 +327,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset) * NOTE: we assume for now that only irqs in the first gpio_chip * can provide direct-mapped IRQs to AINTC (up to 32 GPIOs). */ - if (offset < d->irq_base) + if (offset < d->gpio_unbanked) return d->gpio_irq + offset; else return -ENODEV; -- 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 v4 6/6] ARM: davinci: da850 evm: add GPIO pinumux entries DT node
From: KV Sujith
Add GPIO DT node and pinmux entries for DA850 EVM. GPIO is
configurable differently on different boards. So add GPIO
pinmuxing in dts file.
Signed-off-by: KV Sujith
Signed-off-by: Philip Avinash
Signed-off-by: Lad, Prabhakar
---
arch/arm/boot/dts/da850-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 588ce58..f82c129 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -17,6 +17,21 @@
soc {
pmx_core: pinmux@1c14120 {
status = "okay";
+
+ gpio_pins: pinmux_gpio_pins {
+ pinctrl-single,bits = <
+ /* GPIO2_4 GPIO2_6 */
+ 0x18 0x8080 0xf0f0
+ /* GPIO2_8 GPIO2_15 */
+ 0x14 0x8008 0xf00f
+ /* GPIO3_12 GPIO3_13 */
+ 0x1C 0x8800 0xff00
+ /* GPIO4_0 GPIO4_1 */
+ 0x28 0x8800 0xff00
+ /* GPIO6_9 GPIO6_10 GPIO6_13 */
+ 0x34 0x08800800 0x0ff00f00
+ >;
+ };
};
serial0: serial@1c42000 {
status = "okay";
@@ -101,6 +116,11 @@
pinctrl-names = "default";
pinctrl-0 = <&mii_pins>;
};
+ gpio: gpio@1e26000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_pins>;
+ };
};
nand_cs3@6200 {
status = "okay";
--
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 v4 4/6] gpio: davinci: add OF support
From: KV Sujith
This patch adds OF parser support for davinci gpio
driver and also appropriate documentation in gpio-davinci.txt
located at Documentation/devicetree/bindings/gpio/.
Signed-off-by: KV Sujith
Signed-off-by: Philip Avinash
[prabhakar.cse...@gmail.com: simplified the OF code, removed
unnecessary DT property and also simplified
the commit message]
Signed-off-by: Lad, Prabhakar
---
.../devicetree/bindings/gpio/gpio-davinci.txt | 32
drivers/gpio/gpio-davinci.c| 54 ++--
2 files changed, 83 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
new file mode 100644
index 000..55aae1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -0,0 +1,32 @@
+Davinci GPIO controller bindings
+
+Required Properties:
+- compatible: should be "ti,dm6441-gpio"
+
+- reg: Physical base address of the controller and the size of memory mapped
+ registers.
+
+- gpio-controller : Marks the device node as a gpio controller.
+
+- interrupts: Array of GPIO interrupt number.
+
+- ti,ngpio: The number of GPIO pins supported.
+
+- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual
interrupt
+line to processor.
+
+Example:
+
+gpio: gpio@1e26000 {
+ compatible = "ti,dm6441-gpio";
+ gpio-controller;
+ reg = <0x226000 0x1000>;
+ interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
+ 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
+ 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
+ 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
+ 50 IRQ_TYPE_EDGE_BOTH>;
+ ti,ngpio = <144>;
+ ti,davinci-gpio-irq-base = <101>;
+ ti,davinci-gpio-unbanked = <0>;
+};
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index bcb6d8d..bb20a39 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -134,6 +137,40 @@ davinci_gpio_set(struct gpio_chip *chip, unsigned offset,
int value)
__raw_writel((1 << offset), value ? &g->set_data : &g->clr_data);
}
+static struct davinci_gpio_platform_data *
+davinci_gpio_get_pdata(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ struct davinci_gpio_platform_data *pdata;
+ int ret;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+ return pdev->dev.platform_data;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ ret = of_property_read_u32(dn, "ti,ngpio", &val);
+ if (ret)
+ goto of_err;
+
+ pdata->ngpio = val;
+
+ ret = of_property_read_u32(dn, "ti,davinci-gpio-unbanked", &val);
+ if (ret)
+ goto of_err;
+
+ pdata->gpio_unbanked = val;
+
+ return pdata;
+
+of_err:
+ dev_err(&pdev->dev, "Populating pdata from DT failed: err %d\n", ret);
+ return NULL;
+}
+
static int davinci_gpio_probe(struct platform_device *pdev)
{
int i, base;
@@ -144,12 +181,14 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
struct device *dev = &pdev->dev;
struct resource *res;
- pdata = dev->platform_data;
+ pdata = davinci_gpio_get_pdata(pdev);
if (!pdata) {
dev_err(dev, "No platform data found\n");
return -EINVAL;
}
+ dev->platform_data = pdata;
+
/*
* The gpio banks conceptually expose a segmented bitmap,
* and "ngpio" is one more than the largest zero-based
@@ -501,11 +540,20 @@ done:
return 0;
}
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id davinci_gpio_ids[] = {
+ { .compatible = "ti,dm6441-gpio", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
+#endif
+
static struct platform_driver davinci_gpio_driver = {
.probe = davinci_gpio_probe,
.driver = {
- .name = "davinci_gpio",
- .owner = THIS_MODULE,
+ .name = "davinci_gpio",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(davinci_gpio_ids),
},
};
--
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 v4 3/6] gpio: davinci: use irqdomain
From: "Lad, Prabhakar"
This patch converts the davinci gpio driver to use irqdomain
support.
Signed-off-by: Lad, Prabhakar
---
arch/arm/mach-davinci/da830.c |1 -
arch/arm/mach-davinci/da850.c |1 -
arch/arm/mach-davinci/dm355.c |1 -
arch/arm/mach-davinci/dm365.c |1 -
arch/arm/mach-davinci/dm644x.c |1 -
arch/arm/mach-davinci/dm646x.c |1 -
drivers/gpio/gpio-davinci.c| 49 ++--
include/linux/platform_data/gpio-davinci.h |3 +-
8 files changed, 32 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 0813b51..fb72035 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -1153,7 +1153,6 @@ static struct davinci_id da830_ids[] = {
static struct davinci_gpio_platform_data da830_gpio_platform_data = {
.ngpio = 128,
- .intc_irq_num = DA830_N_CP_INTC_IRQ,
};
int __init da830_register_gpio(void)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 352984e..4379317 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1283,7 +1283,6 @@ int __init da850_register_vpif_capture(struct
vpif_capture_config
static struct davinci_gpio_platform_data da850_gpio_platform_data = {
.ngpio = 144,
- .intc_irq_num = DA850_N_CP_INTC_IRQ,
};
int __init da850_register_gpio(void)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index ef9ff1f..5160aed 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -900,7 +900,6 @@ static struct resource dm355_gpio_resources[] = {
static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
.ngpio = 104,
- .intc_irq_num = DAVINCI_N_AINTC_IRQ,
};
int __init dm355_gpio_register(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1511a06..4fe29fa 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -713,7 +713,6 @@ static struct resource dm365_gpio_resources[] = {
static struct davinci_gpio_platform_data dm365_gpio_platform_data = {
.ngpio = 104,
- .intc_irq_num = DAVINCI_N_AINTC_IRQ,
.gpio_unbanked = 8,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 143a321..178cb68 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -786,7 +786,6 @@ static struct resource dm644_gpio_resources[] = {
static struct davinci_gpio_platform_data dm644_gpio_platform_data = {
.ngpio = 71,
- .intc_irq_num = DAVINCI_N_AINTC_IRQ,
};
int __init dm644x_gpio_register(void)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 2a73f29..01c576f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -763,7 +763,6 @@ static struct resource dm646x_gpio_resources[] = {
static struct davinci_gpio_platform_data dm646x_gpio_platform_data = {
.ngpio = 43,
- .intc_irq_num = DAVINCI_N_AINTC_IRQ,
};
int __init dm646x_gpio_register(void)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 95c6df1..bcb6d8d 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,7 +293,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
__raw_writel(status, &g->intstat);
/* now demux them to the right lowlevel handler */
- n = d->irq_base;
+ n = irq_find_mapping(d->irq_domain, 0);
if (irq & 1) {
n += 16;
status >>= 16;
@@ -313,10 +314,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip,
unsigned offset)
{
struct davinci_gpio_controller *d = chip2controller(chip);
- if (d->irq_base >= 0)
- return d->irq_base + offset;
- else
- return -ENODEV;
+ return irq_find_mapping(d->irq_domain, offset);
}
static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
@@ -373,6 +371,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
+ int gpio_irq = 0;
ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -402,9 +401,15 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
*/
for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) {
chips[bank].chip.to_irq = gpio_to_irq_banked;
- chips[bank].irq_b
[PATCH v4 2/6] gpio: davinci: remove unnecessary printk
From: "Lad, Prabhakar"
the devm_*() helper prints error messages in case of
errors no need to do the same in the driver.
Signed-off-by: Lad, Prabhakar
---
drivers/gpio/gpio-davinci.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 6c90cfb..95c6df1 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -389,11 +389,9 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
}
clk = devm_clk_get(dev, "gpio");
- if (IS_ERR(clk)) {
- printk(KERN_ERR "Error %ld getting gpio clock?\n",
- PTR_ERR(clk));
+ if (IS_ERR(clk))
return PTR_ERR(clk);
- }
+
clk_prepare_enable(clk);
/*
--
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 3.11 00/66] 3.11.7-stable review
On Fri, Nov 01, 2013 at 07:31:26PM -0700, Guenter Roeck wrote: > On Fri, Nov 01, 2013 at 03:06:36PM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.11.7 release. > > There are 66 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 Nov 3 22:04:49 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.7-rc1.gz > > and the diffstat can be found below. > > > Build results look good: > total: 110 pass: 108 skipped: 2 fail: 0 > > qemu tests all pass. > > Details are at http://server.roeck-us.net:8010/builders. Thanks for testing all three of these 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/
[PATCH v4 0/6] gpio: daVinci: Fixes and feature enhancement
From: "Lad, Prabhakar" Patches 1, 2 and 3 are newly added. This patch series does the following a> Fixes check for offset for unbanked gpios. b> Ports the driver to use irqdomain. c> Adds dt binding support for gpio-davinci. d> Adds DA850 dt support goio. Changes for v4: 1: Added irqdomain support for the driver. 2: Dropped the ACK's. 3: Removed unnecessary DT property. This patch series has been tested on DA850 for GPIO7_4 (ie switch 8 on SW7.). Patches can be found at [1]. [1] http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/davinci_gpio KV Sujith (3): gpio: davinci: add OF support ARM: davinci: da850: add GPIO DT node ARM: davinci: da850 evm: add GPIO pinumux entries DT node Lad, Prabhakar (3): gpio: davinci: Fixed a check for unbanked gpio gpio: davinci: remove unnecessary printk gpio: davinci: use irqdomain .../devicetree/bindings/gpio/gpio-davinci.txt | 32 ++ arch/arm/boot/dts/da850-evm.dts| 20 arch/arm/boot/dts/da850.dtsi | 15 +++ arch/arm/mach-davinci/da830.c |1 - arch/arm/mach-davinci/da850.c |1 - arch/arm/mach-davinci/dm355.c |1 - arch/arm/mach-davinci/dm365.c |1 - arch/arm/mach-davinci/dm644x.c |1 - arch/arm/mach-davinci/dm646x.c |1 - drivers/gpio/gpio-davinci.c| 111 +++- include/linux/platform_data/gpio-davinci.h |3 +- 11 files changed, 153 insertions(+), 34 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt -- 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/
[PATCHv2] coccinelle: Add a script to find unnecessary ifs with no body
This script finds code like this, with an unnecessary if:
if (foo) {}
Provides report mode only, since patching often eliminates conditionals
that contain TODO comments or similar.
Signed-off-by: Josh Triplett
---
v2: Drop patch mode.
scripts/coccinelle/misc/unnecessary-if.cocci | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 scripts/coccinelle/misc/unnecessary-if.cocci
diff --git a/scripts/coccinelle/misc/unnecessary-if.cocci
b/scripts/coccinelle/misc/unnecessary-if.cocci
new file mode 100644
index 000..28ac895
--- /dev/null
+++ b/scripts/coccinelle/misc/unnecessary-if.cocci
@@ -0,0 +1,23 @@
+/// Find unnecessary ifs with no statements.
+//
+// Report mode only, since patch mode often deletes ifs that contain TODO
+// comments.
+//
+// Confidence: High
+// Options: --no-includes --include-headers
+
+virtual report
+virtual context
+
+@r depends on report || context@
+expression E;
+position p;
+@@
+if@p (E) {}
+
+@script:python depends on report@
+p << r.p;
+@@
+
+msg = "WARNING: Unnecessary if with no body."
+coccilib.report.print_report(p[0], msg)
--
1.8.4.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] coccinelle: Add a script to find and remove unnecessary ifs with no body
> I observed several where the patch seemed entirely correct, with no > FIXME/TODO/XXX comments associated with the conditional. > > Nonetheless, I don't mind removing the patch mode if you don't think > it's worthwhile. I'll send a v2. I think it would be better without it. thanks, julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: Add a script to find and remove unnecessary ifs with no body
On Sat, Nov 02, 2013 at 03:51:50PM +0100, Julia Lawall wrote:
> On Sat, 2 Nov 2013, Josh Triplett wrote:
>
> > This script matches code like:
> >
> > if (foo) {}
> >
> > and either eliminates it (if foo has no side effects) or replaces it
> > with foo (if foo has side effects).
> >
> > Works perfectly in report mode; the results of patch mode are
> > semantically correct but may still benefit from further simplification.
>
> Actually, I would get rid of the patch mode. Looking through some of the
> results, I don't see any where just deleting the code is the right thing
> to do. They all look like cases where the developer wanted to remember to
> think more about the problem.
I observed several where the patch seemed entirely correct, with no
FIXME/TODO/XXX comments associated with the conditional.
Nonetheless, I don't mind removing the patch mode if you don't think
it's worthwhile. I'll send a v2.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] coccinelle: Add a script to find and remove unnecessary ifs with no body
On Sat, 2 Nov 2013, Josh Triplett wrote:
> This script matches code like:
>
> if (foo) {}
>
> and either eliminates it (if foo has no side effects) or replaces it
> with foo (if foo has side effects).
>
> Works perfectly in report mode; the results of patch mode are
> semantically correct but may still benefit from further simplification.
Actually, I would get rid of the patch mode. Looking through some of the
results, I don't see any where just deleting the code is the right thing
to do. They all look like cases where the developer wanted to remember to
think more about the problem.
julia
>
> Signed-off-by: Josh Triplett
> ---
> scripts/coccinelle/misc/unnecessary-if.cocci | 40
>
> 1 file changed, 40 insertions(+)
> create mode 100644 scripts/coccinelle/misc/unnecessary-if.cocci
>
> diff --git a/scripts/coccinelle/misc/unnecessary-if.cocci
> b/scripts/coccinelle/misc/unnecessary-if.cocci
> new file mode 100644
> index 000..7ed721f
> --- /dev/null
> +++ b/scripts/coccinelle/misc/unnecessary-if.cocci
> @@ -0,0 +1,40 @@
> +/// Remove unnecessary ifs with no statements.
> +//
> +// Confidence: High
> +// Options: --no-includes --include-headers
> +
> +virtual patch
> +virtual report
> +virtual context
> +
> +@r1 depends on patch@
> +expression E, E2, f;
> +@@
> +(
> +- if (
> + <+... \(f(...)\|++E\|--E\|E++\|E--\|E=E2\) ...+>
> +- ) {}
> ++ ;
> +|
> +- if (E) {}
> +)
> +
> +@r2 depends on report || context@
> +expression E, E2, f;
> +position p;
> +@@
> +(
> +- if@p (
> + <+... \(f(...)\|++E\|--E\|E++\|E--\|E=E2\) ...+>
> +- ) {}
> ++ ;
> +|
> +- if@p (E) {}
> +)
> +
> +@script:python depends on report@
> +p << r2.p;
> +@@
> +
> +msg = "WARNING: Unnecessary if with no body."
> +coccilib.report.print_report(p[0], msg)
> --
> 1.8.4.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] coccinelle: Add a script to find and remove unnecessary ifs with no body
This script matches code like:
if (foo) {}
and either eliminates it (if foo has no side effects) or replaces it
with foo (if foo has side effects).
Works perfectly in report mode; the results of patch mode are
semantically correct but may still benefit from further simplification.
Signed-off-by: Josh Triplett
---
scripts/coccinelle/misc/unnecessary-if.cocci | 40
1 file changed, 40 insertions(+)
create mode 100644 scripts/coccinelle/misc/unnecessary-if.cocci
diff --git a/scripts/coccinelle/misc/unnecessary-if.cocci
b/scripts/coccinelle/misc/unnecessary-if.cocci
new file mode 100644
index 000..7ed721f
--- /dev/null
+++ b/scripts/coccinelle/misc/unnecessary-if.cocci
@@ -0,0 +1,40 @@
+/// Remove unnecessary ifs with no statements.
+//
+// Confidence: High
+// Options: --no-includes --include-headers
+
+virtual patch
+virtual report
+virtual context
+
+@r1 depends on patch@
+expression E, E2, f;
+@@
+(
+- if (
+ <+... \(f(...)\|++E\|--E\|E++\|E--\|E=E2\) ...+>
+- ) {}
++ ;
+|
+- if (E) {}
+)
+
+@r2 depends on report || context@
+expression E, E2, f;
+position p;
+@@
+(
+- if@p (
+ <+... \(f(...)\|++E\|--E\|E++\|E--\|E=E2\) ...+>
+- ) {}
++ ;
+|
+- if@p (E) {}
+)
+
+@script:python depends on report@
+p << r2.p;
+@@
+
+msg = "WARNING: Unnecessary if with no body."
+coccilib.report.print_report(p[0], msg)
--
1.8.4.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: [Suggestion] about latest commit for "scripts/get_maintainers.pl"
On 11/02/2013 02:32 AM, Joe Perches wrote:
> On Fri, 2013-11-01 at 19:20 +0800, Chen Gang wrote:
>> > Hello Joe:
> Hello Chen Gang.
>
>> > I meet a failure about "scripts/get_maintainers.pl", it is about the
>> > commit "750432d get_maintainer.pl incomplete output", if use original
>> > "scripts/get_maintainer.pl", it will be OK.
>> >
>> > Please help check, thanks.
> I don't get that effect.
For me now, I made 3 patches for hexagon, 2 of them can cause issue. I
use sfr next-20131101 tree, the related patch is in attachment (1, 3 can
cause issue), hope they are useful for us.
> I'll look into it and see what I find next week.
Thank you very much, just please help analyze it when you have time.
> You seem to have a work-around available.
Yes, at least now, it doesn't matter to me. I guess this issue is not
urgent to us.
Thanks.
--
Chen Gang
>From ef7384078bacdc5151039ea710943e5710d7c5ed Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 18:58:18 +0800
Subject: [PATCH 1/3] hexagon: kernel: remove useless variables 'dn', 'r' and
'err' in time_init_deferred() in "time.c"
Signed-off-by: Chen Gang
---
arch/hexagon/kernel/time.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/hexagon/kernel/time.c b/arch/hexagon/kernel/time.c
index 9903fad..d0c4f5a 100644
--- a/arch/hexagon/kernel/time.c
+++ b/arch/hexagon/kernel/time.c
@@ -191,9 +191,6 @@ void __init time_init_deferred(void)
{
struct resource *resource = NULL;
struct clock_event_device *ce_dev = &hexagon_clockevent_dev;
- struct device_node *dn;
- struct resource r;
- int err;
ce_dev->cpumask = cpu_all_mask;
--
1.7.7.6
>From 2e587500be49b44b8d8a5b1e429c6f75b0803495 Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 19:44:02 +0800
Subject: [PATCH] hexagon: kernel: kgdb: include related header for pass compiling.
Need include related headers for pass compiling, the related error (with allmodconfig for v4):
CC arch/hexagon/kernel/kgdb.o
arch/hexagon/kernel/kgdb.c:30: error: invalid use of undefined type 'struct pt_regs'
arch/hexagon/kernel/kgdb.c:31: error: invalid use of undefined type 'struct pt_regs'
...
arch/hexagon/kernel/kgdb.c:220: error: implicit declaration of function 'local_irq_save'
arch/hexagon/kernel/kgdb.c:222: error: implicit declaration of function 'local_irq_restore'
...
Signed-off-by: Chen Gang
---
arch/hexagon/kernel/kgdb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 82d5c25..038580c 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -18,6 +18,8 @@
* 02110-1301, USA.
*/
+#include
+#include
#include
#include
--
1.7.7.6
>From cc69a713ea496aa8e952d9c3c312a659dc1fd5ab Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Fri, 1 Nov 2013 19:45:59 +0800
Subject: [PATCH] hexagon: include: asm: kgdb: extend DBG_MAX_REG_NUM for "cs0/1"
Need extend maximized number for "cs0/1", the related warning (with allmodconfig for v4):
arch/hexagon/kernel/kgdb.c:79: warning: excess elements in array initializer
arch/hexagon/kernel/kgdb.c:79: warning: (near initialization for 'dbg_reg_def')
arch/hexagon/kernel/kgdb.c:80: warning: excess elements in array initializer
arch/hexagon/kernel/kgdb.c:80: warning: (near initialization for 'dbg_reg_def')
Signed-off-by: Chen Gang
---
arch/hexagon/include/asm/kgdb.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/hexagon/include/asm/kgdb.h b/arch/hexagon/include/asm/kgdb.h
index 32a6fb6..ccd3ac3 100644
--- a/arch/hexagon/include/asm/kgdb.h
+++ b/arch/hexagon/include/asm/kgdb.h
@@ -34,10 +34,11 @@ static inline void arch_kgdb_breakpoint(void)
* 32 gpr + sa0/1 + lc0/1 + m0/1 + gp + ugp + pred + pc = 42 total.
* vm regs = psp+elr+est+badva = 4
* syscall+restart = 2 more
- * so 48 = 42 +4 + 2
+ * also add cs0/1 = 2
+ * so 48 = 42 + 4 + 2 + 2
*/
#define DBG_USER_REGS 42
-#define DBG_MAX_REG_NUM (DBG_USER_REGS + 6)
+#define DBG_MAX_REG_NUM (DBG_USER_REGS + 8)
#define NUMREGBYTES (DBG_MAX_REG_NUM*4)
#endif /* __HEXAGON_KGDB_H__ */
--
1.7.7.6
Re: [PATCH v2 05/13] uprobes: add arch write opcode hook
On 11/01, David Long wrote: > > On 10/29/13 15:59, Oleg Nesterov wrote: >> >> Or. arm can actually reimplement set_swbp(). This doesn't mean the >> duplication of write_opcode() code, we can simply export this helper. >> > > That actually looks to me like the cleanest approach. I have changed > the static write_opcode() to a global uprobe_write_opcode(), and now > call it from an arm set_swbp(). OK, great. > Please do *not* make set_swbp() (and set_orig_insn()) static's. It > looks like we now have a use for at least one of them. I am not sure... it still seems to me it makes sense to cleanup this interface... But. I am not going to do this until we merge your changes. We will see then. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-next 07/13] driver: staging: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL while
calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c | 3 +--
drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c | 3 +--
drivers/staging/rtl8188eu/core/rtw_recv.c | 6 ++
drivers/staging/rtl8192e/rtllib_rx.c | 3 +--
drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 3 +--
drivers/staging/rtl8712/recv_linux.c | 3 +--
drivers/staging/rtl8712/rtl8712_recv.c | 6 ++
drivers/staging/rtl8712/xmit_linux.c | 3 +--
drivers/staging/sbe-2t3e3/dc.c | 12
9 files changed, 14 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
b/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
index 10b2210..bbafdcc 100644
--- a/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8187se/ieee80211/ieee80211_rx.c
@@ -138,8 +138,7 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
if (ieee->frag_next_idx[tid] >= IEEE80211_FRAG_CACHE_LEN)
ieee->frag_next_idx[tid] = 0;
- if (entry->skb != NULL)
- dev_kfree_skb_any(entry->skb);
+ dev_kfree_skb_any(entry->skb);
entry->first_frag_time = jiffies;
entry->seq = seq;
diff --git a/drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c
b/drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c
index b346653..fe747b1 100644
--- a/drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8187se/ieee80211/ieee80211_tx.c
@@ -234,8 +234,7 @@ void ieee80211_txb_free(struct ieee80211_txb *txb) {
if (unlikely(!txb))
return;
for (i = 0; i < txb->nr_frags; i++)
- if (txb->fragments[i])
- dev_kfree_skb_any(txb->fragments[i]);
+ dev_kfree_skb_any(txb->fragments[i]);
kfree(txb);
}
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index 2011657..93fb9ed 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -209,10 +209,8 @@ int rtw_free_recvframe(union recv_frame *precvframe,
struct __queue *pfree_recv_
_func_enter_;
- if (precvframe->u.hdr.pkt) {
- dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by driver
*/
- precvframe->u.hdr.pkt = NULL;
- }
+ dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by driver */
+ precvframe->u.hdr.pkt = NULL;
_enter_critical_bh(&pfree_recv_queue->lock, &irqL);
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 8aeaed5..0118854 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -133,8 +133,7 @@ rtllib_frag_cache_get(struct rtllib_device *ieee,
if (ieee->frag_next_idx[tid] >= RTLLIB_FRAG_CACHE_LEN)
ieee->frag_next_idx[tid] = 0;
- if (entry->skb != NULL)
- dev_kfree_skb_any(entry->skb);
+ dev_kfree_skb_any(entry->skb);
entry->first_frag_time = jiffies;
entry->seq = seq;
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index 59900bf..70bf7a4 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -138,8 +138,7 @@ ieee80211_frag_cache_get(struct ieee80211_device *ieee,
if (ieee->frag_next_idx[tid] >= IEEE80211_FRAG_CACHE_LEN)
ieee->frag_next_idx[tid] = 0;
- if (entry->skb != NULL)
- dev_kfree_skb_any(entry->skb);
+ dev_kfree_skb_any(entry->skb);
entry->first_frag_time = jiffies;
entry->seq = seq;
diff --git a/drivers/staging/rtl8712/recv_linux.c
b/drivers/staging/rtl8712/recv_linux.c
index 495ee12..c422d1f 100644
--- a/drivers/staging/rtl8712/recv_linux.c
+++ b/drivers/staging/rtl8712/recv_linux.c
@@ -75,8 +75,7 @@ int r8712_os_recvbuf_resource_alloc(struct _adapter *padapter,
int r8712_os_recvbuf_resource_free(struct _adapter *padapter,
struct recv_buf *precvbuf)
{
- if (precvbuf->pskb)
- dev_kfree_skb_any(precvbuf->pskb);
+ dev_kfree_skb_any(precvbuf->pskb);
if (precvbuf->purb) {
usb_kill_urb(precvbuf->purb);
usb_free_urb(precvbuf->purb);
diff --git a/drivers/staging/rtl8712/rtl8712_recv.c
b/drivers/staging/rtl8712/rtl8712_recv.c
index d59a74a..9a4e87c 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -145,10 +145,8 @@ int r8712_free_recvf
Re: [PATCH] fs/befs/linuxvfs.c: need signed cast for variable 'block'
On 11/01/2013 10:41 AM, Chen Gang wrote:
> On 11/01/2013 04:45 AM, Greg KH wrote:
>> On Thu, Oct 31, 2013 at 12:08:33PM -0700, Kees Cook wrote:
>>> On Thu, Oct 31, 2013 at 12:06 PM, Al Viro wrote:
On Thu, Oct 31, 2013 at 09:53:59AM -0700, Kees Cook wrote:
> If block (type sector_t) is unsigned, we shouldn't cast it signed.
> This entire code path should be removed. What is BEFS's expected
> maximum block size? (Looks like even befs_blocknr_t is u64, so nothing
> seems trivially in danger of wrapping.) I would also note that all the
> format strings are wrong too (%ld instead of %lu).
FWIW, this
res = befs_fblock2brun(sb, ds, block, &run);
if (res != BEFS_OK) {
befs_error(sb,
"<--- befs_get_block() for inode %lu, block "
"%ld ERROR", inode->i_ino, block);
return -EFBIG;
}
also looks wrong - ioctl(..., FIBMAP, ...) shouldn't be able to spew
printks on a valid fs and hitting it with block number greater than
file length will, AFAICS, trigger that.
I agree that this code needs fixing, but just making gcc STFU about the
comparison would only serve to hide the problem. Anybody familiar with
befs or willing to learn it?
>>>
>>> Agreed. MAINTAINERS shows it as orphaned. Perhaps it should be moved
>>> into staging?
>>
>> Only if we want to delete the thing. I'll be glad to take it there, and
>> remove it in 2 releases and then if anyone complains, we can add it back
>> easily. Just let me know.
>>
>
> Excuse me, I am not quite familiar with BEFS, I guess your meaning is:
>
> "if it is no further more discussion (e.g. within 1 week, no members
> reply), you will remove it (take it to "drivers/staging" sub-directory)".
>
Oh, for me, it is not suitable to move a file system sub-directory to
"drivers/*/" sub-directory. And I can not find any sub-directory like
'staging' under "fs" sub-directory, either.
Do we have any sub-directory like "staging" in "fs" sub-directory? if
no, do we have to create it or have to use another ways instead of?
After reference the "drivers/staging" explanation (list below), we know
it is only for drivers (not fs).
menuconfig STAGING
bool "Staging drivers"
default n
---help---
This option allows you to select a number of drivers that are
not of the "normal" Linux kernel quality level. These drivers
are placed here in order to get a wider audience to make use of
them. Please note that these drivers are under heavy
development, may or may not work, and may contain userspace
interfaces that most likely will be changed in the near
future.
Using any of these drivers will taint your kernel which might
affect support options from both the community, and various
commercial support organizations.
If you wish to work on these drivers, to help improve them, or
to report problems you have with them, please see the
driver_name.README file in the drivers/staging/ directory to
see what needs to be worked on, and who to contact.
If in doubt, say N here.
Thanks.
> If what I guess is correct, I support you (else, please let me know)
>
>
> Thanks.
>
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-next 02/13] driver: net: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
dev_kfree_skb_irq is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/net/ethernet/amd/ni65.c | 6 ++
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 --
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 6 ++
drivers/net/ethernet/atheros/atlx/atl1.c | 6 ++
drivers/net/ethernet/icplus/ipg.c | 6 ++
drivers/net/ethernet/intel/e1000e/netdev.c| 3 +--
drivers/net/ethernet/marvell/pxa168_eth.c | 3 +--
drivers/net/ethernet/xilinx/ll_temac_main.c | 3 +--
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 6 ++
drivers/net/hamradio/scc.c| 10 +++---
drivers/net/vmxnet3/vmxnet3_drv.c | 3 +--
drivers/net/wireless/ath/ar5523/ar5523.c | 6 ++
12 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/amd/ni65.c b/drivers/net/ethernet/amd/ni65.c
index 1cf33ad..0695ce2 100644
--- a/drivers/net/ethernet/amd/ni65.c
+++ b/drivers/net/ethernet/amd/ni65.c
@@ -1030,10 +1030,8 @@ static void ni65_xmit_intr(struct net_device *dev,int
csr0)
}
#ifdef XMT_VIA_SKB
- if(p->tmd_skb[p->tmdlast]) {
-dev_kfree_skb_irq(p->tmd_skb[p->tmdlast]);
-p->tmd_skb[p->tmdlast] = NULL;
- }
+dev_kfree_skb_irq(p->tmd_skb[p->tmdlast]);
+p->tmd_skb[p->tmdlast] = NULL;
#endif
p->tmdlast = (p->tmdlast + 1) & (TMDNUM-1);
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index a36a760..cf89008 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -848,12 +848,10 @@ static inline void atl1c_clean_buffer(struct pci_dev
*pdev,
pci_unmap_page(pdev, buffer_info->dma,
buffer_info->length, pci_driection);
}
- if (buffer_info->skb) {
- if (in_irq)
- dev_kfree_skb_irq(buffer_info->skb);
- else
- dev_kfree_skb(buffer_info->skb);
- }
+ if (in_irq)
+ dev_kfree_skb_irq(buffer_info->skb);
+ else
+ dev_kfree_skb(buffer_info->skb);
buffer_info->dma = 0;
buffer_info->skb = NULL;
ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_FREE);
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 7a73f3a..c3ca8c6 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -1257,10 +1257,8 @@ static bool atl1e_clean_tx_irq(struct atl1e_adapter
*adapter)
tx_buffer->dma = 0;
}
- if (tx_buffer->skb) {
- dev_kfree_skb_irq(tx_buffer->skb);
- tx_buffer->skb = NULL;
- }
+ dev_kfree_skb_irq(tx_buffer->skb);
+ tx_buffer->skb = NULL;
if (++next_to_clean == tx_ring->count)
next_to_clean = 0;
diff --git a/drivers/net/ethernet/atheros/atlx/atl1.c
b/drivers/net/ethernet/atheros/atlx/atl1.c
index 538211d..b8cc654 100644
--- a/drivers/net/ethernet/atheros/atlx/atl1.c
+++ b/drivers/net/ethernet/atheros/atlx/atl1.c
@@ -2082,10 +2082,8 @@ static int atl1_intr_tx(struct atl1_adapter *adapter)
buffer_info->dma = 0;
}
- if (buffer_info->skb) {
- dev_kfree_skb_irq(buffer_info->skb);
- buffer_info->skb = NULL;
- }
+ dev_kfree_skb_irq(buffer_info->skb);
+ buffer_info->skb = NULL;
if (++sw_tpd_next_to_clean == tpd_ring->count)
sw_tpd_next_to_clean = 0;
diff --git a/drivers/net/ethernet/icplus/ipg.c
b/drivers/net/ethernet/icplus/ipg.c
index 25045ae..d3a5e1f 100644
--- a/drivers/net/ethernet/icplus/ipg.c
+++ b/drivers/net/ethernet/icplus/ipg.c
@@ -823,10 +823,8 @@ static void init_tfdlist(struct net_device *dev)
txfd->tfc = cpu_to_le64(IPG_TFC_TFDDONE);
- if (sp->tx_buff[i]) {
- dev_kfree_skb_irq(sp->tx_buff[i]);
- sp->tx_buff[i] = NULL;
- }
+ dev_kfree_skb_irq(sp->tx_buff[i]);
+ sp->tx_buff[i] = NULL;
txfd->next_desc = cpu_to_le64(sp->txd_map +
sizeof(struct ipg_tx)*(i + 1));
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 4ef7867..4c22a1a 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@
[PATCH net-next 12/13] driver: net: fix space before '(' and remove extra variable
Signed-off-by: Govindarajulu Varadarajan
---
drivers/net/ethernet/sgi/ioc3-eth.c | 4 +---
drivers/net/usb/usbnet.c| 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c
b/drivers/net/ethernet/sgi/ioc3-eth.c
index 6bd90f2..80dcfd9 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -851,13 +851,11 @@ static inline void ioc3_clean_rx_ring(struct ioc3_private
*ip)
static inline void ioc3_clean_tx_ring(struct ioc3_private *ip)
{
- struct sk_buff *skb;
int i;
for (i=0; i < 128; i++) {
- skb = ip->tx_skbs[i];
+ dev_kfree_skb_any(ip->tx_skbs[i]);
ip->tx_skbs[i] = NULL;
- dev_kfree_skb_any(skb);
ip->txr[i].cmd = 0;
}
ip->tx_pi = 0;
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index b37f812..bd18155 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1377,7 +1377,7 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
drop:
dev->net->stats.tx_dropped++;
not_drop:
- dev_kfree_skb_any (skb);
+ dev_kfree_skb_any(skb);
if (urb) {
kfree(urb->sg);
usb_free_urb(urb);
--
1.8.4.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 net-next 11/13] driver: usb: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/usb/gadget/u_ether.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index 2aae0d6..3b61ac6 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -251,8 +251,7 @@ enomem:
defer_kevent(dev, WORK_RX_MEMORY);
if (retval) {
DBG(dev, "rx submit --> %d\n", retval);
- if (skb)
- dev_kfree_skb_any(skb);
+ dev_kfree_skb_any(skb);
spin_lock_irqsave(&dev->req_lock, flags);
list_add(&req->list, &dev->rx_reqs);
spin_unlock_irqrestore(&dev->req_lock, flags);
@@ -339,8 +338,7 @@ quiesce:
break;
}
- if (skb)
- dev_kfree_skb_any(skb);
+ dev_kfree_skb_any(skb);
if (!netif_running(dev->net)) {
clean:
spin_lock(&dev->req_lock);
--
1.8.4.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 net-next 08/13] driver: isdn: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/isdn/gigaset/ser-gigaset.c | 3 +--
drivers/isdn/hisax/hfc_usb.c | 6 ++
drivers/isdn/hisax/icc.c | 6 ++
drivers/isdn/hisax/ipacx.c | 6 ++
drivers/isdn/hisax/isac.c | 6 ++
drivers/isdn/hisax/st5481_b.c | 6 ++
drivers/isdn/hisax/w6692.c | 6 ++
7 files changed, 13 insertions(+), 26 deletions(-)
diff --git a/drivers/isdn/gigaset/ser-gigaset.c
b/drivers/isdn/gigaset/ser-gigaset.c
index 8c91fd5..9128526 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -221,8 +221,7 @@ static void flush_send_queue(struct cardstate *cs)
spin_unlock_irqrestore(&cs->cmdlock, flags);
/* data queue */
- if (cs->bcs->tx_skb)
- dev_kfree_skb_any(cs->bcs->tx_skb);
+ dev_kfree_skb_any(cs->bcs->tx_skb);
while ((skb = skb_dequeue(&cs->bcs->squeue)) != NULL)
dev_kfree_skb_any(skb);
}
diff --git a/drivers/isdn/hisax/hfc_usb.c b/drivers/isdn/hisax/hfc_usb.c
index 849a807..a1f8380 100644
--- a/drivers/isdn/hisax/hfc_usb.c
+++ b/drivers/isdn/hisax/hfc_usb.c
@@ -864,10 +864,8 @@ rx_int_complete(struct urb *urb)
fifon, urb->status);
fifo->urb->interval = 0;/* cancel automatic
rescheduling */
- if (fifo->skbuff) {
- dev_kfree_skb_any(fifo->skbuff);
- fifo->skbuff = NULL;
- }
+ dev_kfree_skb_any(fifo->skbuff);
+ fifo->skbuff = NULL;
return;
}
len = urb->actual_length;
diff --git a/drivers/isdn/hisax/icc.c b/drivers/isdn/hisax/icc.c
index 51dae91..2c52996 100644
--- a/drivers/isdn/hisax/icc.c
+++ b/drivers/isdn/hisax/icc.c
@@ -549,10 +549,8 @@ ICC_l1hw(struct PStack *st, int pr, void *arg)
case (HW_DEACTIVATE | RESPONSE):
skb_queue_purge(&cs->rq);
skb_queue_purge(&cs->sq);
- if (cs->tx_skb) {
- dev_kfree_skb_any(cs->tx_skb);
- cs->tx_skb = NULL;
- }
+ dev_kfree_skb_any(cs->tx_skb);
+ cs->tx_skb = NULL;
if (test_and_clear_bit(FLG_DBUSY_TIMER, &cs->HW_Flags))
del_timer(&cs->dbusytimer);
if (test_and_clear_bit(FLG_L1_DBUSY, &cs->HW_Flags))
diff --git a/drivers/isdn/hisax/ipacx.c b/drivers/isdn/hisax/ipacx.c
index 5faa5de..55192a4 100644
--- a/drivers/isdn/hisax/ipacx.c
+++ b/drivers/isdn/hisax/ipacx.c
@@ -181,10 +181,8 @@ dch_l2l1(struct PStack *st, int pr, void *arg)
case (HW_DEACTIVATE | RESPONSE):
skb_queue_purge(&cs->rq);
skb_queue_purge(&cs->sq);
- if (cs->tx_skb) {
- dev_kfree_skb_any(cs->tx_skb);
- cs->tx_skb = NULL;
- }
+ dev_kfree_skb_any(cs->tx_skb);
+ cs->tx_skb = NULL;
if (test_and_clear_bit(FLG_DBUSY_TIMER, &cs->HW_Flags))
del_timer(&cs->dbusytimer);
break;
diff --git a/drivers/isdn/hisax/isac.c b/drivers/isdn/hisax/isac.c
index 7fdf78f..d0895f2 100644
--- a/drivers/isdn/hisax/isac.c
+++ b/drivers/isdn/hisax/isac.c
@@ -547,10 +547,8 @@ ISAC_l1hw(struct PStack *st, int pr, void *arg)
case (HW_DEACTIVATE | RESPONSE):
skb_queue_purge(&cs->rq);
skb_queue_purge(&cs->sq);
- if (cs->tx_skb) {
- dev_kfree_skb_any(cs->tx_skb);
- cs->tx_skb = NULL;
- }
+ dev_kfree_skb_any(cs->tx_skb);
+ cs->tx_skb = NULL;
if (test_and_clear_bit(FLG_DBUSY_TIMER, &cs->HW_Flags))
del_timer(&cs->dbusytimer);
if (test_and_clear_bit(FLG_L1_DBUSY, &cs->HW_Flags))
diff --git a/drivers/isdn/hisax/st5481_b.c b/drivers/isdn/hisax/st5481_b.c
index 4098491..b753aca 100644
--- a/drivers/isdn/hisax/st5481_b.c
+++ b/drivers/isdn/hisax/st5481_b.c
@@ -254,10 +254,8 @@ static void st5481B_mode(struct st5481_bcs *bcs, int mode)
} else {
st5481_usb_device_ctrl_msg(adapter, GPIO_OUT,
adapter->leds, NULL, NULL);
}
- if (b_out->tx_skb) {
- dev_kfree_skb_any(b_out->tx_skb);
- b_out->tx_skb = NULL;
- }
+ dev_kfree_skb_any(b_out->tx_skb);
+ b_out->tx_skb = NULL;
}
}
diff --git a/drivers/isdn/hisax/w6692.c b/drivers/isdn/hisax/w6692.c
index a858955..dd1fbf4 100644
--- a/drivers/isdn/hisax/w6692.c
+++ b/drivers/isdn/hisax/w6692.c
@@ -653,10 +653,8 @@ W6692_l1hw(struct PStack *st, int pr, void *arg)
case (HW_DEACTIVATE | RESPONSE):
[PATCH net-next 10/13] driver: infiniband: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/infiniband/hw/amso1100/c2.c | 6 ++
drivers/infiniband/hw/nes/nes_hw.c | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2.c
b/drivers/infiniband/hw/amso1100/c2.c
index d53cf51..30c4d00 100644
--- a/drivers/infiniband/hw/amso1100/c2.c
+++ b/drivers/infiniband/hw/amso1100/c2.c
@@ -312,10 +312,8 @@ static inline int c2_tx_free(struct c2_dev *c2dev, struct
c2_element *elem)
pci_unmap_single(c2dev->pcidev, elem->mapaddr, elem->maplen,
PCI_DMA_TODEVICE);
- if (elem->skb) {
- dev_kfree_skb_any(elem->skb);
- elem->skb = NULL;
- }
+ dev_kfree_skb_any(elem->skb);
+ elem->skb = NULL;
return 0;
}
diff --git a/drivers/infiniband/hw/nes/nes_hw.c
b/drivers/infiniband/hw/nes/nes_hw.c
index 9020024..2275a8e 100644
--- a/drivers/infiniband/hw/nes/nes_hw.c
+++ b/drivers/infiniband/hw/nes/nes_hw.c
@@ -2856,8 +2856,7 @@ void nes_nic_ce_handler(struct nes_device *nesdev, struct
nes_hw_nic_cq *cq)
break;
}
}
- if (skb)
- dev_kfree_skb_any(skb);
+ dev_kfree_skb_any(skb);
nesnic->sq_tail++;
nesnic->sq_tail &= nesnic->sq_size-1;
if (sq_cqes > 128) {
--
1.8.4.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 net-next 06/13] driver: net: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/net/ethernet/amd/lance.c | 9 +++--
drivers/net/ethernet/atheros/alx/main.c | 6 ++
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 6 ++
drivers/net/ethernet/atheros/atlx/atl1.c | 6 ++
drivers/net/ethernet/cisco/enic/enic_main.c | 3 +--
drivers/net/ethernet/freescale/fec_main.c| 6 ++
drivers/net/ethernet/hp/hp100.c | 3 +--
drivers/net/ethernet/intel/e1000/e1000_main.c| 6 ++
drivers/net/ethernet/intel/e1000e/netdev.c | 12
drivers/net/ethernet/intel/igb/igb_ptp.c | 6 ++
drivers/net/ethernet/intel/igbvf/netdev.c| 6 ++
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 6 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 6 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c| 6 ++
drivers/net/ethernet/korina.c| 12
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 12
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 9 +++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 6 ++
drivers/net/ethernet/seeq/sgiseeq.c | 6 ++
drivers/net/ethernet/sgi/ioc3-eth.c | 9 +++--
drivers/net/ethernet/smsc/smsc9420.c | 3 +--
drivers/net/ethernet/sun/sunbmac.c | 12
drivers/net/ethernet/ti/cpmac.c | 6 ++
drivers/net/hyperv/netvsc_drv.c | 3 +--
drivers/net/irda/vlsi_ir.c | 15 +--
drivers/net/usb/cdc_mbim.c | 3 +--
drivers/net/usb/cdc_ncm.c| 15 +--
drivers/net/usb/lg-vl600.c | 6 ++
drivers/net/usb/usbnet.c | 3 +--
drivers/net/vmxnet3/vmxnet3_drv.c| 6 ++
drivers/net/wireless/ath/ath10k/mac.c| 6 ++
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c| 3 +--
drivers/net/wireless/ath/ath9k/main.c| 6 ++
drivers/net/wireless/ath/ath9k/recv.c| 6 ++
drivers/net/wireless/ath/wil6210/txrx.c | 6 ++
drivers/net/wireless/b43/main.c | 9 +++--
drivers/net/wireless/b43legacy/main.c| 9 +++--
drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c | 3 +--
drivers/net/wireless/brcm80211/brcmsmac/main.c | 12
drivers/net/wireless/ipw2x00/ipw2200.c | 6 ++
drivers/net/wireless/ipw2x00/libipw_rx.c | 3 +--
drivers/net/wireless/ipw2x00/libipw_tx.c | 3 +--
drivers/net/wireless/mwifiex/init.c | 3 +--
43 files changed, 96 insertions(+), 192 deletions(-)
diff --git a/drivers/net/ethernet/amd/lance.c b/drivers/net/ethernet/amd/lance.c
index 256f590..4b8fc50 100644
--- a/drivers/net/ethernet/amd/lance.c
+++ b/drivers/net/ethernet/amd/lance.c
@@ -845,14 +845,11 @@ lance_purge_ring(struct net_device *dev)
struct sk_buff *skb = lp->rx_skbuff[i];
lp->rx_skbuff[i] = NULL;
lp->rx_ring[i].base = 0;/* Not owned by LANCE
chip. */
- if (skb)
- dev_kfree_skb_any(skb);
+ dev_kfree_skb_any(skb);
}
for (i = 0; i < TX_RING_SIZE; i++) {
- if (lp->tx_skbuff[i]) {
- dev_kfree_skb_any(lp->tx_skbuff[i]);
- lp->tx_skbuff[i] = NULL;
- }
+ dev_kfree_skb_any(lp->tx_skbuff[i]);
+ lp->tx_skbuff[i] = NULL;
}
}
diff --git a/drivers/net/ethernet/atheros/alx/main.c
b/drivers/net/ethernet/atheros/alx/main.c
index 5aa5e81..2bee48b 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -64,10 +64,8 @@ static void alx_free_txbuf(struct alx_priv *alx, int entry)
dma_unmap_len_set(txb, size, 0);
}
- if (txb->skb) {
- dev_kfree_skb_any(txb->skb);
- txb->skb = NULL;
- }
+ dev_kfree_skb_any(txb->skb);
+ txb->skb = NULL;
}
static int alx_refill_rx_ring(struct alx_priv *alx, gfp_t gfp)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index c3ca8c6..b420ead 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -686,10 +686,8 @@ static void atl1e_clean_tx_ring(struct atl1e_adapter
*adapter)
/* second free skb */
for (index = 0; index < ring_count; index++) {
tx_buffer = &
[PATCH net-next 13/13] scripts/checkpatch.pl: Add dev_kfree_skb*(NULL) check to checkpatch
Signed-off-by: Govindarajulu Varadarajan
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 66cad50..e651b8a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3719,7 +3719,7 @@ sub process {
# check for needless "if () fn()" uses
if ($prevline =~ /\bif\s*\(\s*($Lval)\s*\)/) {
my $expr = '\s*\(\s*' . quotemeta($1) . '\s*\)\s*;';
- if ($line =~
/\b(kfree|usb_free_urb|debugfs_remove(?:_recursive)?)$expr/) {
+ if ($line =~
/\b(kfree|dev_kfree_skb|dev_kfree_skb_any|dev_kfree_skb_irq|usb_free_urb|debugfs_remove(?:_recursive)?)$expr/)
{
WARN('NEEDLESS_IF',
"$1(NULL) is safe this check is probably
not required\n" . $hereprev);
}
--
1.8.4.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 net-next 09/13] driver: s390: remove unnecessary NULL check before dev_kfree_skb_any
dev_kfree_skb_any is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/s390/net/claw.c | 6 ++
drivers/s390/net/ctcm_mpc.c | 6 ++
drivers/s390/net/qeth_core_main.c | 6 ++
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/s390/net/claw.c b/drivers/s390/net/claw.c
index fd7b3bd..66c0b14 100644
--- a/drivers/s390/net/claw.c
+++ b/drivers/s390/net/claw.c
@@ -834,10 +834,8 @@ claw_release(struct net_device *dev)
ccw_check_return_code(privptr->channel[i].cdev, rc);
}
}
- if (privptr->pk_skb != NULL) {
- dev_kfree_skb_any(privptr->pk_skb);
- privptr->pk_skb = NULL;
- }
+ dev_kfree_skb_any(privptr->pk_skb);
+ privptr->pk_skb = NULL;
if(privptr->buffs_alloc != 1) {
CLAW_DBF_TEXT(4, trace, "none2fre");
return 0;
diff --git a/drivers/s390/net/ctcm_mpc.c b/drivers/s390/net/ctcm_mpc.c
index 2dbc77b..2dd53a6 100644
--- a/drivers/s390/net/ctcm_mpc.c
+++ b/drivers/s390/net/ctcm_mpc.c
@@ -964,8 +964,7 @@ void mpc_channel_action(struct channel *ch, int direction,
int action)
grp->outstanding_xid2++;
ch->in_mpcgroup = 1;
- if (ch->xid_skb != NULL)
- dev_kfree_skb_any(ch->xid_skb);
+ dev_kfree_skb_any(ch->xid_skb);
ch->xid_skb = __dev_alloc_skb(MPC_BUFSIZE_DEFAULT,
GFP_ATOMIC | GFP_DMA);
@@ -1017,8 +1016,7 @@ void mpc_channel_action(struct channel *ch, int
direction, int action)
grp->num_channel_paths--;
grp->active_channels[direction]--;
- if (ch->xid_skb != NULL)
- dev_kfree_skb_any(ch->xid_skb);
+ dev_kfree_skb_any(ch->xid_skb);
ch->xid_skb = NULL;
if (grp->channels_terminating)
diff --git a/drivers/s390/net/qeth_core_main.c
b/drivers/s390/net/qeth_core_main.c
index 0a328d0..7d33b94 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -1282,10 +1282,8 @@ static void qeth_free_qdio_buffers(struct qeth_card
*card)
qeth_free_cq(card);
cancel_delayed_work_sync(&card->buffer_reclaim_work);
- for (j = 0; j < QDIO_MAX_BUFFERS_PER_Q; ++j) {
- if (card->qdio.in_q->bufs[j].rx_skb)
- dev_kfree_skb_any(card->qdio.in_q->bufs[j].rx_skb);
- }
+ for (j = 0; j < QDIO_MAX_BUFFERS_PER_Q; ++j)
+ dev_kfree_skb_any(card->qdio.in_q->bufs[j].rx_skb);
kfree(card->qdio.in_q);
card->qdio.in_q = NULL;
/* inbound buffer pool */
--
1.8.4.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 net-next 04/13] driver: staging: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
dev_kfree_skb_irq is protected from NULL. No need to check for NULL while
calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/staging/slicoss/slicoss.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/slicoss/slicoss.c
b/drivers/staging/slicoss/slicoss.c
index 869dcd3..1073880 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2616,8 +2616,7 @@ static void slic_xmit_complete(struct adapter *adapter)
address;
/* hcmd = (struct slic_hostcmd *) rspbuf->hosthandle; */
if (hcmd->type == SLIC_CMD_DUMB) {
- if (hcmd->skb)
- dev_kfree_skb_irq(hcmd->skb);
+ dev_kfree_skb_irq(hcmd->skb);
slic_cmdq_putdone_irq(adapter, hcmd);
}
rspbuf->status = 0;
--
1.8.4.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 net-next 05/13] driver: usb/gadget: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
dev_kfree_skb_irq is protected from NULL. No need to check for NULL
while calling this function.
Signed-off-by: Govindarajulu Varadarajan
---
drivers/usb/gadget/f_phonet.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/f_phonet.c b/drivers/usb/gadget/f_phonet.c
index eb3aa81..9e220b6 100644
--- a/drivers/usb/gadget/f_phonet.c
+++ b/drivers/usb/gadget/f_phonet.c
@@ -393,10 +393,8 @@ static void __pn_reset(struct usb_function *f)
usb_ep_disable(fp->out_ep);
usb_ep_disable(fp->in_ep);
- if (fp->rx.skb) {
- dev_kfree_skb_irq(fp->rx.skb);
- fp->rx.skb = NULL;
- }
+ dev_kfree_skb_irq(fp->rx.skb);
+ fp->rx.skb = NULL;
}
static int pn_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
--
1.8.4.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 net-next 03/13] driver: atm: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
dev_kfree_skb_irq is protected from NULL. No need to check for NULL while calling this function. Signed-off-by: Govindarajulu Varadarajan --- drivers/atm/eni.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c index b1955ba..78a4445 100644 --- a/drivers/atm/eni.c +++ b/drivers/atm/eni.c @@ -481,7 +481,7 @@ trouble: if (paddr) pci_unmap_single(eni_dev->pci_dev,paddr,skb->len, PCI_DMA_FROMDEVICE); - if (skb) dev_kfree_skb_irq(skb); + dev_kfree_skb_irq(skb); return -1; } -- 1.8.4.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 net-next 00/13] Protect dev_kfree_skb_irq from NULL and remove unnecessary NULL checks
dev_kfree_skb_irq is not NULL safe. The following patch checks skb for NULL in
dev_kfree_skb_irq.
At many places we check for NULL before calling dev_kfree_skb_*(). Moving the
check to dev_kfree_skb_irq_*() removes the reddundant if condition and makes
code simpler.
Also dev_kfree_skb_any either calls dev_kfree_skb_irq or dev_kfree_skb
depending on where your code is running. dev_kfree_skb is NULL safe but
dev_kfree_skb_irq is not. This patch fixes it.
Govindarajulu Varadarajan (13):
net: Check skb for NULL in dev_kfree_skb_irq
driver: net: remove unnecessary skb NULL check before calling
dev_kfree_skb_irq
driver: atm: remove unnecessary skb NULL check before calling
dev_kfree_skb_irq
driver: staging: remove unnecessary skb NULL check before calling
dev_kfree_skb_irq
driver: net: remove unnecessary skb NULL check before calling
dev_kfree_skb_irq
driver: net: remove unnecessary NULL check before dev_kfree_skb_any
driver: staging: remove unnecessary NULL check before
dev_kfree_skb_any
driver: isdn: remove unnecessary NULL check before dev_kfree_skb_any
driver: s390: remove unnecessary NULL check before dev_kfree_skb_any
driver: infiniband: remove unnecessary NULL check before
dev_kfree_skb_any
driver: usb: remove unnecessary NULL check before dev_kfree_skb_any
driver: net: fix space before '(' and remove extra variable
scripts/checkpatch.pl: Add dev_kfree_skb*(NULL) check to ckeckpatch
drivers/atm/eni.c| 2 +-
drivers/infiniband/hw/amso1100/c2.c | 6 ++
drivers/infiniband/hw/nes/nes_hw.c | 3 +--
drivers/isdn/gigaset/ser-gigaset.c | 3 +--
drivers/isdn/hisax/hfc_usb.c | 6 ++
drivers/isdn/hisax/icc.c | 6 ++
drivers/isdn/hisax/ipacx.c | 6 ++
drivers/isdn/hisax/isac.c| 6 ++
drivers/isdn/hisax/st5481_b.c| 6 ++
drivers/isdn/hisax/w6692.c | 6 ++
drivers/net/ethernet/amd/lance.c | 9 +++--
drivers/net/ethernet/amd/ni65.c | 6 ++
drivers/net/ethernet/atheros/alx/main.c | 6 ++
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 10 --
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 12
drivers/net/ethernet/atheros/atlx/atl1.c | 12
drivers/net/ethernet/cisco/enic/enic_main.c | 3 +--
drivers/net/ethernet/freescale/fec_main.c| 6 ++
drivers/net/ethernet/hp/hp100.c | 3 +--
drivers/net/ethernet/icplus/ipg.c| 6 ++
drivers/net/ethernet/intel/e1000/e1000_main.c| 6 ++
drivers/net/ethernet/intel/e1000e/netdev.c | 15 +--
drivers/net/ethernet/intel/igb/igb_ptp.c | 6 ++
drivers/net/ethernet/intel/igbvf/netdev.c| 6 ++
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 6 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 6 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c| 6 ++
drivers/net/ethernet/korina.c| 12
drivers/net/ethernet/marvell/pxa168_eth.c| 3 +--
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 12
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 9 +++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 6 ++
drivers/net/ethernet/seeq/sgiseeq.c | 6 ++
drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++
drivers/net/ethernet/smsc/smsc9420.c | 3 +--
drivers/net/ethernet/sun/sunbmac.c | 12
drivers/net/ethernet/ti/cpmac.c | 6 ++
drivers/net/ethernet/xilinx/ll_temac_main.c | 3 +--
drivers/net/ethernet/xilinx/xilinx_axienet_main.c| 6 ++
drivers/net/hamradio/scc.c | 10 +++---
drivers/net/hyperv/netvsc_drv.c | 3 +--
drivers/net/irda/vlsi_ir.c | 15 +--
drivers/net/usb/cdc_mbim.c | 3 +--
drivers/net/usb/cdc_ncm.c| 15 +--
drivers/net/usb/lg-vl600.c | 6 ++
drivers/net/usb/usbnet.c | 3 +--
drivers/net/vmxnet3/vmxnet3_drv.c| 9 +++--
drivers/net/wireless/ath/ar5523/ar5523.c | 6 ++
drivers/net/wireless/ath/ath10k/mac.c| 6 ++
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c| 3 +--
drivers/net/wireless/ath/ath9k/main.c| 6 ++
drivers/net/wireless/ath/ath9k/recv.c| 6 ++
drivers/net/wireless/ath/wil6210/txrx.c
[PATCH net-next 01/13] net: Check skb for NULL in dev_kfree_skb_irq
Signed-off-by: Govindarajulu Varadarajan
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0054c8c..63bd44d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2146,7 +2146,7 @@ EXPORT_SYMBOL(__netif_schedule);
void dev_kfree_skb_irq(struct sk_buff *skb)
{
- if (atomic_dec_and_test(&skb->users)) {
+ if (skb && atomic_dec_and_test(&skb->users)) {
struct softnet_data *sd;
unsigned long flags;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
Hi Matt, On Friday 01 of November 2013 15:45:50 Matt Porter wrote: > This adds a pair of APIs that allows the generic PHY subsystem to > provide information on the PHY bus width. The PHY provider driver may > use phy_set_bus_width() to set the bus width that the PHY supports. > The controller driver may then use phy_get_bus_width() to fetch the > PHY bus width in order to properly configure the controller. I somehow does not like this. If we take this path for any further properties that we may need, we will end up with a lot of consumer specific properties stored in a PHY object having their own accessor functions. Since this is just an integration detail, what about simply adding this as a property in device tree node of the OTG controller (and pdata if considering non-DT support)? Another option would be some framework for retrieving arbitrary properties from the PHY, but I'm not really sure there is a need for such. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
