ess widths of 17 or 25 bits,
>> - Move handling inside the switch() statement.
>> ---
>> Documentation/devicetree/bindings/eeprom/at25.txt | 4 +++-
>> drivers/misc/eeprom/at25.c| 3 +++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> Reviewed-by: Rob Herring
Reviewed-by: Ivo Sieben
not a DT expert but to me your first proposal makes the most sense
to me and feels the most intuitive:
I would go for the address-with value 9 option here.
Since we only expect value 9 to be a valid option, maybe you could
rewrite it a bit to explicitly check for value 9:
if (val == 9) {
chip->flags |= EE_INSTR_BIT3_IS_ADDR;
val -= 1;
}
I think this is slightly more readable.
Hope this helps,
Regards,
Ivo Sieben
Andy, Joe,
What do you think about my patchset below?
Regards,
Ivo Sieben
2014-05-15 16:43 GMT+02:00 Ivo Sieben :
> Raise a SUSPICIOUS_CODE_INDENT warning when unexpected indentation is found
> after a conditional statement. This can be used to find missing braces or
> wrong inden
Andy, Joe,
What do you think about my patchset below?
Regards,
Ivo Sieben
2014-05-15 16:43 GMT+02:00 Ivo Sieben :
> When picking up a complete statement block #if/#else/#endif prepocesor
> boundaries are taken into account by pushing current level & type on a stack.
> But on an #e
#endif
+ }>
CONDITION<+ if (!test())>
Signed-off-by: Ivo Sieben
---
Request for comments:
I think I fixed a problem here that I encountered while I was working on another
changeset in which I check the statement block after a condition.
Somehow the statement block did not co
();
return;
Which can be either intended by the programmer as:
if (foo)
bar();
return;
or
if (foo) {
bar();
return;
}
Signed-off-by: Ivo Sieben
---
Request for comments:
I think this is a nice warning to have
Patch looks OK to me.. but I'm not an expert.
Regards,
Ivo Sieben
2013/10/11 Sebastian Andrzej Siewior :
> From: Thomas Pfaff
>
> In commit ee23871389 ("genirq: Set irq thread to RT priority on
> creation") we moved the assigment of the thread's priority f
Commit-ID: ee23871389d51e07380d23887333622fbe7d3dd9
Gitweb: http://git.kernel.org/tip/ee23871389d51e07380d23887333622fbe7d3dd9
Author: Ivo Sieben
AuthorDate: Mon, 3 Jun 2013 12:12:02 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 11 Jun 2013 16:18:50 +0200
genirq: Set irq thread to
there are situations thinkable (altough I cannot come up with a proper
example) where it is normal behavior that a IRQ directly kicks in
after enabling the interrupts.
Regards,
Ivo Sieben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
e uart port it
receives the "old" data and gives an error.
Signed-off-by: Ivo Sieben
---
v2:
* Removed the sched_setscheduler() call in irq_thread() function
* Updated commit log why this solves an issue for me with a UART driver
kernel/irq/manage.c | 11 ++-
1 file cha
handled on a normal scheduling priority instead of the
realtime priority that you would expect. Fixed this by setting the RT
priority on creation of the irq_thread.
Signed-off-by: Ivo Sieben
---
RFC:
Whas there a specific reason for the irq_thread to be created on normal
scheduling and only set to RT
er. Why should we delay this fix?
>
FYI: Greg has added my patch to his tty-next branch, so my fix has
been approved.
Thank you all for reviewing.
Regards,
Ivo Sieben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to m
d has a risk to block on the spinlock needlessly (causing context
switches to low priority task and back to the high priority task)
Regards,
Ivo Sieben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
ith "scheduler overhead" (maybe not a good name for it,
sorry for the confusion).
Does this makes sense to you?
Regards,
ivo Sieben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
st.
>
> Not sure this will actually help to make the code cleaner. The last
> patch you sent looks simple and clean. IMHO it doesn't make sense
> to create _if_active helper for each wake_up*.
>
> Oleg.
>
The comments by Oleg point out to me that the 'if waitqueueu_act
Oleg, Peter, Ingo, Andi & Preeti,
2013/1/2 Jiri Slaby :
> On 01/02/2013 04:21 PM, Ivo Sieben wrote:
>> I don't understand your responses: do you suggest to implement this
>> "if active" behavior in:
>> * A new wake_up function called wake_up_if_active(
Hi Jiri & Alan,
2013/1/2 Alan Cox :
>
>> Looks good, but I would prefer the layer to provide us with
>> wake_up_if_active...
>
> Seconded - this is a problem for the wake up logic in the RT tree. Why
> would we ever do anything else ?
I don't understand your responses: do you suggest to implement
critical section.
Signed-off-by: Ivo Sieben
---
Remark:
This patch has kind of a long history... I first tried to prevent the critical
section in the wakeup() function itself by a change in the scheduler. But after
review remarks from Oleg Nesterov it turned out that using the
waitqueue_active
Hi
2012/11/19 Oleg Nesterov :
>
> Because on a second thought I suspect this change is wrong.
>
> Just for example, please look at kauditd_thread(). It does
>
> set_current_state(TASK_INTERRUPTIBLE);
>
> add_wait_queue(&kauditd_wait, &wait);
>
> if (!CONDITION) // <
Hi
2012/11/19 Oleg Nesterov :
>
> I am wondering if it makes sense unconditionally. A lot of callers do
>
> if (waitqueue_active(q))
> wake_up(...);
>
> this patch makes the optimization above pointless and adds mb().
>
>
> But I won't argue.
>
> Oleg.
>
This patch solved
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
a second repost of this patch v2
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
repost:
Did I apply the memory
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
v2:
- We don't need the &qu
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
REPOST:
Request for comments
Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.
Signed-off-by: Ivo Sieben
---
Request for comments:
- Does this
> +MODULE_DEVICE_TABLE(spi, at25_id);
I use this driver for the ST M95040, M95020 & M95010 eeprom devices.
So wouldn't it be better to use the "famliy" name for these chips
("m95" instead of "m95256").
Regards,
Ivo Sieben
--
To unsubscribe from
26 matches
Mail list logo
