The Linux kernel coding style guidelines suggest not using typedefs for structure types. This patch gets rid of the typedefs for cfs_wi_sched. Also, the name of the struct is changed to drop the _t, to make the name look less typedef-like. The following Coccinelle semantic patch detects the case: @tn@ identifier i; type td; @@ -typedef struct i { ... } -td ; @@ type tn.td; identifier tn.i; @@ -td + struct i Signed-off-by: Shraddha Barke <shraddha.6596@xxxxxxxxx> --- drivers/staging/lustre/lustre/libcfs/workitem.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c b/drivers/staging/lustre/lustre/libcfs/workitem.c index 48009b7..02d18f5 100644 --- a/drivers/staging/lustre/lustre/libcfs/workitem.c +++ b/drivers/staging/lustre/lustre/libcfs/workitem.c @@ -45,7 +45,7 @@ #define CFS_WS_NAME_LEN 16 -typedef struct cfs_wi_sched { +struct cfs_wi_sched { struct list_head ws_list; /* chain on global list */ /** serialised workitems */ spinlock_t ws_lock; @@ -73,7 +73,7 @@ typedef struct cfs_wi_sched { unsigned int ws_starting:1; /** scheduler name */ char ws_name[CFS_WS_NAME_LEN]; -} cfs_wi_sched_t; +}; static struct cfs_workitem_data { /** serialize */ @@ -87,19 +87,19 @@ static struct cfs_workitem_data { } cfs_wi_data; static inline void -cfs_wi_sched_lock(cfs_wi_sched_t *sched) +cfs_wi_sched_lock(struct cfs_wi_sched *sched) { spin_lock(&sched->ws_lock); } static inline void -cfs_wi_sched_unlock(cfs_wi_sched_t *sched) +cfs_wi_sched_unlock(struct cfs_wi_sched *sched) { spin_unlock(&sched->ws_lock); } static inline int -cfs_wi_sched_cansleep(cfs_wi_sched_t *sched) +cfs_wi_sched_cansleep(struct cfs_wi_sched *sched) { cfs_wi_sched_lock(sched); if (sched->ws_stopping) { @@ -221,7 +221,7 @@ EXPORT_SYMBOL(cfs_wi_schedule); static int cfs_wi_scheduler (void *arg) { - struct cfs_wi_sched *sched = (cfs_wi_sched_t *)arg; + struct cfs_wi_sched *sched = (struct cfs_wi_sched *)arg; cfs_block_allsigs(); -- 2.1.0 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel