On Thu, Jan 26, 2012 at 01:17:45PM -0500, Alan Stern wrote: > On Wed, 25 Jan 2012, Sarah Sharp wrote: > > > Somehow we ended up with duplicate hub feature #defines in ch11.h. > > Tatyana Brokhman first created the USB 3.0 hub feature macros in 2.6.38 > > with commit 0eadcc09203349b11ca477ec367079b23d32ab91 "usb: USB3.0 ch11 > > definitions". In 2.6.39, I modified a patch from John Youn that added > > similar macros in a different place in the same file, and committed > > dbe79bbe9dcb22cb3651c46f18943477141ca452 "USB 3.0 Hub Changes". > > > > Some of the #defines used different names for the same values. Others > > used exactly the same names with the same values, like these gems: > > > > #define USB_PORT_FEAT_BH_PORT_RESET 28 > > ... > > #define USB_PORT_FEAT_BH_PORT_RESET 28 > > > > According to my very geeky husband (who looked it up in the C99 spec), > > it is allowed to have object-like macros with duplicate names as long as > > the replacement list is exactly the same. However, he recalled that > > some compilers will give warnings when they find duplicate macros. It's > > probably best to remove the duplicates in the stable tree, so that the > > code compiles for everyone. > > > > The macros are now fixed to move the feature requests that are specific > > to USB 3.0 hubs into a new section (out of the USB 2.0 hub feature > > section), and use the most common macro name. > > > > This patch should be backported to 2.6.39. > > This is fine, but notice that some of the port status-change bits > have names that don't agree with the names in the USB-3.0 spec. For > example, we have USB_PORT_STAT_C_LINK_STATE, whereas the spec talks > about C_PORT_LINK_STATE. Mostly, I tried to follow the convention that the other USB hub macros used. > Do you want to change these names too, or do you not care about them? I don't really care either way. I just want to get rid of the duplicates for the stable tree, and we can rename them however we want in the next release. > Or does it seem redudant to include "_PORT" twice in the same name? > (Although you did just touch the definition of > USB_PORT_FEAT_C_PORT_LINK_STATE.) It looked like the convention was something like this: "USB_" if this bit is part of a port status request, "PORT_STAT_" else if this bit is part of a port set/clear feature request, "PORT_FEAT_" name of the bit in the USB specification. Following those rules, USB_PORT_STAT_C_LINK_STATE makes sense. As I said, I don't care about the name, but I'd really rather not bike shed this. :) Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
