Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-10 Thread Miguel Ojeda
Hi Sebastian, On Tue, Feb 9, 2021 at 10:01 AM Sebastian Andrzej Siewior wrote: > > If I post series with more than just one patch I have a cover letter > including: Yeah, it is a bit confusing when reading without the context (it is hard to keep up with everything going on unless you work

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-09 Thread Sebastian Andrzej Siewior
On 2021-02-08 23:26:57 [+0100], Miguel Ojeda wrote: > Thanks -- can you please add a Link: tag to a lore URL or the docs or > similar where more information can be found regarding the > proposal/discussion for removing `in_interrurt()` etc.? It is useful > to track why these things are happening

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Miguel Ojeda
On Mon, Feb 8, 2021 at 9:41 PM Sebastian Andrzej Siewior wrote: > > It hurts to keep in_interrupt() because it is desired to have it removed > from drivers. The problem is that pattern is often copied and people > sometimes get it wrong. For instance, the code here invoked schedule() > based on

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Sebastian Andrzej Siewior
On 2021-02-08 21:14:54 [+0100], Miguel Ojeda wrote: > On Mon, Feb 8, 2021 at 8:07 PM Sebastian Andrzej Siewior > wrote: > > > > Yes. > > In what way? It hurts to keep in_interrupt() because it is desired to have it removed from drivers. The problem is that pattern is often copied and people

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Miguel Ojeda
On Mon, Feb 8, 2021 at 8:07 PM Sebastian Andrzej Siewior wrote: > > Yes. In what way? > No. If you know the context, pass it along like this is done for > kmalloc() for instance. What do you mean? > The long term plan is not make it available to > divers (i.e. core code only where the context

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Sebastian Andrzej Siewior
On 2021-02-08 19:38:10 [+0100], Miguel Ojeda wrote: > Hi Sebastian, Hi, > > Therefore there is no need to use `in_interrupt()' to figure out if it > > is save to sleep because it always is. > > save -> safe > > Does it hurt to have `in_interrupt()`? Future patches could make it so Yes. > that

Re: [PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Miguel Ojeda
Hi Sebastian, On Mon, Feb 8, 2021 at 6:59 PM Sebastian Andrzej Siewior wrote: > > charlcd_write() is invoked as a VFS->write() callback and as such it is > always invoked from preemptible context and may sleep. > > charlcd_puts() is invoked from register/unregister callback which is >

[PATCH] auxdisplay: Remove in_interrupt() usage.

2021-02-08 Thread Sebastian Andrzej Siewior
charlcd_write() is invoked as a VFS->write() callback and as such it is always invoked from preemptible context and may sleep. charlcd_puts() is invoked from register/unregister callback which is preemtible. The reboot notifier callback is also invoked from preemptible context. Therefore there