> > > > Should those be static anyhow? Being USB, you could probably hook up two of > > > > those and want to operate one of them in this and the other one in another > > > > mode? > > > > > > You could. Whether or not you would is another question. Until then I > > > don't think it is worth bothering with such corner cases for the initial > > > merging of this driver. > > > > A static variable which should be per-device is a corner-case? Frankly, I'd > > think it is a flaw. Unless, of course, these module_params are only rarely > > used. Which would lead to the question if they are really needed. There are > > quite a lot. > > Given their name, I'd say they are there only for debugging purposes. > So yes, they probably are rarely used, which doesn't mean they're > useless. Same thing goes for maxfreq and nodma in mvsdio.c for example. OK, I still wonder if all eight of these debugging-aids really need exposure to all users. There is no documentation how and when to use them. But well... About the "static" thing: Yes, there are already drivers having one or more quirk parameters. That probably justifies it (personal taste aside). > > > Also, I am not convinced of the need of a custom sysfs-file. Seeing its use > > cases might help to identify a need which is probably better solved > > generically. > > I'm sure the author of this driver would be eager to hear from you with > a concrete suggestion. ? This is exactly why I asked for a use case? To see if something should be exposed from the core and not the driver? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
