On Thu, Jun 15, 2023 at 08:28:13PM +0530, Prashanth K wrote: > > > On 15-06-23 08:06 pm, Greg Kroah-Hartman wrote: > > On Thu, Jun 15, 2023 at 07:52:32PM +0530, Prashanth K wrote: > > > > > > In that case, can I resubmit v1 of this patch again, where I have used a > > > macro in usb-conn-gpio driver ? something like this. > > > > > > @@ -27,6 +27,8 @@ > > > #define USB_CONN_IRQF \ > > > (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT) > > > > > > +#define USB_ROLE_UNKNOWN (USB_ROLE_NONE -1) > > > > Are you referencing an existing enum here and assuming it is a specific > > value? > > I' not assuming UBS_ROLE_NONE to be a specific value, but I want an integer > (for macro) which is not equal to USB_ROLE_NONE/DEVICE/HOST, that's why I'm > using (USB_ROLE_NONE - 1), assuming enumerators NONE, DEVICE & HOST will be > having adjacent integer values. Wouldn't that help? You can't do "math" on an enumerated type and expect the result to be anything constant over time. And yes, you can hope that enumerated types are sequential, and the spec says so, but please never rely on that as what happens if someone adds a new one in the list without you ever noticing it. Pleasae treat enumerated types as an opaque thing that you never know the real value of, it's a symbol only. thanks, greg k-h
