On Thursday 20 May 2010 09:48:29 am Greg KH wrote: > On Wed, May 19, 2010 at 08:34:02PM -0600, Steve McKown wrote: > > On Wednesday 19 May 2010 10:29:46 am Greg KH wrote: > > > On Wed, May 19, 2010 at 10:23:30AM -0600, R. Steve McKown wrote: > > > > On Tuesday 18 May 2010 08:01:09 pm you wrote: > > > > > On Tue, May 18, 2010 at 04:57:37PM -0600, Steve McKown wrote: > > > > > > On Tuesday 18 May 2010 08:55:39 am Greg KH wrote: > > > > > > > On Tue, May 18, 2010 at 08:44:59AM -0600, Steve McKown wrote: > > > > > > > - Set VID, PID and descriptors: product, serial, and device > > > > > > > version. > > > > > > > > > > You can dynamically change the vid and pid and stuff? Heh, that's > > > > > going to be fun to track :) > > > > > > > > Thankfully it takes some work to get valid VID/PID allocations, so I > > > > don't suspect a rash of new ones as a result of this driver. We just > > > > use the default VID/PID, even though we've toyed with getting our > > > > own. > > > > > > Oh, you have not seen what people do in the real world. I have a bunch > > > of devices here with a vid/pid of 0x0000/0x0000. And those are devices > > > you can go buy from the store today... > > > > Really? That's foretells some broad and unpleasant consequences... > > It actually works as these are usb class devices. Pretty funny at that, > a nice end-run around the usb.org group... > > > > Lots of companies set these fields to random values, do you really want > > > to make it easier for them to do this? :) > > > > No, I just want to set the descriptors when they must be set. > > I'm confused, when would someone set the descriptor? Usually this > happens at manufacturing time. Is that how you would be using this > feature? Yes; I'm sorry I haven't been clear on this point. We have our own hardware designs incorporating a cp210x. Each unit built needs its cp210x configured: descriptors and port configuration. I worked with SiLabs to glean enough information so I could add this functionality to the linux driver, since we don't use Windows in our shop. Of course, no user needs these features, and their post-mfg use would almost certainly prevent the device from operating properly. What are going to be the sticking points to adding such features to the driver? Based on our discussions thus far, I'm thinking that communicating this information via sysfs using packed structures with CRC might be the way to go. The binary structure would prevent the casual user from doing something like: echo 1234 | sudo tee /sys/blah/blah/VID but the programmatic interface would still be pretty clean. A companion userspace library for mfg use would provide a lib and sample program for setting descriptors and configurations via sysfs. Does this pass conceptual muster? > > > > [snip] > > > > We're getting farther from a patch having reasonable chance of inclusion, > > not closer. > > I don't think so at all. > > > AFAIK, only my company has shown any interest in such features under > > Linux. I don't think the effort to benefit ratio makes this a patch > > worth considering any longer; I'm disinclined to ask you to waste your > > valuable time. > > You're not wasting anyone's time, that's what we are here for. I also heard from another person suggesting these features might have a wider audience. Onward, then. ;) > > I think the gpio stuff would be great to have, if it uses the correct > kernel interface. This is still on my to-do list. All the best, Steve -- 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
