search for: list_prev_entri

This patch replace list_entry with list_{next/prev}_entry as it makes the code more clear to read. Done using coccinelle: @@ expression e1; identifier e3; type t; @@ ( - list_entry(e1->e3.next,t,e3) + list_next_entry(e1,e3) | - list_entry(e1->e3.prev,t,e3) + list_prev_entry(e1,e3) ) Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> --- drivers/gpu/drm/drm_lease.c

On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall <julia.lawall at lip6.fr> wrote: > > > On Mon, 19 Mar 2018, Arushi Singhal wrote: > > > This patch replace list_entry with list_{next/prev}_entry as it makes > > the code more clear to read. > > Done using coccinelle: > > > > @@ > > expression e1; > > identifier e3; > > type t; >

On Mon, 19 Mar 2018, Arushi Singhal wrote: > This patch replace list_entry with list_{next/prev}_entry as it makes > the code more clear to read. > Done using coccinelle: > > @@ > expression e1; > identifier e3; > type t; > @@ > ( > - list_entry(e1->e3.next,t,e3) > + list_next_entry(e1,e3) > | > - list_entry(e1->e3.prev,t,e3) > +

On Mon, Mar 26, 2018 at 4:01 AM, Arushi Singhal <arushisinghal19971997 at gmail.com> wrote: > It's better to use list_entry instead of list_{next/prev}_entry > as it makes the code more clear to read. > This patch replace list_entry with list_{next/prev}_entry. > > Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> Acked-by: Ben Skeggs <bskeggs at

It's better to use "list_for_each_entry_from_reverse" for iterating list than "for loop" as it makes the code more clear to read. This patch replace "for loop" with "list_for_each_entry_from_reverse" and remove "cstate" variable as it is redundant in the code. Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> ---

On Mon, Mar 19, 2018 at 10:35:30AM +0530, Arushi Singhal wrote: > This patch replace list_entry with list_{next/prev}_entry as it makes > the code more clear to read. > Done using coccinelle: > > @@ > expression e1; > identifier e3; > type t; > @@ > ( > - list_entry(e1->e3.next,t,e3) > + list_next_entry(e1,e3) > | > - list_entry(e1->e3.prev,t,e3)

Replace list_entry with list_{next/prev}_entry. Arushi Singhal (2): gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry drivers/gpu/drm/drm_lease.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- changes in v2 *All the

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Quoting Ben Skeggs (2018-03-26 13:34:54) > On Mon, Mar 26, 2018 at 4:01 AM, Arushi Singhal > <arushisinghal19971997 at gmail.com> wrote: > > It's better to use list_entry instead of list_{next/prev}_entry > > as it makes the code more clear to read. > > This patch replace list_entry with list_{next/prev}_entry. > > > > Signed-off-by: Arushi Singhal

On 27 March 2018 at 19:11, Arushi Singhal <arushisinghal19971997 at gmail.com> wrote: > It's better to use "list_for_each_entry_from_reverse" for iterating list > than "for loop" as it makes the code more clear to read. > This patch replace "for loop" with "list_for_each_entry_from_reverse" > and remove "cstate" variable as it

It's better to use "list_for_each_entry_from_reverse" for iterating list than "for loop" as it makes the code more clear to read. This patch replace "for loop" with "list_for_each_entry_from_reverse" and "start" variable with "cstate" which helps in refactoring the code and also "cstate" variable is more commonly used in the

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)