Re: [PATCH] staging: vme_user: Change slot number type from int to u32

[Dan Carpenter]

On Mon, Aug 26, 2024 at 05:18:57PM +0530, Riyan Dhiman wrote:
> >
> > Of course, there is a place for unsigned types in C but it's so subtle and
> > complicated to explain.  I think people wish that there was a way to make C
> > safer when there really isn't.  There is no easy answer like just declare
> > everything as u32.  It's a false hope.
> >
> 
> There is a function in the vme_user driver (vme.c:L715)
> 
> unsigned int vme_master_rmw(struct vme_resource *resource, unsigned int
> mask,
>    unsigned int compare, unsigned int swap, loff_t offset)
> {
> struct vme_bridge *bridge = find_bridge(resource);
> struct vme_master_resource *image;
> 
> if (!bridge->master_rmw) {
> dev_warn(bridge->parent, "Writing to resource not supported\n");
> return -EINVAL;
> }
> 
> if (resource->type != VME_MASTER) {
> dev_err(bridge->parent, "Not a master resource\n");
> return -EINVAL;
> }
> 
> image = list_entry(resource->entry, struct vme_master_resource, list);
> 
> return bridge->master_rmw(image, mask, compare, swap, offset);
> }
> EXPORT_SYMBOL(vme_master_rmw);
> 
> It is declared as unsigned everywhere but returns negative error codes.
> This is an issue,
>  right? How should it be fixed? Do we need to change all the function
> declarations to int,
> or just in this function, since bridge->master_rmw returns an unsigned int?

Easy answer: Just delete vme_master_rmw() because nothing uses it.

Complicated answer: So long as the caller is saving it to int then it will work
okay.  If it saves it to any other type then it will cause problems.

regards,
dan carpenter