On Mon, Feb 16, 2009 at 1:59 PM, Greg KH <greg@xxxxxxxxx> wrote: > > Put it on the logical device, as given to you. > >> I tried not to break existing functionality. Additionally, struct >> usb_xpad contains two device pointers: one to the actual USB device, >> and one to an input device (see source of the in-tree xpad.c). So I >> followed your kobject.txt documentation and samples to create a new >> object whose sole purpose in life is to expose the sysfs interface, >> without interfering with the existing device entries in the driver. >> I'm not sure I see a clean way to use a single struct device here.... > > Put it on the input device, which is what is the per-device thing. It's > much simpler than creating a new struct kobject. You can even create a > subdirectory for your attributes if you use an attribute group (which > you should be doing anyway, it's much simpler that way.) > OK, one thing I'm not clear on: is there a clean API for adding attributes to an existing struct device, or do I need to "subclass" it (the C containment and delegation approach)? This may take me a few days or a week or so, depending on how things go. It's dissertation proposal season.... > And document the attributes please. > Will do... still need to nail down what the interface should look like. > thanks, > > greg k-h > Thanks, Mike -- Mike Murphy Ph.D. Candidate and NSF Graduate Research Fellow Clemson University School of Computing 120 McAdams Hall Clemson, SC 29634-0974 USA Tel: +1 864.656.2838 Fax: +1 864.656.0145 http://cirg.cs.clemson.edu/~mamurph -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html