Hi, (please break your email at 80-characters, have a look at Documentation/email-clients.txt for tips about how to achieve that) On Tue, Mar 03, 2015 at 05:06:45PM +0000, Joao Pinto wrote: > Hello, > > I am sending this email in order to get some feedback from you about a > feature that I am planning to do in a driver I am working on. usually, an RFC comes with a patch implemeting (perhaps partialy) the feature you want comments on. Also, which driver you talking about ? which IP ? How are we supposed to provide any valid comments without knowing such details ? > This new feature basically is to turn the relationship between driver > and hardware IP more transparent, making the software more robust. transparent how ? PCI devices match against classes, product ids, vendor ids, etc. USB device match using similar techniques. How can something be more transparent than that ? > Let me explain the idea: > > a) The hardware has the capability of supplying to the driver the IP > version and crucial features that it support or not again, which HW ? Based on your email domain and the fact that you're Ccing linux-usb, I can only assume you talk about dwc2 because dwc3 already runtime-detects capabilities and versions. > b) The driver would read the hardware capability features and work > without hick-ups even if the developer has configured him (e.g. > menuconfig during build process) to do some specific thing that is not > supported by the current connected hardware this is really norm. Every good driver in the kernel today uses such capability registers to runtime-detect features and necessity for workaround to known errata. Look at drivers/usb/dwc3 for example. > c) If the driver is configured to do something that the connected > hardware is not capable of doing, it simply logs a message to kernel > log and automatically disables it trying to work has fluid as possible that's also norm and implement in many, many drivers. > d) If the hardware does not have the capability of supplying > information of this type to the driver, than it should work according > to the configuration also pretty much common sense. > In your opinion this feature would be a value-added to a new driver / > existent driver? it really dpeends. If you're talking about dwc3 we already do that, if you're talking about musb, then I'd NAK the patch because some implementations of MUSB have always-zero ConfigData, Revision and RAMbits which 100% hinders the possibility of runtime-detecting anything; if you're talking about dwc2, then it might be a very good patch worth looking over. DWC2's maintianer is a colleague of yours so perhaps, if you're really talking about that IP, Cc him ? As a general comment, make sure to always Cc maintainers and make extra clear which piece of HW you're talking about because, frankly, there are a ton of them. cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
